Follow the ISO/IEC 27035 five-phase incident-management process and understand how the detailed ICT response loop fits inside it.
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.
Use the five phases in ISO/IEC 27035-1:2023 as the management lifecycle: plan and prepare; detect and report; assess and decide; respond; and learn lessons. The applies the prepared criteria, activates and coordinates the response teams, maintains the record, and carries the incident to resolution. For ICT incidents, ISO/IEC 27035-3:2020 expands the middle phases into detection, notification, triage, analysis, containment, eradication, recovery, conclusion, and reporting. Part 3 does not cover non-ICT response such as lost paper records.
1
Section 1
How does the ISO/IEC 27035 lifecycle work?
Plan and prepare establishes the approved policy and plan, event and incident criteria, classification scale, roles, decision authority, points of contact, reporting channels, internal and external relationships, tools, training, exercises, and recordkeeping. ISO/IEC 27035-2:2023 develops this phase in detail.
Detect and report starts with an observed or suspected event. Record enough information to understand it and pass it to the proper point of contact. Assess and decide then tests the event against the pre-established criteria. The records whether it is an incident, its initial classification, the response route, and the rationale. Keep the event record even when the decision is 'not an incident.'
Respond is iterative. For an ICT incident, teams may repeat triage, analysis, containment, eradication, recovery, communication, and reporting as facts change. Conclusion should record the final status, recovery and closure decisions, outstanding duties, evidence handling, and follow-up. The learn-lessons phase turns findings into owned changes to the plan, controls, risk assessment, training, relationships, and team capability.
For example, an automated failed-login alert is an event. Assessment may close it as a false alarm, route it through normal account support, or correlate it with other activity and declare an incident. By contrast, loss of a paper file can be an information security incident under Part 1 even though Part 3's ICT containment and recovery procedures do not apply.
Do not wait for complete certainty before recording and routing a suspected event; label uncertain facts and set a reassessment time.
Reassess classification and response whenever scope, impact, threat activity, evidence, recoverability, or an external reporting condition changes.
Coordinate containment with evidence preservation and business impact because changing or shutting down a system can destroy volatile data or disrupt critical services.
Close the operational incident only under the organization's approved criteria, with remaining notifications, evidence retention, investigation, and improvement actions assigned.
If response crosses a work shift, transfer the current facts, authority, open actions, evidence status, communications, deadlines, and next checkpoint to the incoming coordinator while preserving the original coordinator and full chronology.
Part 2 develops the preparation and learning phases through policy, plans, teams, relationships, support, training, testing, monitoring, and improvement.
Part 3 supplies the detailed ICT operations and expressly excludes non-ICT response such as lost paper records.
2
Section 2
What should each phase produce?
The record should follow the incident rather than sit in separate, unconnected documents. Part 1 distinguishes the event report, the incident-management log, and the incident register. The event report supports the first classification decision; the log preserves the chronology and decisions for one incident; the register gives the incident management team an organization-wide view of status, follow-up, trends, and themes.
Record information as completely as the facts allow at each stage. Preserve who supplied it, when it was recorded, which facts were uncertain, and later corrections. Apply access, confidentiality, retention, and chain-of-custody controls when records may support legal, regulatory, disciplinary, contractual, or investigative work.
Plan and prepare: approved policy and plan, scope, criteria, roles, contacts, communication rules, response procedures, training, exercise results, and capability gaps.
Detect and report: event source, time, affected service or asset, observed indicators, initial actions, reporter contact, and a traceable event identifier.
Assess and decide: validation result, incident decision, category, provisional severity, business impact, decision owner, rationale, escalation, and next reassessment.
Respond and conclude: analysis, actions and approvals, containment trade-offs, evidence custody, communications, recovery checks, final classification, closure authority, and unresolved work.
Learn lessons: review participants, what worked or failed, root or contributing causes where established, changes, owners, due dates, and evidence that material changes were tested.
Part 3 describes the ICT operational records created through detection, notification, triage, analysis, response, recovery, conclusion, and reporting.
3
Section 3
Where do the Part 1 and Part 3 views connect?
Part 1 supplies the organization-wide management phases. Part 3 supplies an ICT operations loop within detect and report, assess and decide, and respond. A user, system, or external source reports an event to a point of contact; monitoring verifies and records it; triage and analysis develop the facts; authorized teams contain, eradicate, recover, and conclude; internal and external reporting continues as required.
These activities overlap. Analysis can reveal more affected systems, which changes classification and sends the response back to containment. A containment action can destroy evidence or disrupt a service, so the response owner should coordinate the decision with business and evidence owners. Recovery can also expose an ongoing compromise, requiring renewed analysis and containment.
Use one identifier across the event report, incident log, technical case records, communications, evidence records, and incident register.
Keep internal operational notifications separate from external reports; each can have a different trigger, owner, content, recipient, and deadline.
Define authority for disruptive containment, emergency change, continuity activation, external communication, recovery acceptance, and incident closure before an incident.
Part 3 maps ICT detection, notification, triage, analysis, containment, eradication, recovery, conclusion, and reporting to the broader management phases.
Part 1 provides the management process, roles, communications, event report, incident log, register, and decision points that connect the operational activities.
4
Section 4
Which lifecycle mistakes cause gaps?
A linear checklist can hide the need to repeat analysis, classification, containment, and reporting as facts change. The lifecycle should allow controlled loops while preserving the chronology and the reason for each change.
Another gap is treating technical recovery as the end of incident management. Service restoration can occur before external reporting, evidence preservation, investigation, final documentation, or improvement work is complete. Keep those obligations visible and assign them before operational closure.
Do not promote every alert to an incident; assess it against documented criteria and retain the decision.
Do not freeze the initial severity when later facts change impact, scope, recovery, or notification duties.
Do not let technical responders make legal, privacy, continuity, customer, or public-communication decisions without the assigned authority.
Do not alter affected systems before considering volatile evidence, investigative needs, and the operational effect of the change.
Part 1 requires assessment, decision, response, documentation, closure, and lessons learned rather than treating detection or restoration as the full lifecycle.
Part 2 covers pre-assigned roles and authorities, testing, plan improvement, control changes, risk updates, and team evaluation.
5
Section 5
How does the lifecycle end and improve?
Define separate criteria for technical recovery, operational conclusion, and completion of follow-up. Technical recovery confirms that the service, data, or system has returned to an accepted state. Operational conclusion records final actions and status. Follow-up can remain open for evidence retention, regulatory or contractual reports, deeper investigation, risk treatment, control changes, or lessons-learned actions.
Part 2 calls for identifying improvement areas, changing the plan and controls, feeding results into risk assessment and management review, and evaluating the IRT. Assign each accepted change to an owner, due date, and verification method. Feed recurring incident themes from the incident register into planning and risk assessment.
Record who accepted recovery and closure, the criteria used, residual risk, and any open external duty.
Review both the response outcome and the capability: decisions, authorities, staffing, contacts, tools, communications, evidence handling, supplier support, and continuity handoffs.
Retest material changes through an exercise or controlled check and retain the result.
ISO's current listing identifies Part 2:2023, Edition 2, as the published guidance for preparation, testing, teams, relationships, training, and lessons learned.
Part 2 develops the preparation and learning phases through policy, plans, teams, relationships, support, training, testing, monitoring, and improvement.
Part 2 identifies the readiness, exercise, evaluation, and improvement records produced before and after response.
Show 2 more
Part 2 covers pre-assigned roles and authorities, testing, plan improvement, control changes, risk updates, and team evaluation.
Part 2 defines lessons-learned work across the plan, controls, risk assessment, management review, and IRT evaluation.
ISO's current listing identifies Part 3:2020, Edition 1, as published and under systematic review; it covers ICT response operations and excludes non-ICT incidents.
Part 3 supplies the detailed ICT operations and expressly excludes non-ICT response such as lost paper records.
Part 3 describes the ICT operational records created through detection, notification, triage, analysis, response, recovery, conclusion, and reporting.
Show 2 more
Part 3 maps ICT detection, notification, triage, analysis, containment, eradication, recovery, conclusion, and reporting to the broader management phases.
Part 3 covers ICT recovery, conclusion, reporting, and retention of response knowledge that feed the broader learning phase.
ISO's current listing identifies Part 1:2023, Edition 2, as the published foundation for the five-phase incident-management process.
Part 1 provides the five phases, the event-to-incident decision, response, documentation, and lessons-learned process.
Part 1 provides the management process, roles, communications, event report, incident log, register, and decision points that connect the operational activities.
Show 1 more
Part 1 requires assessment, decision, response, documentation, closure, and lessons learned rather than treating detection or restoration as the full lifecycle.