# 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*.

<!--
Guidance: How to use this template
- Use it after every incident that meets the review rule in the
  incident response plan (`compliance/incident-response-plan`, policy
  statement on post-incident reviews): every incident at the two highest
  severity levels and any incident with a novel cause or a missed
  detection. Consider adding every personal data breach to the rule.
  Near misses with a valuable lesson qualify too.
- Fill first: section 1 (facts) and section 3 (timeline) from the
  incident record in `isms/incident-register` (DOC-ISMS-021), the ticket
  and the logs, before the meeting. The meeting then spends its time on
  analysis, not on reconstructing what happened.
- Main pitfall: stopping at "human error". A person clicking a link is
  where the analysis starts, not where it ends. Ask why the system made
  the mistake easy and the damage large.
- The worked example throughout is INC-2027-001 at Quillmere Health
  Systems (medium tier): a support mailbox taken over through a phishing
  page that relayed the multi-factor login.
- 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/security-incident-report`,
  `compliance/personal-data-breach-assessment`,
  `compliance/capa-nonconformity`, `compliance/risk-register`,
  `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: One review document per incident. The Document ID identifies the document type; the review ID (PIR-YYYY-NNN) identifies this review. Classify the review at least as high as the incident record, because it describes weaknesses. -->

| 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](#1-incident-summary)
2. [Review ground rules](#2-review-ground-rules)
3. [Timeline](#3-timeline)
4. [Impact assessment](#4-impact-assessment)
5. [Response performance](#5-response-performance)
6. [Root cause analysis](#6-root-cause-analysis)
7. [What went well and what to improve](#7-what-went-well-and-what-to-improve)
8. [Actions](#8-actions)
9. [Control changes and risk register update](#9-control-changes-and-risk-register-update)
10. [Sharing the lessons](#10-sharing-the-lessons)
11. [Size tiers](#11-size-tiers)
12. [Records and evidence](#12-records-and-evidence)
13. [References](#13-references)

## 1. Incident summary

<!-- Guidance: Five to eight sentences a senior manager can read in one minute: what happened, when, what it affected, how it was stopped, and the headline lesson. Copy identifiers from the incident register so the records join up. Auditors check that the summary matches the register entry. -->

| 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

<!-- Guidance: Read these aloud at the start of the meeting. Blameless does not mean consequence-free for wilful misconduct; it means the review looks for system causes and that honest accounts are never used against the people who give them. State who attends and who decides. -->

The review follows these rules:

1. **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.
2. **Hindsight is named.** When someone says "should have", the
   facilitator asks what information was available at that moment.
3. **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 in
   `isms/security-event-reporting-procedure` (DOC-ISMS-023).
4. **Facts before opinions.** The timeline is agreed before the analysis
   starts. Disputed facts are marked and checked against logs.
5. **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

<!-- Guidance: One row per fact, in UTC, with its source. Include the attacker's first action when known, not only your own detection, so the detection gap is visible. Pitfall: a timeline that starts when the response team was paged. Auditors check that times match logs and the incident register. -->

| 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 |

```mermaid
flowchart LR
  A["Attack: phishing delivered 16:42"] --> B["Session captured 17:05"]
  B --> C["Attacker sign-in and forwarding rule 17:31"]
  C --> D["Alert queued 07:50"]
  D --> E["Staff report 09:12"]
  E --> F["Declared 10:05, T0"]
  F --> G["Contained 10:20"]
  G --> H["Controllers notified 17:10"]
  H --> I["Closed 2027-01-12"]
  I --> J["Review 2027-01-15"]
```

## 4. Impact assessment

<!-- Guidance: Describe impact against the same criteria used to set the severity, so the review can confirm or correct the level. Count what can be counted. Pitfall: writing "no impact" before the scoping is complete. -->

| 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

<!-- Guidance: Measure the response with the same definitions as the incident response plan metrics, so reviews can be compared over time. Compare with the targets in the plan or the severity matrix. -->

| 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

<!-- Guidance: Use at least two techniques: 5 whys for a causal chain and a fishbone (cause categories) for breadth. Stop a chain when you reach a cause the organisation can change and control. Expect more than one root cause. Auditors look for causes that lead to actions, not to "retrain the user". -->

### 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)

<!-- Guidance: Use the categories that fit your organisation. Mark each cause as contributing or root, and check that every root cause appears in section 8 with an action or a recorded decision. -->

```mermaid
flowchart LR
  P["People: realistic lure, normal workload end of week"] --> E["Effect: mailbox takeover with 16 h 49 min exposure"]
  R["Process: monitoring classification not re-reviewed"] --> E
  T["Technology: relayable push MFA, no device compliance check for support"] --> E
  D["Detection: medium alerts wait for business hours"] --> E
  S["Suppliers: mail filter did not flag a newly registered domain"] --> E
  G["Governance: MFA strength set by privilege only"] --> E
```

| 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

<!-- Guidance: Record both. Strengths are worth keeping on purpose, and teams that only hear about failures stop reporting. Each improvement point must map to an action in section 8 or a decision not to act. -->

| 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

<!-- Guidance: Each action has one owner, a due date, a priority and a link to a corrective action record where it addresses a nonconformity or control failure. Prefer actions that remove the cause (engineering, process) over actions that ask people to try harder. Track to closure and verify effectiveness, as clause 10.2 expects for corrective 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

<!-- Guidance: Show which Annex A controls the incident tested, whether each worked, and what changes. Update the risk register and the Statement of Applicability where implementation status changes. Auditors trace an incident to a changed control and a changed risk rating; this table is that trace. -->

### 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

<!-- Guidance: Decide who learns what. Share a short, anonymised version widely and the full review narrowly. Consider whether indicators should go to a sector ISAC or CSIRT through the contacts in `isms/authority-special-interest-contacts`. Pitfall: lessons that stay with the security team. -->

| 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

<!-- Guidance: Keep the review proportionate. The format is the same at every size; the depth, attendees and approvals change. These tiers are the library's working tiers, not official definitions. -->

| 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

<!-- Guidance: These records show that A.5.27 operates: incidents are reviewed, lessons become actions, and actions change controls. List this review in `isms/control-evidence-matrix` (DOC-ISMS-033) against A.5.27 and clause 10.2. -->

| 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

<!-- Guidance: Keep editions current and link only to official sources. -->

- 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.