GDPR/DSGVO Cloud Security: What AWS & Azure Users Must Fix in 2025

GDPR Article 32 requires "appropriate technical and organisational measures" to protect personal data. For teams running on AWS or Azure, this is not abstract — it translates into specific infrastructure settings. This guide maps Article 32 to concrete cloud configuration checks.

The legal basis: GDPR Article 32

Article 32(1) lists four key measures:

1. Pseudonymisation and encryption of personal data
2. Ability to ensure ongoing confidentiality, integrity, availability, and resilience
3. Ability to restore availability after an incident
4. Process for regularly testing, assessing, and evaluating the effectiveness of measures

The fines for violations: up to €20 million or 4% of global turnover (Article 83).

AWS: critical GDPR misconfigurations

S3 — the most common GDPR failure

Public S3 buckets containing personal data are the single most common GDPR violation in cloud environments. Check:

• BlockPublicAcls and BlockPublicPolicy enabled on ALL buckets
• Server-side encryption enabled (SSE-S3 or SSE-KMS)
• Bucket policy enforcing HTTPS only (aws:SecureTransport condition)
• Access logging enabled for buckets containing personal data
• Object-level logging via CloudTrail for GDPR audit trail

RDS & databases

• Storage encryption enabled at instance creation (cannot be changed after)
• rds.force_ssl = 1 parameter group setting
• No publicly accessible RDS instances
• Automated backups with ≥7 day retention
• Deletion protection enabled on production instances

IAM — access to personal data

Article 5(1)(f) requires confidentiality and integrity. This means:

• MFA required for all users who can access personal data
• IAM policies scoped to minimum required permissions
• No long-lived access keys for service accounts (use IAM roles)
• Regular access reviews via IAM Access Analyzer

CloudTrail — the audit trail GDPR requires

GDPR Article 30 requires records of processing activities. CloudTrail provides this for AWS:

• Multi-region trail enabled
• Log file validation enabled (proves logs haven't been tampered with)
• CloudTrail logs encrypted with KMS
• Log retention ≥ 12 months in S3 with lifecycle rules

Azure: critical GDPR misconfigurations

Storage Accounts

• Secure transfer required (HTTPS only)
• Blob public access disabled
• Soft delete enabled for blob data
• Storage encryption with customer-managed keys (for sensitive data)

Azure SQL

• Transparent Data Encryption enabled
• Advanced Threat Protection enabled
• Auditing enabled and logs sent to storage account or Log Analytics
• No public network access for production databases

EU data residency — the Schrems II requirement

Following the Schrems II ruling (2020), transferring personal data to the US is restricted unless appropriate safeguards are in place. For cloud infrastructure, this means verifying that:

• All EC2, RDS, S3, and Lambda resources are in EU regions (eu-central-1, eu-west-1, eu-west-3, etc.)
• Azure resources are in EU regions (West Europe, North Europe, Germany West Central)
• No cross-region replication to US regions without explicit consent mechanism
• CloudFront distributions don't route data outside the EU without consent

ConformScan's EU residency checks explicitly verify every resource region across your AWS and Azure accounts.

GDPR compliance is not a checkbox — it's continuous

A one-time audit does not guarantee compliance. Configuration drift happens: a developer creates a public S3 bucket, someone disables CloudTrail to reduce costs, an RDS instance is created without encryption. Automated daily scanning catches these regressions before your DPA does.