Securing PostgreSQL is one thing. Meeting the requirements for PostgreSQL compliance, HIPAA, PCI DSS, or FedRAMP adds another layer.
What changes when PostgreSQL is in scope for compliance
In an unregulated environment, database security is judged by whether the system is hard to compromise. When PostgreSQL is in scope for compliance, you also need to show that your security controls are documented, working continuously, and can be proved when needed.
The frameworks that most often bring PostgreSQL into scope are SOC 2, HIPAA, PCI DSS, and FedRAMP with its NIST 800-53 underpinning, alongside FIPS 140 where validated cryptography is a procurement requirement.
| Control family | Frameworks that care most | Typical evidence |
| Access control and principle of least privilege | SOC 2, HIPAA, PCI DSS, FedRAMP | Roles and permissions, access reviews, permission changes |
| Data encryption | HIPAA, PCI DSS, FedRAMP | SSL/TLS encryption settings, encryption at rest, key management records |
| Auditing and audit logs | All | Audit trail, retention settings, tamper-protection evidence |
| Data residency | FedRAMP, sovereign and sector-specific regimes | Data, replica and backup locations, support access records |
| Network security | SOC 2, PCI DSS, FedRAMP | Firewall rules, connection controls, network configuration |
| Vulnerability and patch management | SOC 2, PCI DSS, FedRAMP | Version history, security patches, patch timelines and exceptions |
Compliance isn't something you prove once a year. Controls need to keep working, and you need a record that shows they have.
No database platform can make an organization compliant on its own. PostgreSQL compliance depends on a combination of technology controls, operational processes, governance practices, and organizational accountability. The database is one part of that picture.
Organizations adopting AI, vector search, or retrieval-augmented generation (RAG) architectures should apply the same governance and compliance controls to embeddings and vector data that they apply to relational data. That becomes particularly important when access controls haven't kept pace with AI adoption. IBM's 2025 Cost of a Data Breach Report found that 97% of organizations that experienced an AI-related security incident did not have appropriate AI access controls in place. If an embedding comes from regulated data, it needs the same consideration around where it's stored, who can access it, and whether that access is logged.
For more on securing your database, the PostgreSQL security best practices for enterprise databases guide covers the fundamentals. Here, the focus is on the additional controls and evidence needed in regulated environments.
Access control that survives an audit
Access remains a major security concern. Verizon found that stolen credentials were involved in 24% of breaches in its 2024 Data Breach Investigations Report.
One of the most common access control findings is service accounts with excessive permissions. But the problem often isn't how access was originally configured. It's what happens over time. Temporary permissions aren't revoked, old roles remain in place, and application accounts keep access they no longer need.
Role design and privilege sprawl
PostgreSQL roles serve as both users and permission sets. A clear role-based access control (RBAC) structure makes those roles and permissions easier to manage and review. Rather than granting privileges directly to individual users, functional roles can hold the required permissions, and users can inherit them through membership.
This supports the principle of least privilege and makes it easier to REVOKE access when someone's responsibilities change. It also helps prevent nested roles and inherited permissions from gradually giving users more access than intended. Superuser access should be particularly tightly controlled and regularly reviewed. Administrative privileges such as CREATEROLE and CREATEDB should also be limited to accounts that genuinely need them.
Row-level security (RLS) can take this further by restricting which rows individual users can access. This is useful for multi-tenant or need-to-know data, but it can make auditing more complex because effective access depends on RLS policies as well as role membership.
Control how users and applications connect
Access control also starts before a user reaches the database. PostgreSQL's host-based authentication is configured through pg_hba.conf, where teams can control which users, databases, and connection sources are allowed and which authentication methods they must use. Options such as SCRAM-SHA-256, Kerberos, LDAP, certificate-based authentication, and single sign-on can support different security and governance requirements.
Network settings need the same attention. In postgresql.conf, listen_addresses controls which network interfaces accept connections, while rules in pg_hba.conf can require encrypted connections using hostssl. Access to port 5432 should be limited through the network firewall rather than exposed unnecessarily. Local connections can also use Unix domain sockets instead of TCP/IP sockets.
Whatever the setup, the aim is the same: allow only the connections the organization expects and keep the configuration clear enough to review and audit.
Access recertification
Setting access correctly isn't enough. Regulated organizations also need to show that it is regularly reviewed.
Recertification means a named owner confirming, on a defined cadence, that each account still needs the access it holds. The audit trail should show what was reviewed, who reviewed it, when the review took place, and any access that was changed or removed.
A scheduled extract of roles, memberships, and permissions from the PostgreSQL catalog can make this much easier to manage than relying on someone to remember a manual review each quarter.
Encryption and key management
“The data is encrypted” can mean several different things. In a regulated environment, what matters is where encryption is applied, what it protects, and how the keys are managed. That includes protecting data both in transit and at rest.
For data in transit, PostgreSQL uses SSL/TLS encryption to protect connections between the database and its clients. Teams can also set requirements around the TLS versions and ciphers they allow through settings such as ssl_min_protocol_version and ssl_ciphers.
Transparent data encryption vs. filesystem encryption
Encryption at rest can be applied at different layers. Filesystem encryption protects the storage volume, while transparent data encryption (TDE) encrypts data at the database layer.
| Filesystem encryption | Transparent data encryption (TDE) | |
| Where encryption happens | Storage or filesystem layer | Database layer |
| What it protects | Data on an unmounted disk or volume | Database files as they are written to storage |
| When data is decrypted | When the volume is mounted | As the database reads the data |
| Key management | Usually handled outside the database | Managed separately from the encrypted database data |
This distinction matters when choosing encryption at rest for a specific compliance requirement. TDE keeps the database files encrypted at the storage level while the system is running, rather than relying on the protection of the underlying filesystem alone.
For individual sensitive fields, column-level data encryption provides another option. pgcrypto supports this in community PostgreSQL. Because encrypted fields are harder to search and index normally, it is best suited to specific sensitive values rather than every column in a database.
Key custody, rotation, and separation of duties
Encryption is only as strong as the way its keys are managed. For regulated PostgreSQL environments, three questions are particularly important:
- Who can access the encryption keys, and is that separate from the people who administer the database?
- How and when are keys rotated, and is each rotation recorded?
- How can keys be accessed securely if the usual key custodian is unavailable?
Separating database administration from key custody reduces the risk of one privileged account having access to both the encrypted data and the keys needed to decrypt it. Keys can be managed externally through options such as a hardware security module (HSM) or managed key service.
Where procurement specifies FIPS 140 validated cryptography, that requirement applies to the modules performing encryption rather than to the database as a whole, so it should be confirmed for the specific deployment.
Audit logging that produces usable evidence
Standard database logging is built for operations. It answers what went wrong and helps diagnose why. For compliance auditing, the question is different: who accessed what, when, and was that access authorized?
A useful audit trail needs to capture activity such as:
- Access to sensitive data, including reads as well as changes
- Privileged and administrative actions
- Failed authentication attempts
- Schema and permission changes
- Enough context to identify the user behind an application connection
The audit logs also need to remain useful as evidence months or even years later. That means making them tamper-resistant, retaining them for the required period, and keeping them searchable so a specific user, action, or record can be traced when needed.
General log configuration and tools such as pgAudit can provide more detailed PostgreSQL auditing, but organizations still need to decide what to capture, where audit logs are stored, how long they're retained, and who can access them. Dedicated audit logging can help create a clearer audit trail without turning every database event into unnecessary log volume.
Routine monitoring of database activity remains a separate concern and shouldn't be treated as a substitute for auditing.
Data residency and sovereignty
Data residency isn't something a PostgreSQL configuration setting can solve. It depends on where data is stored, which jurisdiction applies, and who can access it. For organizations with data sovereignty requirements, those decisions can determine the deployment model from the start.
The location of the primary database is only part of the picture. Residency and sovereignty requirements can also apply to:
- Read replicas in other regions
- Backup location, including any additional copies made by the backup provider
- Disaster recovery environments
- Development or test environments containing production data
- Support access during incidents or maintenance
Jurisdiction matters as much as physical location. A provider may be subject to laws that allow authorities in another country to compel access to data, even when the servers themselves are elsewhere. This is particularly important for government workloads, regulated financial data, and banking and financial services, where residency requirements can influence the deployment model from the start.
Support access needs the same scrutiny. If an engineer can access a production system, organizations may need to know where that person is located, which legal entity employs them, what they can access, and whether the session is logged. These requirements are much easier to establish before choosing a provider than to retrofit later.
Deployment flexibility gives organizations more control over these decisions. Running PostgreSQL on-premises, in a sovereign cloud, or across a hybrid environment allows data placement to reflect the relevant residency and jurisdiction requirements. It's one of several database features regulated industries should prioritize when choosing how and where to deploy PostgreSQL.
Meeting regulatory requirements without building it all yourself
Everything above can be assembled on community PostgreSQL with enough engineering effort, extensions, and operational discipline.
Fujitsu Enterprise Postgres brings several of these controls into the platform:
- Encryption: TDE and data masking support protection of sensitive data.
- Auditing: Dedicated audit logging supports a clearer compliance audit trail.
- Data residency: On-premises, hybrid, multi-cloud, Kubernetes, and OpenShift deployments provide greater control over data location.
- Security patches and support: 24/7 global support and long version lifecycles help reduce patch and end-of-life risk.
For AI, vector search, or RAG workloads, secure AI capabilities extend security and governance controls to vector data.
These capabilities support a PostgreSQL compliance program alongside the necessary processes, governance, and organizational accountability. Proactive support engagement can also help address security and maintenance requirements before they become compliance gaps.
Try Fujitsu Enterprise Postgres to see how its security and auditing capabilities could support your compliance requirements.
Frequently asked questions about PostgreSQL security in regulated environments
Can PostgreSQL be used in HIPAA or PCI DSS environments?
Yes. PostgreSQL can be used in HIPAA and PCI DSS environments with the appropriate security and compliance controls. These include role-based access control, least privilege, SSL/TLS encryption, encryption at rest, and audit logging. Compliance also depends on how those controls are managed, monitored, and documented.
What is the difference between transparent data encryption and filesystem encryption?
Transparent data encryption (TDE) encrypts data at the database layer, while filesystem encryption protects the underlying storage. Filesystem-encrypted data becomes available when the volume is mounted. TDE encrypts database files as they are written and decrypts them as PostgreSQL reads them, providing a different layer of encryption at rest.
What does an auditor expect from database audit logs?
Database audit logs should provide a clear audit trail showing who accessed or changed data, what they did, and when. This includes access to sensitive data, privileged actions, failed authentication attempts, and permission changes. Logs should also be protected against tampering, retained appropriately, and searchable when evidence is needed.
Does data residency apply to database backups and replicas?
Yes. Data residency requirements can apply to every copy of regulated data, including backups, read replicas, disaster recovery environments, and test systems. Organizations may also need to consider jurisdiction and support access, particularly where data sovereignty requirements restrict where information can be stored or who can access it.
How do you prove PostgreSQL access controls were reviewed?
Keep a record showing what access was reviewed, who reviewed it, when the review happened, and what changed. A scheduled extract of PostgreSQL roles, memberships, and permissions can provide a consistent basis for recertification and create an audit trail showing that access controls are being reviewed regularly.
PostgreSQL Insider 
