SaaS production database security checklist
A practical production database security checklist for SaaS teams: private network access, least-privilege roles, TLS, encryption, secret rotation, patching, audit logs and tested restores.
In this guide
What is a production database security checklist?
A production database security checklist verifies who can connect, what each identity can do, how data is protected in transit and at rest, and whether the team can detect and recover from misuse or failure. Start with a private network path and separate, least-privilege roles; add encryption, managed credentials, updates, audit records and tested backups. The exact controls depend on the database engine, hosting model and customer data.
Map the data and every connection path
List production databases, replicas, analytics copies, exports and backups. Record the data owner, sensitivity, application services, human operators, migration jobs and external processors that can reach each copy. Remove forgotten test endpoints and document why any public connection is needed.
Keep database services off the public internet by default
Prefer private subnets or the provider's private connectivity feature. Restrict inbound traffic to named application or administration paths, narrow source ranges and required ports. If public access is an approved exception, document its owner, compensating controls, expiry date and monitoring; a firewall rule alone does not authenticate a user.
Create a reviewable baseline for each environment
Record the engine and supported version, network boundary, identity roles, encryption settings, backup schedule, log destination and recovery owner. Compare production with this baseline after deployments and provider changes. A checklist is useful when it names evidence and an accountable reviewer rather than only saying a control is enabled.
| Database and data | Allowed identities and paths | Encryption and secrets | Backup and restore evidence | Owner and next review |
|---|---|---|---|---|
| Primary customer database | ||||
| Read replica or analytics copy | ||||
| Backup and export location |
How should SaaS teams control database access and encryption?
Use separate database identities for separate jobs
Give the application, schema migration, reporting, support and emergency administration distinct roles. Grant only the required schemas, tables and operations; avoid using a database owner or superuser account for normal application traffic. Review default privileges and remove unused accounts. For PostgreSQL, choose a supported password authentication method such as SCRAM where password authentication is used.
Require verified TLS for connections that cross a network
Use the database provider's supported TLS configuration and make clients verify the server certificate and hostname. Encryption without certificate validation can leave a client unable to detect an impostor endpoint. Test certificate renewal and connection behavior before changing production settings; PostgreSQL documents server-side TLS and client verification options.
Treat encryption at rest as one layer of protection
Enable the platform's supported storage encryption and protect the keys with access controls and recovery procedures. Encryption at rest does not prevent a compromised application role from reading data it is authorized to query, and it does not replace access reviews, backups or secure exports. Document who can use or administer the relevant keys.
How do you maintain and recover a production database safely?
Keep credentials out of code and rotate them through a tested process
Store database credentials in an approved secrets manager or managed identity system, restrict who can retrieve them, and avoid putting them in source code, chat, command history or verbose logs. Rotation should update the application and database in a coordinated way, confirm new connections work, and revoke the old credential after the transition. Prefer short-lived identity where the platform supports it.
Patch the engine and extensions with a rollback plan
Track supported versions and security advisories for the database, extensions, drivers and managed service. Test upgrades against representative workloads and backups, check compatibility, and schedule a controlled deployment. Define how to restore service if an upgrade fails; delaying updates indefinitely leaves known weaknesses in place.
Protect audit signals and prove that backups restore
Capture authentication failures, privilege changes, sensitive administrative actions and relevant data access according to a documented purpose and retention period. Restrict log alteration and avoid collecting unnecessary personal data. Run restore exercises in a controlled environment, verify integrity and application workflows, and record measured recovery time; a successful backup job alone does not prove recoverability.
Production database security FAQs
Should a production database ever have a public IP address?
A private network path is the safer default. Some architectures have an approved public endpoint, but it needs narrow network rules, strong verified authentication, TLS, monitoring and a documented owner. Reassess the exception and remove public reachability when it is no longer required.
Does database encryption make customer data safe by itself?
No. Encryption helps protect particular storage or network paths, while permissions determine which users and services can read or change data. Secure credentials, application authorization, key access, logging, backups and incident response remain necessary.
Should the application connect as a database administrator?
Usually not. Give the application a dedicated role with only the operations it needs, and reserve owner or administrative privileges for controlled maintenance. Test migrations separately because schema changes may need permissions the runtime application should not have.
How often should a team test database restores?
Set the cadence from recovery objectives, data criticality and the frequency of material system changes. Test a representative restore regularly and after significant changes to backups, encryption keys, database versions or recovery instructions. Record whether the restored service meets the intended recovery point and recovery time.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Database Security Cheat SheetOWASP Foundation
- PostgreSQL 16: Client AuthenticationPostgreSQL Global Development Group
- PostgreSQL 18: Encryption OptionsPostgreSQL Global Development Group