Updated: June 2026 -  When suspicious activity is detected, every minute matters. Security teams need to contain the threat, legal and privacy teams need to assess notification obligations, and business leaders need to understand the potential impact. But before any of that can happen, organisations need to answer a critical question: is this a cyber incident, a data breach, or both? 

What is the difference between a cyber incident and a data breach?

A cyber incident is any event that compromises, or could compromise, the confidentiality, integrity or availability of systems, data, applications or services. This could include a malware infection, a compromised user account, unauthorised access to a cloud environment, a DDoS attack, suspicious network activity or a ransomware attempt.

A data breach is a specific type of incident involving data. It occurs when data is accessed, disclosed, lost, altered, destroyed or stolen without authorisation. This may involve customer records, employee files, payment data, intellectual property, health information, credentials, emails or confidential business documents.

The key question is not simply “has something bad happened?” It is “has data been affected, and what is the likely impact?”

For example, a blocked phishing email may be a security event, but not a breach. A compromised mailbox containing customer data may be a potential breach. A stolen database containing personal information is likely to be a reportable breach, depending on the type of data, the people affected and the level of risk involved.

Why the distinction matters

During the early stages of an incident, terminology can create confusion. Calling something a breach too early may trigger unnecessary alarm, while failing to recognise a genuine breach can create regulatory, legal and reputational risk.

Correct classification helps organisations make better decisions. It determines whether privacy, legal, compliance, cyber insurance, executive leadership and communications teams need to be involved. It also affects whether regulators, customers, affected individuals, suppliers or law enforcement need to be notified.

In 2026, this is especially important because incidents often move quickly. Attackers may steal data before deploying ransomware. A compromised SaaS platform may expose information across multiple business units. A cloud misconfiguration may leave sensitive records publicly accessible. An AI-generated phishing campaign may compromise credentials before anyone realises an account has been abused.

The faster an organisation can classify the event, preserve evidence and understand the scope, the better placed it will be to contain the impact.

Incidents and Breaches: The Definitions 

Before taking an in-depth look at breaches and incidents, it’s important to understand what each refers to. Verizon has very clear-cut definitions for incidents and data breaches: 

• Incident: A security event that compromises the integrity, confidentiality, or availability of an information asset.  
  
• Data Breach: An incident that results in the confirmed disclosure — not just potential exposure — of data to an unauthorised party. 

It’s important to note here that the word incident is used in the definition of a data breach. This is because while all data breaches are definitely incidents, not all incidents are data breaches.  

Two Kinds of Incidents 

An incident is a blanket statement used to describe many different things. Incidents can be broken down into two categories: 

• Security Incident: A security incident is an event that violates an organisation’s security policies and its procedures. 
• Privacy Incident: A privacy incident is a bit more serious. It refers to the disclosure of regulated data, like someone’s personally identifiable information or protected health information, thus violating the Department of Homeland Security’s policies and procedures. 
  

About Events 

Before going further, it’s important to note that there is another category altogether: events. 

The National Institute of Standards and Technology defines events as “any observable occurrence[s] in a system or network.” This includes things like a server receiving a request for a web page, someone in your network sending an email, or a firewall blocking an outsider attempting to make a connection. 

Some of these events can have negative consequences, like unauthorised access to sensitive data or the implementation of malware that destroys data.  

If these categories are broken into tiers, we can rank them in order of increasing severity: 

1. An event 
2. A security incident 
3. A privacy incident 
4. A data breach 

The International Association of Privacy Professionals (IAPP) uses Verizon’s DBIR definition to help determine the difference between an incident and a breach.  

According to their interpretation, a security incident is an event like a malware attack that puts sensitive data at risk for exposure outside of authorization. This refers to any kind of data, including regulated data like financial and medical information, and unregulated data, including intellectual property. It may refer to the unauthorised use or disclosure of regulated data.  

On the other hand, a data breach is an escalation of a privacy incident. Data breaches must be reported to any affected individuals, regulatory agencies, and occasionally to credit reporting agencies and the media.  

When Is an Incident a Breach? 

Since breaches refer specifically to occasions where an incident leads to the unauthorised access to and acquisition of protected and regulated data, it’s helpful to fully understand what qualifies some incidents and breaches.  

So the real difference between the two? It has to do with what happens to the data. Because organisations have to follow very specific protocol when a breach occurs — including contacting individuals and even sometimes the media — these entities should be very careful about labelling an incident as a breach before conducting a thorough investigation. 

For example, under the Health Insurance Privacy and Accountability Act (HIPAA), saying that information was breached is legally not the same thing as saying that information was breached. A full investigation can help organisations reach a real, legal conclusion, and only then should these organisations label a particular qualifying incident as a breach.  

When it comes to categorising an incident as a breach, there are four factors: 

• The identifiability of the information: Can an outsider determine to whom the information pertains? Some information may be protected or regulated, but it may not be attached to specific individuals. It may also relate to just how sensitive the data is. 
• The recipient of the information: Who accessed this information? Did someone who has legal protections get it, or perhaps another covered entity or business associate? This is very different from an instance where regulated data goes to someone else who has a potential motivation to abuse the information. 
• Whether or not the information was accessed: Did the involved party actually access or view the information? Any available forensic evidence may tell you if the information was compromised in this way. 
• The mitigation steps after the discovery of the incident: Were you able to stop the compromise? If an organisation was able to get the information back or receive assurance that it was destroyed, this may impact an incident’s qualification as a breach or not. 
  

Security event, incident, privacy incident or breach?

Not every alert is an incident, and not every incident is a breach. Organisations should use a clear classification model so teams know how to escalate and respond.

This distinction helps avoid both overreaction and underreaction. It gives teams a common language and supports faster decision-making during a stressful situation.

Why the first 24 hours matter

The first 24 hours of an incident can shape the outcome. Organisations need to contain the threat, preserve evidence and avoid making assumptions. They also need to start a decision log that records what happened, when it was discovered, who was involved, what action was taken and why.

A good response is not just technical. It is legal, operational and reputational. The organisation needs to understand what happened before making external statements, but it also needs to act quickly enough to meet legal and regulatory deadlines.

Regulatory Issues and Cybersecurity Incidents 

The damage of a cybersecurity incident or data breach is more than just the cost or the blow to your reputation; in many instances, it can also impact your compliance with national and international regulations. Understanding the difference between an incident and a breach matters in these situations, as there can be regulatory consequences. 

An example of this? The General Data Protection Regulation (GDPR) requires involved organisations to act transparently when it comes to security. As such, if a GDPR inspector suspects that an organisation has attempted to downplay the severity of a data breach, it could be held against that organisation. 

Those who have concerns about whether or not they’ve suffered a breach, or if an event qualifies as an incident or a breach, should implement some kind of incident response service. This can help spot and address threats quickly and give organisations the information they need to understand when and how the incident started as well as how to minimise the overall effect of the incident. 

Another benefit to having an incident response plan? It’s definitely helpful in reacting to security incidents, but it’s also helpful in preventing similar mistakes from happening again in the future. With an incident response plan or system in place, you can log security events and responses and build on your existing knowledge to help prevent similar issues from popping up in the future. 

Common 2026 incident scenarios

Modern incidents are rarely straightforward. Attackers often combine identity compromise, cloud access, data theft, extortion and operational disruption. Here are some common scenarios and how they should be assessed.

These examples show why investigation is essential. The label should follow the evidence, not assumptions.

Ransomware and data theft extortion

Ransomware is no longer only about encryption. Many threat groups now steal data before disrupting systems, then use that information to pressure organisations into payment. Even if systems can be restored from backups, the organisation may still face a data breach if information was accessed or stolen.

This makes forensic investigation critical. Security teams need to determine how attackers entered, what accounts were used, which systems were accessed, whether data was exfiltrated and whether the threat has been fully contained.

If personal, regulated or confidential data has been accessed, the incident may become a breach even if the organisation avoids paying a ransom and restores operations quickly.

Cloud, SaaS and third-party breach risk

Many 2026 breaches begin outside the traditional perimeter. Cloud platforms, SaaS applications, managed service providers and third-party suppliers often hold sensitive data or provide access into core business processes.

A breach at a supplier can still create obligations for the affected organisation. If customer, employee or business data has been exposed through a third party, the organisation needs to understand what data was involved, how many people were affected, whether the supplier has contained the issue and what notification obligations apply.

This is why third-party incident response processes should be built into supplier contracts and vendor risk management programmes. Organisations need clear reporting timelines, contact routes, evidence requirements and responsibilities before an incident happens.

How to prepare before an incident happens

The worst time to decide how to handle a breach is during the breach itself. Organisations should prepare by building clear roles, decision-making structures and escalation paths in advance.

An effective incident and breach response plan should include:

• A clear incident classification model

• Defined roles for security, legal, privacy, IT, communications and leadership teams

• A process for assessing whether personal or regulated data is involved

• Regulatory and contractual notification workflows

• Forensic evidence preservation guidance

• A decision log template

• Pre-approved internal communication routes

• External communication review processes

• Cyber insurance contact details and requirements

• Incident response retainer information

• Supplier breach notification contacts

• Board reporting procedures

• Post-incident review and lessons learned processes

This preparation reduces confusion, improves response times and supports more defensible decisions.

How MDR and incident response work together

Managed Detection and Response can help identify suspicious activity earlier, investigate alerts and support faster containment. However, when an incident escalates into a suspected breach, organisations also need incident response and forensic expertise.

MDR helps detect and respond to active threats. Incident response helps investigate what happened, contain the attack, preserve evidence, assess impact and support recovery. For complex incidents, both capabilities are often needed.

The strongest approach combines continuous monitoring, threat intelligence, endpoint and identity visibility, cloud and SaaS monitoring, incident response planning, forensic readiness and regular tabletop exercises.

This helps organisations move from reactive crisis management to structured response.

What should you do if you are unsure?

If you are unsure whether an incident is a breach, treat it as a potential breach until proven otherwise. That does not mean immediately notifying everyone. It means preserving evidence, involving the right teams, documenting decisions and assessing risk quickly.

Do not delete logs. Do not rebuild systems before evidence is captured. Do not make public statements before facts are confirmed. Do not assume that encryption means data was safe. Do not assume that a third-party issue is not your responsibility.

Bring together security, legal, privacy, IT and leadership teams early. Where needed, engage external incident response specialists to support containment, investigation and decision-making.

Have an Incident Response Team on Your Side 

Businesses must be able to respond to a cyberattack whether it qualifies as an incident or a breach, which is where an incident response team can make all the difference. This can help avoid the three negative impacts of these happenings: 

• Reputational risk 
• Legal risk 
• Financial risk 

At Integrity360, our Cyber Incident Response Team (CIRT) is always there for you, working 24/7/365 to recognise and contain any threats as they happen. This helps to reduce the amount of time it takes to respond and can potentially minimise the impact — sometimes even keeping an incident from developing into a breach.  

We use a wide array of advanced technologies and experienced specialists to deliver an unbeatable incident response service, helping you respond to suspected security incidents in a timely manner.  

No matter if it’s an incident or a breach, our highly skilled team delivers fast responses thanks to our broad skill set. If you’re ready to minimise risk and identify incidents before they develop into larger issues, perhaps it’s time we talked. Contact us today to learn more about our incident response services.

Speak to Integrity360

Not sure whether you are dealing with a cyber incident or a data breach?

Integrity360 can help you respond quickly, preserve evidence, understand the impact and take the right next steps. Whether you need emergency incident response, a retainer, forensic investigation or support improving your incident response readiness, our experts can help reduce business impact and strengthen resilience.

Contact Integrity360 today to discuss how your organisation can prepare for, respond to and recover from cyber incidents.

This blog and its content are provided as a general guide to the subject matter. You should always seek specialist advice about your specific situation.

FAQ

Is every cyber incident a data breach?

No. Every data breach is a cyber incident, but not every cyber incident is a data breach. A DDoS attack, blocked malware attempt or failed login attack may be a cyber incident without involving unauthorised access to data.

When does an incident become a breach?

An incident becomes a breach when data has been accessed, disclosed, lost, altered, destroyed or stolen without authorisation. This may involve personal data, sensitive information, regulated data or confidential business records.

Do you have to report every cyber incident?

No. Reporting depends on the type of incident, the data involved, the organisation’s sector and the applicable legal, regulatory or contractual requirements. Many incidents should be documented even when they are not reportable.

Do you have to report every data breach to the ICO?

No. Under UK GDPR, a personal data breach must be reported to the ICO if it is likely to result in a risk to people’s rights and freedoms. If that threshold is met, the breach must be reported without undue delay and within 72 hours of becoming aware of it.

Can ransomware be a data breach?

Yes. Ransomware can be a data breach if personal, sensitive or regulated data has been accessed, stolen, disclosed or made unavailable in a way that creates risk. Even where encryption is the main impact, the organisation should investigate whether data was exfiltrated.

Can an email sent to the wrong person be a breach?

Yes. If personal or sensitive data is sent to an unauthorised recipient, it may be a personal data breach. The level of risk depends on the data, the recipient, whether the information was recovered and the possible impact on affected individuals.

Is a DDoS attack a data breach?

Usually not. A DDoS attack is typically a cyber incident affecting availability rather than confidentiality. However, it may still be serious, especially if it disrupts critical services or is used as a distraction for another attack.

What should you do first during a suspected breach?

Contain the threat, preserve evidence, identify affected systems, assess whether data is involved, begin a decision log and involve security, legal, privacy and leadership teams. If the incident is serious or unclear, engage incident response specialists quickly.

Why is a decision log important?

A decision log records what the organisation knew, when it knew it, what actions were taken and why. This supports regulatory engagement, legal review, insurance claims, post-incident analysis and board reporting.

How can Integrity360 help?

Integrity360’s Incident Response team helps organisations contain threats, preserve evidence, investigate incidents, assess impact and recover quickly. We support emergency response, incident response retainers, digital forensics, compromise assessments, MDR, threat exposure management and cyber risk advisory services.