The EU slapped Amazon with a €746 million GDPR fine in 2021. Meta collected €1.2 billion in 2023. These aren't outliers — they're signals. Regulators have graduated from warning letters to weaponized enforcement, and organizations still treating GDPR as a legal checkbox exercise are operating on borrowed time.
Whether you're a security engineer trying to understand what GDPR actually requires at a technical level, or a compliance officer at a US company suddenly realizing your SaaS product processes EU personal data, this checklist covers the substance — not the fluff.
What Is GDPR and Who Does It Apply To?
The General Data Protection Regulation came into force on May 25, 2018, replacing the patchwork of EU member-state data protection laws under Directive 95/46/EC. You can reference the regulation directly at the GDPR official website maintained by the EU, though the authoritative legal text lives at EUR-Lex.
Here's the part US companies consistently underestimate: GDPR applies to any organization that processes personal data of EU residents, regardless of where that organization is based. GDPR applies to a startup in Austin if it's selling subscriptions to users in Berlin. It applies to a B2B SaaS company in Singapore if its platform hosts data belonging to French citizens. The regulation's extraterritorial reach is explicit under Article 3.
Two roles matter enormously here. Data controllers determine the purposes and means of processing. Data processors act on behalf of controllers. If you're a cloud service provider or infrastructure vendor, you're likely a processor — which means Article 28 processor agreements are non-negotiable in every customer contract.
The Core GDPR Articles You Actually Need to Understand
There are 99 GDPR articles in total, but the ones that generate most enforcement actions cluster around a handful of themes. Rather than referencing a GDPR PDF and hoping for the best, understand these substantively.
Article 5 — Data Processing Principles
Six principles govern all lawful data processing: lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; and integrity and confidentiality. Accountability — the seventh principle — sits underneath all of them. If you can't demonstrate compliance, Article 5(2) treats it as non-compliance. Documentation isn't bureaucracy here; it's your legal defense.
Articles 13 and 14 — Transparency and Privacy Notices
Data subjects must be informed about who's processing their data, why, how long it's kept, and what rights they have. Most organizations write privacy policies; far fewer actually surface that information at the point of data collection in a format that meets the GDPR's intelligibility standard. The ICO has fined organizations specifically for inadequate transparency — not just for breaches.
Article 17 — Right to Erasure
The "right to be forgotten" sounds simple until you're dealing with data spread across a data warehouse, three microservices, a backup S3 bucket, and a third-party analytics platform. Operationalizing Article 17 requires a data inventory that actually reflects your architecture, not your wishful thinking.
Article 25 — Data Protection by Design and Default
Security controls shouldn't be bolted on after development — they should be baked in from the architecture phase. This aligns directly with the shift-left philosophy that modern security engineering already promotes. If your developers are shipping features without data minimization reviews, Article 25 is where that gap becomes a regulatory liability.
Article 32 — Security of Processing
This is where GDPR gets technical. Article 32 requires appropriate technical and organizational measures including pseudonymization, encryption, confidentiality, integrity, availability, and resilience of processing systems. "Appropriate" is intentionally vague, but regulators assess it against the state of the art — which in 2025 means things like zero-trust architecture, end-to-end encryption, and automated vulnerability management.
Article 33 — Breach Notification
72 hours. That's your window to notify the supervisory authority after discovering a personal data breach. Not 72 business hours. Not 72 hours after your legal team finishes their review. 72 hours from awareness. For Article 34, if the breach is high-risk to individuals, you also need to notify those individuals directly — without undue delay.
The GDPR Compliance Checklist
This is the operational substance. Work through this systematically, not as a one-time audit but as an ongoing program.
1. Data Mapping and Records of Processing Activities (RoPA)
Article 30 requires controllers and processors to maintain records of processing activities. Most organizations have partial records at best. A complete RoPA should document: what data you collect, where it comes from, why you collect it (legal basis), who you share it with, where it's stored (including third countries), and how long you retain it. This isn't optional for organizations with 250+ employees, and practically speaking you need it regardless of size to respond to subject access requests.
Your Cloud Inventory capability is directly relevant here — you can't map data flows you can't see.
2. Establish Lawful Bases for Every Processing Activity
Six lawful bases exist under Article 6: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Consent is the most commonly cited but also the most frequently misunderstood. Consent under GDPR must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't qualify. Silence doesn't qualify. If you're relying on legitimate interests, document the balancing test.
3. Conduct a Data Protection Impact Assessment (DPIA)
Article 35 mandates DPIAs for processing likely to result in high risk to individuals. This includes large-scale processing of special category data, systematic monitoring of publicly accessible areas, and automated decision-making with significant effects. A DPIA isn't a bureaucratic exercise — it's a structured risk assessment. If your DPIA finds unacceptably high residual risk, you must consult the supervisory authority before processing. Most companies skip this and hope for the best. That's a gamble.
4. Appoint a Data Protection Officer (DPO) if Required
Article 37 mandates a DPO for public authorities, organizations that carry out large-scale systematic monitoring, and those processing special category data at scale. Even if you're not required, having a named DPO or privacy lead who owns compliance operationally is a defensible risk reduction measure. The DPO must report to the highest level of management and must not receive instructions on how to perform their tasks.
5. Review and Update Privacy Notices
Your privacy notice must cover the full Article 13/14 disclosure requirements. Beyond legal completeness, consider the UX: is it findable, readable, and accurate? Outdated privacy notices that don't reflect actual data flows are a common regulatory trigger. Review them every time your architecture changes — which in agile environments means reviewing them regularly. Make sure your Privacy Policy reflects current processing activities.
6. Implement Data Subject Rights Workflows
Subject access requests (SARs), rectification, erasure, restriction, portability, and objection. You need documented, tested processes for handling each. The one-month response deadline for SARs is real and enforceable. If you're processing data at scale across distributed systems, manual SAR handling isn't sustainable — automate where possible, document where you can't.
7. Secure Your Processing Under Article 32
This means encryption in transit and at rest, access controls, network segmentation, regular vulnerability assessments, and incident response plans. Penetration testing is expected. Automated scanning is now table stakes. The Compliance platform at SECRAILS helps teams map technical controls to regulatory requirements rather than managing that mapping manually in spreadsheets.
For organizations running cloud infrastructure, CSPM tooling is essential for catching misconfigurations that could expose personal data — misconfigured S3 buckets, overly permissive IAM roles, unencrypted databases. These aren't edge cases; they're among the most common root causes of GDPR-reportable breaches.
8. Build a Breach Detection and Notification Process
Article 33's 72-hour clock starts ticking when you become aware of a breach — so the longer your detection gap, the shorter your response window. Modern organizations should be investing in detection capabilities that shrink dwell time, not just notification workflows that meet the deadline. Once you detect, your notification to the supervisory authority must include the nature of the breach, categories and approximate number of affected individuals, likely consequences, and measures taken.
9. Manage Third-Party Processors with Article 28 Agreements
Every third-party processor handling EU personal data on your behalf needs a Data Processing Agreement (DPA). Article 28 is prescriptive about what these must contain: purpose and duration, nature of processing, types of data, obligations and rights of the controller, subprocessor requirements, and audit rights. Your vendor list is almost certainly longer than your DPA list. Audit it.
10. Address International Data Transfers
Transferring personal data outside the EU/EEA requires an appropriate transfer mechanism. Post-Schrems II, the landscape shifted significantly. Standard Contractual Clauses (SCCs) are the most common mechanism, but you must also conduct a Transfer Impact Assessment (TIA) for each transfer. The EU-US Data Privacy Framework provides a pathway for US-based processors — but it remains subject to legal challenge.
GDPR Compliance for US Companies
The question isn't whether GDPR applies to your US company — it's whether you're in scope. If your website accepts orders from EU residents, if your app is available in the App Store in Germany, if your SaaS has European customers, you're in scope.
Practically, this means: appointing an EU representative under Article 27 (required if you're not established in the EU but process EU data regularly), implementing all the checklist items above, and accepting that US legal standards — including federal privacy law, which still doesn't exist at the federal level — don't satisfy GDPR obligations.
GDPR compliance tools purpose-built for cross-border environments, combined with automated technical controls, dramatically reduce the manual overhead. Tools like OneTrust, TrustArc, and Securiti cover the process layer. For the technical controls — code scanning, secrets management, cloud configuration — the Cloud Security and Policy-as-Code capabilities at SECRAILS give engineering teams the guardrails to prevent privacy-violating configurations from reaching production.
GDPR Compliance Tools Worth Knowing
No single tool handles GDPR end-to-end, and anyone selling you that pitch is lying. The compliance stack typically looks like: a privacy management platform (OneTrust, Didomi, Usercentrics) for consent and notices; a data discovery tool (Spirion, BigID) for finding personal data across your environment; a GRC platform (Vanta, Drata, Tugboat Logic) for evidence collection and control mapping; and security tooling for the technical controls Article 32 demands.
The integration between these layers is where most programs fall down. Your CSPM identifies an exposed database containing PII. Does that automatically trigger a DPIA review? Does it flag the relevant processor agreement? For most organizations, the answer is no — those processes live in separate silos. Closing that gap is what mature GDPR programs actually look like.
What Auditors and Regulators Look For
Supervisory authorities don't just look at whether you had a breach. They look at whether you had adequate controls in place, whether you could demonstrate them, and whether you responded appropriately when something went wrong. The accountability principle (Article 5(2)) is the meta-principle — you must be able to demonstrate compliance, not just claim it.
Documentation is evidence. Your RoPA, your DPIAs, your Article 28 agreements, your training records, your incident response logs — all of it builds the case that your organization treats data protection as a real operational commitment rather than a legal liability to be minimized. Teams using VM Scans and automated compliance tooling can generate audit trails automatically, which is infinitely better than reconstructing evidence after the fact.
The organizations that fare best in enforcement actions are the ones that got caught despite strong controls, not because of weak ones. That distinction matters enormously to regulators deciding between corrective measures and eight-figure fines.