HIPAA Audit Controls: Logging and Reviewing Who Accessed ePHI

Picture the way a small practice usually discovers this kind of problem. A patient calls, upset, asking why someone at the front desk — a neighbor, as it turns out — seemed to know about a diagnosis she had never discussed with them. The owner is certain the systems are secure. Multi-factor authentication is on. The electronic health record is hosted by a reputable vendor. And yet the answer to “who opened this chart, and why” is sitting in a record no one at the practice has ever looked at.

That record is an audit log, and the safeguard that governs it is one of the most quietly important — and most commonly half-finished — requirements in the HIPAA Security Rule. HIPAA audit controls are the controls that let you answer a deceptively simple question: who touched this patient’s data, when, and from where. In our experience, most small practices have the first half of that capability switched on by default and have never used the second half at all.

This guide is the companion to our recent piece on auditing third-party app access to your healthcare SaaS, which ended on a line worth taking seriously: turn on the logs your platforms already offer, and build a habit of glancing at them. This is that habit, explained in full.

What the Security Rule Actually Requires

The HIPAA Security Rule names audit controls as a standard in its own right. Under 45 CFR § 164.312(b), a covered entity or business associate must “implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”

Two verbs carry the entire requirement: record and examine. Recording is the log — the automatic ledger your systems keep of who signed in, what they opened, and what they changed. Examining is the part where a human being actually looks. The rule requires both, and it reinforces the second half elsewhere. A separate administrative provision, the “information system activity review” at 45 CFR § 164.308(a)(1)(ii)(D), directs practices to “implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.”

A word on how the rule is structured, because the labels matter. Audit controls in § 164.312(b) is a standard — a mandatory requirement with no optional implementation specifications beneath it. The information system activity review is a required implementation specification. Both are mandatory; neither is one of the rule’s “addressable” items. “Addressable” does not mean optional — it means you assess whether the named control is reasonable and appropriate for your practice and, if it isn’t, implement an equivalent alternative and document that reasoning. (The related log-in monitoring specification at § 164.308(a)(5)(ii)(C) is addressable in that sense.) The core of audit controls — record activity, and review it regularly — is required outright.

An audit log nobody reads is not a security control. It is a record of everything you could have caught and didn’t.

That distinction is where practices tend to fall short. The logging is on, because modern systems log by default. The reviewing is not, because nobody was ever assigned to do it and no cadence was ever set. The Security Rule treats regular review as part of the requirement, so leaving it undone leaves the safeguard incomplete.

Recording Versus Reviewing: Where Practices Fall Down

It helps to separate the two jobs plainly, because they fail for different reasons.

Recording is mostly a configuration question. Does your electronic health record keep an access log? Does your Microsoft 365 or Google Workspace tenant have its audit log turned on and set to retain data long enough to be useful? Are your firewall and remote-access tools writing their events somewhere that survives a reboot? For most small practices, recording is a matter of confirming defaults and closing a few gaps — an afternoon of settings review, not a purchase.

Reviewing is a discipline question, and it is harder, because it never feels urgent. A log you never read causes no visible problem — right up until the day it becomes the evidence in a breach investigation, and the absence of any review history becomes hard to explain. This is the same pattern we describe in why a HIPAA risk analysis cannot be a checkbox: the control that gets skipped is always the one whose absence stays invisible until it is serious.

Think of it like the security camera over a pharmacy counter. Installing the camera is recording. It deters some problems and captures the rest. But if no one ever reviews the footage, the camera cannot tell you that the same person has been coming back every Tuesday — it can only, after the fact, confirm what you already suspect. The value of the footage is realized in the watching, not the recording. Audit logs are identical.

The Systems That Actually Matter

“Audit controls” can sound like an enterprise concern involving a wall of monitors. For a small practice, it is far more concrete: a handful of systems generate logs that matter, and knowing which ones — and what each is good for — is most of the battle. You cannot review what you have not first located, which is why an honest asset inventory and network map is the natural starting point.

• Your electronic health record. The single most important log in the building. EHR audit logs record which user opened which patient’s chart and when. This is the log that answers the snooping question, and it is the one practices check the least.
• Microsoft 365 or Google Workspace. Your email and document platform records sign-ins, administrator changes, and — critically — the third-party app consents we covered in the OAuth access guide. This is where you see a staff member’s account signing in from a country you don’t operate in, or a new application quietly granted permission to read every mailbox.
• Endpoint protection. Your EDR or antivirus platform logs what ran on each workstation and what it blocked. It is often the earliest signal that a device has been compromised.
• Firewall, VPN, and remote-access tools. These record who connected to your network from outside and when. Remote-access tools in particular are a favorite attacker pathway, and their logs are where an unexpected 3 a.m. session shows up.
• Your backup system. Backup logs tell you whether the job that is supposed to protect you actually ran — and whether someone tried to delete or alter it, which is a hallmark of a ransomware attack in progress.

Each of these logs answers a different question. Together they are the difference between finding out about a problem in hours and finding out about it much later, from someone outside the practice.

The Reason This Matters More in Healthcare: Catching Snooping

Most industries think about audit logs as a way to catch outside attackers. Healthcare has a second, more uncomfortable use that the corporate world rarely faces: audit logs are one of the few things that surface your own people looking at records they had no business opening.

It is one of the oldest patterns in health privacy. A staff member looks up the chart of an ex-partner, a neighbor, a coworker, a local public figure, or a family member going through something private. No malware is involved. No password was stolen. A legitimately authorized user simply opens a record that has nothing to do with their job — impermissible access of exactly the kind the “minimum necessary” principle exists to prevent, and the kind of internal misuse the activity-review requirement is meant to help surface.

The EHR audit log is the control most likely to catch this. Your firewall won’t see it — the access came from inside. Your MFA won’t stop it — the person is a real, authorized user. Preventive measures like role-based access help narrow what staff can reach, and a patient complaint sometimes surfaces it after the fact, but the reliable detective control is a log that records chart access and a person who periodically reads it. That is not about assuming the worst of your team; the staff who protect patient privacy every day are, as we’ve written before, the most powerful security control a practice has. It is about the fact that the misuse technology can’t fully prevent is the one you most need a way to detect.

A Practical Logging and Review Matrix

Here is the core of this guide as a reference you can put to work. The retention figures below are suggested starting points, not legal requirements — right-size them to your own risk analysis, vendor contracts, applicable state law, any litigation hold, and your counsel’s guidance. The point is that every system has an owner and a cadence, not that these exact ones are law.

Work through it system by system. For each one, know what the log should capture, the red flags worth watching for, who owns the review, and a sensible starting point for how long to keep the records.

Electronic health record — the log that answers “who opened this chart.”

• Capture: chart access by user and patient; record changes; exports and prints.
• Watch for: access to VIP, employee, or family-member records; unusually large exports; after-hours access.
• Review: the privacy or security official — monthly, and on any tip.
• Keep (suggested): about six years.

Microsoft 365 or Google Workspace — sign-ins, admin actions, and app consents.

• Capture: sign-ins; administrator changes; new third-party app consents; mailbox rules.
• Watch for: sign-ins from unexpected locations; new OAuth grants; auto-forwarding rules.
• Review: the practice admin or IT partner — a weekly skim, with alerts on anomalies.
• Keep (suggested): a year or more.

Endpoint protection (EDR / antivirus) — what ran on each device, and what got blocked.

• Capture: detections; blocked executions; policy changes.
• Watch for: repeated detections on one device; protection switched off.
• Review: the IT partner — weekly, with alerts on detections.
• Keep (suggested): about a year.

Firewall, VPN, and remote access — who reached the network from outside.

• Capture: inbound connections; remote sessions; account use.
• Watch for: off-hours sessions; new source countries; disabled accounts still connecting.
• Review: the IT partner — weekly, with alerts on anomalies.
• Keep (suggested): about a year.

Backup system — proof the safety net actually ran.

• Capture: job success and failure; deletion or configuration changes.
• Watch for: failed jobs; attempts to delete or alter backups.
• Review: the IT partner — weekly, alongside restore tests.
• Keep (suggested): about a year.

Cadence deserves the same caveat as retention: the Security Rule requires review “regularly” but sets no universal frequency. Monthly and weekly are sensible defaults for a small practice; a higher-volume or higher-risk environment may need more, and a review schedule is not by itself proof that your review is adequate. Let risk, system criticality, and any alerts drive how often and how deeply you look.

How Long to Keep the Logs

Two different clocks are at work here, and conflating them causes real confusion.

The Security Rule’s well-known six-year rule, at 45 CFR § 164.316(b)(2)(i), requires you to retain the documentation the rule requires — your written Security Rule policies and procedures, and the actions, activities, and assessments the rule specifically says to document — for six years from creation or last effective date. Your written audit-control policy clearly falls under that obligation. Keeping evidence that reviews actually happened is prudent and genuinely useful in an audit, but treat it as a practice worth confirming with counsel rather than as a categorical six-year mandate the text spells out.

The retention of the raw log data itself is a separate, risk-based decision the Security Rule does not pin to a single number. In practice, longer is safer, because breach investigations routinely reach back further than you expect — the Medtronic-linked breach we wrote about traced intrusions across many months. For the record that answers “who accessed this chart” — the EHR log — six years is a defensible anchor, both because it aligns with the documentation horizon and because that is roughly how far back a serious inquiry may ask.

Here is the trap: your platform’s default retention is often far shorter than that. Some platforms retain audit data for only a limited window unless you extend it, which can depend on your plan or require an export routine — so confirm your specific product’s current behavior rather than assuming. A log that has already rolled off is a log you cannot review. Decide your retention period deliberately, write it down, and then verify the system is actually configured to hold data that long.

Reviewing Without a Security Operations Center

The phrase “review your audit logs regularly” can conjure an image of an expensive platform and a dedicated analyst. A small practice needs neither. It needs the logs turned on, a short and repeatable routine, and the honesty to actually run it.

A realistic monthly rhythm looks like this:

1. Turn on what’s off. Confirm the EHR audit log is enabled, your Microsoft 365 or Google Workspace audit log is on and set to retain for your chosen period, and endpoint, firewall, and backup logging are all active. This is a one-time setup task with an annual re-check.
2. Let the platform watch the noisy stuff. Many platforms can alert you automatically — check what yours offers and turn on alerts for risky sign-ins, new app consents, and mail-forwarding rules. Letting automation handle high-volume monitoring keeps a human from having to read every line — the same instinct behind device-code phishing defenses, which live or die on someone noticing an unusual sign-in.
3. Do a small, deliberate human review. Once a month, spend a focused block on the things automation can’t judge: pull the EHR access report and spot-check for staff who opened records outside their role, look at the week’s admin changes, and glance at any after-hours remote sessions. You are not reading everything. You are looking for the handful of things that don’t fit.
4. Write down that you looked. A one-line note — date, who reviewed, what was checked, anything flagged — is what turns “we have logs” into “we review them,” and it is the kind of record that helps demonstrate you actually operate the control.

None of this requires an enterprise budget. It requires a named owner, a recurring calendar entry, and the discipline to keep it boring.

Common Mistakes

The failures here are consistent enough to list, because in the field we tend to see the same handful.

• Logging is on; reviewing never happens. The most common gap we see. The data exists, but no one has ever been assigned to look, so nothing is caught early.
• The EHR audit log is never checked. Snooping can go undetected for a long time when the one log that would reveal it is never opened.
• The Microsoft 365 audit log wasn’t enabled, or its retention was left at the default. Practices sometimes discover during an incident that the records they need aged out weeks earlier.
• No retention policy. Without a deliberate decision, logs roll off on the vendor’s schedule, not yours — and that schedule is often shorter than an investigation’s reach.
• Logs are consulted only after an incident. Treated purely as after-the-fact evidence, an audit log loses its most valuable role: catching the slow-building problem before it becomes a breach.

It is worth noting where this may be heading. The Security Rule update proposed by HHS in early 2025 would make logging and review expectations more explicit. As we covered in our breakdown of what the 2026 landscape means for small practices, that proposal is not yet enforceable, and the current rule governs your obligations today — HHS has been clear that the existing Security Rule remains in effect. Building the review habit now is simply good practice regardless of the final rule’s shape.

The Byzantine Takeaway

HIPAA audit controls are a required safeguard with two halves, and in practice most do only the first. Recording — keeping the logs — happens by default. Examining — actually reviewing them — is the part that gets skipped, because a log nobody reads causes no visible problem until the day it becomes the evidence you wish you had. In healthcare, that log has a job few other controls can do: it is the most reliable way to surface a trusted, authorized user looking at a record they had no reason to open. You do not need a security operations center to close this gap. You need the logs turned on, a named owner, a modest monthly habit, and a one-line note that you looked. That is boring, unglamorous operational hygiene — which is precisely why it works, and precisely the kind of control that strengthens your security posture and supports your HIPAA Security Rule efforts.

Where to start: this month, confirm your EHR access log and your Microsoft 365 or Google Workspace audit log are both on and retaining data, then pull one month of EHR access and read it once, looking only for chart access that doesn’t match someone’s job. It is a small exercise that often surfaces something worth a conversation — and it starts the habit that turns a pile of logs into an actual control. For the connected view of who and what can reach your data in the first place, read the companion guide on auditing third-party app access, and for what to do the moment a review turns something up, see what happens in the first 24 hours of a HIPAA incident. Our full set of Security Rule guides lives in one place: the HIPAA Security Rule resource hub.

This article is intended for general informational purposes and does not constitute legal advice. Practices should consult qualified HIPAA counsel regarding their specific obligations.