PostgreSQL HIPAA audit and access controls: what the platform covers
A covered entity or business associate whose PostgreSQL database holds electronic protected health information must show access control and audit control under 45 CFR 164.312. PostgreSQL configuration can support unique identity, restricted row access and activity recording, but the Security Rule is a set of obligations for the organization, not a product feature. The database can enforce and record what the organization has decided; it cannot decide on the organization's behalf who should have access, how long a session may stay idle, or whether the organization's risk analysis is complete.
What the platform helps with. Three requirements map directly to database configuration. Access restriction under 164.312(a)(1) can be supported with individual database roles, least-privilege grants and row-level security policies that limit which rows a user can return or modify. Unique user identification, a required implementation specification, can be supported by giving each person and each service its own role and by avoiding shared accounts, with authentication tied to your identity provider where the chosen method allows it. Audit controls under 164.312(b) can be supported by pgAudit and standard PostgreSQL logging, which record session and object activity to the server log.
What the platform does not cover. Several obligations sit outside the database. Emergency access procedure, a required specification, is a documented process your organization must write and test. Automatic logoff, an addressable specification, depends on your session timeout settings in the application and the client path, and you must assess whether it is reasonable and document the decision. Encryption and decryption, also addressable, depends on your decisions about transport encryption, storage encryption and key management. Reviewing audit logs, the operational half of audit control, and performing the risk analysis under 164.308 are also organizational work that no database setting replaces.
Compliance evidence and attestation. HHS states that no Security Rule standard requires an entity to certify compliance and that HHS does not endorse or recognize private certifications. There is no HIPAA certificate to buy for this database. DeployOpen prepares systems, configuration, documentation and evidence for your own review and for assessments you commission, but DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and HHS Office for Civil Rights investigations evaluate what your organization can demonstrate.
What to confirm before scoping. Ask your compliance lead which implementation specifications have already been assessed as addressable, and what your documented decision is for each. Confirm which PostgreSQL major version and authentication method your environment will use, since that determines which access controls are available. Agree in writing which items are configuration work for the platform, which are policies your team owns, and which are evidence your auditors will request. That split decides both the scope of work and who is accountable for each gap.
Which HIPAA Security Rule requirements PostgreSQL configuration supports
This table maps each technical safeguard in 45 CFR 164.312(a)(1) and 164.312(b) to what PostgreSQL provides and what your team must configure or supply. Rows marked as not covered by PostgreSQL need an organizational control, and the rule allows addressable specifications to be documented as unmet when an equivalent measure is not reasonable. Use the table as a starting point for your risk analysis, not as evidence of compliance on its own.
| Requirement | PostgreSQL capability | Configuration needed |
|---|---|---|
| Access control standard, 164.312(a)(1) | Database roles, client authentication methods in pg_hba.conf, and row security policies restrict which users can reach which data | Grant access through named roles, limit schema and table privileges to the minimum, and enable row security on tables that hold ePHI |
| Unique user identification (required) | Named login roles identify each database user, and pg_hba.conf maps connection types and addresses to authentication methods | Assign one login role per person or service, avoid shared accounts, prefer SCRAM password authentication or certificates, and keep a reviewed role inventory |
| Emergency access procedure (required) | Not covered by PostgreSQL. The organization must supply the control. | Write a break-glass procedure with a separately controlled role, named approvers, time-limited use, logging of each session, and revocation after the event |
| Automatic logoff (addressable) | Idle session timeout settings exist in PostgreSQL, but applying a logoff policy across applications and administrator tools is not covered | Set idle session timeouts in the database after confirming parameter names and behavior for your version, add application-level timeouts, and document any gap with an equivalent measure |
| Encryption and decryption (addressable) | TLS for client connections is configurable through hostssl entries and certificate authentication. Encryption of stored data is not provided by core PostgreSQL. | Require TLS for remote connections, encrypt data volumes and backups with your storage or backup tooling, manage keys outside the database, and record the decision and its basis |
| Audit controls, 164.312(b) (required) | The pgAudit extension records detailed session and object activity through the standard PostgreSQL logging facility | Install pgAudit, set its logging classes for ePHI tables and privileged roles, ship logs to a central store, restrict log access, and define who reviews entries and how often |
| Default-deny on ePHI tables (supports 164.312(a)(1)) | When row security is enabled on a table and no policy exists, PostgreSQL returns no rows to non-owner users | Enable row security on each ePHI table, write policies per role, test with sample users, and confirm how table owners and superusers bypass policies in your version |
How unique database roles satisfy HIPAA unique user identification
Shared database accounts cannot satisfy HIPAA unique user identification, so every person who reaches ePHI in PostgreSQL needs a database identity of their own. 45 CFR 164.312(a)(1) requires that only persons or software programs granted access rights can reach electronic systems holding ePHI, and its unique user identification implementation specification is required, not addressable. A single account used by a support team, a reporting job or a group of clinicians makes it impossible to tie a row read or changed to one individual. The practical work is to inventory every login role that touches patient data, then separate human roles from service roles so each can be named, granted and revoked on its own.
Application service accounts create the same problem in a quieter form. A web application that connects as one database role for all users records the application's identity in the logs, not the clinician's or patient's. Per-person roles are the database-side answer only if the application passes the end user's identity to the database, or if the logging and row policies can see it. Decide early whether each human identity maps to a PostgreSQL role, whether roles are grouped through NOLOGIN parent roles with permissions, and how the application's service role is limited to what it needs. Document which service role belongs to which application and who approves its grants.
Authentication sits between the person and the role. PostgreSQL documents password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth methods, and PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM. New clusters should use SCRAM-SHA-256 for password logins, and any remaining MD5 entries in pg_hba.conf should be found and retired during the build. The right method for the rest depends on the organization's identity provider, which must be confirmed: a directory such as Active Directory or FreeIPA may point to GSSAPI or LDAP, a corporate SSO platform may point to OAuth, and workloads may need certificates. Pick one primary method for staff, then document the exceptions and who approves each.
Identity federation makes these choices hold over time. When a person leaves or changes role, the identity provider should disable the login path, and the database role should be revoked or reassigned through a documented process. Confirm with the identity team whether group membership can drive role grants, how often access is reviewed, and whether the database accepts only federated logins for named staff. Keep break-glass access in a separate, tightly logged path, consistent with the emergency access procedure that 164.312(a)(2)(ii) also requires.
Connection pooling is the point where per-person attribution most often breaks. PgBouncer and similar poolers normally keep a small set of server connections under one database role and multiplex many client sessions across them, so the database sees the pooler's role rather than the person. If the pooler authenticates clients itself, or the application reuses a shared server login, audit records will not identify the individual even when the design looks correct on paper. Confirm with your own pooling and application design whether the pooler passes the client identity through, whether session settings can carry the end user's identity for logging and row policies, and whether pgAudit output will still name the person. Test this with two named users sending queries through the pool before go-live.
When row-level security enforces need-to-know access to ePHI
Row-level security fits when one table holds ePHI for many patients or care relationships, and different users should see different subsets of its rows. The access control standard in 45 CFR 164.312(a)(1) requires that only persons or software programs granted access rights can reach ePHI, and the unique user identification specification means each person must be identifiable to the policy. Row-level security moves part of that decision into the database, so an application defect or a broad shared query does not silently return more rows than the user is allowed to see. Need-to-know is the design goal: a user reaches only the records their role requires.
- Shared tables across care teams: use it where one table serves several clinics, departments or care teams.
- Identity reaches the database: policies need a database role or session value that the application sets reliably.
- Attribute data is stored in a queryable form: care team membership must live in a table the policy can evaluate.
- Coarse table grants are insufficient alone: a grant that allows reading the table cannot express which patients a user may see.
- Performance and evidence: policies add predicates to every query, so test on production-like volumes and confirm activity is recorded.
Illustrative example: a scheduling role may need appointment rows for its own clinic but should not see clinical notes for patients outside its care team. Confirm the access rules with your privacy and security officers before writing any policy.
A policy is created with CREATE POLICY and applies only after the table has ENABLE ROW LEVEL SECURITY set. The USING expression filters rows a command can see or target, and WITH CHECK validates rows that are inserted or updated. Default-deny applies when row security is enabled and no policy exists for the command, so queries return no rows until a policy grants access. Table owners and roles with superuser or BYPASSRLS privileges have bypass behavior, and the exact rules, including how FORCE ROW LEVEL SECURITY changes owner behavior, must be checked in the PostgreSQL row security documentation for your version before you rely on them.
- Enable and force deliberately: confirm whether owners are exempt on your version, and set FORCE where the policy must also bind them.
- Separate read and write predicates: USING governs reads and targets, WITH CHECK governs what a write may store.
- Test default-deny: create a test table with row security enabled and no policy, then confirm a non-owner role returns zero rows.
- Inventory bypass roles: list superusers, BYPASSRLS roles and table owners, then confirm application accounts do not use them.
- Test every command and role: cover SELECT, INSERT, UPDATE and DELETE for each role, including denied cases, on a staging copy.
Keep the policy SQL in version control and store test output with the access control records, so a reviewer can see what each role could reach at a given time.
Row-level security is one access control inside the database. It does not replace authentication, unique accounts, network controls, audit logging or the other Security Rule safeguards. The technical standard lists unique user identification and an emergency access procedure as required, and automatic logoff and encryption and decryption as addressable, which means each must be assessed, implemented or documented with an equivalent measure under 45 CFR 164.306(d). Audit controls under 45 CFR 164.312(b) are a separate required mechanism, so pgAudit or another logging method is still needed to record who read or changed ePHI.
- Authentication and network access: MFA, VPN and identity controls must stand in front of the database, because a policy trusts the identity it receives.
- Shared or generic accounts: a shared application account makes row policies meaningless for attribution.
- Emergency access: a policy that blocks everyone may block urgent care, so design a logged break-glass path.
- Audit trail: policies decide access but do not record it, so pair them with pgAudit.
- Encryption and logoff: assess these addressable specifications separately and document the decision.
For context, on 3 September 2026 France's CNIL fined Hopital Prive de la Loire EUR 500,000 under GDPR Articles 32 and 34, finding that external access lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. This is a regulator decision outside HIPAA, cited only to show that such a failure is recognized. Confirm your HIPAA scope with counsel.
What audit evidence a PostgreSQL HIPAA review will ask for
A HIPAA review of a PostgreSQL database will ask for records that show access was granted deliberately and that activity was both recorded and examined. The cards below list the artifacts the configuration produces and how to keep each one so it can be produced later. Capture alone is not enough, so review records sit alongside the captured data.
pgAudit session and object logs
pgAudit writes session and object audit entries through PostgreSQL's standard logging facility, so they follow the server log stream. Check that the configuration records the statement classes you need for tables holding ePHI, and that each entry identifies the database role that acted. Ship the entries to a central store with restricted read access, and keep a dated copy of the settings in use. Retention and review frequency are organization decisions to confirm against your risk analysis and policies.
Role and grant exports
A catalog export of roles, memberships and grants shows who can reach ePHI tables and whether any accounts are shared. Run the export on a schedule and at each access review, then compare it with the previous export to find unexpected grants. Store exports in the same protected location as the logs, with access limited to the people who perform reviews. Confirm with your access control owner that every person maps to a unique database role. Retention and review frequency are organization decisions to confirm against your risk analysis and policies.
Row policy definitions
Row-level security policies state which rows each database role can read or modify. Export the policy definitions along with the list of tables where row security is enabled, because a table with row security enabled and no applicable policy returns no rows. Verify that each policy matches the access rules in your documented procedures. Keep dated exports alongside the change records for those policies. Retention and review frequency are organization decisions to confirm against your risk analysis and policies.
Authentication configuration files
The host-based authentication file and related server settings determine which clients can connect and which authentication methods they must use, such as certificates or SCRAM passwords. Keep these files under version control and record a checksum for each released version. Check that MD5 password authentication is not enabled, since PostgreSQL 18 deprecated it in favor of SCRAM. Store copies in the protected evidence location and restrict who can edit them. Retention and review frequency are organization decisions to confirm against your risk analysis and policies.
Role and policy change records
Each change to a role, grant or row policy should trace back to a request, an approver and a timestamp. Pull these records from your ticketing system, your configuration repository or your migration tooling, and match them against the catalog exports. Investigate any role or policy change that has no matching record. Keep the matched set in the evidence store with restricted access. Retention and review frequency are organization decisions to confirm against your risk analysis and policies.
Log review and examination records
The audit control standard in 45 CFR 164.312(b) requires mechanisms that record and examine activity, so the review is evidence in its own right. Keep records that show who reviewed the pgAudit and server logs, when they did so, what they examined and what they escalated. Define the review queries or alerts in advance so the examination is repeatable. Restrict access to these records and keep them with the logs they describe. Review frequency and retention are organization decisions to confirm against your risk analysis and policies.
Encryption and automatic logoff decisions under addressable specifications
For the encryption and automatic logoff specifications in 45 CFR 164.312, the first decision is procedural: an addressable specification is not optional. Under 164.306(d), the organization must assess whether each one is reasonable and appropriate for its environment. If it is not implemented, the organization must document why and adopt an equivalent alternative measure where that is reasonable and appropriate. For a PostgreSQL database holding ePHI, the assessment should be written per specification, name the systems it covers (primary, standbys, backups, WAL archives, dump files and audit logs), and be signed off by the people who own the risk. A file that says only "encryption applied" will not show the assessment that OCR reviews look for.
Encryption in transit is the decision most likely to be already settled in practice, but it still needs evidence. Enable TLS on the server, require it for every client and application role through hostssl entries in pg_hba.conf, and reject plain connections with hostnossl rules or equivalent. Cover replication connections and administrative tools such as pg_dump and pgBouncer as well, since a database can be encrypted for application traffic and still expose credentials and data over an administrative path. Where certificate authentication is used, record who issues and rotates the certificates. Confirm the certificate lifecycle, cipher policy and TLS version minimums against your own security baseline, because the server defaults may not match it.
Encryption at rest is where the most common gap appears. PostgreSQL does not provide transparent encryption of its data files in the core product, so the decision sits at the storage, volume or platform layer: encrypted block devices, an encrypted volume service, or a storage platform that encrypts at the array level. Ask the platform owner which layer applies to each location, including WAL, base backups, incremental backups, archived files and any pg_dump output, because each copy of ePHI is in scope. Confirm key management, who can unlock keys, and whether encrypted backups can be restored in the recovery environment. Also check whether pgAudit or server logs can capture query text containing ePHI, since those log files are data stores too.
Automatic logoff has to be set at more than one layer. At the application layer, the product's own session timeout should end idle user sessions and require re-authentication. At the database layer, idle session timeout settings can end sessions that sit unused, and the parameter names and availability depend on the major version, so confirm them against the version you run. Shared connection pools complicate this: a pooler such as PgBouncer holds server connections for many users, so a per-user logoff at the application may not close the database session. Document which layer enforces the timeout, the chosen value, how it was justified, and how a test shows an idle session is actually terminated.
The January 2025 proposed update to the Security Rule would require encryption of all ePHI at rest and in transit, with limited exceptions, and would change the audit control wording (90 FR 898). As of October 2026 it is still a proposal, not a final rule, and the Unified Agenda projects final action for July 2027. Plan for the current rule, but design the encryption decisions so they can be re-assessed without rebuilding the database. Keep the documented assessments, the storage layer map and the logoff settings in a register that can be updated. If your cluster runs PostgreSQL 14, note that its support window ends November 12, 2026, so an upgrade that also revisits encryption settings may be scheduled in the same change window.
What PostgreSQL and pgAudit leave to your organization
PostgreSQL provides roles, row security, authentication methods and logging hooks, but it does not make the decisions that the HIPAA Security Rule assigns to covered entities and business associates. The cards below list each gap, what the platform leaves open, and what your organization or a partner must add.
Emergency access and break-glass accounts
Section 164.312(a)(2)(ii) requires an emergency access procedure so that ePHI stays reachable during an outage or security incident. PostgreSQL does not define break-glass accounts, their approval, or how their use is logged. Create a named, rarely used emergency role, store its credentials in a vault with dual control, and alert on every login. Test the procedure in a drill and record the results.
Risk analysis and documented policies
Section 164.308(a)(1) requires an accurate and thorough risk analysis and risk management, and section 164.316 requires written policies and procedures. PostgreSQL ships no policy text and no risk register. Your organization or an adviser must map each database role, extension, backup and network path to ePHI. Document each decision, including encryption at rest, and for any addressable specification you do not adopt, the reason and the equivalent measure you choose.
Audit log review and alerting
Section 164.312(b) requires mechanisms that record and examine activity in systems that use ePHI. pgAudit writes session and object events to the PostgreSQL log, but reviewing those events is a procedure you must run. Define who reviews which events, how often, which events raise alerts, and how each follow-up is recorded. Before you choose a build, confirm pgAudit availability and compatibility with your chosen PostgreSQL major version with the pgAudit project.
Log retention and tamper resistance
Audit records help only if a database host administrator cannot alter them unnoticed. Ship logs to a separate system with access-restricted or write-once storage, and set retention to match your documented policy and any contractual or state requirement. PostgreSQL does not forward, sign or manage retention of its logs. Ask counsel to confirm the retention period, and test that archived logs can be restored and read.
Application attribution and automatic logoff
Section 164.312(a)(2)(iii) addresses automatic logoff, and PostgreSQL does not decide when a user session should end. Many applications connect through one shared service account, so the database alone cannot show which clinician acted. Pass each user's identifier into the session context, log it with pgAudit, and configure idle timeouts in the application and connection pooler. Verify both settings in a test environment before go-live.
Failover, backups and business associate contracts
Sections 164.308 and 164.310 cover contingency planning and device and media controls, and PostgreSQL does not decide them. Its failover documentation states that the server does not detect a primary failure or notify a standby, so automatic failover needs external tools. Backups need encryption and tested point-in-time recovery. If a managed or hosting provider creates, receives, maintains or transmits ePHI, a business associate contract under section 164.314 must be in place first.
Configuration sequence for PostgreSQL HIPAA audit and access controls
This sequence takes a PostgreSQL cluster holding ePHI from inventory to a tested, documented set of access and audit controls. Each step maps to a technical safeguard in 45 CFR 164.312 or a documentation requirement, and it closes with an artifact your team or an assessor can review.
Inventory ePHI tables and their users
The data owner and platform engineers map every database, schema and table that stores or processes ePHI. They then list each application service account and each person with a network or login path to those objects. This supports 45 CFR 164.312(a)(1), which requires that only persons or software programs granted access rights can reach ePHI. The step is complete when every ePHI table has a named owner and every access path appears in the inventory.
Set the supported PostgreSQL major version
Choose a major version that is inside its support window on the go-live date, and record its end-of-life date in the evidence register. The versioning policy lists support for versions 14 through 18, with versions 13 and earlier unsupported. Plan the next major upgrade well before the current end date, using pg_upgrade or logical replication, and write the upgrade decision into the lifecycle record. The step is complete when the chosen version and its upgrade date are approved and documented.
Enforce unique roles and SCRAM authentication
The database administrator creates one login role per person and one per service, with no shared accounts, and grants each role only the privileges it needs. Set password_encryption to scram-sha-256 and remove every MD5 rule from pg_hba.conf, since PostgreSQL 18 deprecates MD5 in favor of SCRAM. Where your identity provider supports it, confirm whether GSSAPI, LDAP, certificate or OAuth authentication fits your model. This supports unique user identification under 164.312(a)(2)(i). The step is complete when the role listing matches the inventory and no MD5 entry remains.
Define row policies and test default deny
For tables where access depends on the patient relationship or care team, enable row-level security and write one policy per role that needs filtered access. With row security enabled and no policy present, PostgreSQL returns no rows, so confirm that each role sees only what it should. Table owners bypass row policies unless the table is set to force row-level security, so check that setting explicitly. The step is complete when a test suite, run as each role, shows permitted rows returned and out-of-scope rows hidden.
Install pgAudit and choose event classes
Using the risk analysis, the security lead selects which pgAudit classes to record, such as reads, writes, DDL and role changes, and whether to log at session or object level. The database administrator installs the extension, sets pgaudit.log and applies object-level settings to the ePHI tables. Entries flow through PostgreSQL's standard logging facility. This addresses 164.312(b), which requires mechanisms that record and examine activity in systems containing ePHI. The step is complete when sample entries appear for test reads and writes, and the settings are stored in version control.
Route logs to a protected central store
The platform team forwards PostgreSQL server logs and pgAudit output to a central log store that database administrators cannot silently edit, with read access limited to a named review group. Confirm the store's retention, integrity and access logging features with its vendor or project before you rely on them. DeployOpen can connect the pipeline to a platform such as Graylog, Loki or OpenSearch if you choose one. The step is complete when a test event generated by a privileged account arrives in the central store with its original timestamp.
Enable TLS and document the encryption decision
The platform team enables TLS on the server and uses hostssl entries in pg_hba.conf so that clients without encryption are refused. The security lead documents the at-rest encryption approach, whether storage-level, filesystem or another method, and the reason for the choice. Under 164.306(d), an addressable specification requires a documented assessment and, if it is not implemented, a documented equivalent measure. The step is complete when a connection without TLS fails in testing and the signed decision record is filed.
Test controls and write the evidence register
The QA or security team runs negative cases as an unauthorized role: a login with a wrong password, an MD5 login attempt, a plaintext connection, a query outside a row policy and a privileged action that should appear in the audit log. Results are recorded with dates and the tester's name. The evidence register then maps each control to its requirement, owner, artifact location and the review schedule your organization sets. HHS states that no Security Rule standard requires certification, so this register supports audits and investigations without serving as a certification. The step is complete when every negative case has a recorded result and the register is approved.
Questions buyers ask before hiring help with PostgreSQL HIPAA controls
Does PostgreSQL alone make a database HIPAA compliant?
No. PostgreSQL provides features that support specific HIPAA Security Rule controls, such as unique database roles, row security policies and, with the pgAudit extension, detailed activity logging. The Security Rule applies to the whole system that holds electronic protected health information, so the application, identity provider, network paths, backups, encryption design, written policies and staff procedures must also be addressed. Row security defaults to denying access when it is enabled and no policy exists, so policies must be written and tested before go-live. Each control you rely on needs a documented configuration, a named owner and evidence that it works. The risk analysis that the Security Rule requires is the starting point for deciding which controls apply.
Is there an official HIPAA certification for a PostgreSQL database?
No. HHS states that no Security Rule standard requires an entity to certify compliance, and it does not endorse or recognize private organizations' certifications. HHS also says that a private certification does not prevent it from later finding a violation. DeployOpen prepares systems, configurations, documentation and evidence for your compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform that work when you choose one. Ask any provider offering a HIPAA certificate to show the basis for it in writing and to name the body that stands behind it. The Office for Civil Rights enforces the rule through complaint investigations, compliance reviews and audits, so treat your readiness evidence as material you may need to show a regulator, customer or assessor.
What drives the cost of PostgreSQL HIPAA access and audit work?
The cost follows the written scope, and DeployOpen does not publish a price list. The main drivers are the number of schemas and tables that hold ePHI, the number of database roles and how they map to job functions, and the connection patterns of each application, such as shared service accounts, per-user connections or a connection pooler. Logging volume and retention period, whether your existing identity provider can supply database authentication, the encryption design for data at rest and in transit, and whether an external audit is planned also change the work. Fixed-scope work is priced once from agreed deliverables. Recurring costs include log storage, log review, role reviews, upgrades and any retainer for ongoing support. Ask for one-time and recurring items separately, along with the assumptions behind each.
How long does PostgreSQL HIPAA access control work take?
It depends on the scope and the environment, and no duration applies until a written scope exists. Timing moves with the same drivers as cost: the number of ePHI schemas and roles, how many applications connect and how they authenticate, how quickly your identity team can complete the required integration, and whether the target environment is ready for changes. Decisions on retention periods and risk treatment often take longer than the technical configuration itself. Ask for a written timeline that lists each phase, the client decisions and access dependencies each phase needs, and the review points that affect dates. Also ask how a slipped dependency changes the schedule. Treat any single duration quoted before scoping as an estimate that needs confirmation.
What does our team need to provide for PostgreSQL HIPAA controls work?
Expect to provide access and ownership in four areas. First, access to the database environment in your infrastructure, including a non-production copy for testing role and policy changes. Second, named owners for each application that connects to the database and for the identity provider that will supply users. Third, a risk analysis owner who can confirm which ePHI the database holds, who needs it and which threats matter most. Fourth, decision makers for log retention, encryption design and who may review audit records, since audit logs can contain sensitive data. You will also need change windows for configuration changes and restarts. Unnamed owners tend to stall work, so confirm these people before scoping begins.
Can our own team implement HIPAA controls on PostgreSQL without a partner?
Yes, if the team has strong PostgreSQL administration and security skills and time to test changes. Engineers can create unique roles, configure row security policies, enable pgAudit, set logging and plan encryption by working from the PostgreSQL and pgAudit documentation. Some work stays with your organization regardless of who builds the controls: the risk analysis, written policies and procedures, decisions about who may access which records and how long logs are kept, and evidence that each control works. A partner can shorten the build and provide an independent technical review, but it cannot make those decisions for you. Assess your team against the tasks in the scope, test in a non-production copy, and name who will run log reviews and role reviews after go-live.
What are the financial penalties for HIPAA Security Rule violations?
For penalties assessed on or after January 28, 2026, 45 CFR 102.3 sets an inflation-adjusted range from $145 per violation, where the entity had no knowledge of the violation, up to $2,190,294 per violation for uncorrected willful neglect. The calendar-year cap is $2,190,294. The amount depends on the culpability tier HHS assigns, which reflects what the organization knew and how quickly it corrected the problem. HHS OCR enforces the Security Rule through complaint investigations, compliance reviews and audits, and its 2024 to 2025 HIPAA audits focus on provisions most relevant to hacking and ransomware. Civil money penalties are only one cost. Breach response, notification obligations, customer contract terms and litigation can also follow a security incident.
How DeployOpen scopes and delivers PostgreSQL compliance configuration
DeployOpen plans and configures PostgreSQL databases that hold ePHI in infrastructure you control, mapping unique database roles, row-level security, pgAudit activity records and encryption decisions to the HIPAA Security Rule access control and audit control standards. We start from a written scope and deliver documented configuration and evidence that your compliance team and auditors can review. DeployOpen prepares systems and evidence for assessment and does not issue certifications or attestations.
How we scope
- The written scope lists each database, role model, row-level policy and pgAudit setting covered for ePHI.
- We agree which PostgreSQL major version and hosting environment the configuration targets before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.
How we build
- Create one login role per person and per service account, with group roles mapped to your access model.
- Enable row security on tables holding ePHI and write policies that match care-team need-to-know rules, tested with sample roles.
- Configure pgAudit session and object logging through the standard PostgreSQL logging facility, with the event classes agreed in scope.
How we hand over
- Documented role inventory, policy definitions, pgAudit settings and a log routing description your team can review and maintain.
- A mapping of configuration to 45 CFR 164.312 implementation specifications, so compliance staff can trace each safeguard to evidence.
- Test results from verification steps, including denied queries under row policies and log entries for sampled activity.
How we support
- Retainers cover ongoing support, PostgreSQL minor updates and planned major upgrades for the configured cluster.
- Role reviews and changes to row policies follow your change process, with each change documented for the audit trail.
- Periodic security testing of the database tier can be added, covering access paths and misconfigurations.
