An ISO 27001 incident response plan is the documented, tested process — required under Annex A 5.24 through 5.28 — for detecting, assessing, containing, communicating, and recovering from information security incidents, with evidence that the process actually runs rather than sitting in a drawer. Enterprise and healthcare buyers now ask for this evidence before signing: the global average cost of a data breach reached a record $4.99 million in 2026, up 12% year over year according to IBM's 2026 Cost of a Data Breach Report, and procurement teams now treat a vendor's incident response maturity as a hard gate, not a nice-to-have.
This guide is for CISOs, CTOs, founders, and compliance leads at midmarket and startup companies — particularly fintechs with license obligations, healthcare vendors handling PHI, and companies selling into enterprise accounts. It draws on Konfirmity's experience across 6,000+ security audits and 25+ years of combined expertise to show what auditors and buyers actually check, not just what the standard says on paper.
Key Takeaways: ISO 27001 Incident Response Plan Requirements
- Annex A 5.24 through 5.28 together require a documented, risk-based incident management process: planning and preparation, event assessment, response, learning, and evidence collection.
- A certificate alone proves nothing to a buyer — auditors and enterprise security teams both look for evidence the plan actually operated: incident logs, investigation reports, communication records, and test results.
- A severity classification (commonly P1 through P4) drives response time, escalation, and notification requirements; ISO 27001 doesn't mandate this exact scheme, but Annex A 5.25 requires organizations to assess and classify events by severity.
- Recovery is inseparable from business continuity — the plan must integrate with backup, disaster recovery, and RTO/RPO commitments, not treat data restoration as a separate problem.
- A tested, documented plan is a sales asset: it shortens security questionnaires, reduces follow-up questions, and directly affects deal velocity for regulated buyers.
Why Mature Incident Response, Not Just a Certificate, Matters
Enterprise buyers have learned that a framed certificate without continuous operation behind it protects nobody. They expect evidence of mature detection, escalation, containment, communication, and recovery — not a policy binder. Business disruption and customer churn make up the largest share of breach costs industry-wide, and breaches now routinely take weeks or months to fully resolve, so buyers specifically look for vendors who can limit downtime and communicate clearly during a crisis.
For healthcare vendors handling PHI, a mishandled incident isn't just a lost deal — it can trigger HIPAA breach notification obligations directly. For fintechs, a sponsor bank or regulator reviewing incident history expects to see a tested process, not a template. Auditors inspect incident logs, communication records, and corrective actions specifically to judge whether an organization operates its controls or merely documents them.
What an ISO 27001 Incident Response Plan Is
An ISO 27001 incident response plan is the document and process an organization uses to prepare for, detect, assess, respond to, recover from, and learn from information security incidents. It lives inside the wider Information Security Management System (ISMS) that ISO 27001 mandates, and its purpose is to minimize damage and restore service by defining roles, workflows, and communications in advance of needing them.
Plan versus Process
The plan is the written document: mission, scope, definitions, severity levels, and procedures. The incident management process is the ongoing operational workflow — monitoring, detection, escalation, response, recovery, and post-incident review — executed using playbooks, not improvised in the moment. Both have to align. One of the most common findings Konfirmity sees is a plan drafted for certification that was never operationalized: the document exists, but nobody has run it, tested it, or updated it since.
ISO 27001 Requirements: Annex A 5.24 Through 5.28
ISO 27001:2022 splits incident management into five Annex A controls, each covering a distinct stage of the lifecycle. Auditors check each one separately — a plan that only addresses response and skips evidence collection or lessons-learned will draw a finding even if the response procedures themselves are solid.
Annex A 5.24: Information Security Incident Management Planning and Preparation
The organization plans and prepares for managing information security incidents by defining, establishing, and communicating incident management processes, roles, and responsibilities. This is the foundational control: without it, nothing downstream has an owner.
Annex A 5.25: Assessment and Decision on Information Security Events
The organization assesses information security events and decides whether to categorize them as information security incidents. This is where severity classification lives — see the P1–P4 model below.
Annex A 5.26: Response to Information Security Incidents
Information security incidents are responded to in accordance with documented procedures. Ad hoc response, even if effective, does not satisfy this control on its own — the response has to trace back to a documented playbook.
Annex A 5.27: Learning From Information Security Incidents
Knowledge gained from information security incidents is used to strengthen and improve information security controls. A root cause analysis that never updates a policy or a risk register is incomplete in an auditor's eyes.
Annex A 5.28: Collecting Incident Evidence
The organization establishes and implements procedures for the identification, collection, acquisition, and preservation of evidence related to information security events. This control matters beyond the audit itself — evidence collected properly is what supports legal action, insurance claims, and regulatory notifications if an incident escalates.
Beyond Annex A, incident response threads through the main clauses too: Clause 6 (Planning) requires incident response to be part of risk treatment, Clause 9 (Performance evaluation) requires monitoring and evaluating incidents, and Clause 10 (Improvement) covers the corrective action that Annex A 5.27 also demands.
Incidents That Fall Under ISO 27001 Scope
ISO 27001 defines an incident as an event that compromises the confidentiality, integrity, or availability of information — anything from a minor policy violation to a full-scale breach. The plan needs categories and severity levels to help the team prioritize rather than treating every event identically. Common examples Konfirmity sees classified inside ISMS scope:
- Data breach and data leakage — unauthorized access to personal or proprietary data; exfiltration via unsecured APIs, misconfigured cloud storage, or insider abuse.
- Unauthorized access — compromised credentials, privilege escalation, or authentication bypass.
- Malware and ransomware — infection via phishing, supply-chain compromise, or drive-by download; encryption of data with a ransom demand.
- Service outages tied to security events — DDoS attacks, or a crash triggered by active exploitation.
- Third-party and supplier incidents — a breach at a vendor that exposes your data, or a vendor outage that affects your service.
Scope this broadly enough to catch what matters, but not so broadly that minor issues swamp the team — that's what severity classification is for.
Core Components of an ISO 27001 Incident Response Plan
Roles and Ownership
Roles and ownership are the foundation every other component depends on: an incident response manager owns the process end to end, with authority to declare an incident and coordinate the response. The team typically includes security engineering, IT operations, legal counsel, communications, and — for healthcare — a privacy officer, with a senior executive (often the CISO) providing sponsorship and final approval. For every role, define duties, on-call schedules, backup contacts, and decision authority in writing; "everyone knows who does what" is not evidence an auditor accepts.
Incident Classification and Severity Levels
Once an event is detected, it needs to be classified so the response is proportional. A common, defensible model uses four tiers:
| Severity | Definition | Response Time | Escalation |
|---|---|---|---|
| P1 — Critical | Severe business impact: confirmed data breach, full outage, active ransomware | Immediate (minutes) | Executive team, legal, PR on-call |
| P2 — High | Significant but contained impact: partial outage, confirmed unauthorized access to non-critical systems | Within 1 hour | Incident response manager, CISO |
| P3 — Medium | Affects non-critical systems, no confirmed data exposure | Within 4 hours | Security engineering, asset owner |
| P4 — Low | Minor, no material impact: policy violation, blocked attack attempt | Within 1 business day | Logged, reviewed periodically |
ISO 27001 does not mandate this exact P1–P4 scheme, but Annex A 5.25 requires organizations to assess and classify events by severity, and auditors expect the classification to visibly drive response time and escalation — not just exist as a label.
Response Procedures
Response procedures document the step-by-step actions for each incident type and severity level: verify the incident, contain it (isolate affected systems, revoke credentials), preserve evidence, notify stakeholders, eradicate the threat, recover systems, and formally close the incident. This mirrors the widely used lifecycle of preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. Specify who executes each step, what approvals are required, and when to loop in third parties — cloud providers, an incident response retainer, or law enforcement.
Communication Plan
Communication has to be timely, accurate, and matched to the audience. Internally: the incident response team, leadership, and any affected departments. Externally: pre-approved templates for customer notification that already account for legal and contractual review, so nothing goes out ad hoc during a live incident. Define channels, spokespersons, and escalation points in advance — deciding who talks to the press during an active P1 incident is too late to figure out communication roles.
Legal and Regulatory Considerations
Legal and regulatory considerations intersect with a wide set of obligations. HIPAA's Security Rule requires policies to identify and respond to incidents, mitigate harm, and document outcomes. GDPR requires notifying supervisory authorities within 72 hours of becoming aware of a personal data breach, and affected individuals where there's high risk to their rights. Contracts frequently impose stricter timelines than the regulatory floor. Work with legal counsel ahead of time to interpret these obligations, coordinate with insurance, and pre-decide when to involve law enforcement — not during the incident itself.
Recovery Plan and Business Continuity
Recovery is more than restoring data: it means validating system integrity, confirming the underlying vulnerability is actually patched, and verifying business operations are fully functional again. The plan should integrate with recovery time objectives (RTOs) and recovery point objectives (RPOs) defined elsewhere in your ISMS, not treat them as a separate document. For the full disaster recovery and business continuity plan requirements under ISO 27001, see our ISO 27001 business continuity and DR guide. For backup-specific requirements, see our ISO 27001 backup and recovery guide.
An incident response plan that works is a security asset, not a compliance box.
Share your work email and we'll help you build a response plan auditors and enterprise buyers both trust.
Step-by-Step: How to Build an ISO 27001 Incident Response Plan
- Define scope and objectives. Identify which systems, data types, services, and vendors the plan covers, aligned with the ISMS scope (Clause 4.3) and the risk treatment plan. Set concrete objectives — maximum acceptable outage, notification timelines — not vague aspirations.
- Identify risks and likely incident scenarios. Use your existing risk assessment to map technical threats, process failures, and supplier risks to specific response actions. Healthcare organizations should model PHI exposure scenarios explicitly; fintechs should model payment fraud and data theft.
- Create clear response workflows. Build a decision tree or playbook per incident category: detection through closure, escalation criteria, containment strategy, evidence collection, and third-party involvement, aligned to any contractual SLAs.
- Assign roles and train the team. Document responsibilities, then run role-specific training, tabletop exercises, and simulations so the team has actually rehearsed the plan before a real incident forces them to improvise it.
- Document, review, and approve. Produce the formal plan, version-control it, and get sign-off from senior management. Cross-reference related policies (access control, change management, business continuity), and schedule a review at least annually or after any significant incident.
Testing, Monitoring, and Continuous Improvement
A plan that has never been tested is a hypothesis, not a control. Run tabletop exercises to simulate scenarios and evaluate communication and decision-making, and periodic live simulations — failing over to backup systems, restoring from backup — to test the technical procedures for real. Track metrics that matter: incident frequency, mean time to detect, mean time to contain, mean time to recover, and recurrence rate, and feed them back into the ISMS to update risk assessments and control design. After every real incident, run a retrospective specifically to identify root cause and implement corrective action — this is what Annex A 5.27 is checking for.
Common Mistakes Companies Make
From auditing thousands of incident response programs, the same mistakes companies make recur:
- Treating incident response as a one-time document. Teams draft a plan to pass an audit, then forget it. Months later roles have changed, new systems exist, and the plan no longer reflects reality.
- Overly technical plans nobody can actually follow. A plan that reads like a system manual is unusable mid-crisis. Keep it clear and actionable — who, what, when, how — for a non-technical stakeholder as much as an engineer.
- Weak communication planning. Plans that stop at the IT team ignore legal, HR, PR, and customer success, who are just as critical during a live incident. Inconsistent or delayed external messaging damages trust and can itself violate a notification obligation.
- Failing to link incidents back to risk management. Lessons from an incident should update the risk register and justify control investment. Skipping this step means repeating the same mistake at the next incident.
What Auditors Look For During ISO 27001 Audits
Auditors assess documentation and evidence of execution together — expect them to request:
- Incident logs — records of events, detection times, classification, actions taken, and closure, showing incidents are tracked consistently rather than ad hoc.
- Investigation reports and root cause analyses for significant incidents, including lessons learned and corrective actions taken.
- Communication records showing notifications to stakeholders and customers met contractual and regulatory timelines.
- Test results from tabletop exercises and live simulations, including who participated and what was found.
- Corrective actions and policy updates — proof that incidents actually changed a policy, a control, or a risk assessment, not just got logged and closed.
Red flags that trigger findings: a plan with no evidence it's ever been tested, incident logs missing severity classification, delayed notifications, or a repeated incident type with no remediation trail.
Free template
The ISO 27001 Incident Response Plan & Severity Matrix Template
A ready-to-adapt plan, the P1-P4 severity matrix from above with response times built in, and a fully worked incident log showing exactly what auditors expect in each field. Enter your work email and we'll send the PDF.
How a Strong Incident Response Plan Supports Enterprise Sales
A mature incident response program directly shortens security review. During vendor risk assessment, a vendor who can answer questions about breach history, notification timelines, and recovery procedures with specifics — not generalities — moves through review faster. Konfirmity's clients typically report completing security questionnaires around 50% faster once the plan and its evidence exist and are current, which compounds into faster procurement and fewer stalled deals. Konfirmity is a security-driven compliance platform: run it self-serve, or add the fully managed service and a dedicated team implements the incident response process, runs the tabletop exercises, and keeps the evidence current, so teams spend under 70 hours a year on compliance instead of hundreds of internal hours.
See how your incident response plan holds up
Book a demo and we'll map your current incident process against what ISO 27001 auditors and enterprise security teams actually check.
Book a demo
Frequently Asked Questions
Yes. ISO 27001:2022 requires organizations to plan and prepare for incidents, and Annex A control 5.24 specifically requires a formal incident management process. Without it, you cannot claim conformity — and beyond compliance, the plan is what actually protects customer data and trust when something goes wrong.
P1 through P4 is a common severity-based incident classification. P1 (critical) incidents cause severe business impact — a confirmed data breach or full outage — and require immediate response. P2 (high) incidents have significant but contained impact. P3 (medium) incidents affect non-critical systems. P4 (low) incidents are minor with no material impact. ISO 27001 doesn't mandate this exact scheme, but Annex A 5.25 requires organizations to assess and classify events by severity.
Any event that compromises the confidentiality, integrity, or availability of information within the ISMS scope qualifies — data breaches, unauthorized access, malware infections, service outages caused by attacks, and third-party incidents. Minor policy violations may be treated as security events until severity is assessed; a risk-based classification determines which events require the full incident response process.
Ownership typically sits with the incident response manager or CISO, who maintains the plan and coordinates activity. Execution is cross-functional: IT operations handles system recovery, security engineering analyzes and contains the threat, legal manages regulatory obligations, communications leads external messaging, and executives make high-level calls. Assign this explicitly in the plan and back it with training — a role nobody has rehearsed isn't really assigned.
At least annually, and after any significant change to systems or the organization. Tabletop exercises and live simulations are the standard way to surface weaknesses before a real incident does. Some organizations test quarterly for critical systems — testing frequency should scale with your risk profile and any contractual testing obligations.
No. ISO 27001 is an internationally recognized, certifiable standard for building and operating an information security management system (ISMS). SOC 2 is an attestation report on the design and operating effectiveness of an organization's controls. Many companies pursue both, since they cover overlapping but distinct requirements and serve different buyer audiences.
A commonly used framework organizes incident response around five C's: Containment (limiting impact through rapid isolation), Communication (keeping stakeholders aligned with clear updates), Coordination (making sure the right people handle the right tasks), Compliance (preserving audit trails and meeting standards like SOC 2 and ISO 27001), and Continuous Improvement (running blameless retrospectives). ISO 27001 doesn't name this exact framework, but it maps closely to Annex A 5.24 through 5.28.
A widely used model is Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned, and Continuous Testing. ISO 27001 doesn't name these exact seven stages, but Annex A 5.24 through 5.28 cover the same ground: planning and preparation, assessment, response, learning, and evidence collection.
Incident logs with timestamps and severity classification, investigation reports with root cause analysis, communication records, corrective actions, test reports, and proof of management review. Auditors also check that the plan itself is versioned, approved, and reviewed periodically — evidence of continuous improvement after real incidents or tests is what separates a working control from a filed document.
Conclusion
Building an ISO 27001 incident response plan is not a compliance task — it's a business asset. Enterprises and regulators now expect proof that vendors can detect, contain, and recover from incidents, not a certificate alone. A mature plan integrates with risk management and business continuity, assigns clear roles under Annex A 5.24, classifies severity under 5.25, executes documented response under 5.26, learns from every incident under 5.27, and preserves evidence under 5.28. For companies selling to enterprise clients, that combination accelerates sales, reduces renewal friction, and protects the relationships that took years to build.
