Key GDPR Compliance Requirements

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.

FAQs

When does the GDPR 72-hour breach notification clock actually start? The clock starts when the organization becomes "aware" of the breach — meaning there's reasonable certainty a security incident compromised personal data — not when the breach first occurred and not only after a full investigation is complete. Regulators expect notification before the investigation wraps up, not after.

Does every data breach need to be reported to a regulator under GDPR? No. Only breaches likely to pose a risk to people's rights and freedoms require regulator notification. However, this exemption is narrow, and organizations are expected to document their reasoning even for breaches they determine don't require reporting.

When do you have to notify the actual individuals affected by a breach, not just the regulator? Only when the risk to those individuals is "high" — a separate, higher bar than the risk threshold that triggers regulator notification under Article 34. This means a breach can require notifying a supervisory authority without requiring direct notification to every affected person.

Can you notify a regulator before your breach investigation is finished? Yes, and in fact you're expected to. Organizations can notify in phases — informing the regulator of what's known so far and following up with additional details as the investigation progresses, rather than waiting until every fact is confirmed.

What happens if a company misses the 72-hour breach notification deadline? Missing the deadline without good reason is treated as its own separate violation, distinct from the breach itself. Fines specifically for failure to notify can reach €10 million or 2% of global annual turnover.

Do breaches that don't require regulator notification still need to be documented? Yes. Every breach must be documented internally, regardless of whether it ultimately required notification. Regulators can request this internal record to verify that the organization's "no notification needed" determination actually holds up.

When is a Data Protection Impact Assessment (DPIA) actually required? DPIAs are triggered by specific high-risk scenarios: large-scale processing of special category data (health, biometric, etc.), systematic large-scale monitoring of a publicly accessible area, or using new technologies in ways that could significantly affect people, such as automated decision-making or profiling.

What should an organization do if it's unsure whether a DPIA is required? The safer default is to run the assessment anyway. A DPIA provides a structured way to identify and document risk, and if a regulator later questions why one wasn't performed, having actually assessed and documented the decision is a stronger position than simply assuming it didn't apply.

How many core requirements make up GDPR compliance? Nine connected obligations: a lawful basis for processing, clear privacy notices, enabling data subject rights, records of processing activities, DPIAs when necessary, security safeguards, 72-hour breach reporting, Data Processing Agreements with vendors, and managing cross-border transfers.

Why do GDPR's nine compliance requirements need to work together rather than as separate checklist items? They're interdependent — your lawful basis determines what a DPIA needs to evaluate, your records of processing activities are what you'd check during a breach investigation, and a weak vendor DPA undermines your own breach response since you depend on vendors reporting incidents quickly. Treating them as one connected system holds up better under regulatory scrutiny than nine isolated boxes.