Audit log

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

Audit log, access log, and audit trail differ

Vendors and policies do not use these labels uniformly, and the current HIPAA rule does not separately define them. On this page, an audit log records defined system events. An access log means a narrower log or report focused on access attempts and activity. An audit trail may combine application, identity, database, device, network, export, and administrative records into evidence for a workflow or investigation.

A clinical correction history is related, yet it answers a different question: how a record changed, who changed it, and what earlier content remains available. A practice may need both clinical version history and security activity records. A single login report rarely supplies a complete trail.

HIPAA links recording with examination

The current HHS Security Rule page states that the rule protects electronic protected health information (ePHI) created, received, used, or maintained by a HIPAA covered entity or business associate. Entity status must be determined before treating HIPAA as the governing source.

For regulated entities, 45 CFR 164.312(b) requires hardware, software, or procedural mechanisms that record and examine activity in information systems containing or using ePHI. 45 CFR 164.308(a)(1)(ii)(D) separately requires procedures to regularly review information-system activity records, including audit logs, access reports, and security-incident tracking reports.

Turning on a log meets only part of that need. OCR's Phase 2 HIPAA Audit Protocol, updated July 2018 lists audit criteria including review frequency and documentation, workforce roles, activities needing investigation, timeliness, log capability, and whether key systems generate records. It is an audit aid, not a regulation, current enforcement instruction, or finding about one practice.

Build coverage from systems and risk

Inventory every application, database, identity service, device, integration, cloud service, messaging route, file store, and administrative console that creates, receives, maintains, transmits, contains, or uses ePHI. For each one, record the owner, data, users, service accounts, vendor, available events, configuration, clock source, retention, export route, review process, and testing evidence.

Risk-based events may include:

• successful and failed authentication, session creation, termination, and recovery.
• patient-record creation, view, search, change, correction, deletion, download, print, export, and sharing.
• permission, role, account, authentication, configuration, interface, and logging-control changes.
• privileged, vendor, API, batch, emergency, and service-account activity.
• unusual volume, location, time, device, destination, failure, or access pattern.

For regulated entities, the audit-controls standard applies to activity in information systems that contain or use ePHI. Use the flexibility factors in 45 CFR 164.306(b) and the practice's documented risk analysis to determine reasonable and appropriate mechanisms, event selection, control intensity, and review design, not whether to implement the standard. OCR's January 2026 nonbinding cybersecurity newsletter likewise says risk analysis and risk management can inform audit-control implementation. The current HIPAA rule does not prescribe one universal event list or field schema.

Make each event usable and trustworthy

A useful event usually needs a stable actor or service identity, timestamp with timezone, action, result, source, session or correlation ID, system, affected resource, and relevant organization or tenant. Define fields before collection and test them against real workflows. Shared accounts and an unlabeled “changed” event weaken attribution.

Protect logs as sensitive records. Limit access by role, record access to the logging platform, synchronize clocks, control configuration changes, preserve original evidence, and test whether a privileged actor can disable, alter, or erase records without detection. Exclude passwords, tokens, secret keys, and unnecessary clinical content. Centralization, encryption, tamper evidence, alerts, backup, and separation of duties should follow assessed risk and current requirements.

The 2006 NIST SP 800-92 offers general guidance on log infrastructure and management. It was developed in a federal information-security context and is not itself a HIPAA rule or an ABA-specific standard.

Review anomalies through an incident process

Define alert and review owners, cadence, severity, evidence fields, response target, escalation path, and closure authority. Preserve the query, source records, reviewer, timestamps, reasoning, actions, and outcome. An unusual event may be authorized, mistaken, malicious, or caused by faulty logging. A log anomaly is not automatically a HIPAA security incident or breach. Apply the security-incident definition in 45 CFR 164.304 and the procedures in 45 CFR 164.308(a)(6) to suspected or known incidents. If facts indicate an impermissible acquisition, access, use, or disclosure of PHI, separately evaluate the breach presumption, exceptions, and risk-assessment factors in 45 CFR 164.402.

Set retention by log type and governing source. Under 45 CFR 164.316(b)(2)(i), a regulated entity must retain the Security Rule documentation described in §164.316(b)(1) for six years from creation or from when it last was in effect, whichever is later. The rule's text does not automatically apply that period to every raw operational audit log. Set each log's retention using applicable documentation, state-law, contract, payer, insurance, litigation-hold, clinical-record, and incident requirements; suspend routine deletion for a hold or active investigation.

A fictional control test exposes two gaps

A fictional practice creates 40 approved test events across its identity, EHR, export, and administrator systems. Thirty-seven appear with every required field, so tested event completeness is 37 of 40, or 92.5%. Three remain in the denominator: one service-account event lacks a stable actor identifier, one export event lacks a resource identifier, and one permission-change test produces no central record.

Six alerts are due for review by the test cutoff. Five are reviewed on time, so timely review is 5 of 6, or 83.3%. The late alert stays open with an owner and age. One reviewed alert reflects approved access, one exposes stale access, and three are test artifacts.

These results measure the stated test and review process. They do not prove HIPAA compliance, show that every production event is captured, or establish that a breach occurred. The practice records corrective actions, retests all three failed event types, and preserves the original results.

Measures need a defined unit

Useful controls include:

• required test events recorded with complete fields divided by required test events executed.
• systems with approved logging enabled and successfully tested divided by systems due for testing.
• alerts reviewed within target divided by alerts due by the cutoff.
• privileged and service accounts with an attributable owner divided by accounts reviewed.
• unresolved logging gaps by count, severity, owner, and age.
• retained logs successfully retrieved and validated divided by retention tests attempted.

State the system version, event definition, population, window, exclusions, numerator, denominator, owner, and evidence. Report disabled or unreachable sources separately. Pair percentages with raw counts and investigate whether apparently strong results hide untested systems or weak event definitions.