What a security breach is and what to do step by step

A security breach —or data breach— is not always a sophisticated cyberattack. Very often it is a laptop left on a train, an email sent to the wrong person or a folder shared by mistake. What makes the difference is not preventing it 100% from happening, but knowing exactly what to do when it does. This guide explains what a data breach is under the GDPR, what types exist and the orderly protocol any organisation should follow: detect, contain, assess, document and, where appropriate, notify.

What is a security breach?

The GDPR calls it a personal data breach and defines it in its art. 4.12 as "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed".

It is worth reading that definition slowly, because it dismantles the most common misconception. A breach is not only a cyberattack. The rule speaks of accidental causes as much as unlawful ones, and of incidents as everyday as losing a device or granting access to someone who should not have had it. These are common examples that fit within art. 4.12:

• Loss or theft of a laptop, a mobile, a USB stick or a folder of paper documentation.
• Erroneous sending of an email or a document to the wrong recipient, or with the list of recipients visible in open copy.
• Unauthorised access to a system, whether external (intrusion) or internal (a person consulting data they should not have reached).
• Malicious encryption of information by ransomware, which leaves it inaccessible.
• Accidental deletion or alteration of a database with no backup available.

The key is to understand that a breach always refers to personal data: information about identified or identifiable natural persons. An incident affecting only anonymous technical data does not constitute a breach in the sense of the GDPR, although it may still be an information security problem worth resolving.

Types of breach: confidentiality, integrity and availability

Although art. 4.12 does not label them by name, its wording gives rise to three types of breach depending on which dimension of security is affected. Classifying the incident into one of them is the first step to properly assessing what has happened.

Confidentiality breach

There is unauthorised access to or disclosure of the data. This is the case of the email sent to the wrong person, improper access to a system or the accidental publication of a list. The data still exists and is intact, but it has been seen by someone who should not have seen it.

Integrity breach

The data is altered in an unauthorised way and ceases to be reliable. For example, an improper modification of records or a manipulation that means the information no longer reflects reality. The risk here is making decisions based on data that has ceased to be correct.

Availability breach

There is a loss of access to the data or its destruction. The typical case is ransomware that encrypts the information, an accidental deletion with no backup or the unrecoverable failure of a storage medium. The data may still exist, but the organisation cannot use it when it needs to.

A single incident can combine several types at once. An attack that steals a database and also encrypts it affects confidentiality and availability simultaneously. That is why the analysis must be carried out incident by incident, taking nothing for granted.

What to do step by step in the event of a breach

When an incident is detected, the professional response is orderly, not hasty. Acting methodically makes it possible to decide with judgement which obligations are triggered and which are not. This is the logical sequence.

1. Detect and confirm

The first step is to confirm that something has happened and what it is. Many alerts turn out to be false positives; others, real incidents. Note down when you became aware of the fact, because that moment marks the start of the subsequent deadlines. Being aware means a reasonable certainty that data has been compromised, not a mere initial suspicion.

2. Contain

Before analysing anything in depth, you have to stop the damage. Depending on the case: isolate the affected equipment, revoke compromised access or credentials, remove from the system the document published in error or request the recall of the email sent to the wrong person. Containing does not resolve the breach, but it prevents it from growing while it is assessed.

3. Assess the risk

This is the step that determines everything else. You have to assess the risk to the rights and freedoms of the affected individuals, taking into account the type of data involved, its volume, how many people are affected, the ease of identifying them and the possible consequences for them (for example, identity theft, financial loss or an impact on their privacy). The result of this assessment decides whether the breach stays in the internal register, whether it is also notified to the authority or whether it must additionally be communicated to the affected individuals.

4. Document ALWAYS (art. 33.5 GDPR)

There is no room for interpretation here: all breaches are documented, whether notified or not. Art. 33.5 GDPR requires the controller to document any breach of security, including the facts relating to it, its effects and the corrective action taken. That internal breach register is what makes it possible to demonstrate that the organisation assessed each incident with judgement, including those it decided not to notify because they did not pose a risk. Documenting well is, in practice, the best proof that the organisation has acted diligently.

5. Notify the supervisory authority when there is a risk (art. 33 GDPR)

If the assessment concludes that the breach is likely to result in a risk to the rights and freedoms of individuals, art. 33 GDPR requires it to be notified to the supervisory authority (in Spain, the AEPD). This must be done without undue delay and, where feasible, within the 72 hours following awareness of the breach. If that deadline is not met, the notification must be accompanied by an explanation of the reasons for the delay. The notification describes the nature of the breach, the categories and approximate number of individuals affected, the likely consequences and the measures taken or proposed.

6. Communicate to the affected individuals if the risk is high (art. 34 GDPR)

When the breach is likely to result in a high risk to the rights and freedoms of individuals, art. 34 GDPR additionally requires it to be communicated directly to the affected individuals, without undue delay and in clear and plain language. The aim is that they can protect themselves: change a password, monitor bank movements or stay alert to possible impersonation attempts. Art. 34 itself provides for exceptions to this communication, for example where measures had been applied —such as encryption— that render the data unintelligible to third parties, or where individual notification would involve a disproportionate effort and an equivalent public communication is chosen instead.

Table of deadlines and actions

This is the relationship between each obligation, its basis in the GDPR and when it is triggered. It helps to distinguish what must always be done from what depends on the assessed risk.

Note the tiered logic: documentation is universal, notification depends on there being a risk and communication to the affected individuals is only triggered by a high risk. Not every breach reaches the last tier, but every breach passes through the first.

The breach protocol: preparing in advance

The best way to respond well to a breach is to have decided in advance how you are going to respond. A security breach protocol is the internal document that sets out, before anything happens, who does what and in what order. It is not bureaucracy: it is what makes it possible to meet a 72-hour deadline without improvising.

A useful protocol, grounded in day-to-day reality, usually covers:

• A clear internal reporting channel. So that anyone on the team knows who to alert as soon as they notice something odd, without fear of doing so. Many breaches take time to manage because whoever detects them does not know who to turn to.
• A person responsible for coordinating the response. A figure who centralises decisions and prevents everyone acting on their own.
• An internal register template ready to document the incident in accordance with art. 33.5: what happened, when it was discovered, which data and people it affects, what was done and with what result.
• A risk assessment criterion defined in advance, so as not to have to improvise the assessment under pressure.
• The contact details of the technical staff, the data protection adviser and the channel for notifying the authority, at hand and up to date.

The breach protocol fits within a broader framework of information security policy, which defines the technical and organisational measures of art. 32 GDPR. The two support each other: good security measures reduce the likelihood of breaches, and a good protocol ensures an orderly response when one occurs regardless.

Response checklist

A quick list to have at hand on the day it happens. It does not replace the full protocol, but it orders the first moves.

• ☐ Confirm the incident and note the date and time you became aware of it.
• ☐ Contain: isolate systems, revoke access, remove what was published or sent in error.
• ☐ Identify which data and how many people the incident affects.
• ☐ Classify the breach: confidentiality, integrity, availability or a combination?
• ☐ Assess the risk to the rights and freedoms of the affected individuals.
• ☐ Document everything in the internal breach register (always, art. 33.5).
• ☐ Decide whether it is appropriate to notify the authority (art. 33) and, if so, do it within the deadline.
• ☐ Decide whether it is appropriate to communicate to the affected individuals due to high risk (art. 34).
• ☐ Record the corrective measures taken so that it does not happen again.

Frequently asked questions

What is a security breach under the GDPR?

Art. 4.12 GDPR defines a personal data breach as any breach of security leading to the accidental or unlawful destruction, loss or alteration of personal data, or the unauthorised disclosure of, or access to, such data. It is not only a cyberattack: losing a laptop, sending an email containing data to the wrong recipient or misplacing paper documentation also counts.

Are all security breaches notified to the AEPD?

No. Only breaches likely to result in a risk to the rights and freedoms of the affected individuals are notified to the supervisory authority (art. 33 GDPR). That said, all breaches, whether notified or not, must be documented in an internal register (art. 33.5 GDPR). The decision to notify depends on a prior risk assessment, not on apparent severity.

How quickly must a breach be notified to the supervisory authority?

Art. 33 GDPR provides that, where a breach must be notified, it should be done without undue delay and, where feasible, no later than 72 hours after the controller becomes aware of it. If notified later, the reasons for the delay must accompany the notification. The clock starts when the organisation has reasonable certainty that it has occurred, not from the first indication.

When must the affected individuals be informed of a breach?

When the breach is likely to result in a high risk to the rights and freedoms of the affected individuals (art. 34 GDPR). In that case they must be informed without undue delay, in clear language, explaining what has happened, the possible consequences and the measures taken. If the risk is high but measures that neutralise it have been applied, art. 34 itself provides for exceptions to this communication.

In summary

A security breach is any unauthorised destruction, loss, alteration, disclosure of or access to personal data (art. 4.12 GDPR), and it can range from a cyberattack to a wrongly sent email. The correct response is always methodical: detect, contain, assess the risk, document in the internal register —this last step, always, as required by art. 33.5— and, depending on the risk, notify the supervisory authority within the deadline of art. 33 and communicate to the affected individuals in accordance with art. 34. Having a protocol ready turns a delicate moment into an orderly procedure.

How Certix supports you

At Certix we help organisations prepare their breach protocol before they need it and manage it with judgement when the moment arrives. We define the internal reporting circuit, the register template in accordance with art. 33.5, the risk assessment criterion and the coordination of the notification where appropriate. The aim is not fear, but order: that you know exactly what to do and within what deadline.

You can start by understanding the full framework in our GDPR guide or reviewing how the protocol fits within your information security policy.

---

This content is purely informational and educational; it does not constitute specialised legal advice. Applying the regulations to each specific case requires individual analysis.