GDPR for Security Teams: Breach Notification and Article 32

Security teams are rarely responsible for GDPR as a whole, and should not try to be. But several provisions bear directly on security operations, and the breach notification timeline in particular has operational consequences that must be worked out before an incident rather than during one.

GDPR for Security Teams: The Parts That Affect You

Article 32: security of processing

Article 32 requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk. It deliberately avoids prescribing specific technologies, instead naming considerations such as pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience, the ability to restore availability after an incident, and a process for regularly testing and evaluating effectiveness.

That last point is the one security teams should note: regular testing and evaluation is written into the regulation. Penetration testing, vulnerability management and control assessment are ways of demonstrating it, and the documentation of those activities is what evidences compliance if a regulator asks.

The 72-hour notification clock

Where a personal data breach is likely to result in a risk to individuals' rights and freedoms, it must be notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it.

Two details matter operationally. The clock starts at awareness, not at the point of full understanding — so it usually runs while investigation is still ongoing. And notification can be provided in phases where full information is not yet available, which is explicitly permitted and preferable to missing the deadline. Where the risk to individuals is high, they must be informed too.

The practical implication is that the decision about whether something constitutes a notifiable breach cannot be improvised. Security and privacy colleagues need an agreed process, agreed decision-makers and rehearsed communication before it is needed.

Article 32 requires appropriate, risk-based security

What counts as a personal data breach

The definition is broader than many teams assume. It covers destruction, loss, alteration, unauthorised disclosure of, or access to personal data — accidental or unlawful.

Ransomware is a breach even without exfiltration, because it affects availability.
An email containing personal data sent to the wrong recipient is a breach.
A lost unencrypted laptop or drive is a breach.
An internal employee accessing records without a legitimate purpose is a breach.
A backup deleted with no recoverable copy is a breach through loss of availability.
Not every breach requires notification — the test is risk to individuals — but every one requires assessment and internal documentation.

Where security work intersects

Records and data mapping — you cannot assess breach impact without knowing what personal data exists and where. This is usually privacy-owned but security-dependent.
Data minimisation — data not retained cannot be breached, so retention policy is a security control as well as a privacy one.
Encryption and pseudonymisation — explicitly referenced, and relevant to assessing risk after an incident.
Access control and monitoring — evidencing that access is limited and reviewed.
Processor management — suppliers processing personal data on your behalf sit within your responsibility, so their security matters to you.
Incident detection capability — you cannot notify within 72 hours of awareness if detection takes months, which links the regulation directly to detection investment.

Security and privacy teams must rehearse together

A practical note on scope

GDPR applies based on where the individuals are, not solely where the organisation is. An organisation outside the EU or UK offering goods or services to people there, or monitoring their behaviour, can fall within scope.

This regularly surprises organisations that assumed geography exempted them. The question of applicability is a legal one and should be answered by qualified counsel rather than assumed by the security team — but security should know the answer, because it determines whether the 72-hour process needs to exist.

Related from TechBiz Security

Sources & further reading

Frequently asked questions

When does the GDPR 72-hour breach notification clock start?

It starts when the organisation becomes aware of the personal data breach, not when the investigation concludes. Notification may be made in phases where full information is not yet available, which is preferable to delaying beyond the deadline.

Is ransomware a personal data breach under GDPR?

Generally yes, even without exfiltration, because encryption affects the availability of personal data and the definition covers loss of availability as well as unauthorised disclosure. Whether notification is required depends on the risk to individuals.

What does Article 32 require technically?

It requires measures appropriate to the risk rather than a prescribed list, referencing pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, restoration capability, and a process for regularly testing and evaluating effectiveness.

Does GDPR apply to organisations outside Europe?

It can. Applicability depends substantially on whether the organisation offers goods or services to, or monitors the behaviour of, individuals in the relevant territory. It is a legal determination and should be confirmed with qualified counsel.

GDPR for Security Teams: The Parts That Affect You