GDPR Compliance on AWS RDS PostgreSQL: What You Can and Cannot Control

The Shared Responsibility Gap

AWS RDS handles:

• Physical datacenter security
• Network encryption (SSL/TLS)
• Encryption at rest (KMS)
• Automated backups and point-in-time recovery
• Patch management for PostgreSQL engine
• Multi-AZ failover

You handle:

• Knowing where PII lives in your tables
• Deleting user data on request (GDPR Article 17)
• Tracking consent and legal basis (Articles 6-7)
• Masking data for non-privileged users
• Maintaining audit trails (Article 5(2))
• Setting retention policies
• Access control within the database

Installing pgcomply on RDS

-- 1. Enable pgcrypto (if not already)
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- 2. Install pgcomply
\i pgcomply.sql

-- 3. Run quick_setup
SELECT pgcomply.quick_setup();

Enabling pg_cron for Automation

In the RDS parameter group:

shared_preload_libraries = pg_cron
cron.database_name = your_database

After reboot:

CREATE EXTENSION pg_cron;
SELECT pgcomply.schedule_jobs(install := true);

RDS-Specific Considerations

Superuser access: RDS does not give you the true postgres superuser. You get rds_superuser, which has most privileges but is not a true superuser. pgcomply works fine with rds_superuser.

Parameter changes: Some postgresql.conf settings require parameter group changes and reboot (like ssl, shared_preload_libraries). health_check() will flag these but you fix them via the AWS Console, not psql.

Backup retention: RDS automated backups retain data for 0-35 days. For GDPR, ensure backup retention is documented in your privacy policy. Deleted user data remains in backups until the backup expires.

RDS-Specific Health Check Findings

Some pgcomply.health_check() results require RDS-specific fixes:

SSL_ENFORCED: FAIL

On self-hosted PostgreSQL, you edit postgresql.conf. On RDS:

1. Go to RDS Console → Parameter Groups
2. Set rds.force_ssl = 1
3. Apply immediately (no reboot needed)

-- Verify after change
SELECT * FROM pgcomply.health_check() WHERE rule = 'SSL_ENFORCED';

SUPERUSER_COUNT: WARN

RDS creates rds_superuser role by default. You cannot remove it, but you can minimize additional privileged roles:

-- Check who has rds_superuser
SELECT * FROM pgcomply.role_hierarchy()
WHERE member_of = 'rds_superuser';

-- Ensure only your admin role inherits it

LOG_STATEMENT: WARN

On RDS, logging is configured via parameter groups:

log_statement = 'ddl'           -- Log schema changes
log_connections = 1              -- Log connections
log_disconnections = 1           -- Log disconnections

Backup and GDPR: The Retention Problem

RDS automated backups retain data for 0-35 days. This means a deleted user's data may still exist in backups for up to 35 days after forget().

Document this in your privacy policy:

-- Tag the backup retention for compliance documentation
SELECT pgcomply.tag('_infrastructure', 'backup_retention', '35 days (RDS automated)');
SELECT pgcomply.tag('_infrastructure', 'backup_note', 'Deleted PII may persist in backups for up to 35 days');

Under GDPR, this is generally acceptable as long as:

1. It is documented in your records of processing
2. Backups are encrypted (RDS KMS encryption handles this)
3. The retention period is proportionate

Multi-AZ and Compliance

RDS Multi-AZ creates a synchronous standby replica in a different Availability Zone. For compliance:

-- Verify pgcomply functions work identically after failover
-- (Run after a planned failover test)
SELECT * FROM pgcomply.health_check();
SELECT pgcomply.verify_audit();
SELECT count(*) FROM pgcomply.pii_registry;

The pgcomply schema, audit trail, and all metadata replicate automatically. No special configuration needed.

Summary

AWS RDS is GDPR-compliant at the infrastructure level. The application-level gap — PII management, deletion, consent, masking, audit trails — is your responsibility. pgcomply fills this gap as a pure SQL extension that runs inside your RDS instance without compiled dependencies.