NYDFS Part 500 Ransomware and Extortion Payment Reporting: The 24-Hour Playbook

If your firm decides to pay a ransom, NYDFS gives you 24 hours to tell the superintendent and 30 days to prove the decision was defensible. Neither clock is survivable if you start thinking about the answer after the encryption has already happened.

Section 500.17 of the NYDFS cybersecurity regulation (23 NYCRR Part 500) does something most incident-reporting rules do not: it reaches past the breach itself and into the payment decision. Since the notification provisions took effect on 1 December 2023, a covered entity that makes an extortion payment in connection with a cybersecurity event has to report that payment within 24 hours and, within 30 days, file a written justification of why it paid. This is not a security-team obligation. It is a board-level decision with a regulatory evidence trail attached, and firms that treat it as an IT matter discover the gap at the worst possible moment.

The two clocks, and which one people miss

There are three time limits in play, and they are commonly confused. Section 500.17(a) requires notice to the superintendent as promptly as possible but no later than 72 hours after you determine a cybersecurity incident has occurred. That is the well-known one, and I have written separately about engineering the evidence trail behind the 72-hour notification.

The extortion-payment duties sit in Section 500.17(c) and run on a different trigger. Under 500.17(c)(1), if the covered entity makes an extortion payment, it must give notice of that payment within 24 hours of the payment — not of the incident. Under 500.17(c)(2), within 30 days of the payment it must provide a written description of the reasons payment was necessary, the alternatives to payment that were considered, all diligence performed to find those alternatives, and all diligence performed to ensure compliance with applicable rules and regulations.

Read that carefully. The 24-hour clock starts when the money moves. If your legal, finance and executive functions spent three days debating whether to pay, none of that counts against the clock — but all of it needs to be documented, because it becomes the 30-day justification. The regulator is not just asking whether you paid. It is asking you to show your working.

Why the decision cannot be improvised

The payment decision in a live ransomware event is made under conditions engineered by the attacker to remove your judgement: a countdown timer, systems down, staff exhausted, a threat to leak or destroy data. Deciding who is even allowed to authorise a payment in that environment is a governance failure waiting to happen. I have set out the underlying tension in the payment and disclosure dilemma; here the point is narrower and operational. The decision rights have to exist on paper before the incident, or they will be improvised during it.

A workable pre-agreed decision framework names, in advance:

• Who authorises an extortion payment — typically a named executive or committee with a defined monetary threshold above which the board or a designated director must approve.
• Who must be consulted before authorisation: legal counsel, the CISO, the money-laundering reporting officer or equivalent, and outside counsel or an incident-response retainer.
• Who performs and signs off the sanctions check before any payment is made.
• Who owns the notification to NYDFS and the assembly of the 30-day file.

None of this is exotic. It is the difference between a decision you can defend and a decision that happened because a mid-level manager panicked and wired cryptocurrency to keep the business running.

Inside the 24-hour clock

Once payment is authorised and made, the runbook for the following 24 hours is short and should be mechanical:

1. Record the exact timestamp of the payment. This is the start of the clock, so it is the single most important fact to capture accurately.
2. File the extortion-payment notice through the NYDFS portal within 24 hours. Treat this as separate from, and additional to, any 72-hour incident notice already filed.
3. Preserve the payment record — wallet address, amount, chain, exchange or broker used, and the counterparty demand — in a form that will survive to the 30-day filing and any later supervisory follow-up.
4. Open the 30-day justification file immediately, while the reasoning is fresh, rather than reconstructing it a month later from memory.

The mistake to avoid is treating the 24-hour notice as the end of the obligation. It is the announcement. The substantive test is the 30-day file.

The 30-day file, and the sanctions trap inside it

The written description required by 500.17(c)(2) has four parts, and each needs contemporaneous evidence rather than after-the-fact narrative. Why payment was necessary: the operational impact, the state of your backups, the recovery time you faced without paying. The alternatives considered: restoration from backup, rebuilding, accepting data loss, the advice you took. The diligence to find alternatives: who you asked, what they said, when. And the diligence to ensure compliance with applicable rules — which is where the sanctions exposure lives.

Paying a ransom to a person or group on a US sanctions list is a violation in its own right, regardless of the NYDFS filing. The “diligence performed to ensure compliance with applicable rules and regulations” is, in practice, your OFAC screening: the check that the wallet, the group and the ransomware variant are not sanctioned, and the record of that check with a name and a timestamp. A payment made without that screening documented is doubly exposed — once to NYDFS for an unjustified payment, and once to the sanctions regime for the payment itself. This is the same trap firms face under the emerging US federal reporting regime; I have written about building the muscle for it in the context of CIRCIA’s incident and ransom-payment reporting.

Who owns this before anything happens

The uncomfortable answer is that no single function owns it cleanly, which is exactly why it falls through the cracks. Security owns detection. Legal owns the sanctions and regulatory analysis. Finance owns the mechanics of moving the money. The board owns the accountability. The extortion-payment playbook is the document that binds those four together with named roles and a rehearsed sequence, tested in a tabletop exercise where someone actually has to say the words “I authorise this payment” and the sanctions officer actually has to produce a clearance.

Run that rehearsal now, in daylight, with the lawyers in the room. The alternative is running it for the first time at 3am with a countdown timer on the screen and a regulator’s 24-hour clock already ticking.