NYDFS section 500.16(a)(1) lists nine areas an incident response plan must address for different types of cybersecurity events, including ransomware: goals, internal processes, roles and decision authority, communications, remediation requirements, documentation, recovery from backups, root cause analysis, and updates to the plan.
This is general information, not legal advice.
The nine areas as a checklist
| # | Area in the rule | Engineering question |
|---|---|---|
| i | Goals of the plan | What are we protecting and what counts as recovered? |
| ii | Internal response processes | Who does what in the first hour? |
| iii | Roles, responsibilities, decision authority | Who can isolate a system or take a service offline? |
| iv | External and internal communications | Who tells leadership, customers, regulators and vendors? |
| v | Remediation of identified weaknesses | How do lessons become tickets? |
| vi | Documentation and reporting | Where is the timeline kept? |
| vii | Recovery from backups | Which backups, how long to restore, who approves? |
| viii | Root cause analysis | How and why it happened, business impact, prevention |
| ix | Updating the plan | When do we revise it? |
The rule says the plan addresses these areas with respect to different types of events, including disruptive events such as ransomware. A single generic page is unlikely to meet that wording.
Pieces beyond the plan itself
Section 500.16 adds several duties around the plan:
- Current copies must be accessible to the people who need them, including during an event. A plan stored only on the system that is down does not meet that goal.
- Employees who carry out the plan receive training on their roles.
- At least annually, the incident response and business continuity plans are tested with the staff and management critical to the response, and the ability to restore critical data from backups is tested.
- Backups needed to restore material operations are maintained and protected from unauthorized alteration or destruction.
Notice clocks sit next to the plan
Reporting duties live in section 500.17, including notice to the superintendent within 72 hours after determining that a cybersecurity incident has occurred. Your plan should show where that decision point sits and who makes it.
A short build order
- Draft the roles and the decision authority first. Most delays in real incidents are about who can decide.
- Add a contact tree that works offline.
- Write ransomware specific steps, including backup isolation.
- Define the root cause analysis template.
- Schedule the annual exercise and keep its record.
Mistakes to avoid
Plans often fail in predictable ways. The plan lives in a wiki that goes down with the incident. Contact lists are out of date. Roles name titles that no longer exist. Ransomware is mentioned in one sentence with no steps. And the annual test is a reading of the document rather than an exercise. Keep an offline copy, check contacts each quarter, name decision makers by role and by person, write ransomware steps, and run a scenario with a clock.
Quick check
Does the plan need a root cause analysis step?
Yes. Item viii requires preparation of a root cause analysis describing how and why the event occurred, the business impact, and what will be done to prevent reoccurrence.
How often must the plan be tested?
At a minimum annually, with the staff and management critical to the response, under 500.16(d).
Sources
- 23 NYCRR 500.16, Incident response and business continuity management
- 23 NYCRR 500.17, Notices to Superintendent
Last reviewed: 19 October 2026.
