ISO/IEC 27035 is the international standard for information security incident management. It defines a structured, repeatable lifecycle for preparing for, detecting, reporting, assessing, responding to, and learning from security incidents, giving organizations a common process rather than improvised, ad hoc firefighting.
Most teams do not fail incident response because they lack tools. They fail because roles are unclear, reporting is inconsistent, and nobody feeds lessons back into the next round of preparation. ISO/IEC 27035 exists to close exactly those gaps. In this guide we walk through the standard’s structure, its lifecycle phases, how it fits alongside ISO 27001 and NIST SP 800-61, and how to build a response capability around it.
What is ISO/IEC 27035?
ISO/IEC 27035 is a multi-part standard in the ISO/IEC 27000 family. Rather than a single document, it is a series that separates high-level principles from the detailed operational guidance security teams need day to day. This modular design lets a small organization adopt the core process while a mature SOC layers on the deeper operational parts.
- ISO/IEC 27035-1:2023 — Principles and process, including the key activities of the incident management lifecycle.
- ISO/IEC 27035-2:2023 — Guidelines to plan and prepare for incident response, plus applying lessons learned.
- ISO/IEC 27035-3:2020 — Guidelines for ICT incident response operations, aimed at detection and technical handling.
- ISO/IEC 27035-4 — Later part extending guidance toward coordination and information sharing.
The guidance is deliberately generic. ISO states it applies to all organizations regardless of type, size, or nature, and expects each one to tailor it to their own information security risk situation.
The ISO 27035 incident lifecycle phases
The heart of the standard is a cyclical, five-phase lifecycle. Each phase produces inputs for the next, and the final phase loops directly back into the first, creating continual improvement rather than a one-off runbook.
- Plan and prepare — Establish an incident management policy, assign roles and an incident response team, define communication paths, build playbooks, and provision detection and forensic tooling.
- Detection and reporting — Monitor systems, accept user reports, and collect signals so events are captured, logged, and routed for triage.
- Assessment and decision — Triage each event, confirm whether it is a genuine incident, assign severity based on business impact, and authorize the response.
- Responses — Contain the threat, eradicate malicious artifacts, recover systems from validated backups, and keep stakeholders informed throughout.
- Lessons learned — Review what happened, update controls, procedures, and tooling, and feed the improvements back into the plan and prepare phase.
The average time to identify and contain a data breach fell to 258 days in 2024, a seven-year low, while the global average breach cost rose to a record USD 4.88 million (Source: IBM Cost of a Data Breach Report, 2024). A disciplined ISO 27035 lifecycle is how organizations shrink that window.
How ISO 27035 complements ISO 27001
ISO/IEC 27001 sets the requirements for an information security management system (ISMS) but stays deliberately high-level about how you actually run incident response. ISO/IEC 27035 fills that gap with the operational detail. The two are designed to work together, and ISO 27035 includes a reference table cross-mapping its content back to ISO 27001.
In the 2013 revision, incident management lived in Annex A.16. In ISO/IEC 27001:2022, those requirements were consolidated into Annex A controls 5.24 through 5.28, covering incident planning and preparation, assessment and decision on events, response, learning from incidents, and collection of evidence. ISO 27035 gives you the process to satisfy each of these controls in practice, so certification auditors see a working capability rather than a policy on paper.
Adopting ISO 27035 is one of the most direct ways to demonstrate evidence for ISO 27001 Annex A controls 5.24–5.28 — the incident lifecycle it defines maps almost one-to-one onto what an auditor expects to see.
ISO 27035 and NIST SP 800-61
There is substantial overlap between ISO/IEC 27035 and NIST SP 800-61, the US guide to computer security incident handling. Both describe the same broad lifecycle, differing mainly in terminology and emphasis. A common pattern is to use ISO 27035 as the governance and management overlay that aligns with your ISMS, while drawing on NIST SP 800-61 for hands-on technical detection, analysis, containment, and eradication playbooks. The two frameworks reinforce rather than replace each other.
Building an incident response capability with ISO 27035
Standing up a capability is a program, not a document. Start in the plan and prepare phase: write a concise incident management policy, name an accountable owner, and formalize the incident response team with clear escalation paths. Define what qualifies as an event versus a reportable incident so triage is not left to guesswork.
Next, make reporting frictionless. If staff cannot report a suspicious event in seconds, detection stalls. Wire up monitoring and alerting, agree a severity scale tied to business impact, and pre-authorize response actions so the team is not seeking permission mid-crisis. Document containment and recovery playbooks for your most likely scenarios, and rehearse them with tabletop exercises before a real incident forces the test.
Finally, treat lessons learned as mandatory, not optional. Hold a structured post-incident review, capture concrete actions, and route them back into policies, controls, and playbooks. That closing loop is what separates a mature ISO 27035 capability from a binder that gathers dust, and it is the discipline that steadily brings your detection and containment times down.