BrowseToolsGuidesComparePricingStacksPlaybooksBlogSearch
ComplianceReadiness checkISO 27001ISO 42001SOC 2PCI DSSPolicy templatesControl mapCompliance softwareFramework compare
A.5.26A.5 Organizational controls

Response to information security incidents

A.5EVIDENCEA.6EVIDENCEA.7EVIDENCEA.8EVIDENCECONTROL MAPA.5.26 Evidence MapPOLICY / CONTROL / EVIDENCE / REVIEW

Purpose

Respond to security incidents following documented procedures so they are handled efficiently and consistently.

How to meet this control

In short: Respond to incidents per documented procedures.

  1. Step 01Follow documented response procedures and have a designated, competent team carry out the response
  2. Step 02Contain the incident and preserve evidence promptly, logging every response action in a ticket or incident log
  3. Step 03Escalate per the plan, invoking crisis management or continuity plans where the severity warrants
  4. Step 04Coordinate with internal and external parties such as authorities, suppliers and affected customers on a need-to-know basis
  5. Step 05Formally close and record the incident and run root cause analysis to fix the underlying vulnerability

Tip: Keep an incident log/ticket trail as evidence of response.

What ISO 27002 says to cover

Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.

  • ›Establish incident response procedures and communicate them to all relevant parties
  • ›Have a designated, competent team carry out the response
  • ›Contain the incident and collect evidence as soon as possible after it occurs
  • ›Escalate as needed, including crisis management and invoking continuity plans
  • ›Log all response activities and communicate details on a need-to-know basis
  • ›Coordinate with internal and external parties such as authorities, suppliers and clients
  • ›Formally close and record the incident once resolved, and run forensic analysis if required
  • ›Perform post-incident root cause analysis and address the vulnerabilities that allowed it

Audit evidence to keep

  • - Incident log or ticket trail evidencing the response actions taken
  • - Documented response procedures applied during incidents
  • - Records of escalation and stakeholder communication during incidents
  • - Closed incident records with root cause analysis

Common mistakes

  • - Having an incident plan that staff cannot find
  • - Closing incidents without root cause or lessons learned
  • - Not preserving evidence before systems are changed

Owner, cadence, and proof

Assign one accountable owner for A.5.26. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.

Policy templates for this control

Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.

AI use and governance policyUse for ISO 42001, AI governance, employee AI use, data handling, human review, and AI supplier risk.Incident response policyUse for ISO 27001 A.5.24 to A.5.28, SOC 2 incident response, PCI DSS 12.10, and security event handling.Information security roles and responsibilitiesUse for ISO 27001 A.5.2, A.5.3 and A.5.4, defining security roles, segregation of duties, management responsibilities, and SOC 2 organisational controls.Backup and continuity policyUse for ISO 27001 A.5.29, A.5.30, A.8.13, A.8.14, SOC 2 Availability, and resilience controls.
Open the control-to-policy map
← A.5.25 Assessment and decision on information security eventsA.5.27 Learning from information security incidents →
Back to all organizational controls or see the requirements (clauses 4 to 10). To run this control with automation, read how AI manages controls.