GDPR Compliance on AWS: Data Residency, Processing Agreements, and Technical Controls

GDPR creates compliance obligations for any organization processing personal data of EU residents, regardless of where that organization is based. If your SaaS serves European customers, GDPR applies to how you handle their data — including data stored and processed on AWS. The regulation imposes requirements around consent, data subject rights, data processor agreements, breach notification, and technical safeguards that translate directly into AWS configuration requirements.

AWS itself is a data processor for the personal data you store in your AWS environment. This relationship needs to be formalized through the AWS Data Processing Addendum (DPA), which AWS provides as a standard document. Beyond the legal formalities, the technical controls required by GDPR's Article 32 — appropriate technical and organizational measures — map to specific AWS configurations.

Data Processing Agreement with AWS

Article 28 of GDPR requires a written contract between data controllers (your organization) and data processors (AWS) covering how personal data is processed. AWS provides the AWS Data Processing Addendum, which incorporates Standard Contractual Clauses (SCCs) for international data transfers and covers the required elements of Article 28. Accept the AWS DPA through the AWS Artifact console — it's a self-service process that applies to your entire account.

The DPA covers AWS's obligations: processing data only on your instructions, implementing appropriate security measures, assisting with data subject rights requests, notifying you of breaches within 72 hours of detection, and submitting to audits. It also includes AWS's sub-processor list, which you must review and either accept or object to specific sub-processors.

Data Residency and Region Selection

GDPR doesn't explicitly prohibit transferring EU personal data outside the EU, but it requires appropriate safeguards when data crosses EU borders. The Standard Contractual Clauses in the AWS DPA provide one such safeguard for transfers to AWS regions outside the EU/EEA.

For customers who want EU data to remain within EU borders — either due to regulatory requirements, customer contractual requirements, or risk aversion — AWS EU regions provide an appropriate processing location. The primary EU-resident regions are eu-west-1 (Ireland), eu-central-1 (Frankfurt), eu-west-2 (London), eu-west-3 (Paris), eu-north-1 (Stockholm), eu-south-1 (Milan), eu-central-2 (Zurich), and eu-south-2 (Spain).

Data residency requires more than just choosing an EU region. Review every AWS service you use to confirm data stays in the selected region. Some services (CloudFront, Route 53, IAM, CloudTrail management events) have components that operate globally or in the us-east-1 region by default. Understand these exceptions and evaluate whether they create data transfer concerns for your use case.

Article 32: Technical Safeguards

Article 32 requires "appropriate technical and organizational measures" to ensure security appropriate to the risk. The regulation provides non-exhaustive examples: pseudonymization and encryption of personal data, ability to ensure confidentiality and integrity, ability to restore availability after incidents, and regular testing of security measures.

Encryption: Enable encryption at rest for all services containing personal data using AWS KMS. S3 server-side encryption with KMS-managed keys, RDS storage encryption, EBS default encryption, and DynamoDB KMS encryption. For encryption in transit, enforce TLS 1.2 or later for all endpoints. Document your encryption approach in your privacy documentation.

Pseudonymization: Where practical, store personal data with identifiers that aren't directly linkable to individuals without a separate key. A common pattern for analytics: store a user_id (UUID, not email or name) in analytics tables, with the mapping to actual user identity maintained separately with stricter access controls. This limits the scope of a breach — compromised analytics data doesn't include direct personal identifiers.

Access controls: Implement IAM policies that limit personal data access to personnel and systems with a legitimate need. Maintain access logs (CloudTrail, S3 access logging, RDS audit logs) that document who accessed personal data and when. These logs support both security monitoring and the accountability requirements of GDPR.

Data Subject Rights and Technical Implementation

GDPR grants data subjects specific rights that require technical implementation: right of access (provide a copy of personal data), right to erasure ("right to be forgotten"), right to portability (provide data in a machine-readable format), and right to rectification (correct inaccurate data).

The right to erasure is the most technically complex. "Erasure" means making data unrecoverable — not just setting a deleted flag. For S3 objects, deletion removes the object, but versioning and backups may retain copies. Design an erasure process that handles all storage locations: database records, S3 objects, backup files, CloudWatch logs, audit trails. Some data may be retained based on legal obligations (financial records, legal holds) — document the retention basis for each data category.

DynamoDB TTL can implement automatic erasure for data with defined retention periods. S3 lifecycle policies expire objects at defined ages. Build erasure functionality directly into your data architecture rather than treating it as a manual process — a customer who submits a right-to-erasure request and finds their data still in your systems six months later represents a significant compliance failure.

Breach Notification Requirements

Article 33 requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach. This clock starts when you discover the breach — the faster you detect breaches, the more time you have to investigate and prepare the notification. Configure GuardDuty, CloudTrail alerting, and anomaly detection to minimize detection time for unauthorized data access.

Your breach response plan should include: incident detection and containment procedures, an assessment process for determining whether a breach has occurred (not every security incident is a personal data breach), a notification template, and a list of the supervisory authorities relevant to your customer base (each EU country has its own supervisory authority, though you notify the authority in the country where your EU establishment is located).

Related Reading

• SOC 2 compliance on AWS — technical controls that overlap with GDPR Article 32
• HIPAA compliance on AWS — comparison of healthcare and EU data protection requirements
• S3 encryption configuration — technical implementation for GDPR encryption requirements
• CloudTrail best practices — audit logging for GDPR accountability requirements

FAQ

Does GDPR apply if I'm not based in the EU?

Yes. GDPR has extraterritorial reach. If your service monitors behavior of EU residents or offers goods/services to EU residents, GDPR applies regardless of where your organization is established. This is one of the most important (and most frequently overlooked) aspects of GDPR — it's not a regulation about where you're based, it's a regulation about whose data you process.

Is storing data in an AWS EU region sufficient for GDPR compliance?

Data residency in EU regions addresses the data transfer requirement (data stays in EU jurisdiction) but doesn't address the full scope of GDPR. You still need the DPA with AWS, appropriate technical safeguards, processes for data subject rights requests, privacy notices, and the other requirements of the regulation. Residency is necessary but not sufficient.

What is a Data Protection Impact Assessment (DPIA) and when do I need one?

A DPIA is a structured risk assessment required before processing activities that are "likely to result in a high risk" to individuals. This includes large-scale systematic monitoring, processing sensitive categories of data, and using innovative technologies. On AWS, new processing activities involving biometric data, health data, or large-scale behavioral analytics warrant a DPIA before deployment. The DPIA documents the risks, the mitigations, and the residual risk accepted.