ISO/IEC 27035 Series: ISO/IEC 27035 Series – Tutorial (about 60 minutes)

The ISO/IEC 27035 series is the international guidance for information security incident management: how an organisation gets ready for security incidents, notices them, decides what they are, responds to them and learns from them. Security managers, security operations centre (SOC) teams, IT operations, risk and compliance staff and auditors use it to design and check their incident capability. After this tutorial you will be able to explain the five-phase incident management process, find your way around the four parts of the series, and plan a practical incident capability that would stand up to an ISO/IEC 27001 audit.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: ISO/IEC 27035 is a multi-part series published jointly by ISO and IEC through subcommittee ISO/IEC JTC 1/SC 27 (Information security, cybersecurity and privacy protection), under the common title "Information technology – Information security incident management". The current parts are: Part 1, Principles and process (ISO/IEC 27035-1:2023, second edition, replacing the 2016 edition); Part 2, Guidelines to plan and prepare for incident response (ISO/IEC 27035-2:2023, second edition, replacing the 2016 edition); Part 3, Guidelines for ICT incident response operations (ISO/IEC 27035-3:2020, first edition); and Part 4, Coordination (ISO/IEC 27035-4:2024, first edition, published December 2024). Parts 1 and 2 were revised to line up with the incident controls of ISO/IEC 27002:2022. Part 3 went through its periodic systematic review in 2025 (the review closed in December 2025); the ISO catalogue does not yet show the outcome and the 2020 edition is still listed as published, so this course teaches it and you should check the catalogue for any later decision. The series began as a single standard, ISO/IEC 27035:2011, which itself replaced the technical report ISO/IEC TR 18044. All parts are guidance documents: they recommend, they do not impose certifiable requirements. Verified 2026-10-29 from the ISO catalogue entries for each part (life-cycle stage and edition) and the ISO27k reference pages on each part.

Who this is for: people who are new to formal incident management. That includes engineers who are joining an on-call or SOC rota, IT and service managers who will own an incident plan, information security and risk officers preparing for an ISO/IEC 27001 audit, and consultants or auditors who keep seeing "27035" cited in policies and want to know what it actually says.

Prerequisites: none. A general idea of what an information security management system (ISMS) is will help in Lesson 7, but every term is explained when it first appears. This course paraphrases the standards; anyone implementing them should buy the official texts from ISO, IEC or a national standards body, because standards text is copyrighted.

By the end of this tutorial:

You will be able to explain why incident management needs a planned, repeatable process and what the ISO/IEC 27035 series covers and leaves out.
You will be able to use the core vocabulary correctly, including event, incident, vulnerability, triage, containment, eradication, recovery and lessons learned.
You will be able to describe the five phases of the incident management process and say which part of the series gives the detailed guidance for each.
You will be able to outline the documents, teams, relationships and tests an organisation needs before an incident happens.
You will be able to explain how conformity is checked, and why there is no ISO/IEC 27035 certificate for an organisation.
You will be able to follow a realistic incident from first alert to improvement actions, including coordination with suppliers and partners.
You will be able to compare the series with ISO/IEC 27001, ISO/IEC 27002, ISO 22301, the digital evidence standards and NIST SP 800-61.

Lesson 1 – Origins, purpose and scope

Incidents are going to happen

No set of security controls is perfect. Staff click on convincing phishing messages, software ships with flaws nobody has found yet, suppliers get breached, laptops are left on trains and attackers keep changing their methods. A starting assumption of the ISO/IEC 27035 series is that some incidents will get through, however good the preventive controls are. What separates a well-run organisation from a badly run one is not whether incidents occur but how quickly they are noticed, how calmly and effectively they are handled, and whether the same thing is prevented from happening again.

Organisations without a planned approach tend to make the same mistakes. Nobody knows who should be called at two in the morning. The person who notices something odd does not know where to report it, or fears being blamed. Technical staff wipe and rebuild an infected server before anyone has captured what happened, destroying the evidence needed to find out how far the attacker got. Managers learn about the breach from a journalist. Customers and regulators are told too late or too much. When the dust settles, nobody writes down what went wrong, so the next incident goes the same way.

The ISO/IEC 27035 series exists to replace this improvisation with a structured, repeatable capability. It describes a lifecycle that starts long before any alarm goes off, with policy, planning, people, tools and relationships, and that ends with learning that feeds back into the controls. The guidance is meant to apply to any organisation, whatever its size, sector or type, and can be scaled down for a small company or up for a multinational group.

From a technical report to a four-part series

International work on this topic started with a technical report, ISO/IEC TR 18044, in 2004. In 2011 it was turned into a full international standard, ISO/IEC 27035:2011, which placed incident management firmly inside the ISO/IEC 27000 family of information security standards. Experience showed that one document could not serve both the managers who design an incident capability and the analysts who do the hands-on work, so the material was split into parts. Parts 1 and 2 were published in 2016, Part 3 in 2020, Parts 1 and 2 were revised in 2023, and Part 4 on coordination across organisations followed at the end of 2024.

The 2023 revision of Parts 1 and 2 was largely driven by ISO/IEC 27002:2022, the catalogue of information security controls, which reorganised its incident management controls. Because many organisations implement ISO/IEC 27035 to satisfy those controls within an ISO/IEC 27001 ISMS, keeping the two in step matters. The revision also refreshed terminology and strengthened guidance on relationships with internal and external parties.

What the series covers

Taken together, the parts give guidance on:

the principles behind good incident management and the overall process;
planning and preparing: policies, plans, teams, tools, awareness, training and testing;
detecting and reporting information security events, and deciding which of them are incidents;
responding to incidents, from containment through recovery, including the collection of evidence;
learning lessons and turning them into improvements;
the day-to-day operations of an ICT incident response function; and
coordinating a response when several organisations are involved in the same incident.

What it does not cover

The series is not a catalogue of preventive security controls; those live in ISO/IEC 27002 and similar frameworks. It is not a business continuity standard, although serious incidents can trigger continuity plans; ISO 22301 covers that. It does not give detailed forensic procedures for handling digital evidence; the ISO/IEC 27037, 27041, 27042 and 27043 standards do. It does not tell you which laws apply to your organisation or set legal notification deadlines; it reminds you that legal and regulatory duties must be identified and built into your plan. And, importantly, it does not prescribe tools, products or a specific team size. It describes what needs to exist and why, leaving each organisation to decide how.

Why "information security" and not just "cyber"

The series speaks of information security incidents rather than only cyber attacks. An incident can be a malware outbreak, but it can equally be a lost unencrypted laptop, a misdirected email containing customer records, an employee copying files before resigning, or a physical break-in to a server room. The process is the same: something happens that may harm the confidentiality, integrity or availability of information, someone notices, someone decides what it is and how serious it is, the organisation responds, and then it learns. Part 3 does focus on ICT operations, but Parts 1 and 2 are written broadly enough for non-technical incidents too.

Lesson 2 – Key concepts and vocabulary

The series has its own vocabulary, defined in Part 1 and aligned with ISO/IEC 27000. The definitions below are paraphrased. Getting them right matters, because many arguments during real incidents come from people using the same word for different things.

Information security event – any observed occurrence that suggests information security may have been breached or a control may have failed, or a situation not seen before that could be security relevant. An alert from an antivirus tool, a report of a suspicious email or an unusual login are all events. Most events turn out to be harmless.
Information security incident – one or more related events that could harm the organisation's assets or compromise its operations. Every incident starts as at least one event, but only a minority of events become incidents.
Information security vulnerability – a weakness of an asset or control that could be exploited. Reporting a vulnerability is not the same as reporting an incident: nothing may have happened yet, but the weakness still needs handling.
Information security incident management – the whole set of activities for preparing for, detecting, reporting, assessing, responding to and learning from incidents. It is broader than "incident response", which is only one phase.
Incident response – the actions taken to mitigate or resolve an incident once it has been confirmed, including protecting and restoring normal operations.
Incident management team (IMT) – the people with the authority and skills to manage incidents across their lifecycle: they own the plan, decide on classification and escalation, and coordinate the response. Earlier editions and much older material use the acronym ISIRT (information security incident response team) for a similar idea.
Incident response team (IRT) – the people who carry out the response activities for a given incident, such as analysis, containment and recovery. An IRT can be permanent (for example a SOC or CSIRT) or assembled for one incident, and can include external specialists.
Point of contact (PoC) – the person or function to whom events are reported and who carries out the first check of each report. In many organisations this is the service desk or a SOC analyst on shift.
Triage – a quick sorting of reported events to decide whether they need attention, how urgent they are and who should handle them. The word comes from emergency medicine.
Containment – actions that stop an incident from spreading or causing more harm, such as isolating a host, disabling an account or blocking a domain. Containment buys time; it does not remove the cause.
Eradication – removing the cause and the attacker's footholds, for example deleting malware, closing the exploited vulnerability and resetting stolen credentials.
Recovery – restoring affected systems and services to normal operation and confirming they are clean and working.
Incident management plan – the documented description of how the organisation will handle incidents: scope, roles, classification scheme, procedures, communication paths, tools and records.
Lessons learned – the structured review after an incident (or an exercise) that identifies what worked, what did not and what will change. The series treats this as a full phase, not an optional extra.
Digital evidence – information stored or transmitted in digital form that may be relied on, for example in a disciplinary hearing, an insurance claim or a court. Its value depends on how carefully it was collected and preserved.

Events, incidents and vulnerabilities in practice

The distinction between events and incidents is the backbone of the process. Think of a busy SOC that receives ten thousand alerts per day. If each one were treated as an incident, the team would collapse. Instead, the PoC filters events, discards false positives, and passes the doubtful ones to the IMT for a proper assessment. Only those that are confirmed as incidents enter the response phase. This funnel protects scarce expert time and makes statistics meaningful: "we had 12 incidents this quarter" is useful only if everyone counts them the same way.

Vulnerabilities follow a parallel path. When a staff member reports that a shared folder is open to everyone, or a researcher reports a flaw in your web application, there may be no evidence of misuse. The series wants these reports welcomed and handled, often by passing them to vulnerability management, while still checking whether the weakness has already been exploited. A good reporting scheme therefore accepts both kinds of report through the same simple channel.

Severity and classification

The series recommends that each organisation defines a classification scheme: categories (for example malware, unauthorised access, data leakage, denial of service, physical loss) and a severity scale based on the impact on the business. Part 2 gives example approaches in an annex but does not impose a scale. A typical scheme might use four levels from low to critical, with clear criteria such as the number of people or customers affected, the sensitivity of the data, the effect on key services and the likely legal or reputational consequences. The point of severity is to drive decisions: who must be informed, how fast, which resources may be used and when continuity plans should be considered.

Lesson 3 – Structure of the series

The four parts are designed to be read together. Part 1 sets the frame; Parts 2 and 3 zoom in on particular phases; Part 4 extends the picture beyond one organisation's walls.

Figure 1 – How the four parts of ISO/IEC 27035 fit together, with the digital evidence standards supporting operations.

Part 1 – Principles and process (2023)

Part 1 is the foundation. After the usual scope, references and terms, it gives an overview of incident management: its objectives, the benefits of a structured approach and the basic concepts. It then describes the five-phase process, explaining what each phase aims to achieve and the main activities in it. Its annexes connect the process to the standards on investigation and evidence, give examples of incidents and their causes, cross-reference the incident-related requirements and controls of ISO/IEC 27001 to the parts of the series, and discuss situations that may be discovered during an investigation, such as finding evidence of a different wrongdoing. Anyone using the series should read Part 1 first.

Part 2 – Guidelines to plan and prepare for incident response (2023)

Part 2 gives detailed guidance for the first and last phases of the process, "plan and prepare" and "learn lessons". Its main clauses walk through, in a logical order:

writing an incident management policy;
updating other security policies so they support incident management;
creating an incident management plan;
establishing the incident management capability (the teams and their roles);
establishing internal and external relationships, a clause added in the 2023 edition;
defining technical and other support, such as tools, communication channels and facilities;
awareness and training for everyone who may report or handle incidents;
testing the incident management plan through exercises; and
learning lessons after incidents and exercises.

Its annexes give examples that many organisations adapt: example report forms, example approaches to categorising and rating incidents, and notes on legal and regulatory aspects such as privacy.

Part 3 – Guidelines for ICT incident response operations (2020)

Part 3 is the most hands-on part. It is written for the operational function that handles ICT incidents, typically a SOC, CSIRT or security operations team, and looks at people, process and technology. After an overview it describes common types of attack and then a chain of operations: incident detection, notification, triage, analysis, containment with eradication and recovery, and incident reporting. An annex gives example criteria for turning observed security events into incidents. Part 3 was written against the process model of the 2016 edition of Part 1, but its operations map directly onto the detect, assess and respond phases. It complements Part 1: where Part 1 says what the detection and response phases need to achieve, Part 3 describes how an operations team runs them every day.

Part 4 – Coordination (2024)

Modern incidents rarely stay inside one organisation. A breach at a cloud provider, a managed service provider or a software supplier can affect hundreds of customers at once; a ransomware attack on one company may involve its insurer, its outsourced IT provider, a forensic firm, law enforcement and a national CSIRT. Part 4 gives guidance for several organisations handling an incident in a coordinated way, and for a coordination team where one exists. It covers an overview of coordinated incident management, the coordinated process itself, guidance for the key coordinated activities such as sharing information and agreeing actions, and an annex of examples. It also discusses how taking part in coordination changes an organisation's own internal incident management.

Reading the "should" language

All four parts are written as guidance. Their recommendations use "should" rather than "shall". This is a key structural fact: unlike ISO/IEC 27001, which contains auditable requirements, ISO/IEC 27035 offers a model of good practice that you adapt. You can document that your process "follows ISO/IEC 27035", but nobody can certify you against it as a management system. Lesson 5 returns to this point.

Lesson 4 – How it works in practice

The heart of the series is a five-phase process described in Part 1. The phases are presented in order, but in reality they overlap and loop: a response often uncovers new events, and learning feeds back into preparation.

Figure 2 – The five-phase incident management process of ISO/IEC 27035-1, with learning feeding back into preparation.

Phase 1 – Plan and prepare

Everything that makes a good response possible is done in advance. Following Part 2, an organisation typically:

Writes a policy. A short, management-approved statement of why incident management matters, what it covers, who is responsible, that all staff must report suspected events, and that reporting in good faith will not be punished.
Builds the plan. The plan describes the classification scheme, roles, escalation paths, procedures for common incident types (often called playbooks or runbooks), communication rules, record keeping and links to continuity and crisis management.
Sets up the teams. It decides the shape of the IMT and IRTs: in-house, outsourced (for example a managed detection and response service) or a mix. It names deputies, defines on-call arrangements and sets decision rights, such as who may take a business-critical system offline.
Establishes relationships. Internally with legal, HR, communications, IT operations, facilities and senior management; externally with suppliers, cloud providers, insurers, forensic specialists, national CSIRTs, regulators and law enforcement. Contacts and expectations are agreed before they are needed.
Prepares technical support. Logging and monitoring, a ticketing or case management tool, secure communication channels that still work if email is compromised, forensic tooling, clean recovery media and an up-to-date asset inventory.
Trains people. General awareness for all staff on what and how to report, and deeper training for responders.
Tests the plan. Tabletop exercises, technical simulations and full-scale exercises reveal gaps before a real incident does.

Phase 2 – Detect and report

Events come from two broad sources: technology (security monitoring, intrusion detection, endpoint tools, log analytics, alerts from cloud services) and people (employees, customers, suppliers, researchers, even the press). The plan should make reporting easy and well known: one phone number, one email address or one web form that everyone can find. Reports should capture the basic facts (who noticed what, when and where) without asking reporters to diagnose the problem. The PoC records each report, acknowledges it and performs a first check.

A theme throughout the series is that people must feel safe reporting. If an employee who clicked a phishing link expects punishment, they will stay silent and the attacker gains hours or days. Policies that reward early reporting produce more, and earlier, reports.

Phase 3 – Assess and decide

Assessment happens in two steps. First, the PoC makes a quick check: is this obviously a false alarm, a known issue, or something that needs a closer look? Second, for anything doubtful, the IMT assesses whether the event is an information security incident, classifies it by category and severity, and decides how to proceed: which team responds, who must be informed, whether external help is needed and whether to invoke crisis or continuity arrangements. Decisions and their reasons are recorded, because they may be questioned later.

Figure 3 – How a reported event is sorted: first check by the point of contact, then assessment and classification by the incident management team.

Phase 4 – Respond

Response begins with the most urgent question: how do we stop the harm from growing? Containment options range from gentle (increasing monitoring, blocking one address) to drastic (disconnecting a whole site). The choice depends on severity, the business cost of the action and the need to preserve evidence. Part 3 describes the operational sequence used by most response teams:

Figure 4 – The chain of ICT incident response operations described in ISO/IEC 27035-3, grouped into three stages.

Analysis aims to understand what happened, how, since when and with what effect: which systems and accounts are affected, what the attacker did, and whether data was taken. Containment is applied as soon as enough is understood to choose the right action; analysis often continues in parallel. Eradication removes the root cause. Recovery restores services, often from known-good backups, with extra monitoring for signs that the attacker is back. Throughout, the team keeps a timeline, records decisions and preserves evidence in a way that keeps its integrity: who collected what, when, how, and who has had it since (the chain of custody). When legal action or insurance claims are possible, evidence collection follows the ISO/IEC 27037 family of guidance or uses specialists.

Communication runs alongside the technical work. Senior management needs regular, plain-language status updates. Legal and privacy specialists check whether notification duties apply, for example to data protection authorities or sector regulators. Communications teams prepare messages for staff, customers and the media. Suppliers and partners may need to act too, which is where Part 4's coordination guidance helps.

An incident is closed when the response objectives are met, services are back to normal, records are complete and follow-up actions have owners. Closing too early, while the attacker still has a foothold, is a classic failure.

Phase 5 – Learn lessons

Soon after closure, the people involved review the incident: what happened, what went well, what did not, and why. Good reviews are blameless in tone, focused on systems and decisions rather than individuals, and produce specific actions with owners and deadlines. Typical outputs include new or improved controls, updated playbooks, better monitoring rules, changes to the classification scheme, training needs and updates to the risk assessment. Part 2 encourages lessons from exercises and near misses as well as real incidents, and suggests looking at trends across many incidents: are the same root causes recurring, are detection times improving?

Roles and records across the phases

The series is flexible about organisation charts, but the following roles usually appear in some form: a senior sponsor who approves the policy and resources; an incident manager or IMT lead who coordinates; the PoC function; one or more IRTs; specialists from legal, HR, privacy, communications and IT operations; and external parties such as suppliers and authorities. Typical records include the event log, incident tickets, the classification and decision log, the incident timeline, evidence register, communications log, final incident report and lessons-learned report. These records are what an auditor or regulator will ask for later.

Lesson 5 – Assessment, certification and compliance

No organisational certificate for ISO/IEC 27035

Because all parts of ISO/IEC 27035 are guidance documents, there is no accredited certification scheme that certifies an organisation "to ISO/IEC 27035". Certification bodies certify management systems against requirements standards. If a supplier tells you it is "ISO 27035 certified", ask exactly what they mean: usually it means their ISO/IEC 27001 certificate covers an incident process based on ISO/IEC 27035, or that some staff hold a personal training certificate.

Where the audit actually happens: ISO/IEC 27001

The most common way the series is assessed is indirectly, through an ISO/IEC 27001 certification audit. ISO/IEC 27001:2022 Annex A includes a group of incident-related controls that correspond to the guidance in ISO/IEC 27002:2022. In paraphrase, they cover: planning and preparing for incident management (control 5.24); assessing events and deciding whether they are incidents (5.25); responding to incidents (5.26); learning from incidents (5.27); collecting evidence (5.28); and staff reporting of observed or suspected events (6.8). The overlap with the five phases is deliberate, and Part 1 contains a cross-reference annex for exactly this purpose.

During an ISO/IEC 27001 audit, an auditor will typically look for:

a documented incident management policy and plan, approved and current;
clear roles, with named people and deputies;
a reporting channel that staff actually know about, which the auditor may test by asking employees;
incident records showing classification, decisions, actions and closure;
evidence that lessons were identified and that the resulting actions were completed;
records of exercises and how their findings were handled; and
evidence-handling arrangements proportionate to the organisation's risks.

An auditor will usually sample a few incidents and follow each from report to lessons learned. A plan that looks perfect on paper but has no matching records is a weak position; a modest plan with consistent, complete records is a strong one.

Other forms of assessment

Many organisations use the series as a yardstick in other ways:

Internal audits and gap assessments compare current practice phase by phase with the guidance and list improvements.
Maturity assessments rate the capability on a scale. The series itself defines no maturity levels, so organisations borrow models from elsewhere, for example CSIRT maturity models used by the incident response community, and map them to the five phases.
Exercises are an assessment in action: a well-designed exercise shows whether the plan works under time pressure.
Customer and regulator reviews often ask suppliers to describe their incident process and show sample reports; citing ISO/IEC 27035 helps, but evidence of operation matters more.
Metrics such as time to detect, time to contain, number of incidents by category and completion rate of lessons-learned actions show whether the capability is improving.

Personal qualifications

Several training organisations offer courses and personal certificates built around ISO/IEC 27035, for example for incident managers. These certify that an individual passed a course exam; they are issued by the training or certification body, not by ISO or IEC, and they say nothing about an organisation's capability.

Legal and regulatory compliance

The series does not replace laws. Many jurisdictions and sectors have mandatory incident reporting, such as personal data breach notification under data protection laws or significant-incident reporting for essential and important entities under the EU NIS2 Directive, which uses staged reports (an early warning, a notification and a final report). The series' message is that these duties must be identified during preparation and built into the plan, classification scheme and communication paths, so that the clock does not start running while nobody knows the rules.

Lesson 6 – Worked example

This fictional example follows a mid-sized company through the whole process. It shows how the phases and parts fit together in real life.

The organisation

Harbourline Logistics is a freight and warehousing company with 900 employees in three countries. It has an ISO/IEC 27001 certificate, a small in-house security team of four people, an outsourced 24/7 monitoring service from a managed security provider, and a cloud-hosted transport management system run by a software-as-a-service (SaaS) supplier. Two years ago, a ransomware scare showed that nobody knew who could authorise shutting down the warehouse network, so the chief information security officer (CISO) decided to rebuild the incident capability using ISO/IEC 27035.

Step 1: Plan and prepare

The CISO began with Part 1 to explain the five-phase model to the executive team, then used Part 2 as a checklist. The board approved a two-page incident management policy that commits every employee to report suspected events and promises no blame for honest reports. The security team wrote an incident management plan with four severity levels, defined by impact on customer shipments, personal data and safety. The IMT was set up with the CISO as lead, the head of IT operations, the legal counsel, the HR director and the communications manager, each with a named deputy. Decision rights were written down: the IMT lead may isolate any system for up to four hours; longer outages of warehouse systems need the chief operating officer.

Relationships came next. The contract with the managed security provider was updated to define which alerts it escalates, how fast and to whom. The SaaS supplier agreed to notify Harbourline of incidents affecting its data within an agreed time, and to name a contact for joint response. Harbourline also arranged a retainer with a forensic firm, confirmed its cyber insurance policy's notification rules and recorded the contact details of the national CSIRT and the data protection authority. An out-of-band channel, a separate messaging workspace with accounts not tied to the corporate directory, was set up in case email was compromised.

All staff took a short module on recognising and reporting events; responders received playbooks for phishing, ransomware, lost devices and supplier breaches. In the first year, the team ran two tabletop exercises. The second one revealed that the out-of-band channel had no accounts for the deputies, which was fixed.

Step 2: Detect and report

On a Tuesday at 06:40, the managed security provider's analyst saw an alert: a finance employee's account had signed in from an unusual country and then created a mail forwarding rule to an external address. At 07:05, the same employee phoned the service desk, the designated PoC, saying she had entered her password on a page that looked like the company's document-sharing site the previous evening. Because the policy promised no blame, she reported it as soon as she realised.

Step 3: Assess and decide

The PoC logged both reports in one ticket, linked them and passed them to the IMT lead's deputy, who was on call. Assessment took twenty minutes. The deputy confirmed an information security incident in the category "unauthorised access – account compromise". The initial severity was set at level 2 (significant): one account was affected, but finance mailboxes hold supplier bank details and personal data, and the forwarding rule suggested data was leaving. The decision log recorded the reasoning and the plan to review severity once analysis showed the scope.

Step 4: Respond

Containment came first. The IRT, made up of two in-house analysts and the provider's analyst, disabled the account sessions, reset the password, enforced re-registration of multi-factor authentication and removed the forwarding rule. Before deleting the rule, they exported its details and the relevant sign-in and mailbox audit logs to the evidence store, recording hashes and who collected them.

Analysis then showed something worse: from the compromised mailbox, the attacker had sent a convincing email to a customer asking to change the bank account for future invoices. The IMT raised severity to level 3 (major), convened at 09:00, and brought in legal and communications. Legal determined that the forwarded emails contained some personal data of employees, so a breach assessment was started to decide on notification to the data protection authority within the legal deadline. Communications prepared a warning for the affected customer, and the account manager phoned them before any payment was made.

The attacker had also used the stolen session to open the SaaS transport system. This brought Part 4 into play. Harbourline's IMT contacted the supplier's named incident contact, shared the attacker's IP addresses and session times under a pre-agreed information-sharing arrangement, and asked the supplier to check for the same indicators across its platform. The supplier found the same addresses trying to log in to two other customers' tenants and, acting as coordinator for its customers, warned them. Everyone agreed on who would tell what to whom, so that customers did not receive confusing, contradictory messages.

Eradication included blocking the phishing domain, searching all mailboxes for the same lure and removing it, and checking that no other accounts had suspicious rules. Recovery was quick: the employee's account was restored with fresh credentials and placed under enhanced monitoring for thirty days. The IMT lead closed the incident three days later, once monitoring showed no further activity and every action had an owner.

Step 5: Learn lessons

A week later, a 90-minute blameless review was held with everyone involved, including the provider and the supplier's contact. The team built a timeline: initial compromise at 21:15 Monday, detection at 06:40 Tuesday, containment at 07:30. Findings included: the phishing page used a look-alike domain that the email filter did not catch; the multi-factor method in use could be phished; the escalation from the provider worked well; the customer warning was fast but improvised; and the breach assessment took too long because nobody knew which mailbox folders contained personal data.

Actions were assigned with deadlines: move finance and administrators to phishing-resistant authentication; add a playbook and pre-approved message templates for payment-diversion fraud; introduce a callback rule for bank-detail changes; add look-alike domain monitoring; and add the incident category to the classification scheme. The severity criteria were also clarified. At the next ISO/IEC 27001 surveillance audit, the auditor sampled this incident and followed it from the first alert to the closed actions, using the ticket, decision log, evidence register and review report.

What the example shows

Preparation made the response calm: roles, decision rights and contacts were already agreed. Early, unblamed reporting by the employee cut hours off the response. Classification was revisited as facts emerged. Evidence was preserved before it was destroyed. A supplier relationship planned in advance turned into effective coordination that protected other organisations too. And the review produced concrete improvements rather than a report nobody reads.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27035 sits in a busy landscape. Knowing its neighbours helps you use each one for what it does best and avoid duplicated or conflicting processes.

Figure 5 – Where the ISO/IEC 27035 series sits among requirements, controls, evidence, continuity and other incident guidance.

Standard or framework	What it is	Relationship to ISO/IEC 27035
ISO/IEC 27001:2022	Requirements for an information security management system; certifiable.	Requires incident-related controls (Annex A 5.24–5.28 and 6.8) to be considered; ISO/IEC 27035 explains how to implement them. Certification happens here, not against 27035.
ISO/IEC 27002:2022	Guidance on information security controls.	Gives a short section of guidance per incident control; the 27035 series expands this into full guidance. Parts 1 and 2 were revised in 2023 to align with it.
ISO/IEC 27037, 27041, 27042, 27043	Guidance on identifying, collecting, preserving, analysing and investigating digital evidence.	Support the evidence work in the response phase; 27035-1 has an annex on the relationship.
ISO 22301:2019	Requirements for a business continuity management system.	A severe incident may become a disruption that triggers continuity plans; both plans should link escalation criteria and roles.
NIST SP 800-61 Rev. 3 (2025)	US government guidance on incident response, now organised around the NIST Cybersecurity Framework 2.0 functions.	Covers similar ground from a different angle; many organisations use both. Rev. 3 replaced the older four-phase lifecycle of Rev. 2 with a CSF-based view.
FIRST CSIRT Services Framework	Community description of the services an incident response team may offer, grouped into service areas.	Helps define what an IRT or SOC does; complements the process view of 27035.
ISO/IEC 20000-1	Requirements for an IT service management system.	Has its own incident management process for service interruptions; security incidents should hand over cleanly between the two.

ISO/IEC 27001 and 27002: the "what" and the "how"

A helpful way to think about the relationship: ISO/IEC 27001 says you must manage information security risks and consider a set of controls, including incident management. ISO/IEC 27002 explains each control in a short section. ISO/IEC 27035 explains, across four parts, how to build and run the capability those controls describe. If you are building an ISMS, map your incident plan to the 27001 controls and use the 27035 parts as your design guide.

IT service incidents versus security incidents

Many organisations already run an IT service management process, often based on ISO/IEC 20000-1 or ITIL, in which "incident" means any unplanned interruption to a service. A failed disk is an IT service incident but not normally a security incident. A ransomware attack is both. The two processes should share tools and a service desk where useful, but security incidents need extra steps: confidential handling, evidence preservation, legal assessment and possibly external notification. The plan should say how a service desk ticket becomes a security incident and who decides.

NIST SP 800-61

For many years, NIST SP 800-61 Rev. 2 (2012) was the best known incident handling guide, with a four-phase lifecycle of preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. That maps closely to the five ISO/IEC 27035 phases. In April 2025 NIST replaced it with Rev. 3, which reframes incident response as part of overall cybersecurity risk management using the NIST Cybersecurity Framework 2.0 functions (Govern, Identify, Protect, Detect, Respond, Recover). Organisations that follow both find them compatible: ISO/IEC 27035 offers an internationally agreed process model; NIST adds detailed recommendations and links to the CSF.

Business continuity and crisis management

Incident management and business continuity meet when an incident causes, or threatens, serious disruption. A ransomware attack that stops a warehouse is a security incident and a continuity event at the same time. The incident plan should state the severity at which continuity or crisis teams are alerted, and both plans should use compatible roles and communication channels. Exercises that test both together are particularly valuable.

Common pitfalls and best practices

Common pitfalls

A plan that lives only on paper. Plans written for the auditor and never tested fail at the first real incident, typically because contacts are outdated or decision rights are unclear.
Treating every alert as an incident, or none. Without clear criteria for moving from event to incident, teams are either overwhelmed by noise or miss real incidents hidden among the alerts.
Destroying evidence in the rush to recover. Rebuilding a compromised server before capturing logs and images makes it impossible to know how the attacker got in or what they took.
A blame culture. If people fear punishment for mistakes, they hide incidents, and detection relies only on tools.
Forgetting the supply chain. Contracts that are silent on incident notification and cooperation leave the organisation blind when a supplier is breached.
Closing too early. Declaring the incident over once the visible symptom is gone, while the attacker still holds other footholds.
Skipping or wasting the lessons-learned phase. Reviews that never happen, or produce actions with no owner or deadline, guarantee repeat incidents.
Relying on compromised channels. Coordinating a response over the same email system the attacker is reading.

Best practices

Start with Part 1, then use Part 2 as a build checklist. Understand the whole process before designing teams and tools.
Make reporting simple and safe. One well-advertised channel, quick acknowledgement and a clear no-blame message for honest reports.
Define classification and severity criteria in business terms. Tie each level to who is informed, how fast and what authority applies.
Agree decision rights in advance. Decide who may isolate systems, engage external firms or notify authorities, and name deputies.
Prepare external relationships before you need them. Suppliers, forensic specialists, insurers, national CSIRTs and regulators, with contacts and expectations written down.
Exercise regularly and vary the scenarios. Include executives, suppliers and the out-of-band channel; feed findings into the plan.
Preserve evidence by default. Collect volatile data and logs before containment changes them, and record a chain of custody.
Measure and improve. Track detection and containment times and the closure of lessons-learned actions, and report trends to management.

Summary and key takeaways

ISO/IEC 27035 is a four-part guidance series from ISO/IEC JTC 1/SC 27 on information security incident management: Part 1 (2023) principles and process, Part 2 (2023) planning and preparing, Part 3 (2020) ICT response operations, Part 4 (2024) coordination.
Its core is a five-phase process: plan and prepare, detect and report, assess and decide, respond, and learn lessons, with learning feeding back into preparation.
Events, incidents and vulnerabilities are different things; a clear funnel from event to confirmed incident protects the team and keeps statistics meaningful.
Most of the value is created before an incident: policy, plan, teams, decision rights, relationships, tools, training and tests.
Response combines containment, analysis, eradication and recovery with careful evidence handling and controlled communication.
Organisations are not certified against ISO/IEC 27035; the series is usually assessed through ISO/IEC 27001 incident controls, internal audits and exercises.
Part 4 recognises that incidents cross organisational boundaries and gives guidance on coordinating with suppliers, partners and coordination teams.
The series works alongside ISO/IEC 27001/27002, the digital evidence standards, ISO 22301, NIST SP 800-61 Rev. 3 and legal reporting duties.

Reflection questions

Think of your own organisation: if an employee noticed a suspicious email right now, exactly where would they report it, and how confident are you that they would?
Which criteria would you use to separate four severity levels in your context, and who should be informed at each level?
Pick one critical supplier. What would you need to have agreed with them in advance for a coordinated response like the one in the worked example to work?
In a recent incident or outage you know of, at what point might evidence have been lost, and what would you change to preserve it next time?
How would you show an auditor, using records rather than documents alone, that your organisation learns from incidents?