The NYDFS 72-Hour Cybersecurity-Event Notification Runbook

For a New York-regulated financial institution, the 72 hours after a cybersecurity event is not the time to figure out who decides what gets reported. Z Cyber builds and runs that decision machinery in advance, on the Glance platform, so the determination, the clock, and the filing all happen on a documented path rather than under improvisation.

Most regulated firms read Section 500.17 of 23 NYCRR Part 500 and assume the hard part is the filing itself. It is not. The filing takes minutes through the New York Department of Financial Services portal. The hard part is everything that has to be true before you file: knowing that an event qualifies, agreeing on when the clock started, assembling the facts, and proving later that you moved as promptly as the regulation demands. Z Cyber operates as a cybersecurity operating partner for institutions across financial services, which means we do not hand a client a template and walk away. We build the notification runbook, embed it in the incident response program, and run it alongside the client's team when an event actually lands.

What the NYDFS 72-hour rule actually requires

Under Section 500.17(a), a Covered Entity must notify the Superintendent of the Department of Financial Services as promptly as possible but no later than 72 hours after determining that a cybersecurity event has occurred, in two situations. The first is when notice of that event is required to be provided to any government body, self-regulatory agency, or other supervisory body. The second is when the event has a reasonable likelihood of materially harming any material part of the normal operations of the Covered Entity.

Read those triggers carefully, because they are broader than they first appear. The first trigger pulls in events you are already obligated to report elsewhere, whether to a primary federal regulator, a state agency, or an exchange. If you owe a notice to someone with authority over you, NYDFS wants one too. The second trigger is the judgment call: a reasonable likelihood of material harm to a material part of normal operations. That standard does not require confirmed harm, completed forensics, or a final scope. It requires a reasoned determination that the event could materially disrupt how the institution runs.

When the 72-hour clock starts, and why that matters

The clock runs from the determination that a qualifying cybersecurity event has occurred, not necessarily from the moment of first detection. That distinction is the single most consequential thing to get right, and the single most dangerous thing to get wrong.

It is consequential because the gap between detection and determination is where defensible compliance lives. A security operations center sees thousands of alerts. Not every alert is an event, and not every event is reportable. The regulation gives you room to investigate enough to make a reasoned determination. It is dangerous because a firm that drags out the determination to delay the clock is inviting exactly the scrutiny it hopes to avoid. The Department can and does ask how a determination was reached and when, and a timeline that looks engineered to push the 72-hour window will not hold up. The defensible posture is a determination process that is fast, documented, and consistent, so the clock starts when a reasonable security professional would say the threshold was met.

This is why Z Cyber treats the determination step as a named, owned function rather than a hallway conversation. In Glance, the platform we operate on a client's behalf, the event record captures who made the determination, on what facts, and at what timestamp. That record is the spine of the eventual filing and the firm's defense of its timing.

The extortion-payment rule most firms miss

The Second Amendment to Part 500, which began taking effect in late 2023, added Section 500.17(c) and created a second, tighter clock that many institutions overlook until they are inside an incident. A Covered Entity that makes an extortion payment in connection with a cybersecurity event must notify the Superintendent within 24 hours of making that payment. Then, within 30 days of the payment, the entity must provide the Department a written description of the reasons payment was necessary, a description of the alternatives to payment that were considered, all diligence performed to find those alternatives, and all diligence performed to ensure compliance with applicable rules, including sanctions-related obligations.

The practical trap here is that the extortion-payment obligations are separate from the 72-hour event notification, and they run on their own timetable. A ransomware incident can therefore generate two filings on two clocks: the 72-hour event notice under 500.17(a) once the event is determined, and the 24-hour payment notice under 500.17(c) if and when a payment is made. A runbook that only contemplates the 72-hour path will leave the 24-hour obligation uncovered at the worst possible moment, when leadership is mid-decision on whether to pay.

The notification runbook, step by step

A runbook is only useful if it assigns every action to a named owner and removes the ambiguity that costs hours. Below is the structure Z Cyber builds with clients and operates inside Glance, mapped to the roles that own each step.

Step	Action	Owner
1. Triage	Confirm a cybersecurity event has occurred and capture detection facts and timestamps.	SOC / IR lead
2. Reportability determination	Decide whether either 500.17(a) trigger is met and record who decided, on what facts, and when.	CISO + Legal
3. Start the clock	Log the determination timestamp as the 72-hour start and set the deadline.	CISO
4. Assemble the filing	Draft the portal submission with known scope, affected systems, and response status.	IR + Legal
5. File via portal	Submit through the DFS online portal within 72 hours and retain confirmation.	Legal / Compliance
6. Extortion-payment check	If a payment is made, file the 24-hour notice and prepare the 30-day written description.	CISO + Legal + Executive
7. Supplemental responses	Provide the additional information the Department requests as the investigation matures.	IR + Legal
8. Recordkeeping	Preserve the full timeline, determination rationale, filings, and confirmations.	Compliance

Roles: who actually does what under pressure

The most common failure mode is not a missing step. It is two people each assuming the other owns a step. The runbook only works if every role knows its lane before an incident, and if those lanes are rehearsed.

The CISO owns the security facts and, with Legal, owns the reportability determination. Legal owns the regulatory interpretation, the relationship with outside counsel, and the language of the filing. The incident response team owns scope, containment, and the technical narrative that feeds every submission. Communications owns internal messaging and any external statements, coordinating closely with Legal so nothing said publicly contradicts what is filed. And executive leadership owns the decisions that carry the institution's risk, most acutely the extortion-payment decision under 500.17(c). When Z Cyber runs a client's program, our forward-deployed team sits inside this structure, not adjacent to it, so the determination and the filing happen on the documented path even when the client's own staff is stretched thin.

Connecting the runbook to your broader Part 500 program

Section 500.17 does not stand alone. It is wired directly to the incident response plan and business continuity requirements in Section 500.16, which obligate Covered Entities to maintain plans that are reasonably designed to respond to and recover from cybersecurity events. A notification runbook that is not embedded in that incident response plan is a document, not a capability. The clock-start logic, the determination criteria, and the filing steps all belong inside the same plan the firm tests and maintains.

That integration is also where firms catch the gaps that a standalone runbook hides. Mapping the 72-hour and 24-hour clocks against the full Part 500 control set surfaces dependencies on logging, on access governance, and on the third-party service provider obligations that can themselves generate reportable events. Working through a structured NYDFS Part 500 compliance checklist alongside the runbook keeps the notification process anchored to the rest of the program rather than treated as an isolated legal exercise. For institutions that also handle consumer financial information, the same discipline carries over to overlapping obligations under the GLBA Safeguards Rule, where coordinated incident response avoids contradictory filings across regulators.

Why an operating partner beats a binder

Plenty of firms have a notification policy. Far fewer can prove, on the day of an incident, that the policy actually governs behavior. The difference is operational. A binder on a shelf does not start a clock, does not record a determination rationale, and does not file at hour 70 when the team is exhausted. An operating partner does. Z Cyber implements the runbook in Glance, runs tabletop exercises against it, and stands beside the client's CISO and Legal when a real event tests it. The deliverable is not a document you hope you read correctly under stress. It is a program that behaves the way the regulation expects, with the evidence to show for it.

The regulation rewards institutions that move promptly and document defensibly, and it punishes those that improvise. Building the runbook in calm conditions, embedding it in the Section 500.16 incident response program, and rehearsing the determination step is what separates a 72-hour deadline you meet cleanly from one you scramble to explain afterward.

This article is general information about 23 NYCRR Part 500, not legal advice. Confirm current requirements against the official text at dfs.ny.gov and consult counsel for your institution's specific obligations.