INC-001 Incident Response Plan
Description
A documented Incident Response Plan defines the organisation's approach to detecting, containing, eradicating and recovering from security incidents. The plan covers roles and responsibilities, communication channels, escalation paths and coordination with legal, regulatory and communications functions. Incident handling runs in a case management system that records each handling step against the incident, generates and routes the notifications the plan requires and makes the current plan, its runbooks, the contact list and the incident's state available to responders without depending on the systems under investigation. The plan is reviewed at least annually and after significant incidents.
Rationale
Without a documented plan, incident response is improvised, slow and legally exposed, and a current tested plan is the foundation of the whole capability. A response pieced together afterwards from a chat channel cannot show when escalation happened or whether a notification went out, so the plan has to run in a tool rather than on paper. Independence from the estate under investigation is the property that decides whether the tooling is available in the incident it was bought for.
Applicability (9 profiles)
Annex point 3.1.2(a) requires a categorisation system inside the policy that is consistent with the event assessment and classification under point 3.4.1, and point 3.1.3 requires the roles, responsibilities and procedures to be tested as well as reviewed. Point 3.5.3 adds a communication plan with the CSIRT or competent authority alongside the internal and stakeholder one.
Framework Mappings (21)
| SEF-01 | Security Incident Management Policy and Procedures | full |
| SEF-02 | Service Management Policy and Procedures | full |
| SEF-03 | Incident Response Plans | full |
| SEF-01 | Security Incident Management Policy and Procedures | full |
| SEF-02 | Service Management Policy and Procedures | full |
| SEF-03 | Incident Response Plans | full |
| HIPAA-164.308.a.1.i | Security Management Process | partial |
| HIPAA-164.308.a.6.i | Security Incident Procedures | full |
| HIPAA-164.308.a.6.ii | Response and Reporting | full |
| HIPAA-164.314.a.2.i.C | Business Associate Contract Security Incident Reporting Term | informative |
| 5.24 | Information security incident management planning and preparation | full |
| NIS2-Art.21.2.b | Incident Handling | full |
| NIS2-CIR-3.1 | Incident Handling Policy | partial |
| NIS2-CIR-3.5 | Incident Response | informative |
| IR-1 | Policy and Procedures | full |
| IR-4(1) | Incident Handling | Automated Incident Handling Processes | full |
| IR-6(1) | Incident Reporting | Automated Reporting | full |
| IR-7(1) | Incident Response Assistance | Automation Support for Availability of Information and Support | full |
| IR-8 | Incident Response Plan | full |
| GV-2.1-002 | AI Risk Roles and Responsibilities | GV-2.1-002 | partial |
| GV-6.2-003 | Third-Party Failure Contingency Processes | GV-6.2-003 | partial |
Evidence (3)
Documented Incident Response Plan covering roles, responsibilities, communication channels, escalation paths, and coordination with legal, regulatory, and PR functions.
Example: Incident Response Plan document (version-controlled, approved by CISO or equivalent senior owner, dated within the last 12 months) including RACI chart, communication tree, escalation criteria, and regulatory notification procedures
Test: Request the current IRP. Verify: (1) the plan defines roles and responsibilities with named owners or titles; (2) escalation paths cover at minimum: technical response, legal, PR/communications, and regulatory notification; (3) communication channels and contact lists are included; (4) the document was reviewed and approved within the last 12 months; (5) confirm the plan was updated following the most recent significant incident.
IRP review record confirming the plan was formally reviewed and approved within the last 12 months or following a significant incident.
Example: Document version history or review sign-off record for the IRP, showing last review date, reviewer, change summary, and approver sign-off
Test: Request the IRP version history and most recent review sign-off. Verify: (1) a formal review was conducted within the last 12 months; (2) a named approver with appropriate authority signed off the current version; (3) if a significant incident occurred in the review period, confirm the IRP was updated afterward.
Incident case management configuration showing the handling steps it records, the notification routes it generates and the responder access it provides.
Example: Incident platform configuration export, workflow and notification rules, 2026-08
Test: Export the incident case management configuration. Verify: (1) each phase the plan names has a matching step or state in the tool, (2) notification templates and recipient routes exist for each reporting obligation the plan carries, and at least one notification in the period was generated from them rather than written by hand, (3) the plan, runbooks and contact list are reachable from the tool by every responder role, (4) the tool and its content are hosted independently of the production estate a responder may have to isolate, (5) a closed incident in the period shows a complete step history rather than a single summary entry.
Questions (3)
Does your organisation have a documented incident response plan?
The IRP should be approved by the CISO or equivalent senior owner, version-controlled, and updated following significant incidents. A plan that has not been reviewed in over 12 months is considered stale.
Which functions are explicitly covered in your Incident Response Plan?
All six are expected in a mature IRP. Missing legal or regulatory escalation paths are a common gap that creates exposure during actual incidents.
Which of the following does your incident tooling do?
Options run from the most commonly in place to the least. Independence from the estate under investigation decides whether the tooling is available in the incident it was bought for, and it is the item most often taken for granted.