Complying with the HIPAA Breach Notification Rule

Complying with the HIPAA Breach Notification Rule

The single most important fact about this rule, and the one most generic summaries understate: since the 2013 Omnibus Rule, every impermissible use or disclosure of unsecured PHI is legally presumed to be a reportable breach. The burden of proof is on your organization to demonstrate otherwise — not on OCR to prove that notification was required. That reversal changes how an incident response process needs to work: the default assumption when something goes wrong should be "this is reportable," not "let's see if it's serious enough to report."

Three Situations That Aren't a Breach At All

Before the breach analysis even starts, three narrow exceptions remove an incident from "breach" status entirely, codified at 45 CFR §164.402:

• Unintentional, good-faith internal access — a workforce member accidentally accesses PHI in good faith, within the scope of their authority, and doesn't further use or disclose it.

• Inadvertent disclosure between authorized people at the same organization — PHI sent to the wrong person, but that person is also authorized to access PHI within the same covered entity, business associate, or organized health care arrangement, with no further impermissible use.

• Good-faith belief the recipient couldn't have retained the information — a sealed envelope returned unopened, a misdirected message immediately deleted without being viewed.

These exceptions are narrow and specific. If any condition isn't met — if the access wasn't truly unintentional, if further disclosure occurred, if there's no good-faith basis for believing the information wasn't retained — the incident falls back into the standard breach analysis below.

The Four-Factor Risk Assessment

When an incident doesn't fit one of the three exceptions above, the presumption of breach applies — and the only way to treat it as something less than a reportable breach is a documented assessment across four specific factors:

1. The nature and extent of the PHI involved — what identifiers were included, how many individuals are affected, and whether the health information itself is especially sensitive (Social Security numbers, financial data, or diagnoses like HIV status, mental health, or substance use carry higher risk than less sensitive categories).

2. Who received or could have accessed the information — a disclosure to another covered entity or a known, trusted party carries materially lower risk than disclosure to an unknown party with no apparent legitimate reason to have it.

3. Whether the PHI was actually acquired or viewed, as opposed to merely exposed without evidence anyone accessed it — this is where forensic evidence (access logs, system records) becomes critical, since without it, the presumption of breach stands by default.

4. The extent to which the risk has been mitigated — actions taken between discovery and the final assessment, such as obtaining signed assurances that the recipient won't further use or disclose the information, retrieving the data, or confirming destruction.

All four factors get evaluated together, not in isolation, and the resulting conclusion has to be reasonable and documented in good faith — a cursory or conclusory assessment doesn't satisfy this requirement even if it reaches the "low probability" conclusion.

Notification Requirements Once a Breach Is Confirmed

• Affected individuals: notified without unreasonable delay, no later than 60 calendar days after discovery — not 60 days after the incident occurred, which can be a meaningfully earlier date if discovery was delayed.

• HHS: breaches affecting 500 or more individuals in a state or jurisdiction must be reported within 60 days; breaches affecting fewer than 500 can be logged and reported annually, no later than 60 days after the calendar year ends.

• Media: required for breaches affecting 500 or more individuals in a given state or jurisdiction.

• Business associates: must notify the covered entity promptly with the facts needed for downstream reporting — the covered entity's 60-day clock for notifying individuals doesn't pause while waiting on a slow business associate notification.

Why Documentation Matters Even When Notification Isn't Required

Maintaining records of every breach investigation — including ones that concluded notification wasn't required — isn't optional paperwork. If OCR later investigates the same or a related incident, the absence of a documented risk assessment is itself evidence the organization didn't actually perform one, which removes the only basis for treating the incident as anything other than a presumed breach. Risk assessment documentation should be retained for at least six years, matching HIPAA's general documentation retention requirement.

Building a Process That Matches How the Rule Actually Works

A workable incident response process needs:

• A designated person responsible for breach assessment — typically the Privacy or Security Officer — trained specifically in the four-factor test, not general privacy awareness.

• A standing risk assessment template that walks through all four factors consistently, so assessments don't vary in rigor depending on who's conducting them.

• Fast access to forensic evidence — logs, access records — since the third factor (actual acquisition or viewing) depends heavily on evidence that degrades or disappears if not preserved quickly after discovery.

• A clear timeline tracker from the moment of discovery, since the 60-day clock starts there, not at the moment of the underlying incident.

Automation's Role, Specifically

Continuous monitoring genuinely changes the dynamics of this rule in one specific way: faster detection means the discovery date — which starts the 60-day clock — happens sooner, and faster access to logs makes the third risk-assessment factor (was the information actually accessed) answerable with evidence rather than guesswork. This is a real, mechanical benefit, distinct from general efficiency claims — better detection directly improves both the speed and the defensibility of the breach assessment itself, which connects directly to how SOC 2 and ISO 27001 build continuous monitoring into their own incident response requirements.

For how this rule fits into the broader 2013 regulatory changes, see Exploring the HIPAA Omnibus Rule