The HIPAA Post-Incident Review an OCR Audit Expects

The email arrived during a busy Tuesday morning at a mid-size cardiology practice. It looked like a routine note from the group’s EHR vendor, asking a nurse to re-verify her login ahead of a scheduled system update.

She moved her cursor toward the link – then she paused. The sender’s address was close to the real one, yet a few characters were wrong. She forwarded the message to IT and went back to her patients.

IT confirmed the domain was spoofed, blocked it, and pulled the same message from a handful of other mailboxes. No one had entered credentials, the attachment stayed unopened, and no patient record was touched.

By lunchtime it was handled, and nothing had been lost.

The hard part of that morning had not happened yet.

The HIPAA Security Rule is about to update for the first time since 2013: HIPAA Security Rule Changes for Healthcare Organizations

A Near-Miss is Still an Incident

Under HIPAA, a security incident is not limited to a successful intrusion. The definition in the HIPAA Security Rule covers attempted as well as successful unauthorized access, use, disclosure, modification, or destruction of information in a system. A phishing message that gets reported before anyone clicks still meets it.

So the blocked email that Tuesday was a security incident in the regulatory sense, even though nothing came of it.

The Security Rule has a standard built for this: Security Incident Procedures, at 45 CFR 164.308(a)(6), requires covered entities to identify and respond to suspected or known incidents, mitigate the harmful effects to the extent practicable, and document the incidents along with their outcomes.

That last element carries weight: documentation is written into the standard itself, which means that a reviewer reading your file later is reading it against that requirement.

The scale of the record follows the scale of the event. Office for Civil Rights (OCR) guidance notes that a minor incident may call for only a brief entry, while a more serious one warrants a fuller response and more detailed documentation. A reported phishing attempt with no access sits at the lighter end, but it still leaves something behind that someone may one day read.

The Line Between an Incident and a Breach

An incident and a breach are measured at different thresholds, and the gap between them matters here.

What Counts as a Breach?

A breach is an impermissible acquisition, access, use, or disclosure of protected health information (PHI). The rule sets a high bar for clearing one:

• Once an impermissible event occurs, the rule presumes a breach has happened.
• The organization carries the burden of proof to show otherwise.
• Clearing that bar means demonstrating, through a documented risk assessment, a low probability that the information was compromised. The HHS Breach Notification Rule lays out how that works.

Why the Tuesday Email Is Not a Breach

In the scenario, the facts stop well short of that threshold:

• Nobody clicked the link.
• No credentials were handed over.
• No record was opened or sent anywhere it should not have gone.

With no impermissible access to PHI, there is very likely no reportable breach and no notification to make. That is good news for the practice, and it still leaves a record to make.

A Report Must Still Be Made

Even when no notification is owed:

• Write down what happened and when.
• Record your own conclusion that PHI was not compromised, along with the reasoning.
• Treat that written conclusion as the evidence. Months later, it separates a documented judgment from assumption.

If the Email Had Gone Further

Had PHI been exposed, the organization would work through the four-factor risk assessment the Breach Notification Rule calls for. That analysis weighs:

• The nature and extent of the information involved.
• Who the unauthorized recipient was.
• Whether the information was actually acquired or viewed.
• How well the risk was mitigated afterward.

The result has to be written down whichever way it lands. OCR resolution agreements have repeatedly pointed to risk assessments that were missing or inadequate, and an undocumented conclusion offers a reviewer nothing to credit.

Looking to renew your cyber insurance? Make sure you’re prepared: Healthcare Cyber Insurance: When Insurers Ask the Same Question

What a Reviewer Opens the Folder to Find

A reviewer studying the incident during a compliance review will note the practices that occurred in the hours and days afterward. A strong file tends to hold a few things:

• An incident log entry with a real timestamp: When the email was reported, who reported it, what IT observed, and when the team acted. A record written that day is worth far more than one reconstructed from memory.
• The response and mitigation steps: The spoofed sender blocked, the message purged from other mailboxes, and affected accounts checked for unusual activity.
• A written determination of impact: A short, dated note stating that no PHI was accessed and the reasoning behind it. When the answer is no breach, this note is what stands behind that call.
• Training evidence tied to the person involved: Proof that the clinician had completed security awareness training, including phishing recognition, with completion dates. HIPAA requires a security awareness and training program under 45 CFR 164.308(a)(5), and the training records are the evidence a reviewer needs.
• The corrective step the incident prompted: A targeted phishing simulation for that department, or a change to the mail filtering rules after the team reviewed the incident – something that shows the event was taken seriously
• A link to your risk analysis: Evidence that email-based attacks were already identified as a risk you were managing, so the incident reads as a scenario that was planned for.

Security Gaps That Turn a Clean Incident Into a Finding

The same event can produce two very different files: one that shows the response team knew what it was doing, and the other raises questions the organization has to answer under pressure.

A few gaps arise here:

• The record was written weeks later, dated as if it were written that day: A thin contemporaneous note holds up, while a polished account that was backfilled does not, and a reviewer can often tell. OCR has entered resolution agreements citing documentation that was missing or created after the fact.
• A training program with no proof of who completed it: A policy that says staff receive security awareness training carries little weight on its own.
• An incident handled well but not recorded: Blocking the sender and clearing the mailboxes was the right response. With nothing recorded, there is no evidence any of it happened.
• A response that led nowhere: An incident logged and closed, with no corrective step and no connection to the organization’s risk analysis, reads as an isolated event.

Each gap shares a root: the work got done, and the proof of the work did not survive. A reviewer grades the proof.

Have you assessed your security posture recently? You may be surprised what you find: The Security Gap Many Businesses Don’t Know They Have

Why This Is Drawing More Scrutiny

The HIPAA expectations laid out come from a rule written in its current form in 2013. That rule is now in line for its first major overhaul in over a decade.

What OCR Has Proposed

On January 6, 2025, OCR published a Notice of Proposed Rulemaking in the Federal Register to strengthen the HIPAA Security Rule, its first proposed update since 2013.

The proposal is not yet in effect; HIPAA reports indicate that the final rule has been pushed back, with a current target around mid-2027. The present Security Rule will stay in force while that plays out.

Record and Remediate Cyber Incidents While They’re Fresh

A good file indicates readiness; it sits in a system until a reviewer asks, and then it answers for itself. The incident log, the impact determination, the training record, and the corrective step do the talking, with dates that line up and a conclusion that holds.

Reaching for that file a year later is not the time to find out if it’s up to the right standards.

This is the kind of readiness Louisville Geek builds into the day-to-day for healthcare organizations. Our cybersecurity comes packaged with a vCIO regularly checking reports, so the incident logs, named training records, and corrective steps are kept as routine work.

That is how our healthcare clients sleep at night and pass their risk assessment: with an audit-ready posture in place when a reviewer comes calling.