ISO/IEC 27035 Incident Management Guide

Many organisations have an incident response plan but no incident management system around it: nobody owns preparation, lessons are written and never acted on, and the plan is tested only by a real incident. ISO/IEC 27035 is the international standard series for information security incident management, and it treats response as one phase in a cycle that starts with planning and ends with learning. This guide summarises what each published part covers, how the series fits an ISO/IEC 27001 information security management system and NIST SP 800-61 Rev. 3, and how to build and evidence a capability that follows it. It describes the standards from their official ISO catalogue entries and does not reproduce their text. It is written for incident response leads, ISMS managers, SOC managers and the executives accountable for incident readiness.

Key takeaways

The series is guidance, not a certifiable standard. Organisations certify against ISO/IEC 27001; ISO/IEC 27035 explains how to meet its incident controls well.
Five phases, not one. Part 1 sets out plan and prepare, detection and reporting, assessment and decision, response, and learn lessons. Most failures happen in the first and last.
Parts 1 and 2 were revised in 2023. Part 3 (ICT incident response operations, 2020) completed a systematic review in December 2025, with the outcome not yet shown on the ISO page.
Distinguish events, incidents and vulnerabilities. Triage depends on a shared definition of when an event becomes an incident and who decides.
Plan for identity in every phase. Preparation must include who can revoke service account credentials, tokens and keys, and how dependent services keep running.

What it is and who it applies to

ISO/IEC 27035 is developed by ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection). According to the ISO catalogue, its guidance is generic and intended for organisations of any type, size or nature, adapted to their business and risk situation, and it also applies to external providers of incident management services such as managed detection and response and retained incident response firms.

Part	Title	Edition and status (ISO catalogue, checked 24 October 2026)	Scope in brief
ISO/IEC 27035-1:2023	Information security incident management, Part 1: Principles and process	Edition 2, published February 2023; replaces the withdrawn 2016 edition	Foundation of the series: concepts, principles and a process with key activities from preparation to lessons learned
ISO/IEC 27035-2:2023	Part 2: Guidelines to plan and prepare for incident response	Edition 2, published February 2023; replaces the withdrawn 2016 edition	The plan and prepare and learn lessons phases of Part 1
ISO/IEC 27035-3:2020	Part 3: Guidelines for ICT incident response operations	Edition 1, published September 2020; systematic review closed 3 December 2025, outcome not shown	Detection, reporting, triage, analysis, response, containment, eradication, recovery and conclusion in ICT security operations; excludes non-ICT incidents such as lost paper documents

Part 3 was written against the 2016 edition of Part 1, so terminology may not line up exactly with the 2023 parts. Check the ISO catalogue for any further part or revision before citing the series in a contract or policy.

Who should adopt it: any organisation with an ISO/IEC 27001 ISMS (Annex A incident controls expect a defined approach), providers of incident response or SOC services, and public bodies that need an internationally recognised reference for their incident procedures.
Where it is weaker: it is process guidance, not a technical playbook. Pair it with technique-level material such as the Digital Forensics (DFIR) Guide and the SOC Runbook Template.

Structure and key requirements

Part 1 describes the incident management process as five phases. The table summarises what each phase means in practice and which part goes deeper. The descriptions are NHI Mgmt Group's operational interpretation, not text from the standard.

Phase	What it involves	Detailed in	Typical outputs
Plan and prepare	Management commitment, incident management policy, plan, team, external relationships, tools and training	Part 2	Policy, plan, team charter, contact lists, tooling, training records
Detection and reporting	Monitoring, user and third-party reporting, recording events	Part 3	Event records, alert sources, reporting channels
Assessment and decision	Triage of events, deciding whether an event is an incident, classifying severity	Part 3	Classification, severity, escalation decision
Response	Analysis, containment, eradication, recovery, communication and conclusion	Part 3	Incident log, evidence, recovery confirmation, closure record
Learn lessons	Identifying and implementing improvements and evaluating the response team	Part 2	Post-incident review, action log, updated plan and controls

Plan and prepare, as Part 2 frames it

The ISO catalogue abstract for Part 2 lists the elements of preparation. Each one is a deliverable you can assign and audit:

Management commitment and policy: a signed incident management policy stating scope, authority to act (for example, to isolate systems or revoke credentials) and reporting duties.
Security policies at every level: organisational, system, service and network policies, including risk management, that reference the incident process.
Incident management plan: severity scheme, escalation paths, decision rights, communication rules and links to business continuity. See the Incident Response Plan Template.
Incident management team: the standard distinguishes an incident management team from the response team that carries out technical work; define both, with deputies.
Internal and external relationships: legal, HR, communications, suppliers, cloud providers, regulators, law enforcement and national CSIRTs, agreed before they are needed.
Technical and other support: logging, forensic tooling, out-of-band communications, spare credentials for responders.
Awareness and training: staff know how to report, responders practise. See the Tabletop Exercise Guide.

Events, incidents and vulnerabilities

The series separates an information security event (an occurrence that may indicate a breach of security or failure of controls), an information security incident (one or more related events that can harm the organisation) and a vulnerability (a weakness that has not yet been exploited). Getting this right matters for triage volume: if every event is an incident, the team drowns; if the threshold is unclear, real incidents wait in a queue. Write the decision criteria down, name who makes the call out of hours, and record reported vulnerabilities through vulnerability management rather than the incident queue.

Identity and NHI requirements

ISO/IEC 27035 is technology-neutral, but compromised credentials, tokens and keys feature in many incidents. Build these into each phase:

Prepare: maintain an inventory of service accounts, workload identities, API keys and certificates with owners and dependencies, so responders can tell what breaks if they revoke one. See the Service Account Inventory Template.
Prepare: give responders their own break-glass accounts and out-of-band communications that do not depend on the identity provider under attack.
Detect: include identity telemetry such as new credentials added to cloud applications (ATT&CK T1098.001 Additional Cloud Credentials), use of valid cloud accounts from unusual locations (T1078.004) and application token theft (T1528).
Respond: treat credential revocation and rotation as containment steps with their own runbooks; rotating a key without checking for persistence (new keys, new OAuth grants) leaves the attacker inside. See the Identity Incident Response Playbook and the Secrets Rotation Runbook Template.
Learn: post-incident reviews should ask why a credential was exposed and long-lived, not only how the attacker used it.

The Microsoft Storm-0558 key breach shows the detection and learning phases at work: the US State Department's SOC spotted anomalous mail access using premium audit logging and a custom alert on MailItemsAccessed, and reported it to Microsoft. Organisations without that logging tier could not see the same activity, and the subsequent Cyber Safety Review Board review traced the root cause to a signing key that should have been retired years earlier.

Implementation steps

Gap assessment. Compare your current policy, plan, team and records against the five phases and the Part 2 preparation elements. Score each as absent, partial or in place with evidence.
Policy and authority. Get the incident management policy approved by top management, including explicit authority for the incident manager to isolate systems and revoke credentials without waiting for change approval.
Classification and severity. Define event, incident and severity criteria with examples, including identity scenarios (leaked API key, compromised admin account, malicious OAuth app). Test them against 20-30 historical tickets.
Team and relationships. Name the incident management team and response team with deputies, sign retainers with external responders if needed, and record regulator and supplier contacts, including notification deadlines that apply to you such as NIS2 or DORA.
Detection and reporting channels. Confirm log sources, retention and alert routing; publish one simple reporting route for staff and one for third parties.
Runbooks for response. Write runbooks for the top 5-8 incident types, covering containment, evidence preservation, eradication and recovery, and how to roll back a containment action that breaks a critical service.
Exercise. Run a tabletop against the plan, then a technical exercise. Fix what fails before declaring the capability operational.
Learn lessons formally. Hold a post-incident review for every significant incident and exercise, track actions to closure and update the plan. See the Post-Incident Review and Root Cause Analysis Template.

Small and large organisations

Small organisations: the incident management team may be two or three people plus an external retainer. The plan should name the provider, how to activate them, and which decisions stay in-house (notifying regulators, paying for recovery).
Large and federated organisations: define how business-unit teams escalate to a central team, how incidents spanning units are coordinated, and how severity is kept consistent.
Service providers: the catalogue states that the series applies to external providers. Map your service to the phases so customers can see which phases you perform and which remain theirs.

Evidence and assessment

There is no ISO/IEC 27035 certificate. Conformance is shown through the ISO/IEC 27001 audit, customer and regulator assessments, and internal audit. These records carry most of the weight:

Evidence	Phase	What an assessor looks for
Approved policy and plan with version history	Plan and prepare	Top management approval, review within the stated period, authority to act
Team roster, contact lists, retainers	Plan and prepare	Named deputies, contacts tested recently
Training and exercise records	Plan and prepare	Exercises held, findings tracked
Event and incident register	Detection, assessment	Consistent classification, timestamps for detection, triage and escalation
Incident logs and evidence chain of custody	Response	Decisions recorded with time and owner; evidence handled to a defined procedure
Post-incident reviews and action log	Learn lessons	Actions closed, controls or plan changed as a result

Metrics

Mean time to detect and to contain, by severity, measured from the incident log rather than estimated.
Triage accuracy: share of events escalated as incidents that are confirmed, and incidents found later that were initially closed as events.
External detection rate: share of incidents first reported by a third party, a supplier or a regulator rather than your own monitoring.
Lessons-learned closure: percentage of post-incident actions closed by their due date.
Exercise coverage: number of top incident types exercised in the last 12 months.
Credential containment time: time from confirming a compromised credential to its revocation and replacement.

Mapping to other frameworks

NIST SP 800-61 Rev. 3, published in April 2025 and superseding Rev. 2 (2012), recasts incident response as a CSF 2.0 Community Profile rather than a standalone life cycle. ISO/IEC 27035 keeps a dedicated process model. The two align well; use 27035 to structure the process and 800-61r3 to tie it to CSF outcomes. See the NIST SP 800-61 Incident Response Guide.

ISO/IEC 27035 phase	ISO/IEC 27001:2022 Annex A	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Plan and prepare	A.5.24 Information security incident management planning and preparation	GV.PO, RC.RP	IR-1, IR-2, IR-3, IR-8
Detection and reporting	A.6.8 Information security event reporting; A.8.15 Logging; A.8.16 Monitoring activities	DE.CM, DE.AE	IR-5, IR-6, AU-6
Assessment and decision	A.5.25 Assessment and decision on information security events	RS.MA, RS.AN	IR-4
Response	A.5.26 Response to information security incidents; A.5.28 Collection of evidence	RS.MI, RS.CO, RC.CO	IR-4, AU-9
Learn lessons	A.5.27 Learning from information security incidents	ID.IM	IR-4

CIS Controls v8.1 Control 17 (Incident Response and Management) covers the same capability at safeguard level. For sector rules on reporting timelines, see the NIS2 Directive Guide and the DORA Guide.

Common pitfalls

Plan without authority: the plan says "isolate the host" but the responder must raise a change request first, and containment waits hours.
Lessons learned as a document, not a change: reviews are written, filed and never turned into closed actions, so the same incident recurs.
Detection depends on optional logging: key audit logs are off, sampled or kept too briefly, as the Storm-0558 case showed for organisations without premium logging.
Responders rely on the compromised identity platform: when the identity provider or email is under attacker control, the team cannot communicate or sign in to its tools.
No dependency map for credentials: responders hesitate to revoke a leaked service account key because nobody knows what depends on it.
Outsourced response without defined boundaries: the provider assumes the customer will contain, the customer assumes the provider will, and neither does.

Practitioner checklist

Confirm current editions of each ISO/IEC 27035 part on the ISO catalogue before citing them in policy.
Approve an incident management policy that grants authority to isolate systems and revoke credentials.
Write event, incident and severity criteria with identity examples and test them against past tickets.
Name the incident management team and response team with deputies and out-of-band contacts.
Keep an owned inventory of service accounts, keys and certificates with their dependencies.
Write runbooks for the top incident types, including containment rollback and evidence handling.
Exercise the plan at least annually and after major changes, and track findings to closure.
Map your process to ISO/IEC 27001 A.5.24 to A.5.28 and keep the evidence listed above.
Report detection, containment and lessons-learned closure metrics to leadership each quarter.

ISO/IEC 27035 Incident Management Guide: Principles, Process and Readiness