Turn the ISO/IEC 27035 lifecycle into an operational workflow with explicit decisions, handoffs, owners, evidence, and reopening triggers.
ISO/IEC 27035 is voluntary guidance, not a law or standalone certification scheme. Adapt it to the incident and apply separate legal, regulatory, contractual, and ISO/IEC 27001 requirements where relevant.
Structured answer sets in this page tree.
Cited legal and guidance references.
Use this workflow to move an through the five phases in ISO/IEC 27035-1:2023: plan and prepare, detect and report, assess and decide, respond, and learn lessons. Part 2 covers preparation and learning; Part 3 covers ICT detection, triage, analysis, containment, eradication, recovery, and conclusion. Non-ICT incidents still follow the Part 1 management process, but Part 3 does not supply their operational procedures.
Preparation begins before the alert. Approve the policy and plan, define event and incident criteria, appoint the incident management team, establish reporting channels and external relationships, prepare forms and technical support, train personnel, and exercise the arrangements. These controls determine who receives an event report and how quickly the organization can declare and handle an incident.
When an event arrives, preserve its source and time, validate it, and register it. The incident coordinator applies the prepared criteria, considers business and technical impact, decides whether the event is an information security incident, assigns priority, and activates the appropriate incident response team. An event that does not meet the criteria should still retain its assessment and disposition because later correlation can change the decision.
The intake source can be a user, contractor, supplier, external response organization, monitoring team, or automated sensor. Route every report to the defined point of contact, then to the incident coordinator. Branch explicitly to false alarm, normal operational handling, possible incident pending more facts, or confirmed incident. Give every branch an owner, record, next action, and condition for reassessment.
For an ICT incident, triage establishes priority and routes work; analysis develops and tests hypotheses about scope, cause, affected assets, and likely impact. The coordinator then selects response actions with the technical team and relevant asset or service owners. Containment limits continuing harm, eradication removes incident components, and recovery restores a service, system, or data to an acceptable operational state.
These operations can overlap and repeat. A containment action may reveal another affected system, a recovery check may show that eradication was incomplete, or new facts may raise severity. Each handoff should carry the current facts, uncertainties, authority, time constraints, evidence location, communication status, and next decision point.
The incident register should show the incident's status and follow-up work; the incident log should reconstruct the chronology. Link both to the event report, assessment, response records, communications, evidence items, recovery validation, final report, and improvement actions. Preserve earlier entries and append corrections so reviewers can distinguish what responders knew at each decision point from what became known later.
Evidence quality matters more than volume. A useful record identifies the actor, timestamp and time zone, source, decision or action, result, approval where required, and related evidence. Restrict access to sensitive incident information and preserve potential digital evidence under appropriate handling procedures.
Map each incident phase to a decision owner, required record, escalation branch, closure condition, and improvement action.
Convert ISO/IEC 27035 Incident Lifecycle Workflow into accountable tasks, evidence requests, and review checkpoints.
Review your current scope, evidence gaps, and next implementation steps.
Close the active response only after the authorized owner accepts the recovery result, continuing monitoring is assigned, required communications have been handled or transferred, potential evidence is secured, and unresolved risks or corrective actions have named owners. Improvements can remain open after closure when the response has a documented conclusion and the remaining work is controlled elsewhere.
Reopen the incident, or link a new incident to it under the organization's procedure, when monitoring finds recurrence, recovery fails, new affected assets or parties appear, the severity or reporting analysis changes, or evidence contradicts the closure basis. Keep the original closure decision and record the reopening trigger.
Review the record after incidents and exercises to identify what delayed detection, declaration, escalation, containment, recovery, or reporting. Separate findings about the incident's causes from findings about the response capability. Assign each accepted change to an owner, set a due date and verification method, and update the policy, plan, playbook, contacts, tools, training, or supplier arrangement that failed.
Feed recurring event types, response times, impact, control failures, and unresolved actions into risk assessment and management review. Aggregated metrics can guide investment, but they should not replace review of the decisions and circumstances behind a severe incident.