ISO 27001 Incident Response Policy Template: The 6 Annex A Controls, the NIS2 Notification Gap, and a Free Skeleton

Most organizations that reach for an ISO 27001 incident response policy already have some version of an incident plan sitting in a wiki or a shared drive — something IT wrote after the last outage, aimed at getting systems back online. An ISO 27001 auditor is not testing that document. They’re testing whether your policy maps to six specific Annex A controls, whether you can produce evidence that the process has actually been run — not just written — and whether the last incident, real or simulated, changed anything in your ISMS afterward.

This guide covers exactly which Annex A controls an incident response policy needs to satisfy, how ISO 27001’s incident-management requirements differ from NIS2’s fixed 24-hour/72-hour/one-month notification clock under Article 23 — a distinction that trips up many NIS2-compliant organizations writing their first ISO 27001 policy — what an auditor actually checks for at Stage 2, and a free mini policy skeleton you can use today.

The 6 Annex A Controls an Incident Response Policy Must Cover

ISO/IEC 27001:2022’s incident-management requirements aren’t scattered loosely across Annex A — they sit in one tight cluster of six controls: five Organizational controls, A.5.24 through A.5.28, plus one People control, A.6.8, that feeds the whole process from the front line. [1][2][3] A policy that addresses “detection and response” only in general terms, without mapping explicitly to all six, is one of the most common reasons an incident response policy gets flagged during Stage 1 documentation review.

Control	Title	What the policy has to specify
A.5.24	Information security incident management planning and preparation	Roles, responsibilities, and a defined process for planning and preparing to handle incidents before one happens [1]
A.5.25	Assessment and decision on information security events	Criteria for classifying a reported event as an incident, and who has authority to make that call [3]
A.5.26	Response to information security incidents	The actual containment, eradication, and recovery procedure, following the documented plan [3]
A.5.27	Learning from information security incidents	How findings feed back into risk treatment, controls, and future incident planning [3]
A.5.28	Collection of evidence	Procedures for identifying, collecting, and preserving evidence for potential disciplinary, legal, or forensic use [3]
A.6.8	Information security event reporting	A simple, judgement-free channel for any employee to report a suspected event — the input the other five controls depend on [2]

Note that A.6.8 sits in the People theme, not the Organizational theme where the other five live — it’s easy to miss if you draft the policy by working straight down the Organizational-controls section of Annex A. [2] Auditors treat it as part of the same incident-management cluster regardless of which theme it’s filed under, because reporting is the trigger that starts the whole process.

How This Differs From NIS2’s Incident Handling and Article 23 Notification Regime

If your organization built its NIS2 incident-handling procedure first, it’s tempting to assume ISO 27001’s incident controls simply formalize the same 24-hour/72-hour/one-month reporting clock. They don’t — and getting this backward is one of the most common points of confusion for NIS2-compliant organizations writing their first ISO 27001 policy.

NIS2 Article 21(2)(b) requires “incident handling” as one of ten mandatory risk-management measures. [4] Article 23 then layers a separate, specific notification duty on top: essential and important entities must send an early warning to their CSIRT or competent authority within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours with an initial severity and impact assessment, and a final report no later than one month after the notification. [5] Those deadlines are a statutory clock running to an external regulator, with a separate penalty regime for missing them.

ISO 27001 has no equivalent of that clock anywhere in the standard. A.5.24 through A.6.8 require you to plan for, detect, assess, respond to, and learn from incidents, and A.5.28 requires evidence collection, but none of the six controls names a reporting deadline to any external body — because ISO 27001 has no regulator to report to in the first place. [1][2][3] Certification is voluntary and the standard’s audience is your own ISMS, not a supervisory authority. External reporting obligations only exist to the extent a law like NIS2, GDPR, or a sector-specific regulation imposes them on you separately, alongside your ISO 27001 programme rather than as part of it.

	ISO 27001 (A.5.24-A.5.28, A.6.8)	NIS2 (Articles 21(2)(b) and 23)
What’s required	A documented process: planning, event reporting, assessment, response, evidence collection, lessons learned	Incident handling as a risk-management measure, plus a separate notification duty
External reporting deadline	None specified by the standard itself [1][2][3]	24-hour early warning, 72-hour notification, one-month final report to a CSIRT or competent authority [5]
Who checks compliance	An accredited certification body, at audit and surveillance intervals	A national competent authority, against the statutory clock above
Consequence of a gap	Nonconformity raised at audit; certificate withheld or suspended	Separate penalty regime for missed or late notification [5]

In practice, one incident-management process can satisfy both: run the ISO 27001-structured process across A.5.24-A.5.28 and A.6.8 as your internal engine, and treat NIS2’s 24-hour/72-hour/one-month deadlines as an additional external output your process triggers whenever an incident meets NIS2’s significant-incident threshold. Building the ISO process on top of an existing NIS2 procedure is usually additive, not a rebuild — see our full NIS2 vs ISO 27001 comparison for the control-by-control mapping between the two frameworks.

What an Auditor Actually Wants to See

A written policy that has never been tested is, to an auditor, indistinguishable from a policy that doesn’t work. Certification bodies scoring A.5.24-A.5.28 and A.6.8 during Stage 2 are not primarily reading policy prose — they’re checking for three specific things, in this order.

1. A documented process, not just a policy statement. The policy needs to name who classifies an event (A.5.25), who has authority to respond (A.5.26), and where evidence is stored and for how long (A.5.28) — specific roles and specific steps, not “the security team will respond appropriately.”
2. Evidence that the process has actually run. This is the gap that fails the most first-time audits. A policy with zero incident records and zero exercise history reads as untested, regardless of how well the document itself is written. At minimum, an auditor wants to see either a real incident, however minor — a phishing click, a lost laptop, a misdirected email — or a simulated one, logged in an incident register with dates, actions taken, and who was involved.
3. A closed loop back into the ISMS. A.5.27 exists specifically to require this: what changed in the risk assessment, the control set, or the policy itself as a direct result of the incident or exercise. An incident record that stops at “resolved,” with no documented lessons-learned entry, doesn’t satisfy A.5.27 on its own.

If you’ve already run a NIS2 tabletop exercise or incident simulation, that same evidence — attendance, scenario, findings, corrective actions — largely satisfies A.5.24 and A.5.27’s testing expectations too; there’s no need to run a separate exercise purely for the ISO audit. Our internal audit checklist covers how to self-test this control cluster before an external auditor does.

Free Mini Incident Response Policy Skeleton

Below is a condensed starting point — not the full policy a certification audit expects, but a genuinely usable outline covering the required elements. Use it to see the shape of the document before deciding how much you want to build yourself versus adapt from a pre-written version.

Purpose
To ensure that information security events are identified, assessed, and responded to consistently, and that the organization learns from every incident to reduce the likelihood and impact of recurrence.

Scope
This policy applies to all employees, contractors, and third parties with access to the organization’s information systems, and covers any suspected or confirmed information security event affecting the confidentiality, integrity, or availability of those systems or the data they hold.

Policy Statements

• All personnel must report suspected or observed information security events through the designated reporting channel as soon as they are noticed, with no requirement to diagnose or investigate first (A.6.8).
• A named role is responsible for triaging every reported event and deciding, against documented criteria, whether it constitutes an information security incident (A.5.25).
• A documented response procedure — covering containment, eradication, and recovery — must be followed for every confirmed incident, with actions and timestamps logged (A.5.26).
• Roles, escalation paths, and required tools must be defined and reviewed before an incident occurs, not improvised during one (A.5.24).
• Evidence relevant to an incident must be identified, collected, and preserved in a way that maintains its integrity for potential disciplinary, legal, or forensic use (A.5.28).
• Every closed incident must be reviewed for lessons learned, with resulting changes to risk treatment, controls, or this policy tracked to completion (A.5.27).

Role	Responsibility
Incident Response Lead	Triages reported events, decides incident status, authorizes response actions
All Personnel	Report suspected events promptly through the designated channel
Information Security Manager / ISMS Owner	Reviews lessons learned and updates risk treatment and controls
Management	Reviews significant incidents and approves resulting policy or resource changes

Review Cadence
This policy is reviewed at least annually, and immediately following any significant incident or major change to the organization’s systems or risk profile.

Where This Fits in Your Wider ISO 27001 Programme

An incident response policy doesn’t stand alone — it’s cross-referenced by your Statement of Applicability, tested during internal audits, and often overlaps operationally with business continuity planning once an incident escalates into a longer disruption. If you’re building this policy as part of a first-time certification push, our ISO 27001 compliance guide covers the full clause structure, Annex A overview, and roadmap this policy fits into. If you’re here because your organization is already NIS2-compliant and evaluating whether ISO 27001 is worth pursuing next, our guide to that decision covers the business case and where the real 20-30% gap sits beyond incident management. And where this policy’s response procedure hands off into a longer operational disruption, our business continuity policy template covers what happens next.

FAQ

Which Annex A controls does an ISO 27001 incident response policy need to cover?
Six controls, verified against the current 2022 control set: A.5.24 (planning and preparation), A.5.25 (assessment and decision), A.5.26 (response), A.5.27 (learning from incidents), A.5.28 (collection of evidence), and A.6.8 (event reporting). [1][2][3]

Does ISO 27001 require reporting incidents to a regulator within 24 or 72 hours?
No. That fixed clock comes from NIS2’s Article 23, not from ISO 27001. [5] ISO 27001’s Annex A controls require a documented internal process for handling and learning from incidents, but the standard itself sets no external notification deadline to any authority.

If we already have a NIS2 incident handling procedure, do we need a separate one for ISO 27001?
Not usually a separate one — an extension of it. NIS2’s Article 21(2)(b) incident handling requirement and ISO 27001’s A.5.24-A.5.28 and A.6.8 cluster cover the same underlying activity; the ISO version typically needs more explicit role definitions, evidence-handling detail, and a documented lessons-learned loop than a NIS2-only procedure usually includes. [4]

What’s the fastest way to fail this part of a Stage 2 audit?
Having a well-written policy with no incident register, no exercise record, and no lessons-learned entries behind it. Auditors treat an untested policy as unverified, regardless of how complete the document reads.

Does using a documentation toolkit guarantee we pass this part of the audit?
No. A toolkit can give you a pre-written policy, incident log, and notification forms structured around the right Annex A controls, but certification itself is only granted after an accredited certification body’s Stage 1 and Stage 2 audit of your actual, operating process — documentation prepares you for that audit, it doesn’t replace it.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] ISO 27001:2022 Annex A Control 5.24 Explained, ISMS.online
• [2] ISO 27001:2022 Annex A Control 6.8 Explained, ISMS.online
• [3] ISO 27001:2022 – A.5 Organisational Controls (Incident Management), URM Consulting
• [4] NIS 2 Directive, Article 21 — Cybersecurity risk-management measures, nis-2-directive.com (verbatim mirror of Directive (EU) 2022/2555)
• [5] NIS 2 Directive, Article 23 — Reporting obligations, nis-2-directive.com (verbatim mirror of Directive (EU) 2022/2555)