HIPAA audit logs: what to record and keep

The HIPAA audit controls standard is one sentence long. It asks you to record and examine activity in systems that contain or use electronic protected health information (ePHI). It does not name an event, a field, a tool, or a retention period.

Teams read that silence in one of two ways. Some log everything and keep it forever. Others accept whatever their platform logs by default. Neither holds up well when a hospital's security reviewer, or an investigator from the HHS Office for Civil Rights, asks who looked at a specific patient's record last March.

This article covers what the Security Rule actually says about logs, which events a SaaS product handling ePHI should record, what a usable entry contains, how review should work, and how to set retention when the rule is silent. For where audit controls sit among the other technical safeguards, start with HIPAA technical safeguards for SaaS teams.

What the Security Rule requires #

Three provisions in 45 CFR Part 164 govern logging directly:

• Audit controls, §164.312(b). A standard with no implementation specifications, so it is required. You must implement "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

• Information system activity review, §164.308(a)(1)(ii)(D). Required. You must implement procedures to regularly review records of system activity, such as audit logs, access reports, and security incident tracking reports.

• Log-in monitoring, §164.308(a)(5)(ii)(C). Addressable. Procedures for monitoring log-in attempts and reporting discrepancies.

Two more provisions decide whether your logs mean anything. Unique user identification, §164.312(a)(2)(i), is required: without it, a log can only say that a shared account did something. The integrity standard, §164.312(c)(1), requires protecting ePHI from improper alteration or destruction, and logs often contain ePHI.

Notice what is absent. There is no event list and no retention period. That is deliberate. Section 164.306(b) lets you choose measures based on your size, complexity, infrastructure, costs, and risks. In practice, your risk analysis is the document that justifies what you log.

Which systems are in scope #

The standard covers systems that "contain or use" ePHI. For a typical SaaS product, that reaches further than the production database:

• The application itself, where users view and change records

• Object storage holding uploaded documents or images

• Analytics copies, data warehouses, and reporting replicas

• Backups and snapshots

• Support and admin tooling that can display customer records

• The identity provider that controls access to all of the above

• The cloud control plane, because anyone who can snapshot a database can copy the ePHI in it

People tend to forget one more: the log pipeline. If request bodies or query strings land in your logs, your logging platform now contains ePHI and is in scope. The cleaner fix is to log record identifiers rather than record contents, so the log proves access without repeating the data.

What to record #

Think in three layers. Each answers a different question an investigator might ask.

Application events #

This is where most programs are thin. Infrastructure logs show that a database was queried. They rarely show which user, acting in your product, opened which patient's record. Record:

• Views of patient records, not only changes (reads are the most commonly missing event)

• Creates, updates, and deletes

• Exports, downloads, prints, and bulk queries

• Sharing and permission changes inside the product

• Support staff or administrators accessing a customer's data

• Emergency access, if you have a break-glass path under the emergency access procedure at §164.312(a)(2)(ii)

Identity events #

• Successful and failed log-ins, including MFA failures

• Account creation, role changes, and deactivation

• Password and MFA resets

Infrastructure events #

• Cloud API calls, especially those touching storage, snapshots, and keys

• Direct database sessions and queries run outside the application

• Changes to logging configuration, including any log source being disabled

What a usable entry contains #

An event that cannot be attributed or placed in time is close to useless. For each entry, capture:

• Not done:

  Who: a unique user ID, never a shared account

• Not done:

  For whom: the customer or tenant the record belongs to

• Not done:

  What: the action taken

• Not done:

  Which record: an internal identifier, not the patient's name

• Not done:

  When: a UTC timestamp from a synchronized clock

• Not done:

  From where: source IP address and session or device identifier

• Not done:

  Outcome: success or failure

NIST SP 800-66 Rev. 2, NIST's resource guide for implementing the Security Rule, discusses audit controls in more depth and is a sensible companion to your own analysis.

Reviewing logs without drowning in them #

The rule says "regularly review." Nobody expects a person to read raw logs daily. What a reviewer expects is a defined process that produces a record. A workable version looks like this:

1. Alert on specific patterns. Bursts of failed log-ins, access across tenants, bulk exports, use of break-glass accounts, activity by deactivated users, and any logging source going quiet.

2. Route every alert to a named owner with a ticket, so there is a trail from detection to resolution.

3. Review access reports on a schedule for the highest-risk users: support staff, administrators, and anyone with direct database access.

4. Record the review. Date, reviewer, what was examined, what was found, and the follow-up tickets. This record is the evidence; the logs are not.

The common failure is an alerting setup that fires into a channel nobody owns. An alert nobody acknowledges is not a review. The security monitoring and alerting article covers routing and triage in more detail.

Build one query before anyone asks for it: every access to a given patient's records, by user, over a date range. A covered entity investigating a patient complaint may ask its business associates for exactly this, and producing it slowly reads as not having it.

How long to keep logs #

The Security Rule does not set a retention period for audit logs. What it does set is a documentation requirement. Under §164.316(b)(2)(i), you must keep the documentation the rule requires for six years from the date of its creation or the date it was last in effect, whichever is later. That covers policies, procedures, and written records of actions, activities, and assessments the rule requires you to document.

Whether every raw log line counts as that documentation is a matter of interpretation, and you should confirm your position with counsel. A common and defensible split is to treat review records as documentation and keep raw logs for a period your risk analysis sets.

The last row deserves attention. Under §164.414, a covered entity or business associate carries the burden of showing that a use or disclosure was not a breach. If your logs are what show that an exposed record was never opened, keep them with the incident file, not on the normal expiry schedule.

Check your business associate agreements too. Customers often write their own log retention expectations into them, and those become your obligation.

Protecting the logs themselves #

Logs are evidence only if nobody could have quietly changed them. Treat them like any other system holding ePHI:

• Write logs to storage that is append-only or has object locking enabled.

• Keep them in a separate account or project from production, with separate administrators.

• Restrict read access, and log access to the logs.

• Alert when a source stops sending, or when logging configuration changes.

• Keep clocks synchronized across systems, or your timeline will not hold together under questioning.

Concede the trade-off openly in your risk analysis. Longer retention gives investigators more to work with, and it also gives an attacker more to steal if your logs contain ePHI. Minimizing what goes into the log reduces both problems.

How TrustLynce helps #

TrustLynce's continuous monitoring checks that logging stays enabled on the cloud and identity systems you connect and routes failures to the control owner. Evidence collection captures review records on a schedule, timestamped and attributed, so the six-year documentation trail builds as the work happens.