A.5.26
Response to information security incidents
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Respond to information security incidents according to documented procedures, from detection through closure.
Points of focus
- Incidents are logged with timestamps for detection, containment, and resolution
- Response follows the defined roles and severity from the incident plan (A.5.24)
- Postmortems capture root cause and assign owners and due dates for corrective actions
- Notification decisions, such as customer or regulator, are documented, including the rationale when notification wasn't required
Implementation notes
Log incidents as they happen with timestamps at each stage — detection, containment, eradication, recovery, communication — using whatever ticketing system engineering already uses, rather than a separate compliance log that gets backfilled later. Write a short postmortem for anything above a defined severity, including near-misses, with a root cause and named owners for follow-up actions, and track those actions to closure the same way you'd track a bug. Document notification decisions explicitly, including the reasoning when you decide notification isn't required, since 'we didn't think it was serious enough' with no record looks identical to 'we forgot to check.' Route lessons learned back into the risk register and, where relevant, update the incident plan itself so the same gap doesn't recur.
Audit tip: Ask for the most recent incident or near-miss end to end, including the postmortem and whether every corrective action closed. A single well-documented example beats a long list of vague ticket titles.
Evidence auditors typically request:
- Incident tickets or postmortem docs showing the timeline: detected, contained, resolved, communicated
- At least one sample incident, or near-miss, tracing the full lifecycle with named responders
- Corrective action tracker showing postmortem follow-ups with owners and closure dates
- Notification record or decision log for whether customers or regulators were informed, with rationale
Common gaps
- Postmortems exist but corrective actions have no owner or due date, so they never close
- Only major incidents are logged; near-misses, such as a blocked attack or a caught misconfiguration, aren't captured, so the process looks untested
- Notification decisions aren't documented — no record of who decided a low-severity event didn't require customer notice
- Lessons learned from an incident aren't fed back into the risk register or the incident plan itself
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.5.26 | This control |
| SOC 2 | CC7.4, CC7.5 | CC7.4 covers response and CC7.5 covers recovery — a single well-documented incident with a clear timeline typically supports both criteria. |
| GDPR | Article 33 | If personal data was involved, the incident record should explicitly show whether the Article 33 threshold was assessed, even when the conclusion was that no notification was required. |
| HIPAA | 164.308(a)(6) | 164.308(a)(6) expects documented incidents and outcomes for anything touching PHI — treat PHI-adjacent incidents as a distinct, clearly labeled category in your log. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.5.26)