3.5 Organizational Controls: Incident Management & Evidence (A.5.24–A.5.28)
Key Takeaways
- A.5.24 requires planning and preparation for information security incident management, including roles, procedures, and communication paths before incidents occur.
- A.5.25 and A.5.26 separate event assessment/decision-making from incident response actions so organizations escalate only confirmed incidents with appropriate severity.
- A.5.27 requires learning from incidents and near-misses to strengthen controls, playbooks, and risk assessments after events close.
- A.5.28 requires processes to identify, collect, acquire, and preserve information that can serve as evidence, maintaining chain of custody where legal action is possible.
- PECB Domain 4 scenarios commonly test whether implementers can establish an incident response team, triage events, and preserve forensic evidence without destroying logs.
3.5 Organizational Controls: Incident Management & Evidence (A.5.24–A.5.28)
Information security incidents are inevitable; unmanaged incidents become certification failures. Controls A.5.24 through A.5.28 form the incident-management chain in ISO/IEC 27001:2022 Annex A Theme 5 (Organizational controls). PECB Lead Implementer Domain 4 expects candidates to design these controls as an end-to-end process—from preparation and triage through response, lessons learned, and evidence preservation—not as a single “call the SOC” bullet in the SoA.
Control Map (A.5.24 – A.5.28)
| Control | Title | Lead Implementer deliverable |
|---|---|---|
| A.5.24 | Information security incident management planning and preparation | Incident management policy, roles (IRT), contact trees, severity model, playbooks |
| A.5.25 | Assessment and decision on information security events | Event triage criteria, classification workflow, decision authority |
| A.5.26 | Response to information security incidents | Containment, eradication, recovery procedures; communications |
| A.5.27 | Learning from information security incidents | Post-incident review process, corrective-action linkage |
| A.5.28 | Collection of evidence | Forensic readiness, chain-of-custody, legal hold procedures |
Planning and Preparation (A.5.24)
Control A.5.24 requires the organization to plan and prepare for managing information security incidents by defining, establishing, and communicating processes, roles, and responsibilities. Lead Implementers typically deliver:
- Incident management policy approved by Top Management, aligning with legal/regulatory notification duties identified under Clause 4.2 and control A.5.31.
- Incident Response Team (IRT) with named roles: incident manager, technical responders, communications lead, legal/privacy liaison, and business-unit contacts.
- Severity / priority model (for example, Sev-1 customer-data breach vs. Sev-4 isolated malware alert) that drives escalation timelines.
- Playbooks for common scenarios: ransomware, credential compromise, DDoS, lost devices, insider misuse, and cloud misconfiguration exposure.
- Tools and retainers — SIEM/SOAR access, out-of-band communications, breach-counsel and forensics retainers, backup restoration runbooks.
Preparation is tested on the exam: an organization that “responds ad hoc” fails A.5.24 even if it eventually contains an attack.
Event Assessment vs. Incident Response (A.5.25 & A.5.26)
Control A.5.25 addresses information security events—observable occurrences that may or may not indicate a compromise. Personnel must assess events and decide whether they should be classified as information security incidents. Triage criteria include indicators of compromise, affected asset criticality, potential CIA impact, and regulatory exposure.
Control A.5.26 applies once an event is confirmed as an incident. Response activities typically follow:
Detect → Triage (A.5.25) → Declare Incident → Contain → Eradicate → Recover → Communicate → Close → Learn (A.5.27)
Response actions include isolating systems, resetting credentials, blocking indicators, engaging suppliers under A.5.20/A.5.23, notifying interested parties per Clause 7.4 plans, and restoring from known-good backups (A.8.13). Lead Implementers ensure response authority is pre-delegated so responders need not wait for executive email approval during Sev-1 events.
Learning from Incidents (A.5.27)
Control A.5.27 requires knowledge gained from incidents and information security events to strengthen controls. Effective post-incident reviews answer:
- What failed (people, process, technology)?
- Which Annex A controls or Clause 6.1 risk assumptions were incorrect?
- What corrective actions (Clause 10.1) and continual-improvement opportunities (Clause 10.2) are required?
- Do playbooks, detection rules, and training need updates?
Near-misses and false-positive storms also generate learning: noisy alerts that bury real incidents are themselves an ISMS performance problem under Clause 9.1.
Collection of Evidence (A.5.28)
Control A.5.28 requires the organization to establish and implement procedures for the identification, collection, acquisition, and preservation of information that can serve as evidence. Lead Implementers establish forensic readiness:
- Preserve volatile data and logs before remediation wipes artifacts.
- Maintain chain of custody (who handled evidence, when, and how it was stored).
- Use write-blocking and hash verification for media images when legal action is plausible.
- Coordinate with legal counsel before imaging systems subject to attorney-client or privacy constraints.
- Retain evidence for periods required by law, contracts, and the documented-information retention schedule (Clause 7.5).
A common exam trap: restoring from backup immediately without snapshotting compromised systems can destroy evidence needed for prosecution or insurance claims.
Integration with ISMS Clauses
Incident controls are not isolated Annex A entries. They connect to:
- Clause 6.1.2 / 6.1.3 — residual risk assumes detection and response capability.
- Clause 7.4 — external breach notifications and customer communications.
- Clause 8.1 — operational planning and control of incident processes.
- Clause 9.1 / 9.3 — incident metrics and management-review inputs.
- Clause 10.1 — nonconformities revealed by incidents.
Practical Implementation Scenario
Scenario: A fintech detects unusual API traffic. The NOC is unsure whether it is a load test or credential stuffing. No severity model exists, and engineers begin patching production logs in place.
Lead Implementer guidance: Apply A.5.25 triage using predefined criteria, declare a Sev-2 incident under A.5.26, preserve logs and API gateway captures under A.5.28 before remediation, execute containment (rate limits, credential resets), notify the privacy lead for potential notification assessment, and schedule an A.5.27 post-incident review that updates WAF rules, monitoring use cases, and the risk register.
Which Annex A control primarily requires the organization to plan roles, procedures, and communication paths for handling information security incidents before an incident occurs?
An engineer wants to rebuild a compromised server immediately from a golden image. Legal counsel anticipates litigation. Which control most directly requires preserving information that can serve as evidence before remediation destroys artifacts?
After containing a phishing-driven account takeover, the organization updates awareness training and detection rules based on attacker techniques observed. Which control is primarily demonstrated?