CyphrQ
Menu

ISO/IEC 27035 Explained: Incident Management, NIST and Deadlines

ISO/IEC 27035 is guidance for handling security incidents. Its parts, lifecycle, how it compares with NIST SP 800-61, and reporting clocks.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

10 min read

ISO/IEC 27035 is a series of guidance standards on how to handle information security incidents. It describes a lifecycle: prepare, detect, report, assess, respond and learn. It is guidance, not a certificate you can earn. Its value is a shared process your team, your suppliers and your auditors can point to when a real incident starts the clock on legal reporting duties.

What is ISO/IEC 27035 and who publishes it?

ISO/IEC 27035 is published jointly by ISO and the IEC. It is a multi-part series titled "Information security incident management". The foundation is Part 1, which the IEC webstore calls "the foundation of the ISO/IEC 27035 series". Its current edition is the second, published on 13 February 2023, and it replaces the 2016 edition.

You can find it in ISO's catalogue at iso.org/standard/78973.html. The edition details here come from the IEC webstore listings. The standard text is paid content. So everything below is my paraphrase, not a quote.

What are the parts of ISO/IEC 27035?

The series has four parts. Each covers a different slice of the same lifecycle.

Part Edition What it covers (my paraphrase of the abstract)
27035-1 Edition 2, February 2023 Concepts, principles and the overall process: preparing, detecting, reporting, assessing, responding and applying lessons
27035-2 Edition 2, 13 February 2023 How to plan and prepare, and how to learn lessons afterwards
27035-3 Edition 1, 16 September 2020 Operational guidance for ICT security operations: triage through containment, eradication, recovery and conclusion
27035-4 Edition 1, 2024 (month not checked) Coordination between several organisations working on the same incident

The dates for Parts 1 to 3 come from IEC webstore listings. The Part 4 date comes from catalogue listings in search results, not a checked page, so check the iso.org page before you quote it. The abstract for Part 3 says it builds on an earlier edition of Part 1, so expect its wording to lag the 2023 text.

What does ISO/IEC 27035 cover?

A useful way to read the series is as an answer to one question: what happens between "something looks wrong" and "we have learned from it"?

Part 1 names the activities. You prepare before anything happens. You detect events and report them. You assess whether an event is really an incident and decide what to do. You respond. Then you learn and improve. The term "event" matters: an event is something observed, such as an odd login, and only some events turn out to be incidents.

Part 2 expands the two ends of that loop. Its preparation side covers management commitment and an incident management policy, an incident management plan, an Incident Management Team, links with internal and external parties, and awareness and training. Its learning side covers finding and making improvements and evaluating the response team.

Part 3 covers the middle, from the viewpoint of the security operations team. Part 4 is for the moment when your incident involves other organisations, such as a supplier, a cloud provider or a national response team.

Can you be certified against ISO/IEC 27035?

The catalogue listings describe 27035 as generic guidance for organisations of any type or size, and as applicable to external providers of incident management services. None of them describes a certification scheme for it. So you cannot be "27035 certified" in the way you can be certified to ISO/IEC 27001.

What you can do is use it as the reference for the incident-management part of an information security management system. The SOC 2 vs ISO 27001 post explains how a certificate to the management-system standard works. An auditor of that system will want to see that incidents are handled consistently, and 27035 is a respectable description of what "consistently" looks like. It is also a good yardstick for a supplier who says "we have an incident process".

How does ISO/IEC 27035 relate to ISO/IEC 27001 and ISO/IEC 42001?

Information security has its own certifiable management system: ISO/IEC 27001. Incident management is one subject it expects you to cover, and 27035 supplies the detail of how. For the AI-specific sibling of 27001, see the ISO/IEC 42001 explainer. The Knowledge section lists more on the ISO Standards subtopic page.

How does ISO/IEC 27035 compare with NIST SP 800-61?

NIST SP 800-61 is the US counterpart most incident response teams know. The current revision is Revision 3. NIST's page describes it as "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile", final in April 2025, superseding Revision 2 from August 2012. Its stated aim is to help organisations prepare for incidents, reduce their number and impact, and improve detection, response and recovery.

ISO/IEC 27035 NIST SP 800-61 Rev. 3
Publisher ISO and IEC NIST (US)
Form A paid, multi-part standard series A free publication
Framing A lifecycle process, split across four parts Incident response as part of cybersecurity risk management, as a profile of NIST CSF 2.0
Certification None described in the catalogue listings None; NIST publishes recommendations
Typical user Organisations aligning to ISO management systems Organisations aligning to NIST CSF or US requirements

The practical difference is packaging. The two agree on the broad shape: be ready, find it, deal with it, learn from it. Rev. 3 puts the activity inside the wider NIST CSF 2.0 programme, which is why its title talks about risk management. This post draws on NIST's catalogue page, not the full PDF, so it does not map individual phases between the two. If you need a phase-by-phase crosswalk for an audit, build it from both documents yourself.

Choose by what your customers and regulators already speak. An ISO 27001 shop will find 27035 natural. A team reporting against NIST CSF will start from 800-61.

How does ISO/IEC 27035 line up with regulatory reporting clocks?

The standard does not set a deadline. Laws do, and they start counting from when you become aware or decide an incident is significant. Three examples, each linked to its source:

Rule Clock Starts when
UK GDPR, as explained by the ICO Report a notifiable breach not later than 72 hours After becoming aware of it
US SEC rules, adopted 26 July 2023 Form 8-K Item 1.05 disclosure, generally four business days After the company determines the incident is material
NIS2 Early warning, notification, final report Covered in the NIS2 post

In practice: notice that two of these clocks start from a judgement, "aware" or "material". That judgement is exactly the assessment and decision step in the 27035 lifecycle. If nobody is named to make it, and nobody writes down when it was made, you cannot show when the clock started. This is my reading, not wording from either source, so confirm it with your legal adviser.

The ICO page adds two details worth copying. If you do not yet have the full facts, you can provide information in stages. And you must keep a record of every personal data breach, whether or not you notify.

Going deeper: for security and IT teams

Start with definitions and a decision owner. Write down what counts as an event, an incident and a major incident in your organisation, and who may declare each. Part 1's assessment-and-decision step is where this lives. Record the timestamp of detection, the timestamp of the declaration and the name of the person who declared. Those three entries answer most regulator questions about when you knew.

Build the preparation set from Part 2. The evidence an auditor can ask for follows its list:

  • A signed incident management policy showing management commitment.
  • An incident management plan with severity criteria, escalation paths and communication templates.
  • A named Incident Management Team with roles, backups and out-of-hours contact details.
  • Contact records for internal teams and outside parties: legal, regulators, suppliers, your national response team or CSIRT, insurers.
  • Training and awareness records, including how staff report a suspicious event.

Map operations to Part 3. For the security operations team, Part 3's sequence is a good template for runbooks: triage, analysis, response, containment, eradication, recovery, conclusion. For each runbook, record the decision criteria, the data sources (identity provider logs, endpoint detection alerts, email gateway logs, firewall and DNS logs) and who approves containment steps that affect production, such as disabling an account or isolating a host. Keep an incident log with timestamps for every action. That log is your timeline for the final report.

Use Part 4 for supplier incidents. If a cloud or managed service provider is breached, you need a pre-agreed way to share information. Check your contracts for notification windows that are shorter than your own legal clock, because a supplier who tells you on day three has consumed most of a 72-hour period.

Close the loop. The learning side of Part 2 is where most programmes thin out. Hold a review within a fixed period after each significant incident, record root causes and owners for improvements, and track them to closure. Evaluate the team and the plan, not just the technical fix.

Common nonconformities, described generally:

  • A plan that exists but has never been tested by a tabletop exercise or a drill.
  • Incidents resolved but not recorded, so there is no trend data.
  • No evidence of lessons learned, or actions that never close.
  • Severity criteria that nobody uses, so every incident is handled ad hoc.
  • Supplier contracts with no incident notification terms.

Test the clock. Run a tabletop that starts at "we found suspicious activity" and see how long it takes to reach a decision about notification. Measure the gap between detection and declaration. The ransomware post has a first-hour sequence you can adapt as the scenario.

Mapping to related controls. ISO/IEC 27001 has a group of Annex A controls on incident management; look up the exact control numbers in your own copy of the 2022 edition, since the text was not checked here. NIST SP 800-61 Rev. 3 is useful as the second reference if you also report against NIST CSF 2.0.

Questions to ask a supplier or auditor: Which version of your incident process are you following? When did you last test it? Who can declare an incident, and how fast do you notify customers? Can I see the last lessons-learned record, redacted?

What should you do next about ISO/IEC 27035?

  • Write one-page definitions of event, incident and major incident, and name who declares each.
  • Add "detected at", "declared at" and "declared by" to your incident record.
  • Put your regulatory clocks in one table next to the plan, with who decides and who submits.
  • Run a tabletop with a stopwatch within the next quarter.
  • Check supplier contracts for incident notification windows.

Learn more

  • FIRST training materials: the global forum of incident response teams publishes CSIRT Basic Course modules, exercise guides and breach workshops under a Creative Commons BY-NC-SA 4.0 licence, for non-commercial use.
  • NIST SP 800-61 Rev. 3: the free comparison text, with the full PDF linked from the page.

Key takeaways

  • ISO/IEC 27035 is a four-part guidance series on information security incident management, not a certifiable standard.
  • Part 1 (second edition, February 2023) sets the lifecycle; Part 2 covers preparing and learning; Part 3 covers operations; Part 4 covers multi-organisation coordination.
  • NIST SP 800-61 Rev. 3 (April 2025) is the free US counterpart, framed within NIST CSF 2.0.
  • Laws, not the standard, set the clocks: 72 hours under UK GDPR, four business days after a materiality decision for SEC filers, and the staged NIS2 reports.
  • The assessment-and-decision step is where a clock may start, so name who decides and record when.

Sources