Master GDPR compliance in your cloud infrastructure. Learn how to implement data residency, encryption, and privacy controls in Terraform and Kubernetes.
Five years after its enforcement, the General Data Protection Regulation (GDPR) remains one of the most impactful privacy regulations worldwide. Yet many DevOps teams still treat GDPR as a legal concern rather than an infrastructure challenge.
This is a costly mistake. GDPR violations have resulted in fines exceeding €4 billion since 2018, with penalties reaching up to 4% of global annual revenue. More importantly, the technical requirements of GDPR—data residency, encryption, access controls, and the right to erasure—are fundamentally infrastructure problems that require infrastructure solutions.
For DevOps teams managing cloud infrastructure through Terraform, Kubernetes, and CI/CD pipelines, GDPR compliance must be baked into the code, not bolted on as an afterthought.
GDPR is often discussed in terms of consent forms and privacy policies. But behind every privacy requirement lies a technical implementation challenge:
| GDPR Principle | Legal Requirement | Infrastructure Implication |
|---|---|---|
| Data Minimization | Collect only necessary data | Database schema design, retention policies |
| Storage Limitation | Delete data when no longer needed | Automated data lifecycle management |
| Integrity & Confidentiality | Protect data from unauthorized access | Encryption, access controls, audit logging |
| Data Portability | Export user data on request | API design, data export pipelines |
| Right to Erasure | Delete user data on request | Data discovery, cascading deletes |
| Cross-Border Transfers | Restrict data movement outside EU | Data residency controls, region locking |
Each of these requirements translates directly into infrastructure configurations, policies, and automation that DevOps teams must implement and maintain.
Article 44 of GDPR restricts the transfer of personal data outside the European Economic Area (EEA) unless specific safeguards are in place. For cloud infrastructure, this means enforcing strict regional controls.
Cloud providers make it trivially easy to deploy resources globally. A single misconfigured Terraform variable can place EU citizen data in a US data center, creating immediate compliance violations.
Implement region-locking at the infrastructure level:
# variables.tf
variable "allowed_regions" {
description = "GDPR-compliant regions for EU data"
type = list(string)
default = [
"eu-west-1", # Ireland
"eu-west-2", # London (UK - adequacy decision post-Brexit)
"eu-west-3", # Paris
"eu-central-1", # Frankfurt
"eu-central-2", # Zurich
"eu-north-1", # Stockholm
"eu-south-1", # Milan
"eu-south-2" # Spain
]
}
variable "deployment_region" {
description = "Region for this deployment"
type = string
validation {
condition = contains(var.allowed_regions, var.deployment_region)
error_message = "Deployment region must be within the EU for GDPR compliance."
}
}For AWS Organizations, enforce region restrictions via Service Control Policies:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyNonEURegions",
"Effect": "Deny",
"NotAction": [
"iam:*",
"organizations:*",
"route53:*",
"route53domains:*",
"cloudfront:*",
"waf:*",
"wafv2:*",
"support:*",
"budgets:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-west-1",
"eu-west-2",
"eu-west-3",
"eu-central-1",
"eu-central-2",
"eu-north-1",
"eu-south-1",
"eu-south-2"
]
}
}
}
]
}Note: This SCP uses
NotActionto exclude global services (IAM, Route 53, CloudFront, etc.) that don't operate in specific regions. Without this exclusion, you would lose access to essential account management functions.
Each cloud provider has different region naming conventions:
| Provider | EU Regions |
|---|---|
| AWS | eu-west-1, eu-west-2, eu-west-3, eu-central-1, eu-central-2, eu-north-1, eu-south-1, eu-south-2 |
| Azure | westeurope, northeurope, francecentral, germanywestcentral, swedencentral, italynorth, polandcentral, spaincentral |
| GCP | europe-west1, europe-west2, europe-west3, europe-west4, europe-west6, europe-west8, europe-west9, europe-north1, europe-southwest1 |
Important: The UK region (AWS
eu-west-2, Azureuksouth/ukwest, GCPeurope-west2) remains GDPR-adequate post-Brexit. The EU adequacy decision was renewed until the end of 2031, with an intermediate review scheduled for 2029. The UK has maintained sufficient alignment with GDPR standards to justify this full extension.
Ensure your infrastructure-as-code templates explicitly specify compliant regions and validate inputs to prevent accidental deployments outside approved areas.
GDPR Article 32 requires "appropriate technical and organisational measures" to ensure data security. Encryption is the foundation of the technical measures.
All storage services containing personal data must have encryption enabled:
# S3 bucket with mandatory encryption
resource "aws_s3_bucket" "user_data" {
bucket = "company-user-data-${var.environment}"
}
resource "aws_s3_bucket_server_side_encryption_configuration" "user_data" {
bucket = aws_s3_bucket.user_data.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
kms_master_key_id = aws_kms_key.gdpr_data.arn
}
bucket_key_enabled = true
}
}
# Block all public access (critical for GDPR)
resource "aws_s3_bucket_public_access_block" "user_data" {
bucket = aws_s3_bucket.user_data.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}
# RDS with encryption
resource "aws_db_instance" "users" {
identifier = "users-db-${var.environment}"
engine = "postgres"
engine_version = "15" # Use major version only for auto-updates
instance_class = "db.t3.medium"
# Required attributes
allocated_storage = 100
db_subnet_group_name = aws_db_subnet_group.main.name
# Credentials (use Secrets Manager in production)
manage_master_user_password = true # AWS manages password in Secrets Manager
# GDPR: Encryption mandatory
storage_encrypted = true
kms_key_id = aws_kms_key.gdpr_data.arn
# GDPR: EU region only
availability_zone = "${var.deployment_region}a"
# Protection against accidental deletion
deletion_protection = true
}
# KMS key for GDPR data
resource "aws_kms_key" "gdpr_data" {
description = "KMS key for GDPR-protected personal data"
deletion_window_in_days = 30
enable_key_rotation = true
tags = {
Purpose = "GDPR data encryption"
Compliance = "GDPR Article 32"
}
}Enforce TLS for all data transmission:
# ALB listener - HTTPS only
resource "aws_lb_listener" "https" {
load_balancer_arn = aws_lb.main.arn
port = 443
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06"
certificate_arn = aws_acm_certificate.main.arn
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.main.arn
}
}
# Redirect HTTP to HTTPS
resource "aws_lb_listener" "http_redirect" {
load_balancer_arn = aws_lb.main.arn
port = 80
protocol = "HTTP"
default_action {
type = "redirect"
redirect {
port = "443"
protocol = "HTTPS"
status_code = "HTTP_301"
}
}
}GDPR requires that access to personal data be limited to those who need it. This translates directly into IAM policies and role-based access control.
# IAM role for application accessing user data
resource "aws_iam_role" "app_user_data_access" {
name = "app-user-data-access-${var.environment}"
assume_role_policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Action = "sts:AssumeRole"
Effect = "Allow"
Principal = {
Service = "ecs-tasks.amazonaws.com"
}
}
]
})
tags = {
Purpose = "Application access to user data"
DataCategory = "Personal Data"
Compliance = "GDPR Article 32"
}
}
# Minimal permissions for user data access
resource "aws_iam_role_policy" "user_data_access" {
name = "user-data-access"
role = aws_iam_role.app_user_data_access.id
policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "ReadUserData"
Effect = "Allow"
Action = [
"s3:GetObject",
"s3:ListBucket"
]
Resource = [
aws_s3_bucket.user_data.arn,
"${aws_s3_bucket.user_data.arn}/*"
]
},
{
Sid = "DecryptUserData"
Effect = "Allow"
Action = [
"kms:Decrypt",
"kms:GenerateDataKey"
]
Resource = [
aws_kms_key.gdpr_data.arn
]
}
]
})
}For PostgreSQL databases, implement row-level security:
-- Enable row-level security on users table
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
-- Policy: Users can only access their own data
CREATE POLICY user_isolation ON users
USING (id = current_setting('app.current_user_id')::uuid);
-- Policy: Support staff can access users in their region
CREATE POLICY support_regional_access ON users
FOR SELECT
TO support_role
USING (region = current_setting('app.support_region'));GDPR Article 5(2) introduces the principle of accountability—you must be able to demonstrate compliance. Comprehensive audit logging is essential.
# CloudWatch log group for GDPR audit trail
resource "aws_cloudwatch_log_group" "gdpr_audit" {
name = "/gdpr/audit/${var.environment}"
retention_in_days = 2557 # ~7 years - aligned with accounting/tax retention requirements
tags = {
Purpose = "GDPR audit trail"
Compliance = "GDPR Article 5(2)"
}
}
# CloudTrail for API audit logging
resource "aws_cloudtrail" "gdpr_trail" {
name = "gdpr-audit-trail"
s3_bucket_name = aws_s3_bucket.audit_logs.id
include_global_service_events = true
is_multi_region_trail = false # EU region only
enable_log_file_validation = true
event_selector {
read_write_type = "All"
include_management_events = true
data_resource {
type = "AWS::S3::Object"
values = ["${aws_s3_bucket.user_data.arn}/"]
}
}
tags = {
Purpose = "GDPR data access audit"
Compliance = "GDPR Article 5(2), Article 30"
}
}Beyond infrastructure logs, implement application-level audit events:
interface GDPRAuditEvent {
timestamp: string;
eventType: 'ACCESS' | 'MODIFY' | 'DELETE' | 'EXPORT';
dataSubjectId: string; // Pseudonymized user ID
dataCategory: string; // Type of personal data
purpose: string; // Legal basis for processing
actorId: string; // Who performed the action
actorType: 'USER' | 'SYSTEM' | 'SUPPORT';
outcome: 'SUCCESS' | 'FAILURE' | 'DENIED';
details?: Record<string, unknown>;
}
async function logGDPREvent(event: GDPRAuditEvent): Promise<void> {
await cloudwatchLogs.putLogEvents({
logGroupName: '/gdpr/audit/production',
logStreamName: `data-access-${new Date().toISOString().split('T')[0]}`,
logEvents: [{
timestamp: Date.now(),
message: JSON.stringify(event)
}]
});
}GDPR's storage limitation principle requires that personal data be kept only as long as necessary. This demands automated data lifecycle management.
resource "aws_s3_bucket_lifecycle_configuration" "user_data" {
bucket = aws_s3_bucket.user_data.id
# Temporary uploads - delete after 24 hours
rule {
id = "delete-temp-uploads"
status = "Enabled"
filter {
prefix = "temp/"
}
expiration {
days = 1
}
}
# User documents - archive after 1 year, delete after 7 years
rule {
id = "user-documents-lifecycle"
status = "Enabled"
filter {
prefix = "documents/"
}
transition {
days = 365
storage_class = "GLACIER"
}
expiration {
days = 2555 # 7 years
}
}
# Session data - delete after 30 days
rule {
id = "session-data-cleanup"
status = "Enabled"
filter {
prefix = "sessions/"
}
expiration {
days = 30
}
}
}Implement automated data retention in your application:
-- Create retention policy table
CREATE TABLE data_retention_policies (
table_name VARCHAR(255) PRIMARY KEY,
retention_days INTEGER NOT NULL,
deletion_strategy VARCHAR(50) NOT NULL, -- 'hard_delete', 'anonymize', 'archive'
last_cleanup TIMESTAMP,
created_at TIMESTAMP DEFAULT NOW()
);
-- Insert policies
INSERT INTO data_retention_policies VALUES
('user_sessions', 30, 'hard_delete', NULL, NOW()),
('login_history', 90, 'anonymize', NULL, NOW()),
('user_activity_logs', 365, 'archive', NULL, NOW()),
('deleted_user_data', 30, 'hard_delete', NULL, NOW());
-- Automated cleanup function
CREATE OR REPLACE FUNCTION cleanup_expired_data()
RETURNS void AS $$
DECLARE
policy RECORD;
BEGIN
FOR policy IN SELECT * FROM data_retention_policies LOOP
CASE policy.deletion_strategy
WHEN 'hard_delete' THEN
EXECUTE format(
'DELETE FROM %I WHERE created_at < NOW() - INTERVAL ''%s days''',
policy.table_name,
policy.retention_days
);
WHEN 'anonymize' THEN
EXECUTE format(
'UPDATE %I SET
email = ''anonymized_'' || id || ''@deleted.local'',
name = ''Deleted User'',
ip_address = ''0.0.0.0''
WHERE created_at < NOW() - INTERVAL ''%s days''
AND email NOT LIKE ''anonymized_%%''',
policy.table_name,
policy.retention_days
);
END CASE;
UPDATE data_retention_policies
SET last_cleanup = NOW()
WHERE table_name = policy.table_name;
END LOOP;
END;
$$ LANGUAGE plpgsql;Article 17 grants individuals the right to have their personal data erased. This is one of the most technically challenging GDPR requirements.
Important Legal Note: The right to erasure is not absolute. Article 17(3) provides exceptions where data must be retained, including:
- Compliance with legal obligations (tax records, anti-money laundering)
- Public health purposes
- Archiving in the public interest, scientific or historical research
- Establishment, exercise, or defense of legal claims
Your erasure implementation must account for these exceptions and maintain data required by law.
User data rarely exists in a single location. A typical application might store user data across:
First, create a data map documenting where personal data lives:
# data-map.yaml
data_subject: user
personal_data_locations:
- system: postgres_primary
table: users
identifier_column: id
personal_columns:
- email
- name
- phone
- address
deletion_method: hard_delete
- system: postgres_primary
table: orders
identifier_column: user_id
personal_columns:
- shipping_address
- billing_address
deletion_method: anonymize
- system: elasticsearch
index: users
identifier_field: user_id
deletion_method: delete_document
- system: redis
key_pattern: "user:{user_id}:*"
deletion_method: delete_keys
- system: s3
bucket: user-uploads
prefix_pattern: "users/{user_id}/"
deletion_method: delete_objects
- system: cloudwatch_logs
log_groups:
- /app/user-activity
deletion_method: not_feasible
mitigation: logs auto-expire after 90 daysImplement an erasure service that coordinates deletion across all systems:
interface ErasureRequest {
requestId: string;
userId: string;
requestedAt: Date;
requestedBy: 'user' | 'support' | 'automated';
status: 'pending' | 'in_progress' | 'completed' | 'failed';
systems: SystemErasureStatus[];
}
interface SystemErasureStatus {
system: string;
status: 'pending' | 'completed' | 'failed' | 'not_applicable';
completedAt?: Date;
error?: string;
recordsAffected?: number;
}
async function executeErasure(userId: string): Promise<ErasureRequest> {
const request: ErasureRequest = {
requestId: generateUUID(),
userId,
requestedAt: new Date(),
requestedBy: 'user',
status: 'in_progress',
systems: []
};
// Execute erasure across all systems
const erasureSteps = [
() => eraseFromPostgres(userId),
() => eraseFromElasticsearch(userId),
() => eraseFromRedis(userId),
() => eraseFromS3(userId),
() => notifyThirdParties(userId)
];
for (const step of erasureSteps) {
try {
const result = await step();
request.systems.push({
system: result.system,
status: 'completed',
completedAt: new Date(),
recordsAffected: result.count
});
} catch (error) {
request.systems.push({
system: error.system,
status: 'failed',
error: error.message
});
}
}
// Log erasure completion for audit
await logGDPREvent({
timestamp: new Date().toISOString(),
eventType: 'DELETE',
dataSubjectId: hashUserId(userId),
dataCategory: 'all_personal_data',
purpose: 'Right to Erasure (Article 17)',
actorId: 'erasure_service',
actorType: 'SYSTEM',
outcome: request.systems.every(s => s.status === 'completed')
? 'SUCCESS'
: 'FAILURE',
details: { requestId: request.requestId }
});
return request;
}Manual GDPR compliance verification does not scale. Implement automated policy checks that continuously validate your infrastructure.
# GDPR Compliance Rules for CompliMetric
rules:
# Data Residency
- id: gdpr-001
name: EU Data Residency
description: Resources containing personal data must be deployed in EU regions
severity: critical
resource_types:
- aws_s3_bucket
- aws_db_instance
- aws_rds_cluster
conditions:
- field: region
operator: in
values:
- eu-west-1
- eu-west-2
- eu-west-3
- eu-central-1
- eu-north-1
compliance_mappings:
- framework: GDPR
article: "Article 44"
description: "Transfer of personal data to third countries"
# Encryption at Rest
- id: gdpr-002
name: Storage Encryption Required
description: All storage services must have encryption at rest enabled
severity: critical
resource_types:
- aws_s3_bucket
- aws_db_instance
- aws_ebs_volume
conditions:
- field: encrypted
operator: equals
value: true
compliance_mappings:
- framework: GDPR
article: "Article 32"
description: "Security of processing"
# Access Logging
- id: gdpr-003
name: Access Logging Enabled
description: Storage buckets must have access logging enabled for audit trail
severity: high
resource_types:
- aws_s3_bucket
conditions:
- field: logging
operator: exists
compliance_mappings:
- framework: GDPR
article: "Article 5(2)"
description: "Accountability principle"
# Backup Encryption
- id: gdpr-004
name: Backup Encryption
description: Database backups must be encrypted
severity: critical
resource_types:
- aws_db_instance
conditions:
- field: backup_retention_period
operator: greater_than
value: 0
- field: storage_encrypted
operator: equals
value: true
compliance_mappings:
- framework: GDPR
article: "Article 32(1)(c)"
description: "Ability to restore availability and access to personal data"Block deployments that violate GDPR requirements:
# .github/workflows/gdpr-compliance.yml
name: GDPR Compliance Check
on:
pull_request:
paths:
- 'terraform/**'
- 'kubernetes/**'
jobs:
gdpr-compliance:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run GDPR Compliance Scan
run: |
compli audit \
--rules-filter "framework:GDPR" \
--fail-on critical,high \
--format sarif \
--output gdpr-results.sarif
- name: Upload SARIF results
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: gdpr-results.sarif
- name: Comment PR with results
if: failure()
uses: actions/github-script@v7
with:
script: |
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: '## GDPR Compliance Check Failed\n\nThis PR introduces changes that violate GDPR requirements. Please review the security scan results and address the findings before merging.'
})Your backup systems contain copies of personal data. Ensure:
When using SaaS tools that process personal data, ensure Data Processing Agreements (DPAs) are in place. Track third-party integrations in your infrastructure:
# Document third-party processors in resource tags
resource "aws_lambda_function" "analytics_sync" {
function_name = "sync-to-analytics"
tags = {
ThirdPartyProcessor = "analytics-vendor"
DPASigned = "2024-06-15"
DataCategories = "usage_analytics"
LegalBasis = "legitimate_interest"
}
}Application logs often contain personal data (IP addresses, user IDs, email addresses). Implement log retention policies:
resource "aws_cloudwatch_log_group" "application" {
name = "/app/production"
retention_in_days = 90 # Align with GDPR retention requirements
}Non-production environments often contain copies of production data. Apply the same GDPR controls to all environments, or use synthetic/anonymized data for development.
Track your GDPR compliance posture with real-time metrics:
GDPR Compliance Dashboard
=========================
Data Residency Controls
-----------------------
EU Region Enforcement: ACTIVE
Resources in EU: 847/847 (100%)
Non-EU Resources: 0 VIOLATIONS
Encryption Status
-----------------
S3 Buckets Encrypted: 45/45 (100%)
RDS Instances Encrypted: 12/12 (100%)
EBS Volumes Encrypted: 89/89 (100%)
Access Controls
---------------
IAM Policies Reviewed: Last 7 days
Overprivileged Roles: 2 WARNINGS
MFA Enabled (Admin): 100%
Data Retention
--------------
Active Retention Policies: 8
Last Cleanup Run: 2025-01-19 03:00 UTC
Records Purged (30d): 145,892
Right to Erasure
----------------
Pending Requests: 3
Avg Completion Time: 4.2 hours
Failed Requests (30d): 0
Audit Trail
-----------
CloudTrail Status: ACTIVE
Log Retention: 7 years
Last Audit Export: 2025-01-15GDPR compliance is not a checkbox exercise—it is an ongoing commitment that must be embedded in your infrastructure practices. By treating GDPR requirements as code, you gain:
The investment in GDPR-compliant infrastructure pays dividends beyond avoiding fines. It builds customer trust, simplifies audits, and creates a foundation for handling evolving privacy regulations worldwide.
Legal Disclaimer: This article provides general information about GDPR compliance for cloud infrastructure and does not constitute legal advice. GDPR requirements may vary based on your specific circumstances, industry, and jurisdiction. We recommend consulting with qualified legal counsel to ensure your organization's compliance with applicable data protection laws.
Complimetric provides automated GDPR compliance monitoring for cloud infrastructure. Our platform continuously scans your Terraform configurations and cloud resources against GDPR requirements, providing real-time compliance status and actionable remediation guidance. Start your free trial to secure your cloud infrastructure.