What Audit Logging Does HIPAA Actually Require?

Here is the entire audit logging requirement, quoted in full from 45 CFR 164.312(b): "Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." One sentence. It names no log format, no event types, no retention period, and no review frequency, and unlike most of the Security Rule it carries no implementation specifications underneath it, so there is nothing labeled Required or Addressable to argue about. The six-year figure every vendor page attaches to HIPAA logging comes from somewhere else entirely: 45 CFR 164.316(b)(2)(i) requires you to retain the documentation the Security Rule requires for six years, and audit logs are not that documentation. The contrarian point is which requirement actually catches people. It is not 164.312(b) at all. It is 45 CFR 164.308(a)(1)(ii)(D), which is Required, and which obliges you to regularly review the logs you collected.

What follows is what the text says, where the numbers everyone quotes actually come from, and how to set a retention period the rule refuses to set for you.

Key takeaways

• 164.312(b) is a standard with no implementation specifications. It is mandatory, and its content is entirely up to your risk analysis.
• The Required companion is 164.308(a)(1)(ii)(D), information system activity review: procedures to regularly review records of information system activity such as audit logs, access reports, and security incident tracking reports.
• Six years is the documentation retention period at 164.316(b)(2)(i). It applies to policies, procedures, and required records of actions, activities, and assessments. It is not a log retention period.
• Because HIPAA sets no log retention number, your number comes from somewhere else: breach determination needs, state law, customer contracts, and your own incident detection window.
• The single most valuable log you can keep is the one that lets you say a record was not viewed, because that is factor three of the breach analysis and the only way to answer it affirmatively.

What the text says, and what it deliberately does not

The Security Rule is built in two layers. Standards are always mandatory. Underneath most standards sit implementation specifications, each labeled Required or Addressable, and 45 CFR 164.306(d) explains that an addressable specification must be assessed and either implemented or replaced with a documented equivalent.

Audit controls has no second layer. It is a bare standard, which means it is fully mandatory and fully undefined. Compare it with access control at 164.312(a), which carries four named specifications, two Required and two Addressable. The contrast is deliberate: HHS wrote a technology-neutral obligation and pushed the content decision into your risk analysis.

That decision is governed by 164.306(b), flexibility of approach, which lets you use any security measures that reasonably and appropriately implement the standards, provided you take into account four factors: "the size, complexity, and capabilities of the covered entity or business associate"; its "technical infrastructure, hardware, and software security capabilities"; "the costs of security measures"; and "the probability and criticality of potential risks to electronic protected health information."

So the honest answer to "what does HIPAA require me to log" is: whatever your documented risk analysis concludes is reasonable and appropriate given those four factors. That is not a dodge. It is the mechanism, and the corollary is that a logging design with no risk analysis behind it has no defense, while a modest logging design with a written rationale usually does.

Where the six years actually comes from

164.316(b)(1) requires you to keep your policies and procedures in written form and, "if an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record" of it. Then 164.316(b)(2)(i) sets the time limit: retain that documentation "for 6 years from the date of its creation or the date when it last was in effect, whichever is later."

Read the object of that sentence. It is the documentation this subpart requires: your policies and procedures, your risk analysis, your sanction records, your evaluations, and the addressable-specification memos. Raw audit logs are not documentation required by the subpart, because 164.312(b) never says to document anything. It says to record and examine activity.

One thing commonly filed under this clock is not on it. Breach risk determinations belong to the Breach Notification Rule, and their retention runs through 45 CFR 164.414(a) into 164.530(j), for the same six years under a different provision.

This matters commercially, because "HIPAA requires six years of log retention" is a claim that sells log storage. It is not in the regulation. What is in the regulation is that if your information system activity review produces a record, that review record is documentation, and it is on the six-year clock even if the underlying logs are not.

Our HIPAA compliance checklist for HealthTech covers the surrounding administrative, physical, and technical safeguards as a working list, and defers to this article on the retention question rather than restating a number the rule does not set.

The requirement that actually gets tested

164.308(a)(1)(ii)(D) sits inside the security management process standard and is labeled Required, with no addressable escape: "Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports."

Three words carry the weight. Procedures, meaning a written process rather than an intention. Regularly, meaning on a cadence you define and can evidence, not "when something looks wrong." And review, meaning a human or a tuned detection reads the output and something happens as a result.

This is the requirement that separates organizations in practice. Collecting logs is a purchasing decision and most teams have made it. Reviewing them is an operating decision, and the evidence of it is what a reviewer asks for: who runs the review, on what cadence, against what queries or alerts, what they found last quarter, and what happened next. A SIEM with no assigned reviewer produces storage costs and no compliance value, and the same is true of a cloud-native logging stack nobody has tuned.

What to log, mapped to the questions you will be asked

The regulation will not give you a list, so build one backwards from the questions you have to answer under pressure.

Who accessed this patient's record, and when. Record-level read access on your ePHI stores. This is the log that answers factor three of the breach risk assessment, and it is the difference between writing "we have no evidence of access" and writing "access logs confirm the record was not opened." Only the second one moves the analysis in your favor.

Who has access, and who granted it. Authentication events, privilege grants and revocations, role changes, and administrative actions. This is what supports access review and termination procedures, and it is the first thing an auditor samples.

What changed in the environment. Configuration changes, deployments, and changes to the logging configuration itself. That last one is the one people forget, and it is the one that matters most in an investigation, because a gap in a log is only interpretable if you know whether logging was on.

What left. Bulk exports, report generation, downloads, and API pulls of any volume. Large-volume egress by an authorized user is the pattern most likely to be both a real incident and invisible to a control designed around unauthorized access.

If you also carry a SOC 2, most of this is work you are already doing for the common criteria, and the sensible move is one logging design evidenced twice rather than two programs. Our SOC 2 cost breakdown covers what that overlap is worth in practice.

Setting a retention period the rule refuses to set

Since HIPAA gives you no number, derive one. Four inputs usually decide it.

Your detection window. If your realistic mean time to detect an intrusion is measured in months, logs retained for thirty days cannot reconstruct the incident that matters. Retention shorter than your detection reality is retention that will fail exactly once, expensively.

Your breach determination needs. When you have to demonstrate whether specific records were viewed, you need the logs covering the whole period the exposure could have existed, which is often longer than the period you knew about it.

Contracts and other regimes. Business associate agreements, enterprise customer agreements, payment obligations, and state law can all impose retention floors that exceed anything HIPAA implies. In most engagements the binding number turns out to be contractual.

Cost. 164.306(b)(2)(iii) lists "the costs of security measures" as a factor you are entitled to weigh. Tiering matters more than a single retention number: high-fidelity record-access logs kept hot for a defensible window and archived cheaply afterward is a legitimate design, and one you can write down.

Whatever you choose, write the rationale in the same document as the number. A retention period with a documented basis is a decision. The same period with no basis is a default someone set in a console.

What the proposed Security Rule overhaul would change

The proposed update would make several currently addressable specifications explicit and would add a technology asset inventory and a vulnerability management standard. Two cadences in that standard are worth stating precisely, because most summaries get them slightly wrong. Proposed 45 CFR 164.312(h), as printed in the NPRM at 90 FR 898, would require automated vulnerability scans "in accordance with the covered entity's or business associate's risk analysis required by Sec. 164.308(a)(2) or at least once every six months, whichever is more frequent", and penetration testing by a qualified person "at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis required by Sec. 164.308(a)(2), whichever is more frequent". Note that phrase on both: six and twelve months are floors, not schedules, and a risk analysis that says quarterly overrides them.

As of August 2026 none of it is enforceable. That is proposed text in a rulemaking that has not been finalized, the numbers can move before a final rule, and quoting them as current requirements is the most common error in vendor content on this topic. Our status page on the proposed rule explains where the rulemaking stands and how to check it yourself, and whether HIPAA requires penetration testing covers the adjacent question under the rule actually in force.

The planning implication is not the specific cadences anyway. It is that a program whose logging design exists only as a console setting will have nothing to show when the requirements become explicit, and one that already has a written design, a review procedure, and evidence of the review will mostly be updating a document.

The honest caveat

If you run on managed cloud services with their native audit logging switched on, a defined retention setting, and someone who actually looks at the alerts, you are substantially compliant with 164.312(b) and you do not need to hire anyone to tell you that. The gap in that situation is almost always documentation rather than technology: the controls exist and nobody wrote down why they are reasonable and appropriate. That is an afternoon with a template, not an engagement.

We are worth paying in two situations. The first is legacy or self-hosted clinical systems where record-level read logging genuinely does not exist and someone has to design a way to get it without a rewrite, which is engineering work rather than compliance work. The second is when you have logs and no reviewer, and the useful deliverable is a review procedure with real queries and a named owner rather than a policy that says reviews occur. What we would not sell you, and what plenty of vendors will, is a log retention project justified by a six-year requirement that does not apply to logs.

Where Top Floor fits

We do the logging design, the information system activity review procedure, and the risk-analysis rationale that has to sit behind both under our HIPAA practice. Where the same evidence has to serve an attestation, our SOC 2 practice covers the overlap, and ongoing operation of the review sits under Compliance as a Service. We prepare organizations for assessments; we do not issue attestation opinions on our own work.

How to decide this week

Pick one patient record and try to answer, from logs alone, who read it in the last ninety days. If you cannot, that is the gap, and it is the same gap that will force you to notify on an incident you might otherwise have closed.

Then find out who reviewed your logs last month and what they found. If the answer is nobody, 164.308(a)(1)(ii)(D) is unmet regardless of how much you are spending on storage, and fixing it costs a calendar invite and a saved query before it costs anything else.

Finally, write down your retention period and one paragraph explaining why it is reasonable and appropriate given the four factors at 164.306(b)(2). That paragraph is the artifact that turns a console setting into a defensible control.

Frequently asked questions

How long does HIPAA require you to keep audit logs?

HIPAA sets no log retention period. The audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity and says nothing about how long to keep the output. The widely quoted six years comes from 45 CFR 164.316(b)(2)(i), which requires retaining the documentation the Security Rule requires (policies, procedures, and records of actions, activities, or assessments that the subpart requires to be documented) for six years from creation or last effective date, whichever is later. Raw logs are not that documentation. Your retention period should instead come from your detection window, breach determination needs, contractual obligations, and a cost judgment you write down.

Is audit logging required or addressable under HIPAA?

Required, and unusually so. Most Security Rule standards carry implementation specifications labeled Required or Addressable, where an addressable one can be replaced by a documented equivalent measure. Audit controls at 164.312(b) has no implementation specifications at all: it is a bare standard, which makes it fully mandatory and entirely undefined as to content. What you log is decided by your risk analysis under the flexibility-of-approach rule at 164.306(b), which lets you weigh your size and capabilities, your technical infrastructure, the cost of the measures, and the probability and criticality of the risks.

What is information system activity review and how is it different from audit controls?

Audit controls at 164.312(b) is about producing the records. Information system activity review at 164.308(a)(1)(ii)(D) is about reading them, and it is a Required implementation specification: implement procedures to regularly review records of information system activity such as audit logs, access reports, and security incident tracking reports. Organizations routinely satisfy the first and fail the second, because collecting logs is a purchase and reviewing them is an operating commitment. The evidence a reviewer asks for is the cadence, the named owner, the queries or alerts, and what the last few reviews actually found.

What should we log to satisfy HIPAA?

Work backwards from the questions you will have to answer. Record-level read access on systems holding ePHI, because that is what lets you say affirmatively that a record was not viewed during a breach determination. Authentication, privilege grants and revocations, and role changes, because those support access review and termination procedures. Configuration and deployment changes, including changes to logging itself, because a gap in a log is only interpretable if you know whether logging was on. And bulk exports, downloads, and high-volume API reads, because authorized users moving large volumes is the pattern most likely to be both real and invisible.