ISO 27001 Incident Management: Process and Evidence

An ISO 27001 incident process must do more than close security tickets. It should enable people to report events, decide which events require incident treatment, coordinate response, preserve reliable evidence, communicate through authorised channels and use lessons to improve the information security management system (ISMS).

The practical test is traceability. An auditor should be able to follow a sampled incident from detection through assessment, containment, recovery, communication, closure and improvement without finding unexplained gaps in time, responsibility or evidence.

This guide provides a risk-based operating model that can fit a small organisation or scale across specialised security teams.

Distinguish an event from an incident

Security tools and people generate events: alerts, unusual activity, reported weaknesses and service anomalies. The organisation needs criteria for deciding whether an event is an information security incident and how urgently it should be handled.

Do not rely on a single severity score without context. Assessment should consider:

• affected information, systems and business services;
• actual or potential effect on confidentiality, integrity and availability;
• legal, regulatory, contractual and customer obligations;
• number and type of affected people or records;
• active attacker presence or continuing exposure;
• operational disruption and recovery dependency;
• evidence reliability and uncertainty; and
• potential for escalation across suppliers or entities.

A false positive should still have a recorded rationale when it crossed an investigation threshold. Otherwise, the organisation cannot demonstrate that alerts were assessed consistently.

Define an end-to-end lifecycle

ISO/IEC 27035-1:2023 describes a structured approach covering preparation, detection, reporting, assessment, response and lessons learned. ISO 27001 users can apply that guidance proportionately; it does not replace the organisation’s selected audit criteria.

A practical lifecycle can use the following states:

1. Reported: an event enters an authorised channel.
2. Triaged: ownership, validity and initial priority are determined.
3. Declared: the event meets the organisation’s incident criteria.
4. Contained: immediate exposure is limited.
5. Eradicated or corrected: the direct cause or malicious presence is addressed.
6. Recovered: services and controls are restored and monitored.
7. Reviewed: cause, impact, response and obligations are evaluated.
8. Closed: authorised owners accept completion and improvement actions are tracked.

State names are organisational guidance, not prescribed ISO wording. Define entry and exit conditions so the team knows what each status means.

Assign decision rights before an incident

A responsibility model should identify:

• who receives and triages reports;
• who can declare severity and activate the response team;
• who directs technical containment;
• who authorises disruptive actions;
• who assesses privacy, legal and regulatory duties;
• who communicates with customers, regulators, law enforcement and media;
• who preserves forensic material;
• who accepts service restoration;
• who owns lessons and corrective actions; and
• who declares closure.

Small organisations may combine roles, but decisions still need named authority and backup coverage. Suppliers should appear in the model where they operate detection, infrastructure, support or communications.

The supplier audit guide explains how to test outsourced responsibilities and evidence.

Make reporting simple and controlled

People should know how to report suspected phishing, lost devices, data exposure, unauthorised access, control failures and unusual system behaviour. Provide accessible reporting channels, including an alternative when primary systems are unavailable.

Record the reporter, time, source, affected service, description and immediate actions. Protect confidentiality and avoid asking untrained reporters to collect risky or unnecessary data.

Automated alerts need ownership too. Confirm which platforms create tickets, how duplicate alerts are handled, what happens when integration fails and whether the complete monitored population is known.

Triage by risk, not convenience

Triage determines whether the event is credible, its potential business impact, priority and next owner. The analyst should record the information available, assumptions, classification and escalation decision.

Use a severity method that combines impact and urgency. A payroll-data disclosure affecting one file may require urgent privacy action even if the system remains available. A denial-of-service attempt may have low current impact but high escalation potential.

The risk score calculator can support consistent reasoning when aligned to the organisation’s approved method. It should not automatically make legal notification or executive escalation decisions.

Preserve a defensible incident timeline

The timeline is often the most valuable audit and learning record. Capture:

• when activity began, if known;
• detection and report times;
• decisions, owners and approvals;
• containment and recovery actions;
• evidence sources and collection times;
• internal and external communications;
• changes made during response;
• service restoration and validation; and
• unresolved facts or estimates.

Use synchronised time sources where practical. Preserve original logs and record transformations or exports. Restrict access, maintain integrity and define retention based on legal, operational and investigative needs.

Do not alter production evidence merely to make a clean report. If information is uncertain, label it as preliminary and update it through controlled revisions.

Coordinate containment, recovery and change

Containment can conflict with availability, safety, evidence preservation and customer obligations. Pre-authorise common actions where possible, such as isolating an endpoint or disabling a compromised account. Define who approves higher-impact actions such as taking a production service offline.

Emergency changes should remain traceable. Record the risk, approval, implementation, validation and later review even when the normal workflow is shortened.

Recovery is not complete when a system starts. Confirm that malicious access is removed, required controls are restored, data integrity is understood, monitoring is increased where needed and the business owner accepts service return.

Integrate communication duties

Create decision paths for privacy, regulatory, contractual, cyber-insurance and customer notification. The incident team should involve legal and privacy specialists early without assuming every event is reportable.

Record:

• which obligations were assessed;
• the facts available at each decision point;
• decision owner and time;
• content approval;
• recipients and transmission evidence; and
• follow-up commitments.

Do not invent a universal notification period. Applicable deadlines depend on jurisdiction, sector, contract and incident facts.

Learn beyond the immediate cause

A useful review asks:

• Why did the event occur?
• Why was it not prevented?
• Why was it not detected earlier?
• Which response actions worked or failed?
• Were responsibilities and communications clear?
• Did suppliers meet their obligations?
• What similar systems or data could be affected?
• Which risks, controls, procedures or training must change?

“User clicked a link” is not a complete cause analysis. Examine email controls, authentication, reporting culture, access design, monitoring and response capability.

Link material lessons to the risk register, treatment plan, Statement of Applicability, objectives, competence needs and management review.

Separate closure from improvement completion

The incident can be operationally closed while longer corrective actions remain open. Define closure criteria and transfer improvement actions into a governed tracker with owner, due date, priority and effectiveness measure.

The major and minor nonconformities article explains how correction, cause analysis, corrective action and effectiveness evidence differ.

What an auditor will sample

An auditor may select incidents across:

• severity levels;
• different detection sources;
• relevant business services;
• privacy or customer impact;
• supplier involvement;
• incidents with emergency changes;
• closed and open improvement actions; and
• repeated event types.

For each sample, expect the auditor to compare the case record with logs, communications, change records, recovery evidence and action tracking. A well-written procedure cannot compensate for missing operating evidence.

Use the Annex A control lookup to identify connected control themes such as event reporting, assessment, response, learning and evidence collection.

Pass, partial and fail examples

Pass: Sampled incidents had consistent triage, authorised response, complete timelines, obligation decisions, validated recovery and lessons linked to risk and actions. Effectiveness was checked after changes.

Partial: Technical response was timely, but one supplier notification decision lacked a recorded owner and several lesson actions had no effectiveness criteria.

Fail: Alerts were routinely closed without assessment, the organisation could not identify its incident population, and a material event had no authorised timeline, notification evaluation or improvement action.

These examples support evidence evaluation; the assigned auditor concludes against the actual criteria and complete facts.

Useful performance measures

Measure outcomes carefully:

• percentage of high-priority alerts assessed within the internal target;
• incidents with complete classification and decision records;
• containment and recovery performance by incident type;
• overdue lesson and corrective actions;
• repeated incidents with the same contributing cause;
• monitored asset coverage;
• exercise findings closed effectively; and
• supplier response against agreement.

Average response time alone can hide severe outliers and reward premature closure. Review distributions, material exceptions and data quality.

Common audit gaps

Organisations often:

• confuse all alerts with incidents or record only confirmed breaches;
• omit business, privacy and supplier decision-makers;
• preserve conclusions but not the supporting timeline;
• allow emergency changes without retrospective review;
• close cases before lessons receive owners;
• measure ticket speed rather than risk reduction;
• retain evidence indefinitely without purpose; or
• run exercises that never update the live process.

Build readiness through exercises

Exercise credible scenarios involving technical teams, business owners, legal, communications and suppliers. Test decision-making and evidence capture, not only technical recovery. Record objectives, participants, injects, decisions, results and improvement actions.

The ISO 27001 evidence register guide can help organise records without duplicating sensitive incident material.

The practical conclusion

Effective incident management connects detection to authorised decisions, reliable evidence, recovery and improvement. Design clear thresholds and responsibilities, preserve an accurate timeline, evaluate obligations and keep learning actions visible after operational closure.

An audit-ready process is not one that has never experienced an incident. It is one that can show how incidents are recognised, controlled and used to make the ISMS stronger.

The subject perspective was informed by Advisera’s article on ISO 27001 incident handling, with lifecycle concepts checked against the current ISO/IEC 27035 series.