HIPAA Breach Investigation Requirements

A HIPAA breach forensic investigation is the disciplined process of determining whether an impermissible acquisition, access, use, or disclosure of protected health information (PHI) actually compromised that information — and therefore triggers notification under the HIPAA Breach Notification Rule. The law presumes a breach and requires notice unless the covered entity or business associate can demonstrate, through a documented four-factor risk assessment supported by forensic evidence, a low probability that PHI was compromised. Notification deadlines run from discovery, without unreasonable delay and no later than 60 days.

Few events expose a healthcare organization to more regulatory, financial, and reputational risk than the moment an executive team must decide whether an incident is a reportable breach. Get it wrong in one direction — failing to notify when the law required it — and the organization faces civil monetary penalties, a corrective action plan, and a listing on the U.S. Department of Health and Human Services (HHS) public breach portal. Get it wrong in the other — over-reporting on assumption rather than evidence — and it invites needless investigation, patient alarm, and liability it never actually owed. The difference between those outcomes is almost never a matter of good intentions. It is a matter of forensic rigor: whether the determination rests on documented, defensible evidence or on a hopeful guess. This guide is written for the general counsel, chief compliance officer, CISO, privacy officer, and health-system executive who must own that determination and defend it to the Office for Civil Rights (OCR).

What makes a HIPAA breach a forensic determination, not a compliance judgment call?

The HIPAA Breach Notification Rule (45 CFR §§ 164.400–414), enacted under the HITECH Act, defines a breach as the impermissible acquisition, access, use, or disclosure of unsecured PHI that compromises the security or privacy of that information. The critical word is compromises. Not every impermissible touch of PHI is a breach; the rule turns on whether the information was actually compromised. And that is fundamentally a question of fact — who accessed what, when, whether they read or exfiltrated it, and whether the exposure was contained — which can only be answered by evidence.

Crucially, the rule places the burden of proof squarely on the covered entity or business associate. Following an impermissible use or disclosure, a breach is presumed unless the organization demonstrates a low probability that the PHI has been compromised. That presumption reframes the entire exercise: you do not have to prove a breach occurred to owe notification — you have to prove one did not, to the standard of a documented risk assessment, or notify. An assertion that “we don’t think anyone saw it” is worthless without the audit trail that shows they did not. This is precisely why the determination belongs in the domain of digital forensics rather than committee opinion, and why OCR investigators, in the aftermath, will ask for the evidence and the analysis — not the meeting minutes.

When is a security incident actually a reportable breach?

Three gates sit between an incident and a notification obligation, and a competent investigation works through each in order.

First, was the PHI “unsecured”? The rule only governs unsecured PHI — information not rendered unusable, unreadable, or indecipherable through encryption or destruction that meets HHS-specified standards (aligned to NIST guidance). This is the encryption safe harbor: if a stolen laptop’s drive was properly encrypted and the key was not also compromised, there is no breach of unsecured PHI, and no notification is triggered. The forensic question is narrow but decisive — was the data truly encrypted to standard, and was the key protected?

Second, does a regulatory exception apply? The rule carves out three narrow exceptions: an unintentional, good-faith acquisition by a workforce member acting within their authority; an inadvertent disclosure between two persons both authorized to access PHI at the same organization; and a disclosure where the recipient could not reasonably have retained the information. Each is fact-specific and must be substantiated, not assumed.

Third, and where most determinations actually turn: can you demonstrate a low probability of compromise? If the PHI was unsecured and no exception cleanly applies, the presumption of breach stands unless the four-factor risk assessment rebuts it. That assessment is the heart of the matter.

What is the four-factor risk assessment?

To overcome the presumption of a breach, the covered entity or business associate must perform and document a risk assessment addressing, at minimum, four factors mandated by the rule. The goal is to reach a defensible conclusion about the probability that PHI was compromised. Each factor should be evidenced, not merely asserted — and this is where forensic capability separates a determination that survives OCR scrutiny from one that collapses under it.

Factor	What it evaluates	Forensic evidence that answers it
1. Nature and extent of the PHI	Types of identifiers, sensitivity (clinical, financial, SSN, diagnoses), and likelihood of re-identification	Data mapping of the affected records, field-level analysis of what was exposed, volume and record counts
2. The unauthorized recipient	Who accessed or received the PHI, and whether they have an obligation to protect it (e.g., another covered entity vs. an unknown external actor)	Identity attribution from access logs, source IPs, account analysis, recipient identification
3. Whether PHI was actually acquired or viewed	Was the information merely accessible, or was it actually opened, read, copied, or exfiltrated?	EHR access/audit logs, file-open and read events, data-transfer and exfiltration evidence, forensic disk and memory analysis
4. Extent of mitigation	Whether the risk has been reduced — recovery of data, confirmed deletion, enforceable assurances from the recipient	Recovery confirmation, verified destruction, attestations, containment timeline

The single most consequential factor in practice is the third: was the PHI actually acquired or viewed? A ransomware event that encrypts a server holding ePHI, or a misconfigured database exposed to the internet, creates a presumption of exposure — but audit logs, access records, and exfiltration analysis can sometimes demonstrate that no data was actually opened or removed. Conversely, the absence of logging — a system that simply does not record who accessed what — is often fatal to a low-probability finding, because you cannot prove a negative you never instrumented. Organizations frequently discover, in the worst possible moment, that the audit logging they assumed was running was never fully enabled.

What are the OCR reporting timelines and to whom must you notify?

If the assessment cannot rebut the presumption, notification obligations attach — and they run from the date of discovery, defined as the first day the incident is known, or by exercising reasonable diligence would have been known, to the organization. The clock does not wait for the investigation to finish; it starts when the incident is discovered, which is why forensic work must move in parallel with, not before, the notification calendar. The table below summarizes the core deadlines.

Who must be notified	Trigger	Deadline
Affected individuals	Any reportable breach	Without unreasonable delay, no later than 60 calendar days from discovery
HHS Secretary (OCR) — large breach	Breach affecting 500 or more individuals	Without unreasonable delay, no later than 60 days from discovery
HHS Secretary (OCR) — small breach	Breach affecting fewer than 500 individuals	Annually, within 60 days after the end of the calendar year in which discovered
Prominent media outlets	Breach affecting more than 500 residents of a state or jurisdiction	Without unreasonable delay, no later than 60 days from discovery
Covered entity (by a business associate)	Breach at or by the business associate	Without unreasonable delay, no later than 60 days from discovery

Two operational realities matter here. First, “no later than 60 days” is a ceiling, not a target — OCR has penalized organizations that waited the full period without justification when they could have notified sooner. Second, business associates carry their own clock: a vendor that experiences a breach must notify the covered entity promptly, and the covered entity’s own 60-day window is generally measured from when its business associate (acting as its agent) discovered the incident. Contracts and business associate agreements should make this chain explicit, because a slow vendor can consume a covered entity’s entire notification window before the hospital even learns of the problem. Full requirements are published by the HHS Office for Civil Rights Breach Notification Rule.

What forensic evidence proves — or disproves — a healthcare breach?

The determination is only as strong as the evidence beneath it, and healthcare environments hold that evidence in places most generalist responders overlook. A world-class HIPAA breach investigation preserves and correlates:

• EHR audit logs. Electronic health record systems such as Epic and Cerner record granular access events — which user opened which patient record, when, and from where. These logs are the backbone of the “actually viewed” factor and the primary tool for detecting insider snooping into records the employee had no treatment reason to open.
• Authentication and identity logs. Active Directory, single sign-on, VPN, and remote-access records that establish who was behind an account and whether credentials were compromised or shared.
• Network and exfiltration evidence. Firewall, proxy, DLP, and NetFlow data showing whether PHI actually left the environment, in what volume, and to where — central to distinguishing exposure from acquisition.
• Endpoint and server forensics. Disk and memory analysis of affected systems, including ransomware artifacts, malware, and evidence of staging or data collection prior to exfiltration.
• Cloud and email logs. Microsoft 365 and Google Workspace audit trails, cloud storage access records, and mailbox activity where PHI travels through or resides in cloud services.
• Medical device and imaging systems. PACS, connected devices, and specialized clinical systems that store PHI but frequently lack robust logging — a known blind spot.

The discipline that governs all of it is the same one that governs any defensible digital forensics matter: preserve before you analyze, and analyze before you remediate. Wiping and reimaging an infected server may restore operations, but it also destroys the very evidence that could have proven no PHI was acquired — converting a potentially non-reportable incident into an unprovable one that must be reported by default. Chain of custody, hashing, and independent preservation are not academic niceties here; they are what make the risk assessment credible to a regulator and, if it comes to it, to a court.

How does ransomware change the breach analysis?

Ransomware is the defining healthcare breach scenario of the era, and OCR has been explicit: when ransomware encrypts ePHI, a breach is presumed, because the unauthorized actor has, at minimum, taken control of (acquired) the information. The organization must then use the four-factor assessment to determine whether there is nonetheless a low probability of compromise — and modern ransomware makes that harder, because most contemporary campaigns exfiltrate data before encrypting it (double extortion). A finding that “we restored from backup and lost no data” does not resolve the breach question if the attacker copied records on the way in.

This is where forensic depth is decisive. Demonstrating that ePHI was encrypted-in-place but never exfiltrated — through network egress analysis, review of attacker tooling, and reconstruction of the intrusion timeline — can support a low-probability determination. But that argument only holds if the evidence was preserved and the logging existed. Healthcare organizations facing an active ransomware event should treat the incident simultaneously as an operational crisis, a forensic matter, and a notification clock already running, coordinating incident response, legal, and their cyber services and healthcare and hospital security teams from the first hour. Federal guidance from the Cybersecurity and Infrastructure Security Agency (CISA) should anchor the technical response, while the forensic record anchors the breach determination.

What does a defensible breach determination process look like?

A world-class HIPAA breach investigation follows a repeatable sequence that runs the forensic work and the compliance clock in parallel:

1. Fix the discovery date and start the clock. Document when and how the incident was discovered; the 60-day windows measure from here, so the date must be defensible.
2. Preserve before touching anything. Capture EHR audit logs, authentication records, network telemetry, and affected endpoints into an independent, hashed, chain-of-custody-controlled store before remediation alters them.
3. Scope the affected PHI. Identify precisely which records, identifiers, and individuals were involved — the foundation of Factor 1 and of any eventual notification list.
4. Attribute the access. Establish who the unauthorized person or actor was, and whether they were obligated to protect PHI (Factor 2).
5. Determine acquisition versus exposure. Use logs and exfiltration analysis to establish whether PHI was actually viewed, copied, or removed — the pivotal Factor 3 finding.
6. Document mitigation. Record recovery, confirmed deletion, and enforceable assurances that reduce residual risk (Factor 4).
7. Reach and document the determination. Conclude, with evidence, whether a low probability of compromise is demonstrable — or whether notification is required.
8. Notify and retain the record. Execute required notifications within the deadlines and retain the full assessment and documentation for at least six years, as the rule requires.

The through-line is documentation. Whether the outcome is “notify” or “no breach,” OCR expects a written, evidence-backed risk assessment retained for six years. A decision not to notify is not a decision to keep no record — it is the decision that most demands one, because it is the one the organization will be asked to defend.

How does Honeybadger investigate HIPAA breaches?

Honeybadger Solutions approaches a suspected HIPAA breach the way it must be handled to withstand regulatory and legal scrutiny: preservation first, forensic reconstruction second, and a documented four-factor determination built on evidence rather than assumption. Because our digital forensics, cybersecurity, financial-investigation, and background-intelligence capabilities are delivered in-house and nationwide, a healthcare incident does not fragment across disconnected vendors — the same command that preserves the EHR audit logs and analyzes network exfiltration also builds the risk assessment and supports the notification record. We move against the clock, secure the evidence before remediation destroys it, and give counsel and compliance leaders a defensible answer to the only question that matters: was PHI compromised, and can we prove it either way?

Our work supports everything that follows a healthcare incident — the four-factor assessment, individual and OCR notification, media coordination where required, business-associate and vendor accountability, cyber-insurance recovery, and, where warranted, litigation and law-enforcement coordination — all under a single accountable chain of command. From Arizona home command, with offices in Casa Grande, Phoenix, and Oro Valley, we serve hospitals, health systems, medical groups, and their counsel across the United States, closing the gap between what happened to the protected health information and what the organization can prove and defend afterward.

Frequently asked questions

Is every impermissible disclosure of PHI a reportable HIPAA breach?

No. An impermissible acquisition, access, use, or disclosure of unsecured PHI is presumed to be a breach, but the presumption can be rebutted. If the PHI was properly encrypted (the safe harbor), if a narrow regulatory exception applies, or if a documented four-factor risk assessment demonstrates a low probability that the information was compromised, notification is not required. The burden is on the organization to prove that with evidence, which is why a forensic investigation is essential.

What are the four factors in a HIPAA breach risk assessment?

The rule requires assessing at least four factors: (1) the nature and extent of the PHI involved, including identifiers and re-identification risk; (2) the unauthorized person who used or received the PHI; (3) whether the PHI was actually acquired or viewed, as opposed to merely accessible; and (4) the extent to which the risk has been mitigated. Together they determine whether a low probability of compromise can be demonstrated. Factor three — whether data was actually viewed or exfiltrated — is usually the decisive one and depends on audit logs and forensic analysis.

How long do we have to report a HIPAA breach to OCR?

For a breach affecting 500 or more individuals, notify affected individuals and HHS without unreasonable delay and no later than 60 calendar days from discovery, plus notify prominent media if more than 500 residents of a state are affected. For breaches affecting fewer than 500 individuals, individual notice still follows the 60-day rule, but HHS is notified annually, within 60 days after the end of the calendar year in which the breach was discovered. Discovery is when the incident is known or reasonably should have been known.

Is a ransomware attack on a hospital automatically a HIPAA breach?

OCR guidance treats ransomware that encrypts ePHI as a presumed breach, because the attacker has taken control of the information. The organization can still perform the four-factor assessment to determine whether there is a low probability of compromise, but modern ransomware often exfiltrates data before encryption, so restoring from backup does not, by itself, resolve the breach question. Demonstrating no exfiltration occurred requires preserved logs and forensic egress analysis — which is why evidence must be secured before systems are wiped and rebuilt.