Audit Logs for Dental Software: What an OCR Investigator Looks For

Under HIPAA, an audit log is the record your systems keep of who did what, when, and to which information that touches electronic protected health information (ePHI = electronic protected health information). The Security Rule requires the mechanisms that create and examine those records, not just the records themselves. For a dental practice, that obligation reaches every system in your software stack — including the tools that manage your software licenses.

Most practice owners assume their practice-management system (PMS) covers this. It covers part of it. When OCR — the HHS Office for Civil Rights, the agency that enforces HIPAA — opens an investigation, the requests it sends often reach past patient-record access into territory that no PMS records. This article walks through what the rule actually requires, what an investigator asks for, and the specific evidence gap that leaves otherwise careful practices exposed.

What HIPAA means by "audit controls"

The relevant text is short. The HIPAA Security Rule's audit-controls standard, at 45 CFR §164.312(b), requires covered entities and their business associates to "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

Two words carry the weight: record and examine. It is not enough to capture activity. You also have to look at it. And the scope is defined by where ePHI lives — "information systems that contain or use" it — which in a dental office is rarely a single application. It is the PMS, the imaging software, the workstations they run on, and the tools that activate and control all of them.

The standard is one of the technical safeguards in §164.312. HIPAA does not prescribe a specific technology or log format; it is deliberately flexible so a solo practice and a hospital can both comply at their own scale. That flexibility is not an exemption. It means you choose the mechanism — but you still have to have one, and you have to be able to show it works.

Audit log vs. audit trail vs. activity review

These three terms get used interchangeably, and that imprecision hides where practices fall short. They are different things.

• Audit log — the raw record of events a system produces: individual entries, each capturing an action and its context.
• Audit trail — the connected sequence of those entries that lets you reconstruct what happened across a session or a record over time. A trail is what turns scattered log lines into a story an investigator can follow.
• Information system activity review — the human (or tooled) practice of actually examining logs and reports for anomalies.

That third item is its own HIPAA requirement, and it is easy to miss because it lives in the administrative safeguards rather than the technical ones. The information system activity review standard, 45 CFR §164.308(a)(1)(ii)(D), requires you to "implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports."

Read those two provisions together and the obligation is plain. The technical control under §164.312(b) makes the logs. The administrative review under §164.308(a)(1)(ii)(D) makes someone look at them. A practice that generates logs but never reviews them satisfies the first standard and fails the second — and an investigator can tell the difference by asking for your review records.

What an OCR investigator actually requests

OCR investigations typically begin one of two ways: a breach report you filed yourself, or a complaint someone else filed. In either case, the data request that follows is specific. Based on OCR's published enforcement actions and resolution agreements, investigators commonly ask for evidence that falls into three buckets.

• Access records. Who accessed what ePHI, and when. This is the area your PMS most likely covers — patient-record opens, edits, and exports tied to a named user.
• Configuration and permission changes. When a user was granted access, when permissions changed, when accounts were created or disabled. Investigators look here to see whether access was appropriate and whether it was promptly removed when it should have been.
• Software and license lifecycle events. When software that handles ePHI was installed, activated, deactivated, renewed, or moved to a different machine or user. This is the bucket most practices cannot answer.

That last bucket is the one worth dwelling on. A new install of imaging or practice-management software puts a new system that touches ePHI into service. A license reassigned from a departed hygienist to a new one changes who can reach patient data. An expired license that gets reactivated brings a system back online. Each of those is exactly the kind of activity §164.312(b) contemplates — and in most offices, none of it is recorded anywhere.

Where dental practices fall short

The gap is structural, not careless. A PMS logs activity inside the PMS. It records that Dr. Lee opened the Martinez chart at 9:14 a.m. What it cannot record is the act of installing a second copy of the imaging software on a new operatory workstation, because that install happens outside the application — at the operating system and license level, where the PMS has no visibility.

So when a practice that has carefully kept its software inventory and mapped its practice software stack is asked, "When was this application installed on this machine, and who authorized it?" the answer is often a shrug. The events exist — software got installed, a seat got reassigned, an expired license got reactivated — but they were never logged. That is an evidence gap, and an evidence gap is hard to explain to an investigator who is trying to establish a timeline.

The fix is not another monitoring product or an outside IT service. It is making sure the lifecycle of every licensed application is recorded the same way patient-record access already is: automatically, with an actor and a timestamp, in a form you can produce on request.

What a defensible audit log captures

Whatever system you use, a defensible entry answers the same five questions for every event. If your logs can fill in this table for a license or software change, you can answer the lifecycle questions an investigator raises.

Notice the "before → after" column. An entry that says only "license changed" is weak. An entry that shows the prior state and the new state lets an investigator reconstruct the trail without interviewing your staff. This is where a purpose-built license vault helps: because ProLicensor is the system performing each activation, renewal, deactivation, and reassignment, it can record every one of those events with the actor and timestamp attached, and export the result as a tamper-evident log. It does not watch your network or your patient records — it documents the software-license lifecycle that other tools leave blank.

How long to keep logs

HIPAA's documentation-retention requirement is the rule that sets the clock. 45 CFR §164.316(b)(2) requires you to retain required documentation "for 6 years from the date of its creation or the date when it last was in effect, whichever is later."

The Security Rule does not state a separate fixed lifespan for raw audit-log data the way it does for documentation. But the practical answer for most practices is the same six years, for a clear reason: your logs are the evidence behind the information system activity reviews you are required to document under §164.308(a)(1)(ii)(D). If you must keep the review records for six years, the underlying logs need to be available to support them. Discard the logs early and your review documentation has nothing to stand on.

What to retain, concretely: the lifecycle events for every licensed application that touches ePHI — installs, activations, deactivations, renewals, and reassignments — with actor, timestamp, and before/after state intact, plus the dated records showing you reviewed that activity. Keep them in an exportable form so that producing six years of history on request is a download, not a fire drill. You can see how this fits the rest of a defensible posture on the security overview.

None of this requires turning your practice into an IT shop. It requires knowing which systems touch patient data, recording what happens to those systems over their lifecycle, reviewing that record on a regular cadence, and keeping it long enough to answer the questions an investigator is trained to ask.