Under 45 C.F.R. § 164.312(b), you must implement audit controls that record and examine activity in any system holding electronic protected health information. Compliance means two things at once: your logs must capture the right fields, and you must produce dated evidence that someone reviewed them. Retain that documentation for at least six years under § 164.316(b)(2)(i), and be ready to show a role-based access matrix alongside your review artefacts if the Office for Civil Rights comes calling.
TL;DR:
- Logging must include detailed fields such as user ID, action, resource, timestamp, IP address, success status, and purpose of use to ensure comprehensive forensic reconstruction.
- Audit review evidence must be dated, role-specific, and consistently documented, with retention period extending beyond six years if state laws or litigation expectancies demand it.
- Immutable storage solutions and restricted access controls are essential to prevent log tampering and preserve log integrity for legal and regulatory scrutiny.
- Automated, centralized log collection and regular sampling aligned with risk analysis improve review thoroughness and help meet OCR's documentation requirements.
- Failing to demonstrate active review of existing logs often results in enforcement actions, making ongoing, documented examination a crucial compliance step.
Table of Contents
- Statutory basis: what 45 CFR actually demands
- What to capture in audit logs: seven fields OCR expects
- Log retention: the six-year floor and what it really means
- Proving examination: cadence, sampling, and the artefacts that count
- Protecting the logs themselves: immutability and access control
- Turning requirements into a working checklist
- Common audit log formats and standards worth adopting
- Best practices for automating log collection and review
- Penalties and consequences of falling short
- Audit log events that signal a security incident
- Connecting audit logs to incident response and risk management
- De-identification and handling PHI within audit logs
- What assessments actually turn up
- Get audit-ready without rebuilding your logging from scratch
- Sources
Statutory basis: what 45 CFR actually demands
The regulatory text is short, but it carries two obligations most teams treat as one. § 164.312(b) says covered entities must "implement hardware, software, and/or procedural mechanisms that record and examine activity" in systems containing ePHI. That word "examine" is where audits go wrong. Turning on logging satisfies half the standard. Nobody looking at those logs, on a schedule, with notes to prove it, fails the other half.
OCR guidance on audit controls makes this explicit: the standard covers both collection and documented review, not collection alone. Meanwhile, § 164.316(b)(2)(i) sets the retention floor for that documentation at six years from the date it was created or last in effect, a distinction that trips up organisations that assume retention starts when a policy is retired rather than when it was active.
When OCR runs an assessment, the evidence requests tend to follow a predictable pattern:
- A current role-based access matrix showing who can access which systems and why
- Dated review records, whether that's a signed log, a ticket, or a sampling spreadsheet
- Written policies describing the review cadence and escalation path
- Proof that the policy was actually followed, not just written
The OCR audit protocol treats named-user accountability as central. A generic "admin reviewed" note without a date and a name is close to worthless as evidence.
What to capture in audit logs: seven fields OCR expects
Practical implementations converge on the same seven fields, and skipping the first four is what usually renders a log incomplete under § 164.312(b):
- User ID and role — who acted, and under what authority
- Action verb — create, read, update, delete, export, print
- Resource type and ID — which record was touched, referenced by an opaque identifier
- UTC timestamp — standardised time, not local server time, so events correlate across systems
- Source IP and user agent — where the action originated and from what device or application
- Status and success flag — whether the action completed or was denied
- Purpose of use — the reason access was granted, particularly for break-the-glass scenarios
Each field earns its place because forensic reconstruction depends on answering who, what, which record, when, and from where, in that order, without gaps. Miss the timestamp and you can't build a timeline. Miss the resource ID and you can't tell whether someone browsed one chart or fifty.
One detail catches teams out repeatedly: never log PHI content directly. Log opaque identifiers and correlate them through controlled joins against your primary systems, rather than writing patient names or diagnosis codes straight into log entries, which turns your audit trail into another repository of sensitive data requiring its own protection.
Pro Tip: Attach a unique request ID to every transaction at the point of entry, then propagate that ID through every downstream system it touches. When an incident spans your EHR, your identity provider, and a cloud billing tool, that single ID is what lets you stitch the story together in minutes instead of days.
Log retention: the six-year floor and what it really means
Six years is the federal minimum, not a target. § 164.316(b)(2)(i) requires retaining documentation, including audit review records, for six years from the date of creation or the date it was last in effect, whichever is later.
That "last in effect" clause matters more than it looks. A review policy retired in 2024 still needs to be held until 2030, not discarded the moment it's superseded.
A few practical points worth building into your retention policy:
- State law can extend this. Several states set longer retention windows for medical records generally, and your audit logs should follow the longest applicable rule, not the federal floor by default.
- Many compliance teams settle on seven to ten years for audit-log retention specifically, giving margin against state variation and litigation holds without renegotiating policy every time a new engagement starts.
- Store retained logs in immutable, insert-only archives, and document the retention policy itself, since auditors ask for the policy as often as they ask for the logs.
- Apply legal holds before any scheduled deletion runs, particularly once a breach investigation or litigation is reasonably anticipated.
A related governance guide on building a compliance program walks through how retention policy fits into a wider documentation framework, which is worth reviewing if your current policy only covers logs in isolation.
Proving examination: cadence, sampling, and the artefacts that count
Recording activity and examining it are legally distinct requirements, and OCR treats unreviewed logs as one of the most common findings in enforcement actions. A server full of untouched log files proves nothing except that logging was switched on.
A workable review cadence looks something like this:
- Real-time alerting for high-risk signals: after-hours access to VIP or employee records, bulk exports, repeated failed logins, privilege escalation events
- Daily automated summaries flagging anomalies for a named reviewer to triage before the day ends
- Weekly or biweekly sampling of routine access logs against the role-based access matrix, checking that access patterns still match job function
- Quarterly formal audits with a written report, reviewer signature, and any remediation actions logged with dates
Because the HIPAA Security Rule is technology-neutral, it doesn't specify tools or exact frequencies. Your risk analysis is what should set the cadence, which means a hospital with high staff turnover and broad EHR access probably needs tighter sampling than a small billing office with three named users.
What actually satisfies OCR isn't the review itself but the paper trail behind it: dated notes, ticket numbers, escalation records, and a consistent format applied every time, so an auditor can see the same process repeated month after month rather than a one-off scramble before an assessment. The practical steps for assembling that evidence are covered in more detail in this guide to HIPAA audit readiness.
Pro Tip: Keep review artefacts in the same format every time, even a simple dated spreadsheet with reviewer initials. Auditors read consistency as a sign the process is real, not staged. Inconsistent formats read as evidence assembled after the fact.
Protecting the logs themselves: immutability and access control
A log that can be edited after the fact isn't evidence, it's a liability. Immutability is what turns a log file into something an auditor, or a court, can trust.
Several technical approaches achieve this in practice:
- WORM storage (write once, read many) or append-only database tables that reject update and delete operations entirely
- Hash chains, where each log entry incorporates a cryptographic hash of the previous one, making silent tampering detectable
- Insert-only service accounts with no update or delete permissions granted to the logging pipeline itself
Access to the logs needs its own restriction layer, separate from access to the underlying systems. Restrict log access to a small group of named, authorised personnel rather than shared administrative accounts, because audit trails are themselves a target for anyone trying to cover tracks after unauthorised access.
Encrypt logs both at rest and in transit, route log access through its own auditable stream separate from general system logs, and run periodic integrity checks that verify hash chains haven't broken. NIST's logging and monitoring guidance supports centralising this in a SIEM platform, which makes both the immutability controls and the integrity checks far easier to automate consistently.
Turning requirements into a working checklist
Most of what's covered above collapses into four concrete workstreams. Get these right and the rest follows.
- Catalogue every system touching ePHI — your EHR, identity provider, endpoints, and any cloud or SaaS tool that stores or processes patient data, then map which of the seven required fields each system currently captures.
- Implement immutable retention with a documented legal-hold procedure that overrides scheduled deletion the moment litigation or a breach investigation becomes reasonably foreseeable.
- Define reviewer roles and cadence in writing, then maintain dated evidence, tickets, notes, sampling logs, so the review process is demonstrable months or years later, not just remembered.
- Automate correlation where possible. An integrated governance platform can pull logs across EHR, identity, and endpoint systems into one evidence stream, generating the dated review records and access matrix reports OCR actually asks for.
| Requirement | Minimum standard | Common gap |
|---|---|---|
| Audit controls | Record and examine activity per § 164.312(b) | Logging enabled, but never reviewed |
| Retention | Six years per § 164.316(b)(2)(i) | Deleting logs once superseded, not from last-effect date |
| Log fields | Seven fields: user, action, resource, timestamp, IP, status, purpose | Missing resource ID or purpose-of-use |
| Review evidence | Dated, named, repeatable artefacts | Undated or verbal-only reviews |
| Log protection | Immutable storage, restricted access | Editable logs, shared admin accounts |
A parallel resource on audit trail requirements breaks down common inspection failings in more granular detail if you're building this checklist into a formal policy document.
Common audit log formats and standards worth adopting
HIPAA doesn't mandate a specific log format, which leaves interoperability entirely up to you. That silence causes real friction when correlating events across an EHR, an identity provider, and a handful of SaaS tools that each log differently.
Syslog remains the baseline for network and infrastructure events, widely supported and easy to forward into a central collector. CEF (Common Event Format) and LEEF (Log Event Extended Format) are common choices when feeding a SIEM, since both structure fields in a way security tools parse consistently. For healthcare specifically, FHIR AuditEvent resources are worth evaluating if your EHR vendor supports them, because they map naturally onto the who, what, when, and where fields OCR expects, using healthcare-native vocabulary rather than generic IT fields.
JSON-structured logging has become the practical default for custom applications and internal tools, since it's both machine-parsable and human-readable during an investigation, and it plays well with nearly every modern SIEM ingestion pipeline.
The standard you pick matters less than consistency across your environment. A mix of raw text logs from one system, structured JSON from another, and vendor-proprietary formats from a third creates exactly the kind of correlation gap that makes a six-hour investigation take three days. Standardise field names and timestamp formats (UTC, ISO 8601) across every system before you need them for an actual incident, not after.
Best practices for automating log collection and review
Manual log review doesn't scale past a handful of systems, and OCR's expectation of consistent, documented examination is hard to meet by hand once you're running an EHR, an identity provider, several cloud tools, and endpoint monitoring simultaneously.
Centralising collection in a SIEM is the starting point. It pulls logs from every source into one searchable store, applies consistent timestamp normalisation, and lets you build correlation rules across systems rather than reviewing each one in isolation. From there, automation should handle three tiers of work: real-time alerting on genuinely high-risk events, daily automated summaries that flag anomalies for human triage, and scheduled report generation that produces the dated review artefacts auditors expect without someone manually compiling a spreadsheet every week.
Automated alerting only earns its keep when tuned to your actual risk profile. Logging every field on every system and alerting on all of it produces noise that buries the signals that matter, which is precisely the failure mode OCR guidance warns against when it stresses risk-based filtering over blanket collection. Build alert rules around the events your risk analysis actually flags as high-risk, break-the-glass access, bulk exports, off-hours activity on sensitive records, and let routine access flow through periodic sampling instead of real-time alerts.
The review side benefits from automation too. Scheduling recurring sampling jobs against your role-based access matrix, with results routed automatically to a named reviewer and logged with a timestamp, turns "examine" from a monthly scramble into a background process that generates its own evidence trail.
Penalties and consequences of falling short
OCR enforcement actions repeatedly cite the same pattern: logging existed, but nobody could produce evidence it had been reviewed. That gap between recording and examining is where financial and reputational exposure concentrates.
Civil penalties under HIPAA scale by culpability tier, from unknowing violations through wilful neglect that goes uncorrected, and enforcement settlements have specifically named inadequate audit controls and failure to review activity logs as contributing findings. Beyond the direct penalty, an inadequate audit trail undermines your ability to defend yourself during a breach investigation. If you can't produce a dated record showing who accessed a compromised system and when, you lose the ability to scope the breach accurately, which extends notification timelines and investigation costs.
There's a secondary cost that rarely makes headlines: corrective action plans. Once OCR identifies audit control failures, the resulting corrective action plan often mandates ongoing monitoring, external reporting, and repeated attestations for two to three years, a far heavier ongoing burden than the original penalty. Health systems already stretched on compliance staffing feel this most acutely, since a corrective action plan effectively appoints OCR as a permanent second auditor over your logging practices until they're satisfied the gap is closed.
Audit log events that signal a security incident
Certain log entries deserve immediate attention rather than waiting for a scheduled review cycle. Recognising these patterns is what separates a functioning detection process from a log archive nobody reads.
Watch for repeated failed login attempts followed by a successful one, a classic brute-force signature. Access to a patient record by a user with no clinical or administrative relationship to that patient, sometimes called "curiosity access," shows up constantly in real-world investigations and is exactly the scenario purpose-of-use logging is designed to catch. Bulk record exports or unusually large query results, particularly outside business hours, often precede data exfiltration. Privilege escalation events, a user account suddenly granted administrative rights it didn't previously have, warrant same-day review rather than waiting for the weekly sample.
Access originating from an unfamiliar IP range or geographic location, especially combined with a successful login, points to compromised credentials. Multiple password reset requests in a short window, or access patterns that don't match a user's typical working hours, round out the list of signals worth real-time alerting rather than periodic sampling.
Connecting audit logs to incident response and risk management
Audit logs only earn their value when they feed directly into your incident response process, rather than sitting in a separate silo that gets consulted after the fact. The moment an alert fires, whether from automated monitoring or a review finding, your incident response plan should specify exactly which log sources get pulled first and who has authority to request them.
This connection works both ways. Your HIPAA risk assessment should treat audit log coverage as a control being tested, not just a checkbox, asking specifically whether logging currently covers every system in scope and whether the review cadence matches the risk level of each one. Gaps found during a risk assessment, a cloud tool with no logging enabled, a review cycle that's slipped for two quarters, become direct inputs into your risk management priorities for the following cycle.
During an actual incident, logs are what let you answer the two questions regulators and legal counsel ask first: what happened, and who else might be affected. A well-structured log with consistent fields and a propagated request ID can compress a scoping exercise that would otherwise take a forensic team days into an internal exercise measured in hours. That efficiency is also why maintaining a current role-based access matrix pays off during incident response, since it lets you immediately distinguish between "this access was authorised" and "this access needs investigating" rather than starting that determination from zero.
De-identification and handling PHI within audit logs
Audit logs occupy an odd position: they exist to track access to PHI, but they shouldn't contain PHI themselves. Get this wrong and your logging system becomes a second, less-protected copy of the exact data you're trying to safeguard.
The practical fix is to log opaque identifiers, patient record numbers or internal database keys, rather than names, diagnoses, or other clinical detail, then resolve those identifiers back to meaningful information only through a controlled join against your primary system, restricted to authorised personnel with a legitimate need. This keeps your log store useful for forensic reconstruction without turning it into a target that, if breached, exposes clinical detail on top of the original incident.
De-identification in the formal HIPAA sense, removing the eighteen identifiers under the Safe Harbor method, generally isn't necessary for operational audit logs, since the logs need to remain reversible for investigation purposes. What matters more is minimising what's captured in the first place: log the fact that record 48213 was accessed, not what that record contains. If your logs must be shared with a third party for analysis or a vendor audit, that's the point where genuine de-identification or aggregation becomes necessary, since the sharing itself creates a new disclosure that needs its own justification under the Security Rule.
What assessments actually turn up
Across compliance assessments, one finding shows up more than any other: logs exist, but nobody can produce a dated record showing they were reviewed. That single gap accounts for a disproportionate share of audit-control findings.
The second most common weakness is mutable log storage paired with shared administrative accounts, a combination that makes it nearly impossible to prove logs haven't been altered after an incident. Neither problem is expensive to fix. Enabling append-only logging, restricting log access to named individuals, and scheduling a documented sampling review, even a modest weekly one, closes most of the gap within a matter of weeks, not months.
— Peter
Get audit-ready without rebuilding your logging from scratch
Specialist consultancies build the specific artefacts OCR asks for: a current role-based access matrix, dated review records, and immutable retention policies that hold up under an actual assessment, not just a checklist review. Rather than handing you a policy template and leaving, some consultancies aim to integrate directly with your existing systems and staff to get the evidence trail working in practice, not just on paper.
The Videra platform automates the parts that break under manual effort: pulling logs across your EHR, identity provider, and cloud tools into one correlated evidence stream, generating the dated sampling reports auditors expect, and flagging the seven-field gaps before an assessor finds them first. For hospitals and health systems juggling lifecycle governance alongside compliance reporting, the underlying platform architecture extends the same automated evidence collection across project and asset workflows, not just audit logs.
If your last audit turned up unreviewed logs or a missing access matrix, that's a fixable gap, not a rebuild. Request an assessment and find out exactly where your current logging stands against § 164.312(b) before your next OCR review does.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.