Incident Response Requirements Compared

Incident response is one of the five topics every framework requires. The plans look similar; the reporting deadlines don't. Here is how they compare.

This post covers the 11 frameworks ControlMapping mapped when it was written. Since then, DORA, CPS 234, Cyber Essentials were added on 2026-10-27; their pages and the coverage matrix include them.

Incident response is part of the common core: every framework we map requires it. The core requirement is the same everywhere: a plan, people who know their roles, and a way to detect, contain, recover and learn. The differences are in testing and, above all, in who you must tell, and how fast.

Who requires what

Framework	Incident Response	Link
NIST CSF 2.0	RS.MA-01 RS.MA-02 RS.MA-03 RS.MA-04 ID.IM-04	Topic definition
ISO 27001	A.5.24 A.5.25 A.5.26	Crosswalk
CIS v8.1	CIS 17.1 CIS 17.4 CIS 17.5 CIS 17.7 CIS 17.9	Crosswalk
SOC 2	CC7.4 CC7.3	Editorial
PCI DSS	12.10.1 12.10.3 12.10.2 12.10.4	Crosswalk
CMMC	IR.L2-3.6.1 IR.L2-3.6.3	Crosswalk
800-53	IR-4 IR-8 IR-2 IR-3	Crosswalk
HIPAA	§164.308(a)(6)§164.308(a)(6)(ii)	Crosswalk
GDPR	Art.33(1)Art.33(5)	Editorial
NIS2	3.1 3.5	Crosswalk
Essential Eight	ISM-1819	Editorial

Full detail and the reason for every link: Incident Response across frameworks →

The plan

Every framework expects a documented incident response capability: ISO 27001's incident management planning, assessment and response controls (A.5.24 to A.5.26), SOC 2's evaluation of and response to incidents (CC7.3, CC7.4), PCI DSS's incident response plan (12.10.1), CMMC's incident handling (IR.L2-3.6.1), HIPAA's security incident procedures (§164.308(a)(6)) and NIS2's incident handling policy and response (points 3.1 and 3.5). The content is consistent: roles, severity levels, escalation, containment, eradication, recovery and lessons learned.

Testing

PCI DSS is the only one with a fixed frequency: review and test the plan at least annually (12.10.2), and train the people who run it (12.10.4). CMMC and SP 800-53 require testing of the capability (IR.L2-3.6.3, IR-3) at a frequency you define. CIS asks for routine exercises (17.7). ISO 27001 and SOC 2 expect evidence that the plan works without setting a schedule; an annual tabletop is the usual answer.

Photograph of a small meeting room at night with open laptops, coffee cups, an erased whiteboard and a jacket over a chair — Most incidents don't happen during office hours, and the deadlines don't pause.

Reporting deadlines

This is where frameworks really differ:

Framework	Who you tell	Deadline
NIS2	CSIRT or competent authority	Early warning within 24 hours; notification within 72 hours; final report within one month
GDPR	Supervisory authority (personal data breaches)	Within 72 hours of becoming aware (Article 33)
GDPR	Affected people, when the risk to them is high	Without undue delay (Article 34)
CMMC / DFARS	US Department of Defense	Within 72 hours, under DFARS clause 252.204-7012
HIPAA	Affected individuals (Breach Notification Rule)	Without unreasonable delay, no later than 60 days
PCI DSS	Payment brands and acquirer	As each brand's procedures require (12.10.1)
ISO 27001, SOC 2	No regulatory deadline	Your plan and contracts decide

One incident can trigger several clocks at once. A ransomware attack on an EU cloud provider that stores personal data and handles card payments could start the NIS2, GDPR and payment-brand processes in the same hour.

Key takeaways

Every framework requires an incident response plan; the content is consistent.
Reporting deadlines differ sharply, from NIS2's 24 hours to HIPAA's 60 days.
One incident can start several clocks; one coordinator should own them all.

What to do

Write one plan that meets the strictest content requirements, and list every notification obligation that applies to you, with its deadline, recipient and owner.
Decide who judges significance. NIS2's 24-hour clock starts when you become aware of a significant incident; the decision can't wait for Monday.
Test it at least annually (PCI's rule is a good default), including an out-of-hours scenario.
Keep records of every incident and breach, notified or not: GDPR requires it (Article 33(5)), and every auditor will ask.

The Incident Response topic page lists every requirement with its source; the Reporting topic covers notification. Our NIS2 guide covers the reporting procedure in more detail.

Questions

What are the incident reporting deadlines under NIS2?

An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month.

How often must an incident response plan be tested?

PCI DSS requires review and testing at least annually (12.10.2). CMMC and SP 800-53 require testing of the incident response capability (IR.L2-3.6.3, IR-3). ISO 27001 and SOC 2 expect testing but leave the frequency to you.

Does ISO 27001 set an incident reporting deadline?

No. ISO 27001 requires incident management, including reporting events internally and responding, but no regulatory notification deadline. Deadlines come from law (NIS2, GDPR), contracts and sector rules.

Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.

Incident response requirements compared across frameworks