A.5.26
Response to information security incidents
Organizational controlsCheckpoints 5Evidence 6Cases 5
Control objective
This control covers assessment, containment, eradication, recovery, and closure of information security incidents through predefined roles and procedures. Evidence preservation and stakeholder notification/reporting run alongside response; external reporting must not wait for recovery or incident closure. Record the handling process and results to reduce harm and recurrence and support later improvement.
Key checkpoints
- Are response procedures and a response organization (roles/responsibilities/escalation paths) defined in advance by incident type and severity?
- After an incident is received, do designated personnel carry out and record staged actions through containment, eradication, recovery, and closure?
- During response, is evidence needed for later analysis or legal action collected and preserved without corruption?
- Are notification obligations under law or contract (regulators, data subjects/customers, partners) identified and met within the required deadlines?
- Are response outcomes (cause, actions, impact, recurrence prevention) recorded and reported to relevant departments and management?
Implementation guidance
- Define incident severity levels (for example high/medium/low) and document target response times and escalation criteria per level.
- On initial response, determine the scope of impact and prioritize containment actions (account lockout, session termination, network isolation) to stop the spread.
- Eradicate the root cause and remediate the vulnerability, then restore services/systems to a normal state and verify correct operation and absence of reinfection after recovery.
- Collect evidence such as logs, images, and memory dumps in a manner that preserves the integrity of the original, and record custody/transfer history (chain of custody).
- Assess legal/contractual reporting triggers, starting points, and recipients early, and report within deadlines alongside response. Where investigation is incomplete, use the applicable initial-report and follow-up update procedure.
- Keep a chronological incident log of the whole response, and on closure produce a handling report that feeds into learning from incidents (A.5.27).
Evidence
- Incident response procedures and severity level/escalation criteria
- Response organization chart and role/responsibility (RACI) definitions
- Records of individual incidents (incident log, containment/recovery actions, timeline)
- Evidence collection and chain-of-custody records
- External notification/reporting documents to regulators/data subjects and proof of dispatch
- Incident closure reports and records of reporting to management
Nonconformity examples
- Response procedures exist but lack severity levels/escalation criteria, so the level of response varies from incident to incident.
- Recovery is started without containment, so the incident recurs while the attacker remains present.
- Logs are arbitrarily deleted or overwritten during response, destroying evidence needed for root-cause analysis and legal action.
- A personal data breach is recognized but regulator/data-subject notification is not made within the statutory deadline.
- An incident is handled but the outcome and cause are not recorded, so it does not lead to recurrence prevention or lessons learned.