Rules & Requirements —
GDPR Requirements Checklist: Everything You Need in 2026
GDPR requirements, including lawful data processing, data rights, DPIAs, breach reporting, and secure data transfers.
Share this article
GDPR Requirements: The Full Picture
GDPR applies to any business handling EU residents' personal data, no matter where that business is based. Getting this right isn't just about dodging fines — it's also what lets you actually close deals with privacy-conscious customers and partners. Here's the full set of requirements, with extra depth on the one most pages skip past too quickly: privacy by design.
Lawful Basis for Processing
Every single thing you do with someone's data needs a real legal reason behind it — consent, a contract, a legal obligation, or legitimate interest are the common ones. Document which basis applies to which processing activity, and keep that documentation somewhere you can actually pull it up fast if an audit happens.
Transparent Privacy Notices
People need to actually understand what's happening to their data. That means plain language, not legal jargon buried six pages into a terms-of-service document, and it needs to be genuinely easy to find — on your website, in your app, wherever people are actually going to look.
Data Subject Rights
People can access, fix, delete, or restrict the use of their own data, and you've got one month to respond. GDPR Data Subject Rights: All 8, Explained breaks down all eight rights individually, including the ones most lists leave out.
Privacy by Design and by Default
This one gets glossed over more than almost anything else in GDPR, which is a mistake, because it's a real legal requirement (Article 25), not just good practice. It's actually two separate obligations:
Privacy by design means you think about data protection before you build something, not after. If you're launching a new feature that touches personal data, the privacy review happens at the planning stage — not as a fire drill right before launch.
Privacy by default means your default settings are the privacy-friendly ones, without anyone having to opt into being protected. A few concrete examples of what this actually looks like:
A signup form that only asks for email and password — not date of birth, phone number, or address, unless you genuinely need them
Analytics tracking that's off until someone opts in, not on until they find the switch to turn it off
Posts or profile info that default to private, with "public" as something you have to choose
A mobile app that only requests the permissions it actually needs, not blanket access to your contacts and camera just in case
One real example worth knowing: a retailer ran a DPIA before launching a loyalty program and discovered the planned design would've collected way more location data than the program actually needed. They caught it and scaled it back before a single customer record existed. That's privacy by design working the way it's supposed to — catching the problem on paper, before it's a problem in production.
Data Protection Impact Assessments (DPIAs)
Required when you're planning something genuinely high-risk — large-scale monitoring, processing sensitive data at scale, that kind of thing. A DPIA forces you to spot the risk and document what you're doing about it before you launch, not after something's already gone wrong.
Record of Processing Activities (RoPA)
This is your evidence trail. What data you process, why, who can access it, where it's stored. Regulators ask for this during investigations, and "we don't really have that written down" is not where you want to be standing when they ask.
Vendor and Third-Party Compliance
Any vendor touching your data on your behalf needs a real Data Processing Agreement — not just a signed contract, but one that actually spells out security obligations, confidentiality, and what happens if there's a breach on their end. Controller vs. Processor Responsibilities covers exactly what has to be in that agreement.
Breach Notification
If something goes wrong, you've got 72 hours to notify the supervisory authority — but that clock starts when you become aware of the breach, not when it actually happened, and not every breach even needs reporting. GDPR Compliance Requirements covers this mechanic in real depth, including the part most summaries get wrong about when the clock actually starts.
Cross-Border Data Transfers
Moving personal data outside the EU means you need a real mechanism backing it up — an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules. This isn't a place to wing it; enforcement here has gotten serious, with fines in the hundreds of millions for unlawful transfers.
Bringing It Together With Other Frameworks
A lot of organizations build their GDPR program alongside ISO 27001 and other security frameworks, since the underlying work — risk assessment, access control, documented evidence — overlaps heavily. Build it once, well, and the audits across multiple frameworks all get easier.
FAQs
What is "privacy by design and by default" under GDPR? It's a legal requirement under Article 25, not just a best practice, made up of two obligations: privacy by design means building data protection into a system during planning, before launch; privacy by default means default settings are automatically the privacy-friendly option, without requiring users to opt in to protection.
What does "privacy by default" actually look like in practice? Concrete examples include a signup form that only collects email and password unless more is genuinely needed, analytics tracking that's off until a user opts in, profile settings that default to private, and mobile apps that request only the permissions they actually use — rather than broad access "just in case."
What is a Data Protection Impact Assessment (DPIA) and when is it required? A DPIA is a required assessment for genuinely high-risk processing activities — such as large-scale monitoring or processing sensitive data at scale — that forces an organization to identify risks and document mitigations before launching, rather than after a problem occurs.
Can a DPIA actually change a product before it launches? Yes. One documented example involved a retailer running a DPIA before launching a loyalty program and discovering the planned design would collect far more location data than necessary — the company scaled back the design before a single customer record was collected, which is privacy by design working as intended.
What are the core lawful bases for processing personal data under GDPR? The common lawful bases are consent, contract, legal obligation, and legitimate interest, among a few others. Every processing activity needs one of these documented and readily available in case of an audit — not chosen retroactively to justify existing practices.
What must a privacy notice actually include to be GDPR-compliant? A compliant privacy notice must be written in plain language rather than dense legal jargon, and must be genuinely easy to find — on a website, in an app, or wherever people would reasonably look — rather than buried deep within a terms-of-service document.
When does the 72-hour GDPR breach notification clock actually start? The clock starts when the organization becomes aware of a breach, not when the breach actually occurred. Not every breach requires notification to a supervisory authority — the requirement depends on the level of risk to affected individuals.
What needs to be in a vendor Data Processing Agreement (DPA) under GDPR? A compliant DPA must go beyond a standard signed contract — it needs to explicitly spell out security obligations, confidentiality requirements, and the process for handling a breach that originates on the vendor's end.
What is a Record of Processing Activities (RoPA), and why does it matter during a regulatory investigation? A RoPA is an organization's documented evidence trail — what data it processes, why, who can access it, and where it's stored. Regulators request this during investigations, and being unable to produce it is a significant liability, since its absence has factored into real enforcement actions.
Does GDPR require a specific legal mechanism for transferring data outside the EU? Yes. Cross-border transfers require a valid mechanism — an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules. Enforcement in this area has become notably strict, with fines reaching into the hundreds of millions of euros for unlawful transfers without proper safeguards.
In the Spotlight
Start your GDPR compliance journey with DSALTA's complete checklist.
The General Data Protection Regulation (GDPR) is Europe’s core privacy law, shaping how organizations collect, process, and protect the personal data of EU residents. Non-compliance can result in heavy fines, reputational damage, and loss of customer trust.
GDPR can feel complicated with its broad scope and strict requirements, but DSALTA® makes it manageable. With automated evidence collection, continuous monitoring, and AI- driven risk insights, you can maintain compliance without drowning in manual work. Use this checklist to guide your GDPR journey.
Read more about GDPR compliance with DSALTA.
Stop losing deals to compliance.
Get compliant. Keep building.
Join 100s of startups who got audit-ready in days, not months.




