HIPAA audit log requirements: what to log and review

HIPAA audit log requirements: what your organization must log and review

When a customer, contract or OCR inquiry asks for proof of audit logging, the answer starts with two requirements. The Security Rule requires audit controls under 45 CFR 164.312(b), which call for hardware, software or procedural mechanisms that record and examine activity in information systems containing or using electronic protected health information. It also requires, under 45 CFR 164.308(a)(1)(ii)(D), procedures to regularly review records of information system activity such as audit logs, access reports and security incident tracking reports, and that review is a required implementation specification. Your organization owns both obligations. The rule does not list event types, retention periods for logs, or review frequencies, so no vendor, configuration template or outside party can certify that your logging satisfies it on your behalf.

Because the rule leaves the choice of events open, your risk analysis decides what is logged. Start by identifying every system that creates, receives, maintains or transmits ePHI, then decide which activities on those systems matter: successful and failed log-ins, access to records of patients who are not in the user's care, privilege changes, exports, and changes to logging settings themselves. NIST SP 800-66 Rev. 2 describes this sequence as determining what to track, selecting tools, writing an activity review and audit policy, documenting standard operating procedures and then implementing the process. Confirm with your security official which of these decisions are already recorded in your risk management plan, because an assessor will compare the two.

Implementation partners can configure log sources, forward events to a central store, build review reports and write the procedures, and they can test that the pipeline works as documented. They cannot decide what your organization considers reasonable, and they cannot review the logs for you unless your written arrangement says so and the reviewer is accountable under your policy. Ask any partner to show how each review is recorded, who signs it off, and how exceptions reach your security official. Only an independent auditor or assessor can issue a report on your controls, and HHS does not recognize private HIPAA certifications, so treat any vendor claim of HIPAA certification as a warning sign.

What the audit controls standard requires in practice

The audit controls standard in 45 CFR 164.312(b) asks for hardware, software and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. It is a technical safeguard, but the rule does not give a list of events you must log, a log format, a retention period or a product. The mechanism is yours to choose, and it can be procedural as well as tool-based. A documented manual check of access records against a schedule can satisfy the standard if your risk analysis shows it is adequate for the systems in scope, though most organizations with electronic health records or a large file share end up relying on built-in platform logging plus a review process. The decision you need to make is which systems hold or touch ePHI, what activity on each of them matters, and which mechanism will capture it.

Confirm the status of each element against the Appendix A matrix in the eCFR before you rely on this reading. The audit controls standard is listed as a standard in its own right, and in the matrix it carries no separate addressable implementation specification, so the 164.312(b) mechanism is not optional in the way an addressable specification can be. The activity review duty sits under the administrative safeguards in 164.308(a)(1)(ii)(D), which is a required implementation specification. Verify both points in the matrix, and confirm with your own compliance lead whether any local policy or contract adds stricter logging duties. The two provisions work together: 164.312(b) requires that the records exist, and 164.308(a)(1)(ii)(D) requires that someone regularly examines them.

What to track: the activities a risk analysis usually justifies

The Security Rule does not list the events to log. Organizations decide what to track based on their risk analysis, the systems that hold ePHI and the ways inappropriate access could happen. The categories below are illustrative starting points, not a required list, and NIST SP 800-66 Rev. 2 places determining the activities to be tracked or audited as the first key activity for this standard.

Log-in successes and failures

Records of who authenticated to an ePHI system, when, from where and whether the attempt succeeded. Repeated failures followed by a success can signal password guessing or credential misuse, and the pattern is often the first visible sign of an account takeover. Confirm that every system holding ePHI, including remote access gateways and cloud consoles, sends these events to a central location and that someone is assigned to review them.

Record access by user and role

Entries showing which workforce member opened, viewed, changed or printed a patient record, and whether the access matched their assigned role. Snooping cases in OCR's enforcement record involved staff viewing records with no treatment or business reason, so this category is where those accesses become visible. Confirm that the logs capture the individual user ID, not a shared account, and that the record identifier is included so a reviewer can trace the access to a specific patient.

Privileged and administrator actions

Activity by accounts that can create users, change permissions, reset passwords or read data across many patients, including database administrators and vendor support accounts. These accounts can bypass the controls that limit ordinary users, so their actions carry higher risk. Confirm whether privileged sessions are logged separately, who reviews them and whether emergency or break-glass access is recorded with a stated reason.

Changes to security settings and audit configuration

Events showing that someone disabled logging, changed retention, edited an access policy, modified a firewall rule or altered an encryption setting. An attacker or an insider who turns off audit logging first will leave no trail for the later activity, so changes to the logging itself deserve their own alerts. Confirm that audit configuration changes are written to storage that the administrators who make them cannot edit.

Bulk exports and large downloads

Reports, database extracts, file transfers or API calls that return large volumes of patient data in one action. Bulk movement is a common pattern when ePHI is taken for resale or extortion, and it can occur through a legitimate account. Confirm the thresholds that trigger review, which systems produce exports and whether exports from reporting or analytics tools are logged as well as those from the core clinical system.

Security incident alerts

Alerts from endpoint, network or identity tools that flag malware, anomalous logins, data loss prevention matches or policy violations, together with the tickets created to investigate them. These records support the security incident tracking reports that the activity review specification names. Confirm who receives each alert type, the expected response time for each and how closed alerts are documented.

How the regular activity review runs, step by step

The five NIST SP 800-66 Rev. 2 activities turn the audit controls requirement into a repeatable cycle: decide what to record, choose the tools, write the policy, document the procedure, and run reviews that leave dated records. Each step ends with an artifact an assessor can examine.

Determine which activities to track and audit
Start by listing the systems that create, receive, maintain or transmit ePHI, then decide which events on each system matter for detecting misuse. Typical candidates include log-ins and failed log-ins, record views and changes by user, privilege changes, exports, and security tool alerts. The risk analysis should drive this list, so each entry can be traced back to a risk. The output is a tracked-events list per system with the reason for each entry, signed off by the security official. Confirm the list against your own environment, since NIST SP 800-66 Rev. 2 describes this as a determination the organization makes.
Select tools for auditing and activity review
Choose the hardware, software or procedural mechanisms that will record these events and let staff examine them. This may be a native application log, a centralized log collector, a SIEM, or a manual review of exported reports for a small system. Record why each tool was chosen, what it captures, how long it keeps data, who can alter or delete entries, and what gaps remain. Open-source log pipelines can meet this need, but you must confirm that each one captures the events listed in step one. The output is a tool decision record that names each system and its logging source.
Develop the activity review and audit policy
Write a policy that states what is logged, who reviews it, how often reviews occur, how anomalies are escalated, and how records are kept. The Security Rule does not set a fixed review frequency, so the policy should state the interval your own analysis supports and explain the reasoning. Link the policy to the risk analysis and to your incident response procedure. The output is a signed policy approved by leadership, with a version date and a review date. Keep it in the Security Rule documentation set so it can be retained for six years.
Write standard operating procedures for each review
Turn the policy into procedures that a reviewer can follow without interpretation. Each procedure should name the log source, the query or report to run, the criteria for a suspicious pattern (for example, access to records of patients with no treatment relationship, or access outside normal shifts), the steps for investigation, and the handoff to incident response. Define how the reviewer records a clean review as well as a finding. The output is a review procedure document for each system class, with an owner and a last-updated date.
Implement the audit and activity review process
Put the policy and procedures into operation: enable the logging, route events to the chosen tool, assign named reviewers with backup coverage, and run the first reviews. Each review should produce a dated record showing the reviewer's name, the systems and period covered, the findings, and the action taken on each finding. Test the chain end to end at least once, for example by generating a known test access and confirming it appears in the review. The output is a set of review records that show the process ran as written. Assessors commonly ask for these records first, because a policy alone does not show that anyone looked at the logs.

Why insider snooping cases show where audit logging failed

Enforcement cases show that the audit control failure is usually a review failure. In the Montefiore Medical Center resolution agreement, OCR paid attention to how an employee's inappropriate access to the information of 12,517 patients went unnoticed, and the settlement of $4,750,000 paid in 2024 reflects findings in risk analysis, information system activity review and audit controls. The lesson for a buyer is that the cited failures were not about having no tooling at all. They were about whether the organization decided what to track, looked at the results and acted on what it saw. Ask your team to show, for a sample of recent months, who reviewed access records for your EHR and imaging systems, how often, and what was done with any exception.

The January 2025 proposed rule, published at 90 FR 898, describes a large provider where employees inappropriately accessed patient account information for six months, and the ePHI of more than 12,000 patients was sold to an identity theft ring. The scenario is useful because the access was repeated over a long period. A single rule-based alert that fires once is not enough to show activity review. Plan for routine review of user access reports against job roles and patient assignments, and treat repeated access to records outside a user's assignments as an incident to investigate, not a log entry to archive. Confirm whether your EHR can produce per-user, per-record access reports on a schedule, since that determines whether the review is practical at all.

Doctors' Management Services, a practice management business associate, agreed to pay $100,000 in 2023 after GandCrab ransomware affected about 206,695 individuals. Intruders entered in April 2017 but were not detected until December 2018, and OCR cited the absence of risk analysis, information system activity review and policies. A detection gap of that length means that whatever was recorded was not being examined in a way that surfaced the intrusion. For vendors and covered entities alike, the question to answer is not only whether logs are kept but who receives alerts, whether anyone reviews the logs that are not alerted on, and how the review is documented. Those documents are what an assessor will request, and the six-year retention rule under 45 CFR 164.316(b)(2)(i) applies to them too.

Who reviews the logs: in-house, outsourced, or shared

This table compares three ways to staff the activity review that 45 CFR 164.308(a)(1)(ii)(D) requires, and what the covered entity or business associate keeps owning under each. Read each row against your own staffing, your log volume and the contract terms you can actually get, because the model you choose does not move legal responsibility for the review.

Option	What it fits	What the organization still owns	What to confirm in the contract
In-house review	Organizations with staff who can read application, identity and network logs and act on what they find	Scope of logged activity, review schedule, the review policy and procedures, documented findings and follow-up, and the security official's oversight	Not applicable; confirm internal log retention meets the six-year documentation expectation for policies and reviews
Outsourced monitoring under a business associate agreement	Smaller teams that cannot staff review around the clock but still hold ePHI in their own systems	Still owns the review specification, the decision to act on alerts, incident response, and evidence that reviews happened	Data location, access to raw logs, retention period, named escalation contacts, subcontractor disclosure, and how records return at termination
Shared model	Organizations that want the provider to collect and triage routine events while staff review high-risk alerts	Defines which events are high risk, reviews escalated alerts, tunes rules, and proves the split works in practice	Which alerts the provider triages versus escalates, timing of escalation, who holds raw logs, and how triage decisions are recorded
Common obligation across all three	Any model that uses an outside party to collect or review logs	Outsourcing review does not transfer responsibility for the activity review specification under 164.308(a)(1)(ii)(D)	Written proof of who reviewed what, when, and what action followed, available to the organization and its assessor

Who does what for audit logs: organization, partner and assessor

The covered entity or business associate owns the Security Rule obligation. Under 45 CFR 164.312(b), the organization must have mechanisms that record and examine activity in systems that contain or use ePHI, and under 45 CFR 164.308(a)(1)(ii)(D) it must regularly review that activity. No vendor or auditor can make those decisions for it, and OCR holds the organization accountable whatever a partner has configured.

Risk analysis: Decide which systems hold or use ePHI and which events, such as record access, privilege changes and failed log-ins, need to be tracked.
Policy and review decisions: Set who reviews logs, how often, what counts as an exception and who acts on it.
Retention: Decide how long log evidence is kept and align it with the six-year documentation retention under 45 CFR 164.316(b)(2)(i).
Incident response: Own the escalation path when a review finds inappropriate access, including breach assessment.
Workforce accountability: Sanction or retrain staff whose access is reviewed as inappropriate.

Check that a named person in the organization can explain what is logged, who reviews it and what happened the last time a review found an exception.

Why audit log projects stall or fail a review

Most audit log failures are not missing tools. They come from gaps in coverage, undocumented review, weak record integrity and unclear ownership. Each card below names one pitfall and the check that prevents it before an assessor or OCR investigator asks.

Logging enabled on the wrong systems

Logging is often switched on for the directory, the firewall and the main EHR, while the file share, the reporting database or the integration engine that actually holds ePHI runs with default settings. The standard in 45 CFR 164.312(b) applies to every information system that contains or uses ePHI, so coverage has to follow the data flow, not the tool inventory. Build a list of ePHI systems from your risk analysis, then confirm for each one which events are recorded, where they go and who can read them.

No documented activity review

The review requirement in 45 CFR 164.308(a)(1)(ii)(D) is a required implementation specification, so a log that nobody reads does not satisfy it. Many programs collect logs well but cannot show a written procedure, a named cadence or a reviewer. Write the review procedure first, covering which reports are examined, what counts as an anomaly and the escalation path, then run it on schedule and keep the output.

Review records without dates or reviewers

A review that exists only as a verbal confirmation or an untitled spreadsheet row is hard to defend. Assessors look for who reviewed, which system and time window were covered, what was found and what happened next. A simple review log with a date, a reviewer name, the source reports, the findings and the disposition gives an investigator a clear trail. Ask your auditor which fields they expect before you design the template.

Logs an administrator can alter unnoticed

If the same administrators who run a system can edit or delete its audit records, the log loses value as evidence of what happened. Forwarding events to a separate log store with restricted write access, and alerting on gaps in event flow or changes to logging settings, makes tampering easier to detect. Confirm with your platform team who holds rights to the log store and how those rights are reviewed.

Unclear ownership between IT and the security official

IT often configures the logs, while the security official is accountable for the review and for the risk analysis that determines what gets logged. When neither side owns the handoff, reports are generated but not acted on. Assign in writing who sets log sources, who reviews them, who investigates a flagged event and who signs off on the results. Keep this assignment in the same policy set as the rest of your Security Rule documentation.

Documentation kept without a retention rule

The six-year retention rule in 45 CFR 164.316(b)(2)(i) covers Security Rule documentation, including written policies, the review procedure and records showing that reviews occurred. It does not set how long raw log data must be kept. Confirm your log retention period with your legal and compliance team, your contracts with covered entities and any state or sector rules, and then document it. Keep the review records and their supporting policies for at least six years from creation or last effective date, whichever is later.

What the proposed audit trail standard would change

The current audit controls standard still applies. The January 6, 2025 proposed rule (90 FR 898, RIN 0945-AA22) would redesignate this safeguard as audit trail and system log controls at proposed 164.312(d)(1), with more specific requirements. As of October 2026, HHS has not published a final rule. The latest Unified Agenda lists the rule under Long-Term Actions with final action projected for July 2027. Until a final rule takes effect, your obligations are the ones in 45 CFR 164.312(b) and the review specification in 164.308(a)(1)(ii)(D), and an assessor will test against those words.

Plan for the proposed detail without waiting for it. Design logging so that the set of recorded events, the retention of those records and the review routine can be extended later through configuration and procedure rather than by rebuilding collection pipelines. In practice, that means confirming that your platform's audit sources, such as application logs, directory events and database access records, can be forwarded to one central store, and that each log source has a documented owner. Ask your implementation partner and platform vendors to confirm which events they can emit and at what granularity, because the proposed text is not final and you should not promise a specific field set to an auditor yet.

Track the rule through the Federal Register proposed rule and the Unified Agenda entry, and reassess your logging design whenever HHS publishes a final version. Record the review date and the version of the rule you assessed against in your documentation, so that your six-year retention of Security Rule documentation under 164.316(b)(2)(i) shows what you relied on at each point in time.

HIPAA audit log questions buyers ask before hiring help

Does HIPAA name the specific events we must log?

No. The Security Rule requires mechanisms that record and examine activity in systems that contain or use ePHI under 45 CFR 164.312(b), but it does not list the events to capture. Your risk analysis decides what is tracked, based on where ePHI lives and how it can be accessed or changed. Most programs start with authentication events, access to records containing ePHI, administrative changes, privilege use, and security-relevant system events, then adjust the list as the risk analysis changes. Ask any partner to show you the reasoning that links each logged event to a identified risk, and confirm the list against NIST SP 800-66 Rev. 2, which describes the planning activities behind it.

Can an outside partner make us HIPAA compliant for audit logging?

No. Your organization owns its controls, and only the organization can decide how audit controls operate and who reviews them. An implementation partner can configure logging tools, build collection pipelines, write procedures and prepare evidence, but that work does not make the organization compliant on its own. HHS states that no Security Rule standard requires certification and that private certifications do not prevent a later violation finding, so no vendor or consultant can issue a HIPAA certificate. Only an independent assessor can report on your controls. Treat any promise of certified compliance as a warning sign.

How long do we have to keep audit logs and related records?

The Security Rule sets a six-year rule for documentation under 45 CFR 164.316(b)(2)(i), which requires retaining Security Rule documentation for six years from the date it was created or the date it last was in effect, whichever is later. That rule covers documentation such as review procedures and records of the review, not every raw log line. The Security Rule does not set a retention period for raw audit logs. Retention for raw logs is set by your audit policy, your risk analysis, your contracts with covered entities or business associates, and any other laws that apply to your sector. Ask counsel and your compliance lead to write the retention schedule, and confirm that your logging platform can meet it.

Can our own team run HIPAA audit log review without outside help?

Yes, if you have the staff, the tools and the time to run the review on a regular schedule. Regular activity review is a required implementation specification under 45 CFR 164.308(a)(1)(ii)(D), so the work cannot be occasional. A small team needs a named owner, documented procedures, a tool that can surface unusual access, and a record of each review and its follow-up. Many organizations keep ownership in-house and hire outside help for a one-time setup, a tool deployment or an independent test of their procedures. Be honest about capacity before deciding, because an unreviewed log stream does not meet the standard.

What does our team need to provide before an audit logging engagement starts?

A well-scoped engagement depends on the organization providing four things:

Read access to the systems that contain or use ePHI, including identity providers, databases, EHR or application servers, and cloud accounts
A current risk analysis or the inputs needed to produce one, so the logged events match identified risks
Named reviewers with defined duties, plus an escalation contact who can act on suspicious access
A decision on the review tool, whether it is an existing platform, an open-source stack or a managed service

The written scope should state which systems are included, what is delivered, and who signs off. Confirm each item with your own environment before work starts, since missing access is the most common source of delay.

What drives the effort and cost of HIPAA audit log work?

The main drivers are the number of systems that contain or use ePHI, the volume of log data they generate, and where those systems run. Each additional system adds integration, parsing, and review scope. High log volume increases storage, search and the effort to separate routine activity from real concerns. Cloud systems often provide native logging that can be connected to a central store, while on-premises systems may need agents, network collection and more hands-on configuration. Costs fall into one-time setup and recurring review, storage and tool licensing. Ask any quote to break these out and to state the systems in scope, the log sources, the retention period and who performs each review. No fixed figure applies across organizations, so the written scope determines the price.

How DeployOpen prepares audit logging and review evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the audit logging and activity review evidence that the Security Rule asks you to produce. We prepare the systems, logs and review records; the organization owns its controls and decides what counts as sufficient.

How we scope

The written scope lists each in-scope system that creates or uses ePHI and the activity it must record.
Scope defines which events are tracked, which tools collect them and who reviews the output.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure logging on in-scope platforms so that access, change and security events are recorded and protected.
Log collection, retention settings and access controls for the log store are implemented and tested within the agreed scope.
Review workflows such as access reports and security incident tracking outputs are set up so your staff can run them regularly.

How we hand over

Deliverables include the audit and activity review policy, standard operating procedures and a record of which events are tracked.
Documentation is written so your security official and an independent assessor can trace each control to its evidence.
Handover covers the review records and retention settings, and we confirm with you what your assessor will need to see.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for logging platforms after handover.
Retainers can cover log pipeline maintenance, changes to tracked events and periodic review of the evidence set.
Your assessor, not DeployOpen, decides whether the evidence meets the requirement; we prepare it for that assessment.