A.5.24A.5 Organizational controls

Information security incident management planning and preparation

Purpose

Plan and prepare for incident management by defining the processes, roles and responsibilities needed to respond.

How to meet this control

In short: Plan and prepare for incidents by defining processes, roles and responsibilities.

Step 01Write an incident response plan defining severity levels, roles, a single point of contact and escalation paths
Step 02Provide incident response runbooks for common scenarios (phishing, ransomware, data breach, account compromise)
Step 03Agree resolution timeframes and management objectives per severity level
Step 04Train the incident response team and run periodic tabletop exercises to test the plan
Step 05Map external obligations such as the OAIC notifiable data breach 30-day assessment window into the plan

Tip: A written Incident Response Plan with severity levels is the core evidence.

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.

›Set up a common method and a point of contact for reporting security events
›Establish an incident management process covering detection, triage, analysis and coordination
›Build an incident response process for assessing, responding to and learning from incidents
›Restrict incident handling to competent staff and give them procedure documentation and regular training
›Agree incident management objectives and resolution time frames with management based on severity
›Develop procedures for evaluating events, detecting, classifying, analysing and reporting them
›Define reporting procedures, including incident forms and feedback to those who reported
›Account for external obligations such as breach notification deadlines to regulators

Audit evidence to keep

- Documented incident response plan with severity levels and defined roles
- Incident response runbooks for common incident types
- Records of incident response training or tabletop exercises
- Defined notification obligations and timeframes within the plan

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

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.Data breach response policyUse for ISO 27001 A.5.24 to A.5.28, SOC 2 incident handling, privacy notification, and PCI DSS requirement 12.10.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.

Open the control-to-policy map

← A.5.23 Information security for use of cloud services A.5.25 Assessment and decision on information security events →

Back to all organizational controls or see the requirements (clauses 4 to 10). To run this control with automation, read how AI manages controls.