HIPAA Breach Risk Assessment: Four-Factor Test Guide and Checklist

Four-Factor Breach Risk Assessment Overview

A HIPAA breach risk assessment determines whether there is a low probability that protected health information (PHI) has been compromised. Under the Breach Notification Rule, a breach is presumed unless your documented analysis of the four factors shows a low probability of compromise. Your decision drives whether notifications are required and how quickly you must act.

The four-factor test evaluates: (1) the nature and extent of PHI involved, (2) the unauthorized person who used or received it, (3) whether the PHI was actually acquired or viewed, and (4) the extent to which risk has been mitigated. While some organizations still reference a “risk of harm analysis,” HIPAA requires this specific four-factor evaluation for covered entity compliance.

How to use the four-factor test

• Immediately contain the incident, preserve logs, and secure systems or records.
• Gather facts for each factor and involve privacy, security, legal, and affected business units.
• Weigh all factors collectively; no single factor is determinative.
• Document your rationale, supporting evidence, and final determination.
• Map results to breach notification timing obligations if notification is required.

At-a-Glance Checklist

• Identify what PHI was exposed and in what format.
• Identify who used or received the PHI and their obligations.
• Confirm whether PHI was actually accessed, acquired, or viewed.
• Implement breach mitigation strategies and validate their effectiveness.
• Decide whether notification is required and track all deadlines.

Nature and Extent of PHI Involved

Start by cataloging the PHI elements implicated and assessing how identifiable and sensitive they are. Greater sensitivity and identifiability typically increase risk and reduce the likelihood you can conclude a low probability of compromise.

Data elements and sensitivity

• Direct identifiers: name, address, email, phone, Social Security number, driver’s license.
• Financial/insurance: account numbers, credit/debit details, insurance member IDs.
• Clinical: diagnoses, medications, lab results, treatment plans, imaging, visit notes.
• Highly sensitive categories: mental health, substance use disorder, reproductive health, HIV/STD status, genetic data.
• Scope and volume: number of records and breadth of fields exposed.
• Identifiability: whether the data set is fully identifiable, a limited data set, or effectively de-identified.

Format, context, and protections

• Format: paper, verbal, image, database export, PDF, spreadsheet, or screenshots.
• Security controls: was PHI encrypted, hashed, tokenized, truncated, or otherwise rendered unusable without keys?
• Context: routine operational data vs. research, legal, or high-profile patient records.
• Data age and accuracy: older, less complete, or obfuscated data may present reduced risk.

Unauthorized Person Who Used or Received PHI

Assess who received or could access the PHI and whether they have legal or contractual obligations to protect it. The greater the likelihood of misuse or redisclosure, the higher the risk.

Recipient profile

• Internal workforce vs. external recipient: insider errors often present lower risk if promptly contained.
• Another covered entity or business associate: existing HIPAA obligations can reduce risk.
• Individuals without obligations: family members, unrelated third parties, media, or cybercriminals increase risk.
• Track record: known data brokers, threat actors, or recipients with prior misuse elevate risk.

Ability and intent to use PHI

• Technical ability to access files (e.g., password-protected attachments sent without the password).
• Motivation to misuse data (financial fraud, identity theft, reputational harm).
• Controls in place (NDAs, BAAs, audit rights) that may constrain further use or disclosure.

Whether PHI Was Actually Acquired or Viewed

Demonstrable access or acquisition increases risk; inability to access or credible evidence that no viewing occurred may reduce it. Use objective proof whenever possible.

Evidence to review

• System and application logs indicating file opens, downloads, or exports.
• Email telemetry: read receipts, bounce-backs, and link access logs.
• Endpoint and DLP alerts, EDR telemetry, and forensic artifacts.
• Device status for loss/theft: encryption at rest, lock status, remote wipe success.
• Recipient statements corroborated by artifacts (e.g., unopened mail returned).

Contextual indicators

• Files sent but password-protected without the key provided.
• Logs show attempted access but authentication failed.
• Paper envelope returned unopened or destroyed under supervision.

Extent to Which Risk to PHI Has Been Mitigated

Effective, timely mitigation can materially lower residual risk. Document actions taken and validate outcomes with evidence.

Breach mitigation strategies

• Retrieval or secure deletion of misdirected PHI; certificates or attestations of destruction.
• Remote wipe of lost devices; password resets; key rotation; account lockouts.
• Closing exposed ports, revoking tokens/keys, patching, and strengthening access controls.
• Recipient confidentiality agreements and confirmation of no further use or disclosure.
• Targeted workforce re-training and process changes to prevent recurrence.

Assessing mitigation strength

• Speed of response and duration of exposure.
• Reliability and verifiability of assurances (e.g., logs proving deletion).
• Scope of containment: removal from backups, caches, collaboration tools, and shadow copies.

Breach Notification Requirements

If your analysis does not support a low probability that PHI was compromised, the Breach Notification Rule requires notification. Align your plan to who must be notified, what to include, how to send it, and breach notification timing.

Who to notify

• Individuals: send notice to each affected person.
• U.S. Department of Health and Human Services (HHS): report breaches as required by size.
• Media: notify prominent media outlets if a breach affects more than 500 residents of a state or jurisdiction.
• Business associate to covered entity: BAs must notify the CE and share available details.

When to notify

• Individuals and HHS (500+ affected): without unreasonable delay and no later than 60 calendar days from discovery.
• HHS (<500 affected in a calendar year): no later than 60 days after the end of that year.
• Business associates to covered entities: without unreasonable delay and no later than 60 days from discovery.
• Law enforcement delay: permissible if a written statement or documented request indicates notification would impede an investigation.

What to include in notifications

• What happened (including breach and discovery dates, if known).
• Types of PHI involved (e.g., names, SSNs, clinical data).
• Steps individuals should take to protect themselves.
• What you are doing to investigate, mitigate, and prevent future incidents.
• How to contact you for more information (toll-free number, email, or postal address).

How to notify

• First-class mail or email if the individual has agreed to electronic notice.
• Substitute notice when contact information is insufficient (e.g., website posting and media notice, as appropriate).
• Telephone or other means may supplement written notice in urgent cases.

Documentation and Timing of Risk Assessment

Start the assessment upon discovery—when the incident is known or should reasonably have been known. The discovery date starts your notification clock, so establish a repeatable process that promptly triages, escalates, and investigates incidents.

What to document

• Incident summary, systems and records affected, and precise timeline from discovery to closure.
• Detailed analysis of each of the four factors, including evidence and assumptions.
• Mitigation steps taken, validation of results, and residual-risk rationale.
• Final determination (breach vs. low probability of compromise) and decision-makers.
• Notifications made (audiences, dates, methods, content) and any law enforcement delays.
• Retention: maintain documentation for at least six years for covered entity compliance and audit readiness.

Keep a centralized repository, use a standard template, and review completed assessments for trends to inform training and process improvements.

In summary, apply the four-factor test systematically, corroborate with evidence, and document thoroughly. When the analysis does not support a low probability of compromise, execute notifications accurately and on time, and harden controls to reduce future risk.

FAQs.

What is the four-factor test for HIPAA breach risk assessment?

It is a structured analysis of: (1) the nature and extent of PHI involved; (2) the unauthorized person who used or received it; (3) whether the PHI was actually acquired or viewed; and (4) the extent to which the risk has been mitigated. You weigh all factors together to decide whether there is a low probability that PHI was compromised.

When is a breach notification required under HIPAA?

Notification is required when your documented four-factor analysis does not support a low probability that PHI was compromised. In that case, you must notify affected individuals (and, depending on size, HHS and possibly the media) without unreasonable delay and no later than 60 calendar days from discovery.

How should covered entities document the breach risk assessment?

Record the incident timeline, evidence, and detailed reasoning for each factor; mitigation steps and their effectiveness; the final determination; all notifications sent; and any law enforcement delay. Retain the full file for at least six years to demonstrate covered entity compliance.

What exceptions exist to HIPAA breach notification requirements?

Common exceptions include the inadvertent disclosure exception between authorized workforce members within the same covered entity or business associate; unintentional access or use by a workforce member in good faith and within scope; and situations where you have a good faith belief the unauthorized recipient could not reasonably have retained the information. Additionally, PHI that is properly encrypted or destroyed is generally not subject to the Breach Notification Rule.