Practical toolGlobalISO/IEC 27035

ISO/IEC 27035 Incident Lifecycle Workflow

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.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

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.

Section 1

What sequence should an incident follow?

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.

  • Preparation output: approved policy and plan, current contacts, tested classification and escalation criteria, reporting forms, response resources, and an exercise record.
  • Assessment output: stable identifier, validated facts, incident or non-incident decision, severity and priority, affected services, coordinator, response team, and next review time.
  • Escalation branch: transfer authority to crisis or business-continuity management when organizational thresholds are met, while preserving the incident record and a route back for final resolution.
  • Exception branch: if the incident type, tool, approver, or communication route is unavailable or unrecognized, use the prepared default authority and escalation route instead of inventing an unrecorded process during the incident.
Section 2

How should response, reporting, and handoffs work?

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.

  • Before a disruptive action: record the proposed action, expected benefit, operational and evidentiary risks, approver, and rollback or continuity arrangement.
  • During response: record observations, hypotheses, actions, results, scope changes, severity changes, and the reason for each decision.
  • For reporting: use approved roles and channels; assess internal, customer, supplier, insurer, law-enforcement, regulator, and affected-person requirements separately rather than treating ISO/IEC 27035 as the source of a legal deadline.
Section 3

What evidence should exist at each gate?

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.

  • Detect and report gate: original report or alert, source, timestamps, validation result, and register entry.
  • Assess and decide gate: criteria applied, impact assessment, incident declaration, severity, priority, coordinator, team, escalation decision, and notification review.
  • Respond gate: analysis record, chosen actions and approvals, evidence references, communications, containment and eradication results, and recovery tests.
  • Learn lessons gate: final report, root or contributing causes where established, response evaluation, corrective-action owners and dates, plan or control changes, and verification of completed improvements.
Section 4

When can the incident close or reopen?

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.

  • Do not close on technical restoration alone; confirm business acceptance, security checks, communications, evidence handling, and ownership of residual work.
  • Do not erase or silently reclassify an event when later evidence changes the assessment.
  • Do not combine internal response targets with legal or contractual deadlines; record each source, trigger, owner, and status separately.
Section 5

How should lessons change the operating process?

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.

  • Verify an improvement through a test, exercise, control sample, or later incident; completion of a task ticket alone does not show that the change works.
  • Review external contacts, reporting routes, service dependencies, and authority limits after organizational, supplier, system, threat, or legal changes.
  • Keep lessons appropriately sanitized when using incident experience in awareness or training.
Primary sources

References and citations

iso.org5 citations
Referenced sections
  • Official ISO page for ISO/IEC 27035-2:2023, edition 2, covering preparation and lessons learned.
  • ISO states that Part 2 covers policy, the incident management plan, team establishment, relationships, support, training, and lessons learned.
  • ISO identifies Part 2 as the preparation and lessons-learned guidance that establishes the plan, relationships, support, and team arrangements used during handoffs.
Show 2 more
  • ISO states that Part 2 includes identifying areas for improvement, making improvements, and evaluating the incident response team.
  • Part 2 covers the learn-lessons phase, including improvement identification, implementation, and incident response team evaluation.
iso.org4 citations
Referenced sections
  • Official ISO page for ISO/IEC 27035-1:2023, edition 2, the principles and process foundation for the five incident-management phases.
  • ISO identifies Part 1, edition 2 published in February 2023, as the foundation for preparing, detecting, reporting, assessing, responding, and learning lessons.
  • Part 1 establishes the incident-management process and applies generically to organizations of any type, size, or nature.
Show 1 more
  • Part 1 provides the full process through response and lessons learned, including the management context for conclusion and follow-up.
iso.org4 citations
Referenced sections
  • Official ISO page for ISO/IEC 27035-3:2020, edition 1, covering ICT incident response operations; ISO currently lists it as published and under review.
  • ISO states that Part 3 covers ICT detection, reporting, triage, analysis, containment, eradication, recovery, and conclusion.
  • ISO identifies Part 3 as the operational guidance for ICT incident response and its response phases.
Show 1 more
  • Part 3 supplies the ICT operational activities whose performance and records feed the post-incident review.
Show all related guides (20)

ISO/IEC 27035 Incident Timer Workflow

Create an incident clock that tracks operational checkpoints and separate legal or contractual deadlines without inventing ISO/IEC 27035 time limits.

ISO/IEC 27035 Notification Threshold Mapping Guide

Map ISO/IEC 27035 incident reporting routes to separate legal, contractual, customer, supplier, insurer, and internal notification thresholds.

ISO/IEC 27035 vs ISO 22301 Comparison

Compare ISO/IEC 27035 incident-management guidance with ISO 22301 business continuity management-system requirements and certification scope.

ISO/IEC 27035 vs NIS2 Comparison

Compare voluntary ISO/IEC 27035 incident-management guidance with binding NIS2 duties for in-scope EU entities and national implementation.

ISO/IEC 27035 vs NIST SP 800-61 Comparison

Compare ISO/IEC 27035 with NIST SP 800-61 Rev. 3, including lifecycle differences, shared incident records, and migration from Rev. 2.

ISO/IEC 27035 vs NIST SP 800-61 Rev. 3 Comparison

Compare the ISO/IEC 27035 series with NIST SP 800-61 Rev. 3 incident-response guidance and show how organizations can use both.

ISO/IEC 27035 CSIRT Roles FAQ

Assign ISO/IEC 27035 incident coordinator, IMT, IRT or CSIRT, point-of-contact, evidence, communications, and business decision roles.

ISO/IEC 27035 Escalation FAQ

Define ISO/IEC 27035 escalation and elevation triggers, authorities, handoff evidence, and reassessment rules before incidents occur.

ISO/IEC 27035 Event vs Incident FAQ

Distinguish an information security event from an incident under ISO/IEC 27035 and record the assessment without discarding useful event evidence.

ISO/IEC 27035 Lessons Learned FAQ

Apply ISO/IEC 27035 lessons learned to plans, controls, risk decisions, training, relationships, metrics, and future response capability.

ISO/IEC 27035 Notification Evidence FAQ

Preserve evidence for internal and external incident notifications without attributing legal deadlines or reporting duties to ISO/IEC 27035.

ISO/IEC 27035 Post Incident Review FAQ

Run an ISO/IEC 27035 post-incident review after stabilization and recovery, then assign measurable improvements without losing accountability.

ISO/IEC 27035 Retained Logs FAQ

Retain ISO/IEC 27035 incident logs and digital evidence according to purpose, investigation needs, law, contracts, privacy, and organizational policy.

ISO/IEC 27035 Severity Classification FAQ

Classify incident severity under ISO/IEC 27035 using organization-specific criteria and reassess it as facts, impact, and recoverability change.