Incident versus data breach: how to classify events, assess risk to individuals, meet 72-hour deadlines and keep a defensible decision record.
Topics: Breach Management, GDPR, Incident Response, Governance
A misdirected spreadsheet, a supplier alert, an employee accessing a record without authority, and a ransomware event may all enter the same queue. They should not, however, receive the same classification or response. The distinction between an incident versus data breach determines who must act, what evidence must be preserved, whether individuals face a risk, and whether a regulator may need to be notified.
For privacy, security, legal and risk leaders, this is not a question of terminology. It is an operational control. When teams use inconsistent definitions, they either escalate every minor event until the process stalls or miss the events that require prompt, documented action.
Incident versus data breach: the core distinction
A security or privacy incident is any event that could affect the confidentiality, integrity or availability of information, systems or services. It may be accidental, malicious or caused by a process failure. A phishing attempt blocked by email controls, a temporary outage in a customer portal, or an employee reporting a lost work device can all be incidents.
A data breach is narrower. In a privacy context, it generally concerns a security event that results in the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Under the UK GDPR and GDPR, this is described as a personal data breach.
The practical rule is straightforward: not every incident is a data breach, but every suspected data breach should enter the incident management process immediately. The investigation then establishes whether personal data was involved, whether it was actually affected, and what the consequences may be.
This distinction matters because an incident can be closed after confirming that controls worked and no data was compromised. A confirmed or suspected personal data breach requires a more structured assessment, including containment, impact analysis, notification decisions and a defensible record of the rationale.
Why classification fails in practice
Most classification failures do not result from a lack of policy. They result from fragmented operations. Security may record an event in a ticketing system, legal may keep notification advice in email, and the privacy team may maintain a separate spreadsheet for breach records. No single owner sees the complete decision trail.
The result is predictable. Teams spend critical hours reconciling facts rather than containing the event. They may not know which business owner is responsible for the affected processing activity, which supplier is involved, what categories of personal data are held, or whether a data protection impact assessment identified relevant risks.
There is also a tendency to treat “breach” as shorthand for a cyberattack. That creates blind spots. Many reportable events begin with ordinary operational mistakes: an email sent to the wrong recipient, excessive permissions in a shared folder, paper records left in an unsecured location, or personal data retained beyond the approved period.
Conversely, a significant cyber incident may not amount to a personal data breach if there is reliable evidence that no personal data was accessed, lost, altered or disclosed. It may still demand security remediation, senior oversight and supplier management. The classification should reflect evidence, not assumptions.
Establish a controlled decision path
An effective process begins with a single intake point for any suspected event. The person reporting it should not be expected to make a legal determination. Their role is to provide the facts available: what happened, when it was identified, the systems or records involved, and the immediate containment steps taken.
From there, the organisation needs a defined triage path. The following questions should be answered quickly and recorded consistently:
- Has personal data been involved, or could it reasonably have been involved?
- What happened to the data: was it lost, altered, unavailable, accessed or disclosed?
- Which data subjects, data categories, systems, locations and third parties are affected?
- Has the event been contained, and is there evidence that exposure continues?
- What likely consequences could arise for affected individuals?
- Does the event trigger contractual, regulatory or internal escalation requirements?
These questions are not a substitute for legal judgement. They create the evidence base that enables legal, privacy and security stakeholders to make that judgement without relying on disconnected accounts.
A sound workflow should allow the classification to change as facts emerge. At intake, an event may be recorded as a suspected incident. After triage, it may be closed as a non-breach incident, escalated as a confirmed personal data breach, or remain under investigation. Maintaining this history is essential. It shows that the organisation acted proportionately at each stage rather than retrospectively rewriting the record.
Assess risk to people, not only technical severity
Technical severity and privacy risk overlap, but they are not identical. A short-lived system fault affecting encrypted data may present low risk to individuals. A single disclosure of sensitive information to the wrong recipient may require urgent attention, even where the technical incident appears limited.
Privacy teams should assess factors such as the nature and sensitivity of the data, the volume of records, the ease of identification, the likely recipient, whether the data was protected, and the vulnerability of the individuals involved. The likely effects matter too: financial loss, discrimination, reputational harm, loss of confidentiality, fraud or other significant disadvantage may alter the response.
Under the UK GDPR and GDPR, a personal data breach must generally be notified to the relevant supervisory authority without undue delay and, where feasible, within 72 hours of awareness, unless it is unlikely to result in a risk to individuals’ rights and freedoms. Where the risk is high, affected individuals may also need to be informed without undue delay.
The 72-hour period is not a reason to rush into unsupported conclusions. It is a reason to establish decision-ready incident operations. If the facts are incomplete, the organisation should document what is known, what remains under investigation and why its assessment is reasonable at that point. Requirements can differ across jurisdictions and contractual arrangements, so cross-border organisations need a process that accommodates local counsel and lead authority considerations.
Connect incidents to the governance records that explain them
A breach register alone is not enough. The incident record should connect to the wider governance information that explains the event and supports remediation.
The relevant Record of Processing Activities can identify the purpose, categories of data, retention periods, systems and data recipients associated with the affected activity. A DPIA may show that a particular risk had already been identified and what safeguards were expected. Supplier assessments, contracts and data processing agreements can clarify notification obligations, audit rights and responsibility boundaries.
For incidents involving automated decision-making or AI systems, the AI system registry also becomes relevant. It helps teams identify the system owner, deployment context, data sources, risk classification and control requirements. An AI-related incident may involve more than data exposure. It may reveal failures in access control, training-data handling, human oversight or supplier accountability.
This connected view turns incident management from a retrospective register into a control mechanism. It supports root-cause analysis, shows whether prior assessments remain valid, and assigns remediation to owners with dates and evidence requirements.
Define accountability before an event occurs
Fast decisions require clarity before the first alert arrives. Security teams typically lead technical containment and forensic investigation. Privacy and legal teams assess personal-data implications, notification thresholds and communications. Business owners provide operational context, while procurement or vendor-management teams coordinate with affected suppliers.
The detail will vary by organisation, but responsibility for each decision should be explicit. Who can classify an event as a suspected breach? Who approves regulator notification? Who communicates with data subjects? Who verifies that remediation is complete? An escalation matrix with named roles and deputies is more useful than a policy that only says teams should “collaborate”.
Evidence ownership also needs definition. Preserve relevant logs, correspondence, screenshots, forensic findings, risk assessments, decisions and approval records in the case file. This protects the organisation’s ability to demonstrate accountability and reduces the risk that crucial reasoning disappears across chat messages and inboxes.
Organisations that need help designing this operating model — intake, triage, escalation and evidence standards — can draw on Formiti's privacy consultancy and outsourced DPO services to establish it alongside the platform.
Privacy360 supports this operating model by placing breach and incident management alongside ROPA, DPIAs, vendor risk assessments, contract review and AI system oversight. The value is not simply central storage. It is the ability to route work, connect records, maintain accountable decisions and retain evidence in one governance environment.
Measure whether the process is working
Mature programmes do more than count breaches. They look for patterns that improve control. Repeated misdirected emails may indicate poor recipient-verification practices. Frequent supplier reporting delays may expose weak contractual controls. Similar incidents in one business unit may point to incomplete training, unclear ownership or an unreviewed processing change.
Useful operational measures include time to triage, time to contain, time to reach a notification decision, overdue remediation actions and recurring root causes. These measures should be used carefully. The goal is not to close cases quickly at the expense of accuracy. It is to remove avoidable delay while maintaining a documented, proportionate assessment.
The most reliable organisations treat each incident as a test of their governance design. When records, responsibilities and evidence are already connected, teams can spend their time making informed decisions under pressure rather than searching for the information needed to make them.