GDPR Compliance on AWS: A Practical Guide for SaaS Companies

GDPR is no longer the new compliance burden it was in 2018 — it is the operating reality for any SaaS company with European customers. Penalties have escalated (Meta €1.2B, Amazon €746M), enforcement has matured, and the bar that EU procurement teams expect has risen accordingly. For US SaaS companies, GDPR is rarely a choice; it is a precondition for the European deal pipeline.

This guide covers GDPR compliance on AWS for SaaS: which regions to use, how the AWS Data Processing Addendum works, how to operationalize data subject rights, what your RoPA needs to contain, and the technical controls regulators actually look for during an investigation.

Need help with GDPR on AWS? FactualMinds builds GDPR-compliant architectures for SaaS companies expanding into the EU — including data residency design, DSAR automation, and post-Schrems II transfer mechanism setup. See our compliance services or talk to our team.

Step 1: Determine Whether GDPR Applies

GDPR Article 3 has extraterritorial reach. You’re in scope if:

• You offer goods or services to people in the EU (paid or free, including free trials and freemium tiers)
• You monitor the behavior of people in the EU (analytics, behavioral targeting, fraud detection)

Headquarters location does not matter. A Delaware C-corp serving even one EU customer is in scope. The threshold is the data subject’s location at the time of processing — not their nationality.

You are NOT in scope if your service genuinely does not target EU residents (e.g., a US-only telehealth platform that geo-blocks EU users at signup). Document the determination — “we are not in scope because…” — so you can defend it if challenged.

Step 2: Establish Your Role — Controller, Processor, or Both

GDPR distinguishes between data controllers (who decide why and how data is processed) and data processors (who process data on behalf of a controller).

For most B2B SaaS companies:

• You are a controller for your own employees’ data (HR, payroll), your own customer contact data (billing, CRM), and any analytics or marketing data you collect for yourself.
• You are a processor for the customer data your customers upload into your product (their end users, their tenants, their content).

This dual role matters because the GDPR obligations differ:

• Controllers have obligations to data subjects directly (notice, consent, DSAR responses, breach notification to DPAs).
• Processors have obligations to controllers (contractual, security, sub-processor disclosure, assistance with controller obligations).

Document your role in your privacy policy, customer DPA, and RoPA.

Step 3: Sign the AWS Data Processing Addendum

The AWS DPA establishes AWS as a sub-processor under GDPR Article 28 for any personal data you process on AWS.

• The AWS DPA is automatically incorporated into the AWS Customer Agreement — no separate signature
• AWS Artifact provides downloadable copies for your records
• AWS publishes its sub-processor list (the AWS regions used and AWS subsidiaries involved)
• AWS commits to assist with data subject requests, breach notification, and audit support

You then need to flow GDPR obligations downstream to your own sub-processors:

• Other SaaS vendors (analytics, support, observability)
• Independent contractors with access to customer data
• Any party that touches personal data on your behalf

Each sub-processor needs a DPA. Maintain a sub-processor inventory and disclose it to your customers (most enterprise contracts require advance notice of new sub-processors).

Step 4: Choose AWS Regions for Data Residency

For EU resident personal data, default to EU regions:

Avoid storing EU personal data in non-EU regions unless you have:

1. A documented transfer mechanism (Standard Contractual Clauses + Transfer Impact Assessment, or EU-US Data Privacy Framework certification)
2. Customer contractual permission for the transfer
3. Documented technical and organizational measures for the transfer (encryption, access controls)

EU Sovereign Cloud

AWS announced the EU Sovereign Cloud in late 2023, with operations expanding through 2025–2026. The Sovereign Cloud provides:

• EU-only personnel for operations and support
• Independent EU-headquartered legal entity
• EU-only metadata and customer data
• Air-gapped from non-EU regions

For organizations in regulated EU sectors (public sector, healthcare, finance) or those subject to particularly strict customer requirements, the Sovereign Cloud is becoming the strategic choice.

Step 5: Build Your Records of Processing Activities (RoPA)

RoPA is the first document a Data Protection Authority asks for. It must contain, for each processing activity:

• Purpose of processing (e.g., “customer onboarding”)
• Categories of data subjects (customers, end users, prospects)
• Categories of personal data (name, email, IP address, billing info)
• Categories of recipients (sub-processors, internal teams)
• Transfers to third countries (list AWS regions used)
• Retention periods
• Security measures (encryption, access controls, monitoring)

Maintain it as a living spreadsheet (or in a privacy management tool like OneTrust, TrustArc, or Vanta). Update quarterly and after any new feature launch that changes data flows.

A typical SaaS RoPA has 15–40 entries — one per logical processing activity (customer signup, payment processing, support ticket handling, marketing email, product analytics, etc.).

Step 6: Operationalize Data Subject Rights

Article 15–22 grants seven rights to EU residents:

You must respond within one month (extendable to three for complex requests).

DSAR Architecture on AWS

Build a DSAR workflow that scales:

1. Intake portal — a public form (S3 + CloudFront, or a hosted page like a privacy page) where data subjects submit requests
2. Identity verification — confirm the requester is the data subject (email confirmation, account login, or KYC for sensitive data)
3. Request orchestration — Step Functions workflow that fans out to each data store
4. Data location queries — Lambda functions that query DynamoDB, RDS, OpenSearch, and S3 by user identifier
5. Backup considerations — your erasure plan needs to cover backups (either deletion from backups or retention policy alignment)
6. Export packaging — encrypted ZIP with the data, delivered via S3 presigned URL with expiration
7. Audit log — every DSAR logged in CloudTrail / a dedicated DynamoDB table for evidence

The Backup Erasure Trap

Most companies miss this. If your erasure workflow deletes data from production but the data persists in 90-day backups, you have not honored the request. Options:

• Align backup retention with your DSAR commitment (e.g., 30 days max)
• Maintain a “deletion log” and re-apply deletions if data is restored from backup
• Document in your privacy policy that erasure becomes complete when backup retention expires

The DPA’s expectation is that you have a defensible position, documented and consistent.

Step 7: Implement Privacy by Design Technical Controls

GDPR Article 25 requires “privacy by design and by default.” Practical AWS implementation:

Encryption at Rest and In Transit

• At rest: KMS-encrypted S3, EBS, RDS, DynamoDB; CMK with auto-rotation
• In transit: ACM-issued TLS certificates, VPC endpoints for AWS service traffic
• Application layer: envelope encryption for sensitive fields (e.g., national IDs)

Access Control and Audit

• IAM Identity Center with MFA, SSO, and federation
• Least privilege via permission boundaries and Access Analyzer
• CloudTrail for all API calls; CloudTrail Lake for long-retention forensic queries
• Data event logging for S3 buckets containing personal data

Data Discovery and Classification

• Macie for sensitive data discovery in S3 (PII, health data, financial)
• Tagging policy requiring data-classification tag on all storage resources
• Custom data identifiers for industry-specific PII patterns (e.g., national IDs)

Pseudonymization

GDPR encourages pseudonymization (Art. 32). Practical patterns:

• Application-layer tokenization with a separate KMS key for the token mapping
• Hashing user IDs in analytics pipelines
• Separating identity from behavior (analytics on hashed IDs; identity in a separate, more controlled store)

Step 8: Breach Notification (Article 33–34)

GDPR requires notification of personal data breaches:

• To the DPA: within 72 hours of becoming aware
• To data subjects: without undue delay if the breach is likely to result in high risk

You need an incident response plan that includes:

• Detection mechanisms (GuardDuty, Security Hub, Macie)
• Severity classification (which findings trigger GDPR breach notification)
• Notification templates
• Stakeholder list (DPO, legal, communications, executive)
• Logging of every incident with the determination of whether it was a notifiable breach

The 72-hour clock starts when you become aware — not when you confirm. If GuardDuty alerts on data exfiltration at 3am, the clock starts then.

Step 9: Conduct DPIAs Where Required

Article 35 mandates a Data Protection Impact Assessment (DPIA) for high-risk processing. Triggers most relevant for SaaS:

• AI / ML on personal data — especially Bedrock workloads processing customer data
• Large-scale special category data — health, genetic, biometric
• Systematic monitoring — employee monitoring, public space monitoring
• Profiling with significant effects — credit scoring, hiring decisions, fraud scoring

DPIA contents:

1. Description of processing
2. Necessity and proportionality assessment
3. Risk to data subjects
4. Mitigations and residual risk
5. DPO consultation

If residual risk remains high after mitigation, prior consultation with the DPA is required (Art. 36) — and they may delay or prohibit the processing.

Step 10: Appoint a DPO (or DPO-as-a-Service)

A Data Protection Officer is required when:

• You’re a public authority
• Your core activities require systematic monitoring on a large scale
• You process special category data on a large scale

Most B2B SaaS companies are not strictly required to appoint a DPO, but enterprise customers increasingly expect one. Options:

• Internal DPO — reasonable for mid-size organizations; the DPO must be independent and report to top management
• DPO-as-a-Service — outsourced, common for smaller SaaS
• Privacy lead — informal role for small companies, formalized once the business scales

Post-Schrems II — International Transfers

Schrems II (2020) invalidated the EU-US Privacy Shield. Schrems II compliance currently rests on:

• EU-US Data Privacy Framework (DPF) — the 2023 successor to Privacy Shield; companies certify on the dpf.gov website
• Standard Contractual Clauses (SCCs) — the 2021 modular SCCs from the European Commission
• Transfer Impact Assessment (TIA) — documented assessment of whether the receiving country provides essentially equivalent protection
• Supplementary measures — encryption, pseudonymization, contractual commitments where TIA finds gaps

For US-headquartered SaaS using AWS regions in the EU but with US support staff: maintain SCCs or DPF certification as belt-and-braces, document the TIA, and disclose transfers in your privacy notice.

Cost and Timeline Summary

For a SaaS company starting from scratch on GDPR:

Companies with a mature ISO 27001 program save roughly 40% of effort because access control, encryption, and incident response controls overlap.

Get Started

If your sales cycle is being slowed by EU procurement teams asking about GDPR — or if your customer’s procurement just sent a 200-question security and privacy questionnaire — we can help. We build GDPR-compliant SaaS architectures on AWS that satisfy enterprise European buyers while staying maintainable for engineering teams.

Talk to our team →