ISO 27001 Incident Response Plans: What to Prepare

A security incident can interrupt operations before your organisation has established who is authorised to act. ISO 27001 incident response planning gives teams a usable incident response plan, with clear responsibilities, reporting routes and recovery decisions in place before pressure arrives.

An effective plan connects technical action with business priorities, legal obligations and information security risk. ISO/IEC 27001:2022 allows organisations to structure their arrangements around their needs, rather than imposing one document template.

Preparation starts with understanding the requirements and translating them into workable procedures.

Key Takeaways

• ISO/IEC 27001:2022 requires organisations to assess and treat information security risks, while Annex A controls provide reference points for planning, responding to and learning from incidents.

• Build an accessible incident response plan with clear reporting routes, roles, escalation authority, supplier arrangements and supporting playbooks. ISO 27001 does not prescribe a standalone plan template or a universal response timetable.

• Assess events before classifying them as incidents, and prioritise action according to business impact and urgency. Document decisions, including severity changes and notification assessments.

• Prepare proportionate containment, evidence collection and recovery procedures, and test that people can access the plan and make key decisions.

• Review incidents and exercises, retain appropriate records, and track improvements so the organisation can demonstrate and strengthen its readiness.

What ISO 27001 requires for incident management

ISO/IEC 27001:2022 sets requirements for an information security management system (ISMS). Leadership commitment, resources, risk assessment, documented information and continual improvement underpin the ISMS framework.

Annex A contains 93 reference controls across four themes: organisational, people, physical and technological. Organisations determine necessary controls through risk treatment, compare them against Annex A and document their decisions in the Statement of Applicability.

For ISO 27001 incident response, the following controls provide the main reference points for practical preparation.

Control	Subject	Practical preparation
5.24	Planning and preparation	Establish processes, roles and responsibilities.
5.25	Assessment and decision	Assess security events and decide whether they are incidents.
5.26	Response	Respond through documented procedures.
5.27	Learning	Use incident knowledge to improve controls.
5.28	Evidence collection	Establish evidence identification, collection and preservation procedures.
5.29	Security during disruption	Maintain appropriate information security during disruption.
6.8	Event reporting	Provide channels for timely reporting.

Controls 5.24 to 5.28 form the core incident management control group. Control 5.29 connects incident arrangements with business continuity.

Annex A applicability requires justification, rather than automatic adoption or arbitrary selection. Necessary controls must be implemented, and exclusions explained.

ISO 27001 doesn't mandate a standalone plan with a fixed title or layout. An integrated procedure, supporting playbooks and controlled records can provide workable arrangements. These should connect with the wider ISO 27001 management system, rather than operate separately from risk management.

Build a plan that teams can access and use

Define scope, dependencies and access

For effective ISO 27001 incident response, start with the services, information and locations covered by your ISMS. Identify critical systems, sensitive data, operational dependencies and suppliers whose involvement could affect the response.

Record the plan owner, approval authority, version and review date. Include responder contacts, deputies, supplier escalation routes and links to supporting procedures.

Responders need access when normal systems are unavailable. Keep a protected offline copy of essential instructions and contact details. For remote teams, establish an approved alternative to corporate email and messaging.

Check that supplier contracts support your arrangements. Confirm notification obligations, evidence access, response coverage and who can authorise work outside normal support.

Choose a practical response workflow

A workable process can use five stages: notification, classification, treatment, closure and organisational learning. Treatment includes containment, eradication and recovery.

These stages are a recommended operating structure, not an ISO-mandated sequence. Investigations often revisit classification as new information changes the assessed impact.

Keep the incident response plan as the main procedure, supported by playbooks. Store playbook guidance in a knowledge base for account compromise, malware infection, phishing attack, ransomware attack, zero-day vulnerabilities, data disclosure and supplier incidents. Each playbook should describe triggers, initial actions, decision points and recovery checks.

NIST SP 800-61 Rev. 3, finalised on 3 April 2025, provides complementary guidance across cybersecurity risk management. It supersedes Revision 2 but doesn't replace ISO requirements. The ISO/IEC 27035 series also provides incident management guidance.

Distinguish events from incidents and prioritise action

Assess events before confirming incidents

An information security event is an observed occurrence that may indicate a security failure or abnormal situation. An incident involves circumstances that threaten information security or business operations.

A failed sign-in is an event requiring context. Confirmed unauthorised access to a Microsoft 365 account warrants incident handling. Incidents can also involve lost equipment, misdirected information or physical access failures.

Control 5.25 addresses event assessment and incident classification, a core part of ISO 27001 incident response. During the assessment of security events, a competent responder should make the classification and record the reasoning. Employees shouldn't have to confirm a breach before reporting a concern.

Make reporting simple and severity business-led

Provide one clear reporting route in your incident response plan, with an urgent fallback if it fails. Explain what employees should report and ask them to report suspicions promptly.

Control 6.8 supports timely reporting through appropriate channels. ISO 27001 doesn't impose a universal deadline measured in minutes or hours. Your organisation should define response targets suited to its risks and operating hours.

Assess severity using business impact and urgency, then assign a severity level. Consider affected services, information sensitivity, safety, attacker activity and spread. Check reporting obligations, including whether a data breach may have occurred. Record who can change the priority.

A no-blame reporting culture encourages earlier disclosure, although it isn't a prescribed ISO requirement. Train staff to report mistakes without investigating independently or deleting relevant material.

Assign ownership and escalation authority

Establish incident command and technical responsibility

Name an incident lead who coordinates decisions during a security incident, maintains the incident record and controls escalation. Assign a deputy and define arrangements for out-of-hours coverage.

The technical lead directs investigation and containment. Service owners assess operational impact and confirm recovery requirements. Senior management approves decisions beyond delegated authority, including prolonged service suspension or significant expenditure.

Document who can isolate devices, disable accounts, revoke access and activate business continuity arrangements in the incident response plan. This supports ISO 27001 incident response and clarifies pre-approved actions, reducing delays. Operational technology and safety-sensitive systems still need agreed safeguards.

Small organisations can combine roles. They still need clear accountability and enough capacity to maintain records whilst responders investigate.

Bring specialist functions into decisions

Legal advisers and the data protection lead assess notification duties and evidence considerations. Communications staff coordinate approved updates. HR supports incidents involving employees, whilst supplier owners manage external dependencies.

Define escalation criteria rather than relying on personal judgement alone. Suspected data theft, privileged-account compromise and disruption to critical services should prompt appropriate leadership involvement.

A responsibility matrix can distinguish who performs, approves, advises and receives updates for each major decision. Validate it against actual availability.

Organisations without permanent senior security leadership can use virtual CISO support. External support still needs agreed authority, access and response arrangements before an incident.

Prepare communications and notification decisions

Communications need an owner, approved channels and clear review arrangements. Prepare templates for internal updates, customer notifications and supplier requests. Leave room for confirmed facts rather than speculation.

Each update should state what is known, the operational effect, actions underway and the next update time. Keep sensitive investigative details within the response team.

Remote-first organisations should agree an out-of-band channel that doesn't depend on potentially compromised accounts. Verify participants before sharing incident information.

Maintain a notification register covering contractual duties, regulatory obligations, insurance requirements and sector commitments. Record the trigger, deadline, decision-maker and submission route for each obligation.

Under UK GDPR, a controller must notify the ICO of a personal data breach without undue delay, where required. Where feasible, notification must occur within 72 hours of awareness, unless risk to individuals is unlikely. Processors must notify controllers without undue delay.

  The UK GDPR notification clock relates to awareness of the breach, not completion of the forensic investigation.  

Assess notification duties early and document decisions, including reasons for non-notification. ISO certification doesn't replace legal compliance or customer reporting commitments.

Prepare containment, evidence and recovery procedures

Preserve evidence alongside proportionate containment

Define what responders should collect: identity logs, endpoint alerts, relevant messages, cloud audit records and a timeline of actions.

For Microsoft 365, confirm access to Entra sign-in logs and relevant audit records. For AWS, check CloudTrail coverage, retention and access permissions. Log availability depends on configuration and licensing, so test retrieval beforehand.

Record collection times, time zones, collectors and evidence transfers. Protect originals, restrict access and use integrity checks where appropriate. These arrangements support control 5.28.

Urgent containment may take priority over ideal evidence collection. Record the decision and its impact. Avoid unnecessary reboots or deletion that could destroy useful material.

Recover against agreed acceptance criteria

An incident response plan should translate ISO 27001 incident response requirements into playbooks for containment and recovery, with authorised actions such as isolating endpoints, revoking sessions, disabling compromised accounts and restricting exposed services. For exposed services affected by zero-day vulnerabilities, use threat intelligence to assess exploitation and apply available mitigations.

SaaS account recovery may require reviewing application permissions, mailbox forwarding and authentication settings, alongside password changes. Removing one access route doesn't establish that the compromise has ended.

Define recovery criteria before reconnecting systems. Confirm that the cause has been addressed, restored services operate correctly and required security controls are active. Assign approval to the appropriate technical and business owners.

Coordinate recovery with business continuity priorities. Record accepted residual risks and increase monitoring where justified. Keep the incident open until recovery checks and closure approval are complete.

Test the arrangements and demonstrate improvement

Exercise decisions as well as technology

Run a tabletop exercise around credible risks in your risk assessment. Include leadership, IT, communications, data protection and relevant suppliers.

Test whether staff can find the plan, reach decision-makers and authorise containment. Include loss of corporate messaging, an unavailable responder or an incident affecting a critical supplier.

Technical exercises should verify evidence retrieval, account containment and restoration from backups. Conduct disruptive testing only within an approved scope.

Set exercise frequency according to risk and change. Periodic testing and testing after significant changes are sound practices, but ISO 27001 doesn't prescribe one universal timetable. Capture decisions, delays and assigned improvements to demonstrate ISO 27001 incident response readiness.

Maintain records that show the process works

Use a ticketing system or protected incident register to retain reports, assessments, decisions, actions, communications and closure approvals. A controlled spreadsheet can suit a small organisation if access, change history and backup are adequate.

Review incidents for root causes and control weaknesses. Learning from incidents under control 5.27 should lead to tracked improvements, rather than an unassigned lessons-learned report. Share relevant findings in a responder knowledge base.

Update risks, procedures, training and controls where needed. Incident reviews may identify nonconformities requiring corrective action under clause 10.2.

For audits, retain applicable control decisions, training records, exercise outcomes and evidence of completed improvements to support audit compliance. AKRUP's ISO 27001 implementation support helps organisations connect these records with proportionate risk treatment and certification readiness.

Frequently Asked Questions

Does ISO 27001 require a standalone incident response plan?

No. ISO/IEC 27001:2022 does not prescribe a document title, layout or standalone plan. An integrated procedure, supporting playbooks and controlled records can provide effective arrangements.

What incident response controls are relevant in ISO 27001:2022?

Annex A controls 5.24 to 5.28 cover incident planning, assessment, response, learning and evidence collection. Controls 5.29 and 6.8 address security during disruption and event reporting.

Does ISO 27001 set a deadline for responding to incidents?

ISO 27001 does not set a universal response deadline measured in minutes or hours. Organisations should define targets that reflect their risks, operations and reporting obligations.

When must a personal data breach be reported to the ICO?

Under UK GDPR, a controller must notify the ICO without undue delay where notification is required, and, where feasible, within 72 hours of becoming aware of the breach. The notification clock does not wait for the forensic investigation to finish; processors must notify controllers without undue delay.

Make incident preparedness an operational capability

ISO 27001 incident response arrangements work when people understand their responsibilities and can act within agreed authority. Accessible procedures, tested decisions and controlled evidence give the organisation a dependable response capability.

The strongest assurance comes from demonstrated readiness: teams can report, assess, contain and recover, then address the weaknesses they uncover.

If you would like to find out more information or require any of our services please Contact Us and complete the contact form.