Database Security Compliance: A Practical Guide to Encryption, Access Control, and Audit Logging

Encryption at Rest: Beyond the Checkbox

Enabling encryption at rest on a managed database (RDS, Cloud SQL, Aurora) is usually a single checkbox, which is exactly why it's easy to assume the job is done. It isn't, until backups, snapshots, and read replicas inherit the same encryption — a database encrypted at rest with an unencrypted manual snapshot sitting in storage is still a real exposure, and cloud providers don't always encrypt derived resources by default just because the source was encrypted. Key management matters too: a customer-managed key (CMK) that your team controls and can revoke gives you the ability to cryptographically deny access to all data instantly if a key is compromised — a provider-managed key doesn't offer that lever.

Audit every backup, snapshot, and replica associated with a database, not just the primary instance, and confirm each one is encrypted with a key your organization actually manages.

Encryption in Transit: TLS Everywhere, No Exceptions

Encryption in transit is frequently enabled for application-to-database connections and quietly skipped for everything else touching the database: replication traffic between a primary and a replica, connections from an internal admin tool, or a backup job running from a cron server. Any of those unencrypted paths is a place credentials or data can be intercepted on the network, and 'it's an internal network' is not a control an auditor will accept, since internal networks are exactly where lateral movement happens after any other initial compromise. Enforce TLS at the database level, not just as an application convention — rejectUnauthorized settings, sslmode=require or stricter in PostgreSQL connection strings, and a database configuration that actually refuses plaintext connections rather than merely accepting encrypted ones as an option nobody is required to use.

-- PostgreSQL: reject non-SSL connections entirely
-- In pg_hba.conf, replace "host" with "hostssl" for relevant entries
hostssl  all  all  0.0.0.0/0  scram-sha-256

-- Verify a connection is actually using SSL
SELECT ssl, client_addr FROM pg_stat_ssl
JOIN pg_stat_activity USING (pid);

Least-Privilege Access: The Control Everyone Fails First

The single most common finding in a database security review is a shared superuser or root credential used by multiple people and multiple applications, because it was simpler to set up once than to provision individual, scoped accounts. This fails every relevant compliance requirement at once: there's no way to attribute an action to an individual, no way to revoke one person's access without breaking everyone else's, and no limit on the blast radius if that one credential leaks. The fix is role-based access with per-person or per-service accounts, scoped to exactly the schemas and operations each one requires — a reporting service gets SELECT on specific views, not superuser on the whole database.

This is more setup work upfront and genuinely worth it: when someone leaves the team, revoking their individual account doesn't require rotating a credential every other service also depends on.

-- Scoped role instead of superuser for a reporting service
CREATE ROLE reporting_service WITH LOGIN PASSWORD '...';
GRANT CONNECT ON DATABASE analytics TO reporting_service;
GRANT USAGE ON SCHEMA reports TO reporting_service;
GRANT SELECT ON ALL TABLES IN SCHEMA reports TO reporting_service;
-- No INSERT, UPDATE, DELETE, or access to other schemas

Audit Logging That Actually Answers 'Who Did What'

Audit logging that's technically enabled but never reviewed provides almost none of the security value it appears to on paper — it satisfies a checkbox but not the actual incident-response need. A useful audit log captures, at minimum, authentication events (successful and failed), schema changes (DDL), and access to sensitive tables, with enough detail to answer who performed an action, from where, and when, without requiring a database engineer to reconstruct it from raw query logs after the fact. The practical gap we see most: logs are being written, but nobody has a process to review them regularly or alert on suspicious patterns — a spike in failed authentication attempts, an account querying a sensitive table it's never touched before.

Ship these logs to a system separate from the database itself, so a compromised database credential can't also be used to delete the evidence of what it was used for.

Data Minimization and Retention

A field a compliance framework requires you to protect is far simpler to protect if you don't have more of it than necessary sitting around indefinitely. Data minimization — collecting and retaining only what's actually needed, for only as long as it's needed — reduces the blast radius of any future breach and directly satisfies GDPR's storage limitation principle and similar provisions elsewhere. In practice: define retention periods for sensitive columns explicitly, automate deletion or anonymization once that period passes rather than relying on someone remembering to run a manual cleanup, and be honest about whether a field genuinely needs to exist in production at all versus being movable to a more restricted, separately-audited store.