Post-Incident Review Template (ISO/IEC 27001 A.5.27, ISO/IEC 27035)
Blameless security incident review: summary, ground rules, timeline, impact, response metrics, 5 whys, fishbone, actions, control changes, risk register update
ISMS và ISO/IEC 27001Đầy đủISO/IEC 27001:2022 + Amd 1:2024 A.5.27, clause 10.2 (cited only); ISO/IEC 27035-1:2023, 27035-2:2023postincidentreview
Cách dùng: Use it after every incident that meets the review rule in the incident response plan, and for near misses with a real lesson. Fill the facts and the timeline from the incident register and logs before the meeting, so the meeting spends its time on analysis. The main pitfall is stopping at human error instead of asking why the system made the mistake easy and the damage large.
Xem trước
Post-Incident Review: [Incident ID and short title]
A blameless review format for information security incidents: facts, timeline, impact, root cause analysis (5 whys and fishbone), what went well, what to improve, actions, control changes and the update to the risk register. It supports ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.5.27 (learning from incidents), the lessons-learned phase of the incident management process described in ISO/IEC 27035-1:2023, and improvement under clause 10. Replace every
[bracketed]value and every row marked Example.
Document control
| Field | Value |
|---|---|
| Document ID | DOC-ISMS-022 |
| Review ID | [PIR-YYYY-NNN] (Example: PIR-2027-001) |
| Incident ID | [INC-YYYY-NNN] (Example: INC-2027-001) |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Actions closed] |
| Owner (review facilitator) | [@facilitator] |
| Approvers/reviewers | [@isms-manager], [@incident-commander], [@system-owner] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024 (A.5.27, A.5.24 to A.5.28, clause 10.2); ISO/IEC 27035-1:2023; ISO/IEC 27035-2:2023 |
| Severity and category | [SEVn, CAT-nn] (Example: SEV3, CAT-02 account or credential compromise) |
| Review meeting date | YYYY-MM-DD |
| Next scheduled review | [Action follow-up date, YYYY-MM-DD] |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Review facilitator | [@facilitator] | [Prepared] | YYYY-MM-DD |
| Incident commander | [@incident-commander] | [Facts confirmed] | YYYY-MM-DD |
| ISMS manager | [@isms-manager] | [Approved, actions accepted] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@facilitator] | Facts and timeline drafted before the meeting |
| 1.0 | YYYY-MM-DD | [@facilitator] | Analysis and actions agreed in the review meeting |
| [x.y] | YYYY-MM-DD | [@author] | [Action status update or closure] |
Contents
1. Incident summary
| Field | Value |
|---|---|
| Incident ID and title | [INC-YYYY-NNN, title] (Example: INC-2027-001, support mailbox takeover through relayed login) |
| Detected | [YYYY-MM-DD HH:MM UTC, source] (Example: 2027-01-09 07:50, identity protection alert) |
| Declared (awareness time, T0) | [YYYY-MM-DD HH:MM UTC] (Example: 2027-01-09 10:05) |
| Contained | [YYYY-MM-DD HH:MM UTC] (Example: 2027-01-09 10:20) |
| Closed | [YYYY-MM-DD] (Example: 2027-01-12) |
| Affected services and assets | [Asset IDs from compliance/asset-inventory] (Example: one support mailbox, customer support process) |
| Information security properties affected | [Confidentiality / Integrity / Availability] (Example: confidentiality) |
| Personal data involved | [Yes / No, categories, role as controller or processor] (Example: yes, names and work contact details of hospital staff, processor role) |
| Notifications made | [Regime, recipient, time] (Example: two hospital customers as controllers, 2027-01-09 17:10) |
| Review rule that applies | [Severity / personal data / novel cause / missed detection] (Example: personal data breach and a delayed detection) |
Example summary: on 2027-01-08 a phishing e-mail reached 14 support engineers at Quillmere Health Systems. One engineer signed in on a page that relayed the login, including the multi-factor step, to the real identity provider, and the attacker captured the resulting session. The attacker used the session from a hosting provider address at 17:31, created a forwarding rule and forwarded 37 messages to an external address. An identity protection alert fired the next morning and a colleague reported the same e-mail. The incident was declared at 10:05 and contained 15 minutes later. Nine forwarded messages held names and work contact details of hospital staff; the two affected hospitals were informed the same day as controllers. The main lesson is that the multi-factor method in use for support staff can be relayed, and that medium alerts waited for business hours.
2. Review ground rules
The review follows these rules:
- Blameless. The aim is to understand how the system allowed the incident, not who to blame. People describe what they saw, knew and did at the time, and why it made sense then.
- Hindsight is named. When someone says "should have", the facilitator asks what information was available at that moment.
- Separate from discipline. Statements made in this review are not
used in any disciplinary process. Wilful or malicious conduct, if
suspected, is handled separately under
isms/security-disciplinary-process(DOC-ISMS-052) with its own evidence, consistent with the no-blame rule inisms/security-event-reporting-procedure(DOC-ISMS-023). - Facts before opinions. The timeline is agreed before the analysis starts. Disputed facts are marked and checked against logs.
- Every lesson becomes an action or a recorded decision. A lesson with no owner and no due date is not recorded as learned.
| Attendee role | Why present | Example |
|---|---|---|
| Facilitator (not involved in the response) | Runs the meeting neutrally | Security team analyst from another rotation |
| Incident commander | Owns the facts of the response | Security operations lead |
| Responders | Give first-hand accounts | On-call analyst, identity administrator |
| System or process owner | Owns most actions | Head of customer support |
| Privacy lead or DPO | Breach and notification view | Privacy lead |
| ISMS manager | Links actions to the ISMS records | ISMS manager |
| Person who reported or was targeted (optional, by consent) | First-hand account | Support engineer, by invitation only |
3. Timeline
| Time (UTC) | Event | Source | Phase |
|---|---|---|---|
| 2027-01-08 16:42 (Example) | Phishing e-mail with a fake document-sharing link delivered to 14 support engineers | Mail gateway log | Attack |
| 2027-01-08 17:05 (Example) | One engineer enters credentials and completes the multi-factor prompt on the relay page; session token captured | Identity provider sign-in log | Attack |
| 2027-01-08 17:31 (Example) | Sign-in with the captured session from a hosting provider address; inbox forwarding rule created | Identity provider and mailbox audit logs | Attack |
| 2027-01-08 17:31 to 2027-01-09 10:20 (Example) | 37 messages forwarded to an external address | Mailbox audit log | Attack |
| 2027-01-09 07:50 (Example) | Identity protection raises a medium "anomalous token" alert; queued for business-hours review | Security monitoring platform | Detect |
| 2027-01-09 09:12 (Example) | A second support engineer reports the e-mail with the report button | Event report SER-2027-0011 | Detect |
| 2027-01-09 09:40 (Example) | Analyst links the report to the alert and to the forwarding rule | Ticket | Assess |
| 2027-01-09 10:05 (Example) | Incident declared, SEV3, CAT-02; awareness time T0 recorded | Incident register INC-2027-001 | Assess |
| 2027-01-09 10:20 (Example) | Sessions revoked, password reset, forwarding rule removed, sender domain blocked | Ticket, admin audit log | Respond |
| 2027-01-09 13:30 (Example) | Scoping complete: 37 messages forwarded, 9 with personal data of hospital staff, no patient data | Analyst notes | Respond |
| 2027-01-09 15:00 (Example) | Privacy lead assesses a personal data breach in the processor role | compliance/personal-data-breach-assessment PDB-2027-001 | Respond |
| 2027-01-09 17:10 (Example) | Two hospital customers notified as controllers | Notification log | Respond |
| 2027-01-10 11:00 (Example) | Phishing e-mail purged from the other 13 mailboxes; sign-in review finds no other compromised account | Ticket | Respond |
| 2027-01-12 16:00 (Example) | Incident closed after 72 hours of monitoring with no further activity | Incident register | Close |
| 2027-01-15 (Example) | Post-incident review meeting (3 working days after closure) | This document | Learn |
4. Impact assessment
| Dimension | Assessment | Example |
|---|---|---|
| Confidentiality | What information left our control, how much, how sensitive | 37 messages forwarded; 9 contained names, job titles and work phone numbers of 23 hospital staff; no patient data, no credentials |
| Integrity | What was changed without authorisation | One forwarding rule created; no other changes found |
| Availability | Which services were degraded and for how long | None |
| Customers and contracts | Contractual notifications, service credits, customer trust | Two hospitals informed under the data processing agreement; no service credit |
| Legal and regulatory | Regimes assessed and outcome | GDPR: processor duty to inform controllers without undue delay met; the controllers assessed their own Art. 33 duty. NIS2: assessed as not significant |
| Financial (Example, use local currency) | Direct cost of response | USD 4,800: USD 3,600 internal staff time (48 hours at USD 75) plus USD 1,200 external review of mailbox logs |
| Severity check | Was the declared severity right? | SEV3 confirmed |
5. Response performance
| Measure | Definition | Result (Example) | Target (Example) | Met? |
|---|---|---|---|---|
| Time to detect | First unauthorised access to first detection | 14 h 19 min (17:31 to 07:50) | Under 1 h for identity alerts | No |
| Time to declare | First detection to declaration | 2 h 15 min (07:50 to 10:05) | Under 30 min | No |
| Time to contain | Declaration to containment | 15 min (10:05 to 10:20) | Under 4 h at SEV3 | Yes |
| Total exposure | First unauthorised access to containment | 16 h 49 min | As short as possible | Not a target |
| Notification timeliness | Declaration to controllers informed | 7 h 5 min (10:05 to 17:10) | Within 24 h by contract | Yes |
| Report to declaration | Staff report to declaration | 53 min (09:12 to 10:05) | Under 1 h | Yes |
The figures show that containment and notification worked; detection and declaration did not. The review therefore concentrates its root cause analysis on why the attack succeeded and why detection waited.
6. Root cause analysis
6.1 Problem statements
Analyse each distinct failure separately. Example:
- P1: An attacker could use a phished session to access a support mailbox.
- P2: The first alert waited 1 hour 50 minutes before an analyst looked at it (2 hours 15 minutes to declaration), after the attacker had already had access for over 14 hours.
6.2 Five whys
| Step | P1: access succeeded (Example) | P2: detection waited (Example) |
|---|---|---|
| Why 1 | The attacker held a valid session token for the engineer's account | The alert was rated medium and went to the business-hours queue |
| Why 2 | The relay page passed the engineer's login, including the push approval, to the real identity provider | Alert severity rules rate token anomalies as medium unless the account is privileged |
| Why 3 | Push-based multi-factor authentication can be relayed; phishing-resistant methods were deployed for administrators only | Support accounts were not classed as sensitive, although they hold customer contact data |
| Why 4 | The rollout plan treated support staff as low risk and the shared support desktops did not support security keys | The account classification for monitoring was set in 2025 and not reviewed when the support role changed |
| Why 5 (root cause) | The authentication standard set method strength by privilege, not by the data a role can reach | No trigger re-reviews monitoring classifications when roles or data access change |
6.3 Fishbone (cause categories)
| Category | Cause | Type (Example) |
|---|---|---|
| People | Lure imitated the real document-sharing notice; sent late on a Friday | Contributing |
| Process | Monitoring classification not re-reviewed after role change | Root (P2) |
| Technology | Push multi-factor method can be relayed; sessions not bound to a compliant device | Contributing |
| Detection | Medium identity alerts not reviewed outside business hours | Contributing |
| Suppliers | Mail filtering did not flag a domain registered two days earlier | Contributing |
| Governance | Authentication standard ties method strength to privilege only | Root (P1) |
6.4 Contributing factors that made it worse or better
- Worse (Example): the forwarding rule ran overnight; external forwarding was not blocked by default.
- Better (Example): the report button and a fast human report linked the alert to a real attack; the mailbox audit log was enabled and retained, so scoping was exact.
7. What went well and what to improve
| ID | What went well (Example) |
|---|---|
| WW-01 | The second engineer reported within minutes of reading the e-mail, as trained |
| WW-02 | Containment took 15 minutes from declaration, using the credential compromise playbook in security/soc-playbook |
| WW-03 | Mailbox audit logs gave an exact list of forwarded messages, so notification named the real data, not a guess |
| WW-04 | The privacy lead joined within 5 hours of declaration and the controllers were informed the same day |
| ID | What to improve (Example) | Action |
|---|---|---|
| TI-01 | Support staff use a multi-factor method that can be relayed | ACT-01 |
| TI-02 | Medium identity alerts wait for business hours | ACT-02 |
| TI-03 | External automatic forwarding is allowed by default | ACT-03 |
| TI-04 | Monitoring classification of accounts is not re-reviewed on role change | ACT-04 |
| TI-05 | Awareness content does not show relay-style login pages | ACT-05 |
| TI-06 | Newly registered domains are not quarantined | Decision D-01 |
8. Actions
| Action ID | Action | Addresses | Owner | Due | Priority | CAPA link | Effectiveness check | Status |
|---|---|---|---|---|---|---|---|---|
| ACT-01 (Example) | Extend phishing-resistant authentication (security keys or platform passkeys) to every role with access to customer data; replace shared desktops that cannot support it | P1 root cause, TI-01 | [@identity-lead] | 2027-04-30 | High | CAPA-2027-003 | Sign-in report shows 100% of support sign-ins with phishing-resistant methods for 30 days | Open |
| ACT-02 (Example) | Route medium identity alerts on accounts with customer data access to the 24x7 on-call analyst | P2, TI-02 | [@security-operations-lead] | 2027-02-28 | High | CAPA-2027-004 | Monthly test alert acknowledged within 30 minutes outside business hours | Open |
| ACT-03 (Example) | Block automatic external forwarding by default; allow by exception through security/security-exception-request | TI-03 | [@it-lead] | 2027-01-31 | High | none (configuration change CHG-2027-018) | Quarterly configuration check finds no unapproved forwarding | Open |
| ACT-04 (Example) | Add "data access changed" as a trigger for monitoring classification review in the joiner, mover and leaver process | P2 root cause, TI-04 | [@isms-manager] | 2027-03-31 | Medium | CAPA-2027-005 | Next quarterly access review samples 10 movers and finds classification reviewed | Open |
| ACT-05 (Example) | Add a relay-login example to awareness training and the next phishing simulation | TI-05 | [@awareness-lead] | 2027-03-31 | Medium | none | Simulation report rate at or above the last campaign | Open |
Decisions not to act are recorded with the reason and the risk owner's acceptance:
| Decision ID | Topic | Decision and reason (Example) | Accepted by | Date |
|---|---|---|---|---|
| D-01 (Example) | Quarantine of newly registered domains | Not adopted now: trial in 2026 blocked hospital customers' new domains. Residual risk is covered by ACT-01, which removes the value of a stolen session | Head of IT (risk owner) | 2027-01-15 |
9. Control changes and risk register update
9.1 Controls tested by the incident
| Control | Short label | Worked? (Example) | Change (Example) |
|---|---|---|---|
| A.5.17 | Authentication information handling | Partly: the credential itself was not reused elsewhere, but the session was captured | ACT-01 |
| A.8.5 | Secure authentication | No: method was relayable for this role | ACT-01; update the authentication rule in isms/access-control-policy (DOC-ISMS-041) |
| A.8.16 | Monitoring activities | Partly: alert fired, response delayed | ACT-02, ACT-04; update isms/security-monitoring-procedure (DOC-ISMS-064) |
| A.6.3 | Awareness, education and training | Partly: one click, one fast report | ACT-05 |
| A.6.8 | Reporting security events | Yes | None |
| A.5.26 | Responding to security incidents | Yes: contained in 15 minutes | None |
| A.5.28 | Evidence collection | Yes: logs preserved and exported with hashes | None |
| A.5.34 | Privacy and PII protection | Yes: controllers informed the same day | None |
9.2 Risk register update
Use the 5 x 5 scale from compliance/risk-methodology (DOC-ISMS-010):
score = likelihood x impact; Low 1-4, Medium 5-9, High 10-16,
Critical 17 to 25 (in practice 20 and 25).
| Risk ID | Risk | Before incident | After incident (current) | Target after actions | Owner |
|---|---|---|---|---|---|
| RISK-014 (Example) | Account takeover of staff with customer data access through phishing | L2 x I4 = 8, Medium | L4 x I4 = 16, High (likelihood raised: the attack worked) | L2 x I4 = 8, Medium after ACT-01 and ACT-02 | [@head-of-it] |
| RISK-022 (Example) | Delayed detection of identity attacks outside business hours | Not in register | L3 x I4 = 12, High (new risk) | L2 x I3 = 6, Medium after ACT-02 | [@security-operations-lead] |
Because RISK-014 and RISK-022 are now High, top management reviews the
treatment decision as required by the risk acceptance rule, and the
treatment is added to compliance/risk-treatment-plan (DOC-ISMS-013).
If a control's implementation status changes, update the
compliance/statement-of-applicability (DOC-ISMS-011) entry and its
evidence reference.
9.3 Document updates
| Document | Change (Example) | Owner |
|---|---|---|
compliance/incident-response-plan (DOC-ISMS-020) | Add the relay-login pattern to the credential compromise category notes | Incident response plan owner |
security/soc-playbook | Add check for inbox rules and session revocation as step one | Security operations lead |
isms/access-control-policy (DOC-ISMS-041) | Method strength set by data reach, not only by privilege | Policy owner |
10. Sharing the lessons
| Audience | What they receive | Channel | When (Example) |
|---|---|---|---|
| All staff | Two-paragraph anonymised story, what to look for, thanks to the reporter (with consent) | Staff newsletter | Within 2 weeks |
| Support team | Walk-through of the lure and the new sign-in method | Team meeting | Within 1 week |
| ISMS steering committee | Summary, actions, risk changes | Committee pack (isms/isms-steering-committee-charter) | Next meeting |
| Management review | Trend input: incident counts, lessons, action status | compliance/management-review input | Next review |
| Sector ISAC or CSIRT | Sender domain, relay page address, other indicators | Agreed sharing channel, under its sharing rules | Within 48 hours, if agreed |
| Affected customers | Summary of root cause and actions, if requested | Account manager | On request |
11. Size tiers
| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites) |
|---|---|---|---|
| Who facilitates | Head of Engineering Operations (0.5 FTE ISMS manager), or a peer from engineering if they led the response | A security team member not involved in the response | A trained facilitator pool in the 14-person security office; site leads join for site incidents |
| Reviews per year (Example) | 2 to 4, one combined meeting of 60 minutes each | 8 to 12, 90 minutes each | 30 or more, with a quarterly cross-site lessons review |
| Root cause depth | 5 whys on the main failure | 5 whys plus fishbone for each problem statement | Full method, plus OT-specific causes (safety, plant availability) at the 3 plants |
| Approval | ISMS manager and CEO for High risk changes | ISMS manager; top management for High risk changes | CISO; group risk committee for High and Critical risk changes |
| Integration | Actions in the engineering backlog with a CAPA tag | CAPA register and risk register | Integrated management system: same corrective action process as ISO 9001 and ISO 22301 |
12. Records and evidence
| Record | Owner | Location (Example) | Retention (Example) |
|---|---|---|---|
| This review (approved version) | Facilitator, then ISMS manager | ISMS document store, linked from the incident register | Certification cycle plus 1 year (at least 4 years), longer if litigation or regulatory inquiry is open |
| Timeline sources (log exports with hashes) | Security operations lead | Evidence store under security/forensic-evidence-record | As set for the incident's evidence |
| Actions and corrective actions | Action owners, ISMS manager | compliance/capa-nonconformity records | 3 years after closure |
| Risk register change | Risk owner | compliance/risk-register history | Per risk register retention |
| Lessons summary for management review | ISMS manager | compliance/management-review inputs | With the review minutes |
What an auditor typically samples: the incident register entry, this review, at least one action traced to a changed control and its effectiveness check, and the matching risk register change.
13. References
- ISO/IEC 27001:2022 + Amd 1:2024 (A.5.24 to A.5.28, clause 10.2): https://www.iso.org/standard/82875.html and https://www.iso.org/standard/88435.html
- ISO/IEC 27002:2022: https://www.iso.org/standard/75652.html
- ISO/IEC 27035-1:2023, incident management principles and process: https://www.iso.org/standard/78973.html
- ISO/IEC 27035-2:2023, guidelines to plan and prepare for incident response: https://www.iso.org/standard/78974.html
- NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025)
- Related templates:
compliance/incident-response-plan(DOC-ISMS-020),isms/incident-register(DOC-ISMS-021),isms/security-event-reporting-procedure(DOC-ISMS-023),dev/postmortem,security/soc-playbook,compliance/personal-data-breach-assessment,compliance/capa-nonconformity(DOC-ISMS-087),compliance/risk-register(DOC-ISMS-016),isms/control-evidence-matrix(DOC-ISMS-033)
Standard and licence note
Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (Annex A control A.5.27 and clause 10.2) and the lessons-learned phase of ISO/IEC 27035-1:2023. Clause and control numbers are cited with original short labels only; no ISO or IEC text is reproduced, and you need the official standards to implement and audit these requirements. NIST SP 800-61 Rev. 3 is a US government work. The review format, analysis method and worked example are original. Check the current editions before use.
Template licence: MIT.
Template liên quan
ISMS và ISO/IEC 27001
Incident Register Template (ISO/IEC 27001 A.5.24 to A.5.28)
Event and incident register: field rules, category and regime codes, register rows, GDPR, NIS2 and DORA notification tracking, status lifecycle, period summary
ISMS và ISO/IEC 27001Independent Security Review Checklist Template (ISO/IEC 27001 A.5.35, A.5.36)
Review programme and triggers, reviewer independence, ISMS approach checklist, manager and technical compliance checklists, ratings, reporting, size tiers
ISMS và ISO/IEC 27001Access Control Policy Template (ISO/IEC 27001 A.5.15)
Access principles, role catalogue, joiner mover leaver SLAs, MFA and NIST SP 800-63B-4 password rules, privileged and service accounts, reviews, metrics