A trend I’ve seen is that executives and staff outside of the security and privacy space often refer to any event involving IT security as a “breach”, not only is this incorrect, it’s a dangerous word to be throwing around with some serious consequences. In this article, I’ll be looking at four main terms, those of events, threats, incidents and breaches, as well as the differences between them and why a distinction is vitally important. I will be looking at this from both a cybersecurity and privacy point of view.


According to NIST (National Institute of Standards and Technology), there are two main types of event – an ‘event’ and an ‘adverse event’. An event is defined as “any observable occurrence in a system or network”. This can be someone checking their email, plugging in a USB device, or logging in to a particular server. Any activity on the network is effectively an event. An adverse event, is that of an event with a negative consequence in a network. This could be a server crash, power failure, or a security issue.


Adverse events that have the potential to affect information security, are classified as threats. As per the EC-Council Certified Ethical Hacker material, a threat is seen as “An action or event which might compromise security. A threat is a potential violation of security.” Threats come in a variety of forms, and these are what security teams are protecting against. You need to understand your threat landscape in order to protect it, however, there are times when this will go wrong and a threat will materialise.


When it comes to a threat materialising in terms of the security of data, be it physical security or electronic security, we refer to it as an incident. Some examples of incidents could be that malware has been executed within a network, someone has gained access to a server they should not have access to, or that someone has escalated their rights on a particular system by exploiting some kind of weakness – a privilege escalation.

While an incident does have cause for concern, it is still not a breach. An incident is simply an adverse event that is specifically related to cybersecurity. Policies have been breached, process has been breached, servers may have been accessed but there is still no evidence that personal information has been compromised. This is where the importance of an Incident Response Plan comes in. Once an incident has been identified, there need to be defined steps for a company to follow to classify and investigate the incident. The first step is to confirm that the incident has in fact happened and it is not a false alarm – these do happen – followed by containment of the incident and investigation as to what exactly has been accessed (the scope of the incident).


Breaches occur when an incident has been confirmed to have compromised personal information, to the extent that certain legal definitions are met in accordance with privacy laws (such as POPIA, GDPR and others). Different laws have different definitions of a breach, but in essence a breach is when personally identifiable information (PII) has been exfiltrated (taken from a network) and there is a real threat to the people whose information has been stolen or exposed.

The word breach will immediately prick up the ears of your customers, your staff, the media, and the regulators, which could spell disaster for you in a PR sense if announced prematurely. Announcing a breach when there has in fact only been an incident will completely blow the situation out of proportion. This is like getting toothpaste back into a tube. Even if the regulator and authorities clear your incident as a false alarm, the internet never forgets. You need to be sure that the incident has compromised personal information, or that the threat of compromise of personal information is very, very real.

A Uniform Approach

In order to facilitate your entire company knowing the differences here, you need to have a clear and defined Incident Response Plan (IRP) and Policy. Everyone needs to be on the same page across the organisation, so that if an adverse event is identified internally or externally, no-one jumps to conclusions. The Information Officer / Data Protection Officer needs to be the final port of call for an incident, and only they should be making the first mention of a breach after very careful consideration. Security incidents are a bad thing, but a breach is so much worse – and carries incredible legal weight if brought up.

Ross G Saunders Consulting is a niche data protection consultancy, working with a number of professional partners in order to help you as a business comply with data protection regulation. They help with business process, compliance, documentation and more, and can offer a full range of services to take the hassle out of data protection. Why not reach out to find out how they can help you gain a competitive advantage while simultaneously garnering support from your existing and potential customers.

Share This

Share this post with your friends!