A HIPAA day-90 audit should review grant history, not just a session's current expiry. Here is what to pull.
The day-90 HIPAA audit gap is what happens when a vendor session's deadline moves forward after the grant is issued—so a time-boxed access grant stays open past the window it was scoped to, with nothing in a standard access-list review flagging it. A quarterly or day-90 audit that pulls a grant's history, not just its current status, is the mechanism that catches this; a review that only checks whether each grant's stated expiry looks current will not.
Picture a HIPAA-covered health system onboarding an AI documentation assistant. Legal signs the BAA, security scopes the access, engineering issues a time-boxed session so the vendor's integration engineer can finish setup and get out. The access is supposed to expire on its own—that's the whole point of a time-boxed grant.
In this scenario, ninety days later, an internal audit turns up exactly one finding: that session is still open. Not because anyone re-approved it, not because anyone forgot to revoke it on a list somewhere—because the deadline moved forward once, quietly, and nothing about that looked unusual enough to flag.
That's the gap this piece is about. Not "the vendor had too much access." Not "nobody reviewed the contract." The specific, narrower failure: on a platform that lets a session's deadline move after the grant is issued, access built to auto-expire can still outlive its original window—and a compliance program that assumes "sessions expire" doesn't think to check whether that happened.
Why HIPAA doesn't catch this on paper
HIPAA's Security Rule requires covered entities and business associates to "implement policies and procedures that... establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process" (45 CFR §164.308(a)(4)(ii)(C)). Note the verb: review. Not "review every 30 days." Not "review every 90 days." The Security Rule never sets a numeric interval for that review.
The Rule does not set a numeric review interval for these obligations: §164.308(a)(8)'s evaluation is a standard, so it's mandatory outright—and it still says only "periodic." The access-review specification above is addressable, which means a covered entity that doesn't implement it must document why it isn't reasonable and appropriate for its environment and implement an equivalent alternative measure if one is reasonable and appropriate—under 45 CFR §164.306(d). The health system's own workforce-termination specification (§164.308(a)(3)(ii)(C)) is addressable too—and a vendor's integration engineer working under the vendor's own direction isn't the health system's workforce (a direct-control test, §160.103). The vendor carries that termination duty itself, directly, as a business associate bound by the Security Rule under §164.302. None of that adds up to a scheduled review interval on the health system's side. A vendor session that quietly outlives its original window isn't a documented violation the day it happens—it's a gap that surfaces only when someone goes looking, which is exactly what a day-90 audit is for.
A 2025 proposed rule (the HIPAA Security Rule NPRM, published in the Federal Register 2025-01-06) would remove the required/addressable distinction and make implementation specifications required, with specific, limited exceptions. As of this writing that rule is still proposed, not final—OCR hasn't issued a final rule, and OMB's Unified Agenda (RIN 0945-AA22) now targets July 2027 for final action. (Compliance-industry coverage puts the earlier target at spring 2026; see Medcurity.) It's worth knowing about, but it doesn't change what's enforceable today.
What has changed is how OCR reads a paper control. Four 2026 ransomware settlements, totaling $1.165M (HHS OCR; Sidley Data Matters), all cited a failure to conduct an accurate and thorough risk analysis under §164.308(a)(1)(ii)(A). The compliance-industry read of that pattern: a risk analysis that exists but was never acted on is no longer enough on its own—OCR now evaluates what the entity actually did with what it found (ComplianceHub). "We have an access policy" is not the same claim as "we know what's actually still open." A day-90 audit is one of the few mechanisms that tests the second claim instead of the first.
What "provisioning" and "governing" actually mean here
It's worth being precise about the difference this finding is pointing at, because the two things look identical from a policy document.
Provisioning access is the decision at the front door: who gets in, with what scope, for how long. A well-run vendor onboarding gets this right almost by default—access reviews, least-privilege scoping, a defined expiration are all things a security team already knows to ask for before signing.
Governing what stays open is a different question, asked continuously rather than once: is the access that exists right now still the access someone approved? A session that auto-expires on schedule answers that question by construction—an unattended session reaches its expiry on its own, so no one has to check. A session whose deadline can move breaks the construction quietly. The provisioning decision was correct. The governance assumption built on top of it—that expiry means expiry—stopped being true the moment the deadline moved, and nothing about that event looked like an incident. On a platform that allows the move with no approval step, there's no error, no alert, no denied request. Just a deadline that moved.
Vendor access questionnaires ask the pre-signature question: what to ask before you grant access at all. The day-90 audit finding is squarely an after problem: the grant was reasonable, the review process existed on paper, and the thing that failed was a lever nobody thought to watch.
What to actually check at day 90
If you run vendor or AI-agent access under HIPAA, add these three pulls to your next internal review, whatever platform you're on:
- Grant history, not just current status. Don't just pull the list of active grants and their stated expiry—pull the history of each grant: was it extended, and by whom.
- Service tokens and API keys, pulled separately. Any token or key issued to the integration sits outside a session's expiry entirely and won't show up in a session-grant review at all.
- What actually ran through the session, if the platform supports it. Check the commands against the intent the session was opened for, not just whether the session is still technically open.
A grant that's still active on its original schedule tells you the provisioning worked. A grant that's active past its original schedule, with no record of who approved that, is the thing a day-90 audit exists to catch—and the thing that no addressable HIPAA specification is going to flag for you automatically.
Provisioning access correctly is table stakes. Governing what stays open—continuously, not just at the signature—is the harder and more durable problem, and it's the one worth building your audit calendar around. And even that isn't the last question: a session still being open doesn't tell you what actually ran through it while it was open—the durable question isn't just whether the door was still unlocked, it's what walked through, and whether it matched what the session was opened to do.
FAQ
Does HIPAA require a review every 90 days? No. The Security Rule's access-review specification under 45 CFR §164.308(a)(4)(ii)(C) says "review"—it never sets a numeric interval, and it's addressable rather than required. A day-90 or quarterly cadence is a common audit-calendar choice, not a number the statute itself sets.
Is a session's stated expiry enough to confirm it closed on time? No. A grant's stated expiry only shows its current status. If the platform lets a deadline move forward after the grant is issued, a session can stay open past its original window with nothing in a standard access-list review flagging it. Pulling the grant's history—not just its status—is what catches an extension no one re-approved.
