Audit Logging for HIPAA: Building Access Logs for Employee Health Data

Most HIPAA investigations come down to one question: who accessed this record, and when? HIPAA audit logging and reliable access logs exist to answer it. If your employee-health system can name the user, stamp the time, and point to the specific record that was touched, you can respond with confidence. If it only tracks who changed a record and stays quiet about who merely viewed an employee's SSN or exported a roster, you have a gap that encryption will not paper over.

Occupational health records are PHI when your clinic or facility handles them as a covered entity or business associate. The audit-log obligations below apply to your exam records, immunization histories, exposure files, and everything else sitting behind your employee-health platform.

HIPAA audit logging and access logs: why the rules exist

HIPAA never uses the phrase "audit log" as a mandate. The obligation is stitched together from a few Security Rule provisions and one Privacy Rule provision. Once you see how they interlock, the compliance picture gets clearer, and considerably more demanding than "keep some logs somewhere."

The whole point is accountability. If an employee alleges that a coworker in HR pulled up their positive drug screen, or if the HHS Office for Civil Rights (OCR) shows up after a breach, the access trail is the evidence. With no trail, you have no defense.

The exact rules: audit controls and activity review

Four provisions do the work here.

Audit controls, 45 CFR 164.312(b). This is the source of the logging mandate. It requires covered entities to "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." It is a standard with no separate implementation specification, which means it is not "addressable." It is simply required. You must record activity, and you must be able to examine it.

Unique user identification, 45 CFR 164.312(a)(2)(i). A required specification: "assign a unique name and/or number for identifying and tracking user identity." This is the piece that lets an audit log actually answer "who." Shared logins, like the front-desk clinic1 account that everyone uses, defeat the purpose. If four nurses share one credential, your log can never attribute an access to a person.

Information system activity review, 45 CFR 164.308(a)(1)(ii)(D). Also required. You must "implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." This is the provision people forget. Retention alone falls short; HIPAA requires you to review the logs on a schedule.

Log-in monitoring, 45 CFR 164.308(a)(5)(ii)(C). This one is "addressable," which trips people up. Addressable does not mean optional. It means you either implement it, adopt a documented equivalent, or write down why it is not reasonable and appropriate for your setup. The spec itself calls for "procedures for monitoring log-in attempts and reporting discrepancies," such as repeated failed logins on a manager's account at 2 a.m.

HIPAA access log requirements: what a log must capture

The rules tell you to record activity but stop short of listing fields. For the specifics, HHS points regulated entities to NIST. Its referenced implementation guide, NIST SP 800-66 Rev. 2, published in February 2024, maps Security Rule requirements onto the NIST SP 800-53 audit control family. The relevant control, SP 800-53 AU-3 "Content of Audit Records," describes the elements a well-formed audit record should contain.

Applied to an employee-health system, each logged event should generally capture:

• Who — the unique user ID behind the action (see 164.312(a)(2)(i))
• What — the type of event or action taken
• When — date and time
• Which record — the affected employee record or resource
• Where from — source origin, such as IP address or workstation
• Outcome — success or failure

One detail separates a real HIPAA access log from a plain change log: it has to record reads, exports, prints, and downloads, alongside create and update events. Viewing an employee's PHI is an access. A system that captures only writes cannot tell you who viewed a given employee's SSN, and it will not satisfy 164.312(b) read together with the review requirement in 164.308(a)(1)(ii)(D).

That is a common blind spot in occupational-health software. Someone runs a demographic export of 400 employees, or opens the exposure file on a specific nurse, and nothing is recorded because no data changed. To OCR, an unlogged export of PHI is an access you cannot account for.

How long to keep audit logs

Be careful here, because a lot of vendors overstate this. No HIPAA regulation literally says "retain audit logs for six years." Here is what the text actually says:

• 45 CFR 164.316(b)(2)(i) requires you to keep Security Rule documentation, meaning policies, procedures, and required assessments and actions, for six years "from the date of its creation or the date when it last was in effect, whichever is later."
• 45 CFR 164.528 gives individuals the right to an accounting of disclosures of their PHI for the six years prior to a request.

Neither one is a verbatim "keep logs six years" mandate. Between the documentation clock and the six-year accounting window, though, six years is the de facto floor that most compliance programs adopt for the log data itself, and it is the practical target to build to. State law can push it further. Several states require longer medical-record retention, and the logs describing those records should generally outlive them.

Reviewing logs, not only storing them

Set a cadence and write it down, because 164.308(a)(1)(ii)(D) makes review a genuine requirement. A workable pattern for a small occupational-health shop:

• Weekly: scan for failed-login spikes and after-hours access to sensitive records.
• Monthly: run a "same-name" check. Did any user access a record matching their own last name or department? This catches the curious-coworker problem, one of the most common PHI complaints in employee health.
• On trigger: any time an employee files a privacy complaint, pull the full access history on their record before responding.

Log the review itself. A line like "Reviewed audit logs, no anomalies, [initials], [date]" turns an invisible task into documentation you can produce later.

How logs prove compliance to OCR

When OCR investigates a complaint or breach, the audit log is your evidence. The 164.312(b) mandate to record and examine, combined with the 164.308(a)(1)(ii)(D) mandate to review, means the log has to be both complete and actively used. Failing to produce an access trail is a finding in its own right; to an investigator it reads as a controls failure rather than a neutral gap. Tamper-resistance matters too. A log that a user can edit or delete is not reliable evidence.

What's changing (proposed, not yet law)

On January 6, 2025, HHS/OCR published a Notice of Proposed Rulemaking to strengthen the Security Rule. If finalized, it would largely remove the "addressable versus required" flexibility, making specifications like encryption expressly required with limited exceptions, and it would more explicitly codify monitoring and review of system activity. It remains a proposed rule for now. The 2013 Omnibus-era text quoted above is what is enforceable today. Build to the current rules, and design your logging on the assumption that review and monitoring expectations only get stricter.

FAQ

Do we have to log when someone just reads a record? Yes. A HIPAA access log has to capture reads, exports, and downloads of PHI, alongside edits. A system that logs create and update only cannot answer "who viewed this," which is exactly what OCR asks.

Is six-year log retention actually required? Not verbatim. 164.316(b)(2)(i) requires six years for Security Rule documentation, and 164.528 sets a six-year disclosure-accounting window. Six years is the practical floor, and state law may require more.

Are shared logins ever acceptable? No. 164.312(a)(2)(i) requires unique user identification. Shared accounts make attribution impossible and undermine the whole audit trail.

If you are evaluating whether your employee-health system meets this bar, try one test: ask it who viewed a specific employee's record last month, and see whether it returns names, timestamps, and the actions taken. A read-level access trail, retained for years and reviewed on a schedule, is what separates passing an OCR review from explaining why you cannot.