GDPR Compliance Requirements

GDPR compliance isn't one checklist — it's nine connected obligations, and a few of them get misunderstood in ways that actually matter. This page covers the two most commonly misunderstood ones (breach notification and DPIAs) in real depth, and points you to dedicated pages for the rest rather than repeating them thinly here.

The Nine Requirements, Briefly

A lawful basis for processing. Every single processing activity needs a real legal justification, decided before you start, not invented after someone asks.

Clear privacy notices. People need to actually understand what you're doing with their data — this is the right to be informed in action.

Enabling data subject rights. All eight rights, with real deadlines attached. GDPR Data Subject Rights: All 8, Explained covers each one and the timelines that come with them.

Records of processing activities. A documented map of what data you process, why, and where it goes — required under Article 30.

DPIAs when necessary. Covered in depth below, since "when necessary" actually has specific triggers most people don't know.

Security safeguards. Real technical and organizational measures, not just a written policy. This connects directly to the seven core principles, specifically integrity and confidentiality.

72-hour breach reporting. Also covered in depth below — the trigger condition matters more than the headline number.

Data Processing Agreements with vendors. Controller vs. Processor Responsibilities covers exactly what these agreements need to contain.

Managing cross-border transfers. This has its own set of mechanisms (adequacy decisions, standard contractual clauses) — worth its own dedicated read rather than a one-line summary here.

Breach Notification: The Part Everyone Gets Slightly Wrong

The 72-hour number is real, but the clock doesn't start when the breach happens. It starts when you become "aware" of it — meaning you have reasonable certainty a security incident actually compromised personal data. Not the first suspicious alert. Not after a full investigation either. Somewhere in between, and regulators expect you to notify before your investigation is complete, not after.

A few things worth knowing that most summaries skip:

• Not every breach needs to be reported to the regulator — only ones likely to pose a risk to people's rights and freedoms. But this exemption is narrow, and when in doubt, the safer move is to notify.

• There's a separate, higher bar for telling the actual people affected (Article 34) — that only kicks in when the risk is "high," not just present. So a breach can require regulator notification without requiring you to email every affected person.

• You don't need every fact before you notify. If your investigation is still running, you can notify in phases — tell the regulator what you know now, and follow up later.

• Every breach gets documented internally, period — even the ones that don't end up requiring notification. Regulators can ask to see that internal record to check whether your "we didn't need to notify" reasoning actually holds up.

Miss the 72 hours without a good reason, and the failure to notify is its own separate violation — on top of whatever the breach itself caused. Fines for this specifically can reach €10 million or 2% of global turnover.

DPIAs: When "Necessary" Actually Kicks In

A Data Protection Impact Assessment isn't required for every processing activity — just the ones likely to create high risk for people. The clearest trigger conditions are:

• Large-scale processing of special category data (health, biometric, and the other Article 9 categories)

• Systematic, large-scale monitoring of a publicly accessible area

• Using new technologies in a way that could meaningfully affect people, especially involving automated decision-making or profiling

If you're not sure whether something qualifies, the safer default is to run the assessment. It's a structured way to identify risk and document what you're doing about it — and if a regulator later asks why you didn't run one, "we didn't think it applied" is a weaker answer than having actually checked.

Why These Connect Instead of Standing Alone

None of these nine requirements work in isolation. Your lawful basis determines what a DPIA needs to evaluate. Your records of processing activities are what you'd actually check during a breach investigation to know what data was affected. A weak DPA with a vendor undermines your own breach response, since you're depending on that vendor to tell you about incidents fast. Building these as one connected system, instead of nine separate boxes, is what actually holds up under scrutiny.

Pairing This With Other Frameworks

A lot of this groundwork — security safeguards, incident response, documented risk assessment — overlaps with what ISO 27001 and SOC 2 already require. Build the underlying discipline once, and GDPR, ISO 27001, and SOC 2 all get easier to maintain together instead of as three separate efforts.