Incident response plan: the clause the question tests
Whether there is a written, tested plan for handling a security incident.
How the customer usually asks it
example"Do you have a documented incident response plan, and when was it last tested?"
Anchor clauses
8 frameworks| Framework | Anchor clause |
|---|---|
| ISO/IEC 27001:2022 | 5.24 Information security incident management planning and preparation · 5.26 Response to information security incidents |
| SOC 2 (Trust Services Criteria) | CC7.4 Responds to identified security incidents through defined procedures |
| SIG (Shared Assessments) | domain J Cybersecurity Incident Management |
| CSA Cloud Controls Matrix v4.0.1 | SEF-03 Incident Response Plans |
| NIST Cybersecurity Framework 2.0 | RS.MA-01 The incident response plan is executed in coordination with relevant third parties once an incident is declared |
| NIST SP 800-53 Rev 5 | IR-8 Incident response plan |
| PCI DSS v4.0.1 | 12.10.1 Incident response plan |
| HIPAA Security Rule (45 CFR 164) | 164.308(a)(6)(i) Security Incident Procedures (Standard) |
Every framework that anchors this family is listed here; a register shows the ones ticked for the customer.
Evidence expected
The incident response plan with roles and escalation, the record of the last test or tabletop exercise, and a closed incident record as a sample.
The clauses, with what an assessor asks for
ISO 27001 5.24 Information security incident management planning and preparationDefine incident roles, processes and readiness before an incident happens.
Where answers usually fall short: Roles are defined but not formally assigned or approved; Plans are outdated and lack version control
Source: ISO/IEC 27001:2022
ISO 27001 5.26 Response to information security incidentsRespond to incidents according to the documented procedures.
Where answers usually fall short: Plans not tested regularly; Incident logs incomplete or inconsistent
Source: ISO/IEC 27001:2022
SOC 2 CC7.4 Responds to identified security incidents through defined proceduresNamed, not quoted: the criteria text is not held in full here.
Where answers usually fall short: A response plan exists but no incident record shows it was followed; Containment recorded while the vulnerability that allowed the incident stays open
Source: SOC 2 (Trust Services Criteria)
SIG domain J Cybersecurity Incident ManagementWhat it asks for, in one line (the standard's own text is not quoted here):
Maintain an incident response capability with defined plans, classifications, escalation paths, communications protocols, evidence handling, lessons learned, and regulatory and customer notification procedures.
Where answers usually fall short: No tabletop exercises within 12 months; Customer notification timelines not tracked
Source: SIG (Shared Assessments)
CSA CCM SEF-03 Incident Response PlansWhat it asks for, in one line (the standard's own text is not quoted here):
Maintain an approved security incident response plan that names the internal departments, affected cloud customers and business-critical relationships such as the supply chain that may be drawn in.
Where answers usually fall short: Plan names internal teams only, leaving customer and supplier involvement undefined; Superseded versions still in circulation
Source: CSA Cloud Controls Matrix v4.0.1
NIST CSF RS.MA-01 The incident response plan is executed in coordination with relevant third parties once an incident is declaredThe incident response plan is executed in coordination with relevant third parties once an incident is declared
Where answers usually fall short: Retainer in place but contact path untested; Coordination with law enforcement absent
Source: NIST Cybersecurity Framework 2.0
SP 800-53 IR-8 Incident response planRequires an incident response plan that sets the roadmap and structure for the capability, fits it to the organization, defines reportable incidents and success metrics, defines the resources and management support needed, is approved by defined personnel, distributed to defined recipients, reviewed on a defined frequency, updated for change and lessons learned, and protected from unauthorized disclosure and modification.
Where answers usually fall short: Plan defines severity levels but never defines what counts as a reportable incident; Plan stored only on the system it is meant to help recover
Source: NIST SP 800-53 Rev 5
PCI DSS 12.10.1 Incident response planWhat it asks for, in one line (the standard's own text is not quoted here):
An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident, covering roles, responsibilities, communication, containment, and recovery.
Where answers usually fall short: IRP stale; Roles unassigned
Source: PCI DSS v4.0.1
HIPAA 164.308(a)(6)(i) Security Incident Procedures (Standard)Implement policies to address security incidents. NIST recommends an incident response plan aligned to NIST SP 800-61 with detection, analysis, containment, eradication, and recovery phases.
Where answers usually fall short: Plan exists but not exercised; Roles ambiguous during real incident
Source: HIPAA Security Rule (45 CFR 164)