--- title: GDPR Compliance on AWS: A Practical Guide for SaaS Companies description: GDPR compliance on AWS for SaaS companies handling EU resident data. Region selection, the AWS DPA, data subject rights automation, RoPA documentation, breach notification, and the technical controls regulators expect. url: https://www.factualminds.com/blog/gdpr-compliance-aws-saas-data-protection/ datePublished: 2026-04-27T00:00:00.000Z dateModified: 2026-06-11T00:00:00.000Z author: Palaniappan P category: Security & Compliance tags: gdpr, compliance, frameworks, data-protection, privacy, security, aws --- # GDPR Compliance on AWS: A Practical Guide for SaaS Companies > GDPR compliance on AWS for SaaS companies handling EU resident data. Region selection, the AWS DPA, data subject rights automation, RoPA documentation, breach notification, and the technical controls regulators expect. 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. > **Continuous evidence pipeline (2026):** DPAs investigating a breach will ask for technical control evidence across the incident window — encryption state, access logs, configuration drift history. New orgs should accrue that via **Config conformance packs + Security Hub + CloudTrail Lake** from day one, not manual exports — see [continuous compliance automation](/blog/aws-continuous-compliance-automation-config-audit-manager-2026/). Existing Audit Manager customers can keep framework-mapped assessments through their support window. > **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](/services/cloud-compliance-services/) or [talk to our team](/contact-us/). ## 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: | Region | Code | Notes | | --------- | ------------ | ---------------------------------------------------------- | | Frankfurt | eu-central-1 | Most common; broadest service availability | | Ireland | eu-west-1 | Long-established; broad services | | Paris | eu-west-3 | French data residency emphasis | | Stockholm | eu-north-1 | Lower-cost; sustainability narrative | | Milan | eu-south-1 | Italian data residency | | Spain | eu-south-2 | Newest EU region | | Zurich | eu-central-2 | EU-adjacent (Switzerland is not EU); Swiss data protection | | London | eu-west-2 | **UK GDPR — separate regime post-Brexit** | **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: | Right | What it requires | | ------------------------------------------- | ------------------------------------------------------------ | | Access (Art. 15) | Provide a copy of personal data being processed | | Rectification (Art. 16) | Correct inaccurate data | | Erasure / "Right to be forgotten" (Art. 17) | Delete data when no longer needed | | Restriction (Art. 18) | Stop processing while a dispute is resolved | | Portability (Art. 20) | Provide data in a machine-readable format | | Objection (Art. 21) | Stop processing for direct marketing or legitimate interests | | Automated decision-making (Art. 22) | Right to human review of automated decisions | 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](/blog/hipaa-compliant-ai-aws-bedrock/) 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: | Phase | Duration | Cost | | ------------------------------------------------------ | ---------- | --------------- | | Privacy assessment + scope determination | 2–3 weeks | $5,000–$10,000 | | RoPA, privacy policy, DPA templates | 4–6 weeks | $10,000–$20,000 | | Technical controls (DSAR automation, region migration) | 6–12 weeks | $20,000–$60,000 | | DPO engagement (annual) | Ongoing | $20,000–$50,000 | 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 →](/contact-us/) ## FAQ ### Does GDPR apply to my US SaaS company? Yes, if you process personal data of EU residents — regardless of where your company is headquartered. Article 3 of GDPR has extraterritorial scope: it applies if you (a) offer goods or services to EU residents (paid or free), or (b) monitor the behavior of EU residents (analytics, behavioral advertising). A US SaaS with even one EU customer is in scope. Penalties are real: up to €20 million or 4% of global annual revenue, whichever is higher. The CNIL (France) issued €746M to Amazon in 2021; the Irish DPC issued €1.2B to Meta in 2023. GDPR is enforced. ### Which AWS region should I use for EU data? For EU resident data, prefer EU regions: Frankfurt (eu-central-1), Ireland (eu-west-1), Paris (eu-west-3), Stockholm (eu-north-1), London (eu-west-2 — note UK GDPR, not EU GDPR), Milan (eu-south-1), Spain (eu-south-2), or Zurich (eu-central-2). For maximum data sovereignty under post-Schrems II / Data Privacy Framework concerns, the EU Sovereign Cloud (announced 2023, expanding 2025–2026) provides EU-only operations. Avoid storing EU resident personal data in non-EU regions unless you have a documented transfer mechanism (Standard Contractual Clauses + Transfer Impact Assessment) and customer contracts allow it. ### What is the AWS Data Processing Addendum and do I need it? The AWS Data Processing Addendum (DPA) is a contractual document that establishes AWS as a data processor under GDPR Article 28. It commits AWS to: (1) process customer data only on documented instructions, (2) maintain confidentiality, (3) implement appropriate security measures, (4) assist with data subject requests, (5) notify of personal data breaches, and (6) delete or return data on termination. The AWS DPA is automatically incorporated into the AWS Customer Agreement — you do not sign a separate document. AWS Artifact provides downloadable DPA PDFs for your records. You still need DPAs with your downstream sub-processors (third-party SaaS, contractors). ### How do I handle data subject access requests (DSARs) on AWS? GDPR gives EU residents seven rights: access, rectification, erasure, restriction, portability, objection, and rights related to automated decision-making (Article 15–22). Operationally, you need a DSAR workflow: (1) verify the requester's identity, (2) locate their data across all systems, (3) export or delete as requested, (4) respond within one month (extendable to three for complex requests). On AWS, automate where possible: a DSAR Lambda that queries DynamoDB / RDS / OpenSearch by user ID, encrypts the export, and delivers via S3 presigned URL. For erasure, ensure you cover backups — most companies miss this. Configure backup retention policies aligned to your DSAR commitments. ### What is RoPA and do I have to maintain one? RoPA = Records of Processing Activities (GDPR Article 30). It is a written register of every processing activity your organization performs with personal data, including: purpose, legal basis, data categories, recipients, retention period, transfer destinations, and security measures. Organizations with 250+ employees are required to maintain a RoPA; smaller organizations are required if processing is regular, involves special categories of data (health, genetic, biometric), or is likely to result in risk to data subjects. In practice — every SaaS company should maintain one. It's the first document a Data Protection Authority will request during an investigation. Maintain it as a living document, reviewed quarterly. ### When do I need a Data Protection Impact Assessment (DPIA)? Under GDPR Article 35, a DPIA is required when processing is likely to result in high risk to data subjects. Triggers include: (a) systematic and extensive evaluation including profiling (e.g., credit scoring, AI-driven hiring), (b) large-scale processing of special category data (health, biometric), (c) systematic monitoring of public areas. For most B2B SaaS, the obvious DPIA trigger is AI / ML processing of customer data — especially if it includes profiling, automated decision-making, or biometric features. AWS Bedrock workloads on customer data warrant a DPIA. Once required, the DPIA assesses risks and mitigations; if residual risk remains high, prior consultation with your DPA is required. --- *Source: https://www.factualminds.com/blog/gdpr-compliance-aws-saas-data-protection/*