Controls2 May 2026 7 min read

RDS Controls for SOC 2: Encryption, Multi-AZ, Backups

Configure AWS RDS for SOC 2 compliance. Covers encryption at rest, Multi-AZ deployments, automated backups, parameter groups, and auditor evidence.

Key Takeaways

RDS encryption at rest must be enabled at instance creation — it cannot be added to an existing unencrypted instance.
Multi-AZ deployment is required for availability criteria and recommended for any customer-facing database.
Automated backups with a retention period of at least 7 days must be configured.
Database access must be restricted to application servers via security groups — no direct public access.
Enable pgaudit (PostgreSQL) or MySQL general log for database activity logging.

In this guide

Why RDS Controls Matter for SOC 2
Encryption at Rest
Multi-AZ and High Availability
Automated Backups and Retention
Database Access Controls
Database Audit Logging
RDS Evidence Checklist

Why RDS Controls Matter for SOC 2

Amazon RDS is where customer data typically lives — user records, transaction histories, application state. It is the highest-value target for attackers and the most scrutinized resource by SOC 2 auditors. Controls on RDS address CC6.6 (encryption), CC6.1 (access), availability criteria (A1.2), and CC7.2 (monitoring).

Unlike S3 encryption which can be enabled retroactively, RDS encryption must be set at instance creation. A database running unencrypted today requires a snapshot, encryption of the snapshot, and restoration to a new encrypted instance — a migration with downtime risk. Address this before your audit.

Encryption at Rest

Enable encryption when creating an RDS instance: in the RDS console, under "Storage," check "Enable encryption" and select a KMS key. Use a customer-managed KMS key for production databases — this provides key usage audit trails in CloudTrail and finer-grained access control over who can decrypt the data.

Encryption at rest covers all data files, automated backups, read replicas, and snapshots associated with the encrypted instance. When you create a snapshot of an encrypted instance, the snapshot is also encrypted with the same key.

To encrypt an existing unencrypted instance: create a snapshot, copy the snapshot with encryption enabled (specify a KMS key during copy), restore a new instance from the encrypted snapshot, update your application connection string, and decommission the old unencrypted instance.

Multi-AZ and High Availability

Multi-AZ deployment maintains a standby replica of your database in a different Availability Zone. In the event of an infrastructure failure, RDS automatically fails over to the standby — typically within 60-120 seconds. This satisfies SOC 2 Availability criteria A1.2 (manages capacity and performance) and supports CC9.1 (business continuity).

Enable Multi-AZ for all production databases: RDS console > Modify > Multi-AZ deployment > Yes. For cost-sensitive environments, Aurora with the default Multi-AZ storage architecture provides equivalent durability without the cost of a full standby instance.

Test failover annually: use the RDS console to reboot the instance with failover, verify your application reconnects automatically, and document the recovery time. This is CC7.4 (recovery) evidence.

Automated Backups and Retention

RDS automated backups create a daily backup and retain transaction logs, allowing point-in-time recovery to any second within the retention window. Configure a retention period of at least 7 days; 30-35 days is the best practice for SOC 2 and DPDP Act compliance.

In addition to automated backups, create manual snapshots before major changes — schema migrations, application version upgrades, infrastructure changes. Manual snapshots are retained until explicitly deleted, providing a permanent baseline.

Test backup restoration annually: restore the most recent automated backup to a new instance in a non-production environment, verify data integrity, document the recovery time and RPO/RTO. This is both CC7.4 and SOC 2 Availability criteria evidence.

Database Access Controls

RDS instances should not be publicly accessible. Ensure "Publicly accessible" is set to No. Place the database in a private subnet with no route to the internet gateway. Allow inbound connections only from the application server security group, not from all IP addresses (0.0.0.0/0) or the entire VPC CIDR.

Use IAM database authentication for supported engines (MySQL, PostgreSQL on Aurora). This replaces static passwords with short-lived IAM tokens, eliminating password management and rotating credentials automatically. Configure the IAM policy to grant specific IAM roles the rds-db:connect permission to specific databases.

Restrict direct database access for humans. Developers needing production database access should connect via AWS Systems Manager Session Manager port forwarding — this tunnels the connection through SSM without exposing the database port, and all access is logged in CloudTrail.

Database Audit Logging

Database audit logging is required to evidence CC6.1 (access to data) and CC7.2 (anomaly detection). For PostgreSQL: enable pgaudit extension via a custom parameter group. Set log_statement = "ddl" at minimum; "all" for comprehensive logging. Export logs to CloudWatch Logs.

For MySQL/MariaDB: enable general_log and slow_query_log via the parameter group. For Aurora PostgreSQL or MySQL: same extensions apply. Configure log export to CloudWatch Logs under RDS > Modify > Log exports.

Review database logs periodically (weekly at minimum) for unusual activity: queries accessing large volumes of data, connections from unexpected IP addresses, attempts to drop or modify schema. Document the review cadence in your monitoring procedure.

RDS Evidence Checklist

(1) RDS instance list with encryption status, Multi-AZ status, and backup retention period. (2) AWS Config rule "rds-storage-encrypted" — compliant status. (3) Backup retention configuration screenshot. (4) Backup restoration test record with RTO/RPO measured. (5) Security group configuration showing inbound access restricted to application servers. (6) "Publicly accessible: No" screenshot for all production instances. (7) Database audit log configuration (parameter group settings). (8) CloudWatch Logs showing database audit log export.

Frequently Asked Questions

Can we use Aurora Serverless instead of RDS for SOC 2?

Yes. Aurora Serverless v2 supports encryption at rest (enabled by default), automated backups, Multi-AZ, and IAM authentication — all the same RDS controls apply. The evidence collection is identical. Aurora Serverless is a valid choice for SOC 2-compliant architectures.

What RTO and RPO should we target for the backup restoration test?

SOC 2 doesn't mandate specific RTO/RPO values — your system description should define them and your test should verify you can meet them. Industry standard for B2B SaaS: RTO of 4 hours for a major outage, RPO of 24 hours (or better with PITR enabled). Document your targets in your BCP and verify them with an actual restoration test.

Is read replica a replacement for Multi-AZ for availability purposes?

No. Read replicas are for read scaling and do not provide automatic failover. Multi-AZ provides synchronous replication and automatic failover with no data loss. Use Multi-AZ for availability and read replicas for performance. Both can be used together.

We have developer access to production RDS — is that a SOC 2 finding?

Direct developer access to production databases is a least-privilege concern (CC6.1) and a potential SoD issue (CC5). It's not automatically a finding, but it requires strong compensating controls: all access must be through SSM Session Manager (logged), accessed data queries must be justified in tickets, and access should be reviewed quarterly. Prefer restricting production database access to break-glass procedures only.

Do database passwords need to be rotated for SOC 2?

Yes if you use static database passwords. Rotate master passwords for RDS annually at minimum and on suspected compromise. Use AWS Secrets Manager with automatic rotation to manage RDS credentials — it rotates the password automatically on a schedule without application downtime. This is stronger than manual rotation and provides an audit trail via CloudTrail.