164.312(b) Audit controls: requirements and evidence

What 164.312(b) audit controls requires and why assessors check it

If you are the compliance lead or engineer who has to show that activity on systems holding ePHI is recorded and examined, the core answer is this: 164.312(b) requires hardware, software or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information. The standard is about evidence that someone can see what happened to ePHI, when, and by whom, and that the organization looks at that record. It addresses the risk that unauthorized access, misuse by a workforce member, or ransomware activity goes undetected for long enough to cause a breach. The standard has no separate implementation specifications, and Appendix A to Subpart C marks it as required, so there is no addressable option to document away. Your job is to decide which systems count as containing or using ePHI, which events each one must record, and where those records go.

The difficulty is rarely turning logging on. ePHI usually moves through an EHR, a file share, a patient portal, a cloud storage bucket, a identity provider, and laptops or mobile devices, and each source logs in a different format with different retention settings. A common failure is a dashboard that collects logs from most systems while nobody has written down which events matter, who reviews them, or how often. Assessors look for the gap between collection and review. The NIST SP 800-66 Rev. 2 resource guide, which is informational and not binding, breaks this work into deciding what to track, selecting tools, writing an activity review policy, writing procedures, and running the process. Confirm with your own risk analysis which systems hold ePHI before you scope logging.

No HIPAA certification exists, so no one can issue a document that certifies your audit controls as compliant. HHS states that the Security Rule does not require certification and does not endorse private certifications. The Office for Civil Rights enforces the rule through complaint investigations, compliance reviews and audits, and its 2024 to 2025 audit program reviews 50 covered entities and business associates on provisions most relevant to hacking and ransomware. In practice, an investigator will ask for the defined list of logged activities, sample log entries, evidence of review, and what happened when a review found something. Build your evidence around those questions, and treat any outside assessment as a check on your own records rather than a certificate of compliance.

Which systems and third parties fall under audit controls

Audit controls under 164.312(b) apply to every information system that contains or uses ePHI, so the first job is deciding which systems and parties sit inside that boundary. The decisions below change what you must log, who must produce logs for you, and what evidence an assessor will ask to see.

Core clinical and records systems

The EHR, practice management database and any application that creates, reads or changes patient records are the clearest cases in scope. Confirm that each one can record user activity at the record level, such as who viewed or changed a chart and when. If the vendor only logs logins, you will need a second source for access events or an accepted gap documented in your risk analysis. Ask the vendor for the exact list of logged event types before you rely on them.

File shares and document stores

Network shares, scanned-document folders and collaboration platforms that hold ePHI are in scope even when no one thinks of them as systems. Enable file access logging on the server or platform, and make sure logs record reads, writes, deletes and permission changes. If a share is used only as a temporary drop point, it still contains ePHI and must be covered or purged on a defined schedule.

Identity provider and authentication services

The directory and single sign-on service decide who reaches ePHI, so their logs are often the first evidence an assessor requests. Capture successful and failed sign-ins, MFA events, password resets and changes to group membership. If authentication is delegated to a cloud identity service, confirm in writing which events it retains, for how long, and how you can export them.

Administrative consoles and privileged access

Hypervisor consoles, database administration tools, cloud management portals and infrastructure-as-code pipelines can change or read ePHI without passing through an application. Treat them as in scope and log privileged sessions, configuration changes and break-glass use. Tools that bypass the application layer are a common gap because application logs never show their activity.

Backups and recovery copies

Backup systems hold complete copies of ePHI, so reads, restores, exports and deletions of backup data belong in the audit boundary. Check whether the backup software writes job and restore logs, where they are stored and whether they are protected from the same administrators whose actions they record. A restore performed without a log entry is a difficult question to answer during an assessment.

Business associates and hosted providers

When a cloud host, managed IT provider or SaaS vendor generates logs you rely on, you need contract terms that give you access to those logs and define retention. Identify which provider logs cover your ePHI systems, such as hypervisor, storage and management-plane logs, and record them in your business associate inventory. Where a provider will not share logs, document the reliance on their attestations and the residual risk.

How an assessor tests audit controls

This table sets out each step an assessor typically takes when testing 164.312(b), what they inspect, the evidence they expect to see and where the control most often fails. Read it as a preparation checklist: if a step cannot be shown with records you already hold, that gap is the first thing to fix before an assessment.

Test step	What the assessor checks	Evidence that satisfies it	Where it usually fails
Confirm the ePHI system inventory	Which systems create, receive, store or transmit ePHI, including secondary and backup systems	Current asset list tied to the risk analysis, with data flows and system owners	Systems outside the inventory, such as test copies or reporting databases, have no logging configured
Inspect enabled audit mechanisms	Whether audit logging is turned on for each in-scope system and what events it captures	Configuration exports or screenshots showing audit settings, plus event categories enabled for logins, record access and changes	Logging disabled on a secondary or legacy system, or only authentication events captured
Sample log records	Whether a single recorded action can be traced to one identifiable person or process	Sampled entries showing timestamp, user ID, action, target record and source, pulled from the log store	Shared or generic accounts make entries unattributable to a person
Check log integrity and retention	Whether logs are protected from alteration or deletion and kept long enough to support review	Retention settings, access permissions on the log store, and evidence that logs forward to a central or write-protected location	Administrators can edit or purge local logs, or logs roll over before anyone reviews them
Review activity examination	Whether someone examines audit activity and acts on what they find	Review records, dated sign-offs, alert queues with disposition notes, and escalation tickets	Logs exist and are retained, but no review has happened or no one can show a record of it
Confirm written procedures	Whether the entity has written rules for what is audited, who reviews it and how often	Audit and activity review policy, standard operating procedures and training records for reviewers	Procedures describe a process the team does not follow, or were never approved or updated
Trace a sample event end to end	Whether an alert or review finding led to documented follow-up	Example incident or anomaly walked from log entry to investigation record and outcome	Follow-up is informal, such as chat messages, with no record kept

How to implement audit controls step by step

The sequence turns the broad requirement to record and examine activity into a defined event inventory, a tool set, a written policy, working procedures and a repeatable review cycle that an assessor can trace from start to finish.

Determine the activities to be tracked
Start by listing the systems that create, store, transmit or access ePHI, then list the events each one should record, such as logins, failed authentication, record views, exports, permission changes, configuration edits and administrative actions. Map each system to its owner and to the risk analysis entry it supports. The output is an event inventory that names the system, the event types, the log source and the retention expectation for each. Confirm the inventory with system owners and the security official before moving on, because every later step depends on it.
Select tools for auditing and activity review
Match the event inventory to tools that can generate, collect, store and search those logs. Consider whether each application can write audit records natively, whether a log collector or SIEM can ingest them, and who can read the output. Open-source options such as Nextcloud's admin_audit app, OpenBao audit devices, and log analytics or detection platforms like OpenSearch Security Analytics and Wazuh each cover different sources, so confirm coverage for your own systems rather than assuming it. The output is a tool selection record that lists each source, the tool that captures it, the storage location and the person responsible for reviewing it.
Develop the audit and activity review policy
Write a policy that states which systems are in scope, which events are logged, how logs are protected from alteration and deletion, how long they are kept, who reviews them and how often. Tie the policy to the risk analysis and to the information system activity review standard in 164.308(a)(1)(ii)(D), since that review depends on this logging. The output is a signed policy approved by the entity's leadership and version controlled, with a named owner and a review date. Ask any outside consultant to confirm the policy matches what the tools actually do.
Write standard operating procedures
Turn the policy into procedures that an analyst can follow. Cover how to enable and verify each logging source, how to confirm log integrity and time synchronization, how to triage alerts, how to escalate suspicious activity into incident response, and how to record each review. Include example queries or detection rules as runbook entries, labeled as starting points to be tuned for your environment. The output is a set of runbooks, each with a trigger, steps, owner and record format, stored where the workforce can find them.
Configure logging and detection content
Enable the logging settings chosen in the earlier steps, set log destinations and permissions, and load detection content such as built-in or custom rules. Confirm that logs arrive where expected and that restricted accounts cannot edit or delete them. Test the chain by generating known events, such as a failed login or a permission change, and checking that each appears in the review tool. The output is a configuration baseline and a test record showing which events were generated, which were captured and which were missed, with fixes logged against each gap.
Run the first activity review cycle
Carry out the review as the policy and procedures describe. The reviewer examines the captured events and alerts, records what was reviewed, what was found, how each finding was handled, and who signed off. Note any gaps in coverage and feed them back into the event inventory. The output is a first review cycle record with dated entries, reviewer identity, findings, disposition and escalations. This record is often the first thing an assessor asks to see, so keep it complete rather than summarized.
Repeat, test and update the process
Operate the review on the cadence the policy sets, check that log sources keep reporting, and revisit the event inventory whenever systems, vendors or data flows change. Periodically test whether the logs would show a realistic misuse scenario. Track changes to the policy and procedures with version history. The output is a continuing set of review records, change logs and periodic test results. NIST SP 800-66 Rev. 2 is an informational resource guide, not a legally binding document, so use it as a practical checklist and confirm your obligations against the Security Rule text.

Self-hosted open-source options for audit trails

Application audit logging records what users and administrators do inside the business application that holds ePHI. In Nextcloud, the admin_audit app writes additional event information to an audit log. By default that log sits in the data directory, but the entity can point it to a different path with the logfile_audit setting, which is useful when logs must go to a separate, access-restricted location. The Nextcloud app is licensed under AGPL-3.0-only, and the platform itself is AGPL-3.0 licensed, so confirm the license terms that apply to your deployment before you modify or redistribute it.

Enable the audit app: Confirm admin_audit is installed and active on every instance that stores ePHI, including test or staging copies if they hold real records.
Set the log path: Use logfile_audit to send events to a location with restricted write and read permissions, not the general data directory.
Protect log integrity: Restrict who can edit or delete the audit file and forward copies to a system administrators cannot silently alter.
Cover the events you need: Check which event types the app records against the activities your risk analysis identifies, such as file access and sharing changes.

Confirm with your own configuration that the audit log captures the ePHI access events your policies require, and test it with a known action before relying on it as evidence.

Which evidence passes an audit controls review

An assessor testing 164.312(b) looks for proof that audit mechanisms exist, are switched on, capture the right activity, and are actually reviewed. The cards below cover the artifacts that connect those four points, and the organization owns each one even when an implementation partner helps prepare it.

Inventory of ePHI systems and logged events

This is the list of every system that creates, stores, transmits or processes ePHI, paired with the events each one must log, such as logins, record views, exports, privilege changes and configuration edits. Without it, an assessor cannot judge whether the audit scope matches where ePHI actually lives. Check that the inventory matches the risk analysis and that new systems are added before they go live.

Configuration exports showing audit settings

Export the audit configuration from each in-scope system and keep the dated files as evidence that logging is enabled and pointed at a protected destination. For example, a Nextcloud deployment would show the admin_audit app enabled and its log path set, while an OpenBao deployment would show an audit device enabled. Compare exports over time to catch silent changes.

Sample log extracts tied to named users

Pull short extracts of audit records that show a specific named user, timestamp, action and object accessed. Assessors use these to confirm that activity can be traced to an individual, which links directly to unique user identification under 164.312(a)(2)(i). Confirm that extracts include the authentication context and that sensitive values are handled according to your own policy.

Written activity review policy and SOPs

The policy states which logs are reviewed, by whom, how often, and what counts as a reportable finding. Standard operating procedures give the steps for each review, including how to pull logs, filter them, and escalate anomalies. NIST SP 800-66 Rev. 2 lists developing this policy and these procedures as key activities, so assessors expect both to be dated, approved and current.

Completed review records and alert triage

Keep signed or system-stamped records of each completed activity review, including the period covered, the reviewer, findings and follow-up tickets. Alert triage records show how each alert from a tool such as Wazuh or OpenSearch Security Analytics was accepted, closed or escalated. Gaps in these records are the most common reason a log program looks unused, even when logging works.

Retention and protection settings

Document how long audit records are kept, where they are stored, who can read or change them, and how they are backed up. Retention periods should follow your own risk analysis and any contractual or state requirements, which you should confirm with counsel. Evidence includes the retention configuration, access rights to the log store, and proof that records were not altered or deleted outside the approved process.

What the 2025 proposal would change for audit trails

The January 6, 2025 proposed Security Rule revision (90 FR 898) would redesignate this standard as audit trail and system log controls at proposed 164.312(d)(1), with more specific requirements than the current text of 164.312(b). The proposal is not law. As of October 2026 no final rule has been published, and the latest Unified Agenda entry for RIN 0945-AA22 lists it under Long-Term Actions with final action projected for July 2027. Any date in that entry is a projection, not a commitment, so plan around the current text until HHS publishes a final rule.

The practical decision is to build logging to the current standard now. Today's text asks for mechanisms that record and examine activity in systems that contain or use ePHI, and nothing more specific. Organizations can meet that by deciding which events are logged for each ePHI system, where those logs are stored and protected, who reviews them and how often, and how reviews are documented. Those same decisions are where a more specific final rule would likely add requirements, so the work is not wasted if the rule changes. Keep the proposed text in view, compare it against your logging design when a final rule appears, and record each gap you find as a planned change instead of retrofitting logs under deadline pressure.

Before you change scope, confirm the details with qualified legal counsel and your privacy officer. Ask counsel whether the current standard already requires any logging you are not yet doing, how the proposed redesignation would affect existing documentation, and which proposed elements, if finalized, would apply to your organization as a covered entity or business associate. Keep a dated record of the advice you receive and the decisions you make from it. Treat the NIST SP 800-66 Rev. 2 guidance as a practical companion to the current text, and review it alongside any future final rule rather than assuming the two line up.

What audit controls costs in money and effort

This table breaks the cost of meeting 164.312(b) into the components an organization pays for, marking whether each is one-time or recurring and what drives it up. Open-source tooling removes license spend, but the effort to enable, normalize, store and review logs stays, so use the rows to build a quote request that names who does each task.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Logging and SIEM tooling	Open-source platforms carry no license fee, but the organization or its partner pays for hosting, patching and configuration	One-time setup, then recurring operation	Number of ePHI systems in scope, and whether a dashboard, correlation and alerting layer is added or built by hand
Engineering time to enable and normalize logs	Internal platform or security engineers, or an implementation partner under a written scope	One-time for most systems, recurring when systems change	Count of applications, identity providers and hosts, and how many log formats must be parsed into one schema
Storage and retention	Infrastructure team or cloud account owner, paid through hosting or storage bills	Recurring	Log volume per day, the retention period the risk analysis sets, and whether logs are copied to a separate protected store
Ongoing review by a named person	Internal staff member or designated reviewer, whose time is paid as salary or contract hours	Recurring	Alert volume, how often review happens, and how well alert rules are tuned to remove noise
Alert tuning and rule maintenance	Security engineers who write and adjust detection rules and decoders	Recurring, with spikes after new systems or incidents	Number of custom rules, false positive rate, and changes in applications that alter log output
External testing or review of the logging design	Independent security testing or assessment firm, paid under a fixed-scope written agreement	One-time review, optional periodic re-test	Number of systems tested, whether logs are checked for coverage and tamper resistance, and the depth of the test
Auditor or assessor sampling effort	The independent assessor, who samples logs and reviews records during the assessment	Recurring with each assessment cycle	How well logs and review records are organized, whether review is documented, and how many systems the sample covers
Documentation of the audit and review policy	Compliance lead or security official, or an advisor preparing procedures	One-time, updated when systems or procedures change	Number of procedures to write, and whether logging standards are already part of other Security Rule documentation

Where audit controls programs usually fall short

Most audit control gaps under 164.312(b) are not missing tools. They are logs that cover only part of the environment, records that cannot be tied to a person, and programs with no owner or written procedure. The cards below cover the failures assessors see most often and what to check for each.

Logging on the application only

Teams often enable audit logging in the application that holds ePHI but leave the database, the identity provider and the file store unlogged. An activity review then shows what the front end did but not who queried the records directly or who changed an account. Inventory every system that contains or touches ePHI, then confirm each one writes events to a location the review process reads. Ask the vendor to document which events each component records by default.

Shared administrator accounts

When several staff use one administrator login, audit records show the account but not the person. This defeats the attribution that audit controls exist to provide and overlaps with the unique user identification specification. Check whether privileged access runs through named accounts, and whether break-glass credentials are logged and reviewed each time they are used.

Logs stored beside the systems they describe

If logs sit on the same host, with the same administrator rights, an attacker or a careless operator can alter or delete the record of their own activity. Forward logs to a separate collector or index with restricted write access and retention that does not depend on the source host. Test the path by confirming that a deliberate test event on a monitored host appears in the central store.

Alerts with no owner

Detection rules that fire into a channel nobody watches produce a log trail but no review record. Assessors look for evidence that a named person received, triaged and closed each alert, with the disposition kept. Assign an owner for every alert source, define the escalation path, and keep tickets or case notes that show the review happened and what was decided.

No written activity review procedure

Under 164.312(b), the organization must decide what is tracked, which tools review it, how often, and who does the review. Without a written policy and standard operating procedure, reviews depend on individual habit and cannot be repeated or audited. Write the procedure, name the reviewer and backup, define the activities to be reviewed, and record each review with its date and findings.

No check after upgrades

Software updates, configuration changes and migrations can silently disable an audit module, change log paths or alter event formats that detection rules depend on. A control that worked last quarter may not work today. Add a post-change test to the change process that generates a known event, confirms it appears in the central store, and confirms the related alert still fires.

Who does what for audit controls

Your organization owns the audit control. The standard in 45 CFR 164.312(b) asks for mechanisms that record and examine activity in systems that contain or use ePHI, and the decisions about what counts as that activity sit with your workforce, not with a vendor. Your security official and system owners set the scope, approve the logging policy and accept the residual risk of anything left unlogged. Your team also performs the activity reviews themselves, because a review that nobody signs is not evidence of a review.

Scope decisions: Maintain the list of ePHI systems, including SaaS, backups and admin consoles, and decide which events must be tracked.
Policy and procedures: Approve the audit and activity review policy and the standard operating procedures that describe who reviews what and how often.
Review duties: Assign named reviewers, define how exceptions are escalated, and keep records of completed reviews.
Sign-off: Approve tool selections, retention periods and any change to logging scope through documented change control.

Before engaging anyone, confirm that you can produce a current system inventory and a signed review record for a sample period, because those two artifacts anchor every other piece of evidence.

Common questions about 164.312(b) audit controls

Is there a HIPAA certification for audit controls?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and it does not endorse or recognize private certifications. Any vendor or consultant offering a HIPAA certificate for audit controls is selling a private assessment, and HHS has said such a document does not prevent it from later finding a violation. What satisfies 164.312(b) is evidence that your systems record and examine activity involving ePHI, and that evidence can be reviewed by OCR or by an independent assessor you choose. Ask any provider to explain exactly what their document covers and what it does not.

How long does it take to implement audit controls, and what does the team need to provide?

The duration depends on how many systems hold or use ePHI, how much logging already exists, and how clearly the organization has defined what must be tracked. NIST SP 800-66 Rev. 2 sets out the work as five key activities: decide what activities to track or audit, select tools for auditing and activity review, write the activity review and audit policy, develop standard operating procedures, and implement the process. Your team needs system owners who can name every application and database touching ePHI, an engineer who can configure log sources, and someone accountable for reviewing the output. Ask any implementation partner for a written schedule tied to these activities before work starts.

Can our own team implement audit controls without outside help?

Often yes, provided the team has people who understand both the ePHI data flows and the logging tools. The standard does not prescribe a product, so an in-house team can choose and configure hardware, software or procedural mechanisms. The harder parts are usually the scoping decisions (which systems, which events, which retention) and the review routine, because those need documented policy and someone who signs off on them. Teams that lack logging engineers, or that run several systems with separate log formats, often bring in help for configuration and leave policy and review ownership with their own staff.

What drives the cost of audit controls up or down?

The main drivers are the number of systems in scope, the volume of events each one produces, how much of the logging stack is already in place, and how much review capacity the organization has. Open-source tools can reduce license spend, but they still require engineering time for installation, rule tuning, storage, access control on the logs and ongoing upkeep. Costs recur for storage, maintenance and the people who review alerts, while setup is largely one-time. When requesting a quote, ask for the list of in-scope systems, the assumed retention period, who will operate the stack after handover, and which tasks are excluded from the price.

Can a partner make us compliant with 164.312(b)?

No. The covered entity or business associate owns its safeguards and remains responsible for them under the Security Rule. A partner can prepare systems, configure logging, document procedures and assemble evidence, but it cannot accept the legal obligation on the organization's behalf. Only an independent assessor you engage can test and report on the controls, and HHS does not recognize any private certificate as proof of compliance. Treat a provider who promises compliance outcomes as a warning sign, and ask instead what artifacts and tests they will deliver.

What would the January 2025 proposed rule change for audit controls?

The proposed rule published at 90 FR 898 on January 6, 2025 would redesignate this standard as audit trail and system log controls, proposed 164.312(d)(1), with more specific requirements. As of October 2026, it has not been finalized, and the latest Unified Agenda lists it under Long-Term Actions with final action projected for July 2027. Until a final rule is published, the current text of 164.312(b) governs. Build your logging program so it can meet more specific requirements later, and read the proposal directly for the details rather than relying on summaries.

How do we keep audit evidence current between audits?

Keep evidence as a routine output of operations rather than as a project to assemble before an assessment. Schedule recurring reviews of audit logs, record who performed each review and what was found, and retain the policy, procedures and tool configuration under version control. Check that logging remains enabled after upgrades and that log storage is protected from alteration. For the Wazuh, OpenSearch or Nextcloud logs referenced in the topic facts, confirm each product's retention and export behavior in your own environment before relying on it. Retain a dated record of each review, because that record is what an assessor will ask to see.

How DeployOpen prepares audit controls evidence

DeployOpen's role in 164.312(b) work is to prepare the logging and review machinery and the evidence that proves it runs. The engagement starts with a fixed-scope written agreement that names the ePHI systems in scope, the log sources for each (identity provider, application servers, databases, file shares, the secrets store and network devices), and the retention period the organization has chosen. DeployOpen then implements and hardens the open-source logging and detection components inside the client's own cloud accounts, data center or isolated network. The organization owns the audit policy, the decision about which activities must be tracked, and the review schedule. DeployOpen does not issue audit reports or certifications. An independent assessor tests the controls, and the organization decides what to disclose.

On the build side, the work is concrete. For Nextcloud, that means enabling the admin_audit app and confirming where audit.log is written, or setting a dedicated path with logfile_audit. For OpenBao, it means enabling an audit device so every API request and response is recorded, and checking that sensitive values are hashed as the product documents. For detection, Wazuh decodes collected logs and writes matches to alerts.log and alerts.json, while OpenSearch Security Analytics can run Sigma-based detectors and route findings to the people who review them. Each component is then wired into a single review workflow with named reviewers, alert routing and a documented procedure for escalation. The client should confirm each of these settings against the current vendor documentation in its own environment before relying on them, since defaults and file locations change between releases.

Evidence is the deliverable an assessor will ask for, so DeployOpen prepares a runbook and an evidence pack for each log source: configuration exports, sample log entries, review records and a description of how log integrity and access to the logs are protected. Ongoing support, upgrades and continuous testing are available as retainers, which cover periodic review of logging coverage after system changes and updates to the rule sets. Before signing, ask for the written scope to list each log source, the retention decision, who performs each review and what evidence will be delivered at the end of the work.

164.312(b) Audit controls