A data breach does not announce itself. It might surface as an unusual login alert at 11pm, a supplier calling to say they have received a strange email from your domain, a member of staff reporting that they sent a client file to the wrong person, or a ransomware notification on a Monday morning. In most cases, the first few hours are chaotic, information is incomplete, and the pressure to respond immediately conflicts with the need to understand what has actually happened before taking action.
Organisations that handle breaches well are not necessarily those with the most sophisticated security. They are those that prepared in advance — that had a procedure, knew who to call, understood their notification obligations, and had thought through the decision points before the adrenaline hit.
ISO 27001 builds incident management into the ISMS through Annex A controls 5.24 to 5.28. This guide explains what those controls require and — more practically — how to structure a response from the moment a potential breach is detected to the post-incident review.
Before a Breach: What You Need in Place
Control 5.24 (Information security incident management planning and preparation) requires that you plan and prepare for incident management before incidents occur. This is the control that organisations most commonly satisfy on paper and least commonly satisfy in practice.
At minimum, your incident management preparation should include:
A documented incident response procedure that defines what constitutes a security event, what constitutes a security incident, and what constitutes a reportable data breach. These three things are different, and the distinction matters — particularly when the GDPR 72-hour notification clock is involved.
An incident response team with defined roles. Someone needs to lead the response, someone needs to manage technical containment, someone needs to handle communications, and someone (usually at senior management level) needs to make the notification decision. These roles should be defined before an incident, not assembled under pressure during one.
A contact list covering internal escalation paths, your certification body (in case of significant incidents), your Data Protection Officer or legal adviser, the ICO reporting portal, your cyber insurance provider, and any key suppliers or partners who may need to be notified. A contact list that lives in a system that is offline during an incident is not useful — keep a printed or offline copy.
Preserved logging and monitoring that gives you a chance of reconstructing what happened. Annex A 8.16 (monitoring activities) and 5.28 (collection of evidence) both require that you maintain evidence that can be used in an incident investigation. If your logs only go back 14 days and an attacker has been in your environment for three weeks, your forensic options are severely limited.
Defining Your Terms: Event, Incident, Breach
Control 5.25 (Assessment and decision on information security events) requires you to assess security events and decide whether they constitute incidents. This implies clear definitions.
A security event is any observable occurrence that might be relevant to security. A failed login attempt is a security event. An email flagged by your spam filter is a security event. Most security events are not incidents.
A security incident is a security event that has actually or potentially resulted in a loss of confidentiality, integrity, or availability of information, or a violation of your security policies. A confirmed account compromise is an incident. A successful phishing email is an incident. A ransomware infection is an incident.
A personal data breach (the GDPR definition) is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Not all security incidents are personal data breaches. A ransomware attack that encrypts systems but demonstrably does not exfiltrate personal data may be a security incident without being a notifiable personal data breach. But if there is any uncertainty, the presumption should be that personal data may have been affected until you can demonstrate otherwise.
This distinction drives your notification obligations, which carry hard deadlines. Knowing which category you are in — and making that assessment quickly — is one of the most important first steps in any response.
Data Breach Response: Six Phases
From detection to post-incident review — aligned to ISO 27001 Annex A controls 5.24–5.28
Phase 1: Detection and Reporting
Control 6.8 (Information security event reporting) requires that you have a mechanism for staff to report security events as quickly as possible. This means staff need to know what to report, who to report it to, and how — and they need to feel safe doing so without fear of blame.
When a potential incident is detected, the immediate priority is to report it to the incident response team and preserve the initial information. This means:
Do not attempt to fix it silently. The most common mistake in the first hour of an incident is the person who noticed the problem trying to resolve it without telling anyone. They delete the suspicious email, restart the affected system, or change the compromised password — inadvertently destroying forensic evidence and potentially allowing the attacker to persist through another route.
Document what you know, when you knew it. Start an incident log immediately. Record the time and date the event was detected, who detected it, and what was observed. This log is the foundation of your incident record and, if the incident becomes notifiable, the start of your compliance timeline.
Make the initial notification internally. The person who detected the event notifies the ISMS lead or incident response lead. The ISMS lead decides whether this is a security event requiring monitoring, a confirmed incident requiring the full response, or something that can be closed immediately.
Phase 2: Assessment and Classification
Once the incident response team is assembled, the first task is to understand what you are dealing with well enough to make decisions. This does not require complete information — you will rarely have complete information in the first hours — but it requires enough to classify the incident and determine the immediate priorities.
Key questions at this stage:
What happened? What is the nature of the incident — ransomware, phishing, misdirected email, unauthorised access, physical theft, supplier breach?
What systems or data are affected? Which systems are involved? What categories of data might have been accessed, modified, or exfiltrated? Does that data include personal data? Whose?
Is the attacker still present? Is this an active attack or a historic compromise? If the attacker is still in your environment, containment is urgent. If the incident is historic (a breach that occurred weeks ago and has now been discovered), the immediate pressure is different.
What is the likely impact? To the organisation, to affected individuals, to clients or partners?
When did it start? The timeline of an incident affects both the forensic investigation and the notification clock — if the breach of personal data occurred more than 72 hours ago and you have not yet notified the ICO, that deadline may already have passed.
Classify the incident by severity — critical, high, medium, low — using criteria defined in your incident procedure. A critical incident (active ransomware, confirmed data exfiltration, system-wide compromise) requires immediate full team mobilisation and likely external assistance. A low severity incident (single misdirected email with non-sensitive data) requires a proportionate response but not necessarily the same level of urgency.
Phase 3: Containment
Containment means stopping the incident from getting worse. The approach depends entirely on the nature of the attack, but the general principle is to isolate what is affected without destroying evidence.
For ransomware or malware: Isolate affected systems from the network immediately — disconnect from LAN and Wi-Fi, not just a restart. Do not pay a ransom without taking legal and insurance advice. Preserve a copy of the ransom note and do not delete encrypted files — these may be needed for decryption or forensics.
For account compromise: Revoke the compromised credentials immediately. Enable multi-factor authentication if it was not already in place. Review access logs to understand what the compromised account accessed. Check for persistence mechanisms — additional accounts created, forwarding rules added, authentication tokens issued.
For misdirected email or document: Contact the recipient and request deletion, documenting their response. Assess what data was in the document and whether it includes personal data requiring notification.
For physical theft (device, media): Determine whether the device was encrypted. An encrypted laptop with a strong passphrase is significantly lower risk than an unencrypted one. Remotely wipe if device management allows.
Throughout containment, maintain a chain of custody for any evidence collected. Control 5.28 (Collection of evidence) requires that you collect, preserve and protect evidence — this matters both for any subsequent investigation and for demonstrating compliance in the event of regulatory scrutiny.
Phase 4: Notification Obligations
This is the phase with the hardest deadlines and the most significant consequences for getting it wrong. Notification obligations exist under multiple frameworks that may overlap.
Who to Notify — and When
A practical guide to notification decisions following a data breach or security incident
Notifying the ICO (UK GDPR)
Under UK GDPR Article 33, if a personal data breach is likely to result in a risk to the rights and freedoms of individuals, you must notify the ICO within 72 hours of becoming aware of the breach. The 72-hour clock starts when you have reasonable certainty that a breach has occurred — not when it is fully investigated.
The test for notification is risk, not certainty of harm. If you cannot demonstrate that no risk to individuals exists, you should notify. Failing to notify when notification was required is treated more seriously by the ICO than notifying when a breach ultimately turns out to be lower risk than first assessed.
If the breach is unlikely to result in a risk to individuals, you are not required to notify the ICO — but you must document your reasoning. That documented decision is what you will need to show if the assessment is later questioned.
When notifying the ICO, you will need to provide: a description of the nature of the breach; the approximate number of individuals affected and records involved; the name and contact details of your Data Protection Officer or other contact; a description of the likely consequences; and a description of the measures taken or proposed to address the breach.
If you cannot provide all of this within 72 hours, notify with what you know and provide further information as it becomes available. A partial notification submitted on time is better than a complete notification submitted late.
Notifying Affected Individuals (UK GDPR Article 34)
Where a breach is likely to result in a high risk to individuals, you must also notify those individuals directly — without undue delay. High risk means the breach could result in discrimination, identity theft, financial loss, damage to reputation, or other significant harm.
The notification to individuals must explain in clear language: the nature of the breach; the name and contact details of your Data Protection Officer; the likely consequences; and the measures taken or proposed.
Notifying Customers, Partners and Others
Beyond regulatory notification, you may have contractual obligations to notify customers or partners of incidents affecting their data. Review your contracts — particularly data processing agreements — for notification clauses and timescales. Some customer contracts specify notification windows shorter than the GDPR’s 72 hours.
Your cyber insurance policy may also have notification requirements — check whether you are required to notify your insurer and within what timescale. Failure to notify your insurer promptly can affect your ability to make a claim.
Notifying Your Certification Body
ISO 27001 does not require you to notify your certification body of every security incident, but a significant incident that materially affects your ISMS may be relevant context for your surveillance audit. Some certification bodies ask about significant incidents in the period since the last audit as a standard surveillance question. Transparency here is generally the right approach.
Phase 5: Eradication and Recovery
Once containment is achieved and immediate notifications are made, the focus shifts to eradication — removing the cause of the incident — and recovery — restoring normal operations.
Eradication involves identifying and removing the root cause: the malware, the compromised account, the vulnerability that was exploited. Do not move to recovery until you are confident that eradication is complete — restoring systems from backup onto a still-compromised network simply reinfects them.
Recovery should be phased, starting with the most critical systems and validating each before moving to the next. Monitor restored systems closely in the days following recovery for signs of reinfection or residual attacker presence.
Throughout this phase, continue maintaining the incident log. The timeline of eradication and recovery is part of the documented incident record and may be needed for regulatory purposes.
Phase 6: Post-Incident Review
Control 5.27 (Learning from information security incidents) requires that knowledge gained from security incidents is used to reduce the likelihood or impact of future incidents. The post-incident review is the mechanism for this.
Conduct a post-incident review within a reasonable period of the incident being closed — ideally within two weeks while the detail is fresh. The review should cover:
What happened? The complete timeline from initial compromise (or event) to detection to containment to recovery.
What worked well? Elements of the response that functioned as intended — early detection, rapid escalation, effective containment, smooth communication.
What did not work? Elements that were slow, unclear, poorly resourced, or missing entirely. These are the inputs to corrective action.
What would have reduced the impact? Controls, processes or configurations that, if in place, would have either prevented the incident or reduced its severity.
What changes are needed? Specific corrective actions arising from the review, assigned to owners with target dates.
The post-incident review output feeds directly into your continual improvement process. A significant incident should result in a formal corrective action and, if it revealed a risk that was not previously assessed, an update to your risk assessment.
Documentation Requirements
Throughout an incident, documentation serves two purposes: operational (helping you manage the response) and compliance (demonstrating that you met your obligations). Key documents to maintain:
Incident log — a running record of events, decisions and actions taken throughout the response, with timestamps.
Initial notification record — when the incident was reported internally and by whom.
Classification decision — the basis on which the incident was classified by severity, and the basis on which the personal data breach assessment was made.
Notification decisions — whether the ICO was notified (and when, and what was submitted), whether individuals were notified (and how), and whether other parties were notified.
Evidence log — what evidence was collected, how it was preserved, and who had access to it.
Post-incident review report — the findings of the review and the corrective actions arising from it.
Retain all incident documentation for a minimum of three years, or longer if required by your sector’s regulatory framework.
FAQs
Does every security incident need to be reported to the ICO?
No. The notification obligation under UK GDPR applies when a personal data breach is likely to result in a risk to the rights and freedoms of individuals. Many security incidents do not involve personal data at all, or involve personal data in circumstances where the risk to individuals is low (for example, a misdirected internal email containing a single employee’s name). The obligation is to assess the risk and document your reasoning — not to notify by default. However, when in doubt and the risk is unclear, notifying is generally safer than not.
What if we discover the breach more than 72 hours after it occurred?
The 72-hour clock starts when you become aware that a breach has occurred, not when the breach occurred. If you discover a breach that happened three weeks ago, your 72-hour window starts on the day of discovery. You should notify as quickly as possible, explain in the notification that there was a delay in detection, and provide the timeline you have been able to reconstruct. Late notification is taken seriously by the ICO but is treated differently from a failure to notify at all.
Do we need a specialist forensics firm?
For most small to medium organisations, the answer is: it depends on the severity. A significant breach — ransomware, confirmed data exfiltration, targeted attack — almost certainly warrants external forensic support. Your cyber insurance policy may include access to a breach response firm as part of the policy. For lower-severity incidents, internal IT teams with access to system logs can often conduct a sufficient investigation. The key question is whether you have the capability to establish what happened, what was affected, and whether the threat is fully eradicated.
Can we be fined by the ICO even if we notify promptly?
Yes — prompt notification reduces regulatory risk but does not eliminate it. The ICO can investigate whether the breach was the result of inadequate security measures and take enforcement action regardless of notification. However, prompt notification, demonstrable compliance efforts, and a well-documented response are all mitigating factors that the ICO considers when deciding whether and how to act. Organisations that try to conceal breaches consistently face significantly worse outcomes than those that notify transparently.
What is the difference between ISO 27001 incident management and GDPR breach management?
ISO 27001 incident management covers all security incidents — not just those involving personal data. A ransomware attack on systems that hold no personal data is an ISO 27001 incident but may not be a GDPR breach. Conversely, GDPR breach management has specific legal notification obligations and timescales that go beyond what ISO 27001 requires. In practice, the two frameworks are complementary: a well-designed ISO 27001 incident response process provides the operational foundation for meeting GDPR obligations, but your procedure should explicitly address the personal data breach assessment and notification steps that GDPR requires.
