Security incidents rarely wait for a convenient moment. Organizations that try to build a response process after a breach has already started are working from a position of weakness. ISO 27001:2022 expects processes, roles and responsibilities to exist before anything goes wrong, not after.
The standard addresses this through five Annex A controls, A.5.24 through A.5.28, that together form a complete incident management lifecycle. These controls take an organization from preparation, through assessment and response, into learning and evidence handling. For companies working with ISO 27001 certification in Oman on certification or ongoing compliance, understanding this lifecycle properly is often what separates a smooth audit from a stack of nonconformities.
What Does ISO 27001 Require for Incident Management?
ISO 27001 treats incident management as an ongoing part of the ISMS rather than a one-time emergency plan. The requirement covers preparation, response, and improvement together, and none of these can be skipped.
- Part of the ISMS, incident handling connects directly to risk treatment, monitoring and continual improvement.
- Preparation before incidents happen: Processes, contact lists, and escalation routes need to exist in advance, not built during an incident.
- Documented processes and responsibilities: Every person involved should know their role in writing, since verbal agreements satisfy neither an audit nor a real event.
- Reporting and escalation: Staff need a simple way to report suspected events, with escalation paths everyone understands
- Incident response: Handling must follow a documented, repeatable procedure suited to severity and type.
- Evidence preservation: Logs and records must be protected from alteration once identified.
- Lessons learned: Every incident should feed back into the ISMS through updated risk assessments or training.
Which ISO 27001 Annex A Controls Cover Incident Management?
Five controls form the backbone of incident management under the 2022 standard, each covering a distinct stage in sequence.
- A.5.24, Incident management planning and preparation sets up the process, roles and responsibilities that everything else depends on.
- A.5.25, Assessment and decision on security events: Covers how an organization decides if an event qualifies as a security incident.
- A.5.26, Response to security incidents: Governs containment, investigation, eradication, and recovery activities.
- A.5.27, Learning from security incidents: Requires organizations to turn incident data into concrete improvements.
- A.5.28, Collection of evidence: Addresses how evidence is identified, preserved and handled throughout the process.
How Does Annex A.5.24 Prepare an Organisation for Incidents?
A.5.24 requires organizations to define, establish, and communicate their incident process along with clear roles and responsibilities.
Define the incident management process
The process should cover reporting, detection, triage, classification, escalation, response, recovery, closure and post-incident review as one connected sequence. Gaps between these stages are where incidents get missed or mishandled. A well-written process gives staff a single reference point.
Assign incident management roles and responsibilities
Roles typically include an incident manager, the IT and security team, management, HR, legal, compliance, communications, business owners and outside specialists where needed. Someone must have clear authority to formally declare an incident.
Establish reporting and escalation routes
Reporting channels should cover employees, monitoring alerts, customer reports, supplier notifications, and after-hours situations. Escalation contacts and communication channels need to stay current.
Train employees and incident responders
A documented procedure is not useful if nobody knows it exists. Regular training turns staff into an early warning system.
How Should Organisations Assess Security Events Under Annex A.5.25?
Not every alert is a security incident. A.5.25 requires a defined process for deciding when an event needs a formal response.
Set objective incident classification criteria
Classification should weigh confidentiality, integrity, and availability impact alongside affected systems, data sensitivity, business disruption, and financial exposure. Objective criteria remove guesswork so different staff reach the same conclusion.
Create an incident severity matrix
A simple critical, high, medium and low structure works well for most organizations, each with its own expected response time and escalation path. Without it, minor events sometimes get treated as emergencies while serious ones get delayed.
Record the decision to declare an incident
Every declared incident should have a record showing when it was detected, its source, initial assessment, classification, decision maker and severity. This record becomes the starting point for the response and later audit review.
What Does Annex A.5.26 Require During Incident Response?
A.5.26 requires incidents to be handled according to documented procedures. This is the most operationally demanding of the five controls.
Detect and report the incident
Detection comes from monitoring tools, staff reports or external notifications. Whatever the source, the report needs to enter the formal process immediately.
Contain the incident
Containment might mean isolating compromised devices, disabling accounts, blocking malicious traffic or restricting access. Short term containment stops immediate damage while longer term containment addresses the underlying exposure.
Investigate the root cause
Investigation covers timeline reconstruction, log analysis and identifying compromised credentials and attack vectors. Skipping this step leaves the same weakness open.
Eradicate the threat
Eradication includes removing malware, closing vulnerabilities, resetting credentials and patching affected systems. This should not begin until investigation confirms full scope.
Recover affected systems
Recovery means restoring systems in a controlled way, validating they are clean, and applying closer monitoring afterward.
Communicate during the response
Communication needs to reach management, employees, customers, suppliers and regulators as applicable, protecting trust and reducing regulatory exposure.
How Does Annex A.5.27 Turn Incidents Into Security Improvements?
Closing an incident does not mean the process is finished. A.5.27 requires organizations to turn what they learned into stronger controls.
Conduct a post-incident review
A good review asks what happened, when, how it was detected and why existing controls failed. Reviews should happen soon after closure while details are fresh.
Perform root cause analysis
Root cause analysis separates the immediate cause from contributing factors and the actual root cause, so symptoms alone are not the fix.
Track corrective actions to closure
Each corrective action needs an owner, a deadline, a priority level and evidence confirming it was verified and closed. Actions left open indefinitely are a common audit finding.
Update the ISMS after significant incidents
Lessons learned should feed into risk assessment, policies, security controls, training and playbooks. An incident that changes nothing in the ISMS has not really been learned from.
What Evidence Must Be Collected Under Annex A.5.28?
A.5.28 covers identification, collection and preservation of evidence tied to security events. Handled poorly, it can undermine legal action later. Organizations preparing for certification should also review their ISO 27001 audit preparation process to make sure incident records and evidence can be produced when requested.
Identify what evidence needs to be preserved
Relevant evidence includes system logs, authentication records, emails, screenshots, endpoint data, and incident tickets. Deciding early what counts prevents material from being overwritten.
Preserve evidence without altering it
Preservation involves access restrictions, accurate timestamps, secure storage, and defined retention periods. Any evidence change, even accidental, can reduce its value in legal proceedings. ISO Consultancy Oman helps organizations build these preservation controls correctly from the start.
Maintain a chain of custody
Chain of custody records should show who collected the evidence, when, how it was transferred and where it was stored. Gaps raise doubts about the evidence itself.
Know when legal or forensic support is needed
Some incidents require legal, regulatory or law enforcement involvement, and recognizing this early prevents mistakes that cannot be undone.
What Documents Should an ISO 27001 Incident Management Process Include?
Rather than simply saying to document your procedure, here is the actual set of documents auditors expect to see.
- Incident Management Policy, setting overall intent and scope at management level
- Incident Response Procedure, the operational detail covering detection through closure
- Incident Classification Matrix, defining severity levels and the criteria behind them
- Incident Reporting Form, giving staff a consistent way to submit reports
- Incident Register, a running log of all declared incidents and their status
- Incident Response Playbooks, step-by-step guidance for common incident types
- Escalation Matrix, showing who gets contacted at each severity level
- Communication Templates, pre-drafted messages for common stakeholder groups
- Evidence Collection Procedure, detailing how evidence is identified and preserved
- Chain-of-Custody Form, tracking evidence handling from collection to storage
- Post-Incident Review Template, standardizing how lessons are captured after closure
- Corrective Action Register, tracking improvements through to verified completion
Which Roles Should Be Involved in ISO 27001 Incident Management?
Incident management works best when responsibility is spread across the organization, not resting on one team. Smaller organizations can combine roles, and ISO Consultancy Oman typically helps clients map this out during the initial gap assessment.
- Incident Manager, coordinating the overall response and keeping the process moving
- Information Security Team, leading investigation and technical response
- IT Team, handling system containment and recovery work
- Management, making major decisions and approving resources
- Legal, advising on obligations and evidence handling
- HR, managing incidents involving employee conduct
- Compliance, tracking regulatory and contractual requirements
- Communications, managing internal and external messaging
- Business Owner, weighing in on business impact and service decisions
How Do Annex A.5.24 to 5.28 Work With Other ISO 27001 Controls?
Incident management does not operate in isolation. It connects to other Annex A controls that either feed the process or depend on its outputs.
A.6.8, Information security event reporting
Employees need a clear way to report suspected events. This control provides the front door that A.5.24 and A.5.25 rely on.
A.5.5, Contact with authorities
Some incidents require notifying regulators, law enforcement or other authorities. This control sets expectations for when and how those contacts should happen.
A.5.29 and A.5.30, Disruption and business continuity
Security incidents and broader business disruption often overlap, so continuity and disruption controls need to work alongside the incident process.
A.8.15 and A.8.16, Logging and monitoring
Detection and investigation depend heavily on the quality of logs and monitoring already in place.
What Will an Auditor Check During an Incident Management Audit?
Auditors look for more than a policy sitting in a folder. They want proof the process operates as written.
- A.5.24: procedure, defined roles, contact lists and training records
- A.5.25: incident register, classification matrix and escalation records
- A.5.26: incident tickets, response records and communication logs
- A.5.27: post-incident reviews and tracked corrective actions
- A.5.28: evidence register and chain-of-custody records
Auditors care about proof that the process operates in practice, not just that documents exist. This practical evidence angle is increasingly emphasized across current incident management guidance.
What Are the Most Common ISO 27001 Incident Management Gaps?
Most nonconformities come from gaps between what is written and what actually happens day to day.
- A procedure exists, but staff does not know it, so a polished document nobody has read gives little protection.
- Events are reported but not classified, so response effort gets applied inconsistently.
- Severity levels are undefined, so teams treat everything as urgent, or nothing as urgent.
- Roles have not been assigned, causing confusion that slows down response.
- Procedures have never been tested, so an unexercised plan often fails unpredictably.
- Evidence is not preserved properly, weakening any later legal action.
- Reviews are not documented, so lessons get forgotten within weeks.
- Corrective actions are not tracked, leaving open items unresolved.
- Records cannot show the full timeline, making it hard to prove the process was followed.
How to Build an ISO 27001 Incident Response Workflow
A working workflow moves through a clear, repeatable sequence rather than individual judgment, removing ambiguity during a stressful moment.
Detect, report and record
The workflow starts the moment something unusual is noticed. This first report gets logged immediately, even before it is confirmed.
Assess, classify and declare
The assigned reviewer assesses the report against the classification matrix and sets severity. Once severity is set, the incident manager formally declares the incident and triggers escalation.
Escalate, contain and investigate
Escalation notifies the right people, containment limits further damage, and investigation identifies the root cause and full scope.
Eradicate, recover and close
Eradication removes the threat, recovery restores systems under monitoring, and closure ends the response once systems are stable.
Review and improve
A post-incident review captures lessons and feeds them back into the ISMS, closing the loop for future prevention.
Conclusion
Incident management under ISO 27001 is not a document sitting on a shelf waiting for a breach. It is a lifecycle that starts with preparation, moves through assessment and response, and ends with lessons that strengthen the whole ISMS. Organizations that treat A.5.24 through A.5.28 as one connected process, backed by real records and tested procedures, move through certification audits with far fewer surprises. This is the groundwork ISO Consultancy Oman helps organizations put in place before an auditor ever asks to see it.
Get Started With Your Incident Management Program
If your incident management process is still scattered across separate documents or exists mostly in people’s heads, now is a good time to fix that before your next audit. ISO Consultancy Oman works with organizations across the country to build programs that hold up under real scrutiny. Reach out to discuss where your process stands and what needs attention first.
Email; info@finsoulnetwork.com
Frequently Asked Questions
Which ISO 27001 controls cover incident management?
A.5.24 through A.5.28 form the core incident management controls, covering preparation, assessment, response, learning and evidence handling.
Is an incident response plan mandatory for ISO 27001?
The standard does not prescribe one document format. What matters is a documented, working process backed by records that prove it operates consistently.
What is the difference between a security event and an incident?
A security event is something observed that could indicate a problem. It becomes an incident once assessed and formally declared under A.5.25.
What evidence should be retained after a security incident?
Logs, authentication records, communications and material tied to detection or response should be preserved under controlled access with a clear chain of custody.
How often should an organization test its incident response process?
There is no single mandated frequency. Organizations should set a testing schedule that matches their risk profile and keep records of each exercise.