HIPAA Breach Assessment: Determining Low Probability of Compromise

It was 4:15 PM on a Friday when the Practice Manager called me, voice shaking. "We found an unencrypted laptop in the parking lot. It belonged to one of our nurses who left three months ago. It has patient data on it."

My first question wasn't about how many patients. It was: "Has the data been compromised?"

Her answer: "We don't know."

That uncertainty—that gap between "we lost control of PHI" and "patient data was actually compromised"—is where the HIPAA Breach Notification Rule's risk assessment comes in. And after conducting over 200 breach assessments in my fifteen years in healthcare cybersecurity, I can tell you this: understanding how to properly assess the probability of compromise is the difference between a $50,000 notification exercise and potentially avoiding notification altogether.

But here's the critical part: you have to get it right. Because if you get it wrong, the consequences aren't just expensive—they can be career-ending.

What the OCR Actually Requires (And What Most People Get Wrong)

Let me start with a story that illustrates the most common mistake I see.

In 2019, I was brought in after a clinic decided that a stolen laptop containing 4,200 patient records didn't constitute a breach. Their reasoning? The laptop was password-protected.

Their IT Director told me confidently: "Password protection means low probability of compromise. We don't have to report it."

They were wrong. And it cost them $387,000 in penalties.

Here's what they missed: the HIPAA Breach Notification Rule requires a risk assessment based on four specific factors—not just whether you had some security measures in place.

"A breach assessment isn't about proving you had security. It's about demonstrating, through documented analysis, that the specific circumstances of this specific incident result in a low probability that PHI was compromised."

The Four-Factor Test: What the OCR Actually Looks At

The HIPAA Breach Notification Rule at 45 CFR § 164.402(2) requires assessment of four factors:

I've seen organizations get tripped up on every single one of these factors. Let me break down what fifteen years of experience has taught me about each one.

Factor 1: Nature and Extent of PHI Involved

This isn't just about volume. I've seen organizations focus entirely on the number of records exposed while completely ignoring what those records contained.

The Data Sensitivity Hierarchy

From my experience conducting breach assessments, here's how the OCR and courts view different types of PHI:

Highest Risk PHI:

• Social Security Numbers

• Financial account information

• Treatment records for sensitive conditions (mental health, HIV/AIDS, substance abuse, reproductive health)

• Complete medical records with full treatment history

• Genetic information

• Biometric data

Moderate Risk PHI:

• Diagnosis codes without detailed treatment information

• Medication lists

• Appointment dates and times

• Insurance information

• Provider names

Lower Risk PHI:

• Appointment reminders without diagnostic information

• General demographic information alone

• Dates of service without associated diagnoses

Let me give you a real example. In 2021, I assessed two incidents for two different clients on the same day:

Incident A: A thumb drive containing names, dates of birth, and appointment dates for 12,000 patients was lost.

Incident B: An email containing the full medical record, including SSN, insurance information, and complete treatment history for mental health services for 47 patients was sent to the wrong recipient.

Guess which one resulted in breach notification?

Both of them.

But here's the interesting part: Incident B had a much stronger case for "low probability of compromise" because we could demonstrate the recipient (a wrong email address within the same healthcare system) immediately deleted the information without reading it, and we had email server logs proving it.

Incident A? No way to prove the thumb drive wasn't accessed. Full notification required.

"In breach assessment, evidence beats assumptions every single time. The OCR doesn't care about what you think happened. They care about what you can prove happened."

Creating a PHI Sensitivity Matrix

I recommend every healthcare organization create a PHI sensitivity matrix. Here's a template I've used with dozens of clients:

This isn't an official OCR guideline—it's a framework I've developed through experience. But it's helped organizations make consistent, defensible decisions about breach assessment.

Factor 2: The Unauthorized Person Who Used or Received the PHI

This is where I see the most creative (and dangerous) interpretations of the rule.

I once reviewed a breach assessment where a medical practice argued that because PHI was accidentally emailed to a pharmaceutical sales representative who regularly visited their office, this was a "trusted individual" and therefore low probability of compromise.

The OCR disagreed. Strongly. The resulting settlement was $215,000.

The Identity Matters Framework

Here's how I evaluate the "unauthorized person" factor:

Very High Risk Recipients:

• Unknown individuals

• Competitors

• Media outlets

• Anyone with apparent malicious intent

• Public disclosure (internet posting, lost in public place)

High Risk Recipients:

• Former employees (especially if terminated for cause)

• Vendors without business associate agreements

• Individuals outside the healthcare/covered entity

• Multiple unknown recipients

Moderate Risk Recipients:

• Current employees without need to know

• Business associates under BAA

• Other covered entities (but outside treatment relationship)

• Known individuals with no apparent misuse intent

Lower Risk Recipients:

• Employees with partial need to know

• Treating providers within care coordination

• Business associates actively engaged in permitted services

• Individuals with demonstrated immediate destruction/non-viewing

Real Case Study: The Fax Machine Mistake

In 2020, I worked with a hospital that faxed patient records to the wrong doctor's office. The fax contained full medical records for 8 patients, including SSNs and sensitive diagnoses.

Here's how we built the low probability of compromise argument:

1. Recipient Identity: Another physician's office bound by HIPAA

2. Immediate Response: Called recipient within 12 minutes of discovering error

3. Documented Cooperation: Recipient confirmed the fax was received, unread, and immediately fed through cross-cut shredder

4. Physical Evidence: Recipient provided video of document destruction

5. Written Attestation: Signed statement that no PHI was viewed or disclosed

6. Technical Evidence: Fax logs showing only one successful transmission

Result: Successfully documented low probability of compromise. No breach notification required.

Cost: Approximately $15,000 in legal review and documentation.

Comparison: Breach notification for 8 patients would have been about $8,000 in direct costs, but the reputational damage and OCR attention would have been significantly worse.

"The quality of your relationship with the unauthorized recipient can be the difference between notification and no notification. Document everything."

Factor 3: Whether PHI Was Actually Acquired or Viewed

This is the factor that causes the most confusion, because it requires proving a negative: that something didn't happen.

The Evidence Hierarchy

After conducting hundreds of these assessments, I've developed a hierarchy of evidence strength:

The Laptop Encryption Decision Tree

I've created this decision tree based on dozens of lost/stolen device assessments:

Encrypted Device (FIPS 140-2 validated encryption or equivalent):

• Device not recovered: Low probability of compromise ✓

• Device recovered, no evidence of access attempts: Low probability of compromise ✓

• Device recovered, evidence of unsuccessful access attempts: Low probability of compromise ✓

• Device recovered, evidence of successful decryption: BREACH - Notification required ✗

Encrypted Device (Non-validated encryption):

• Requires additional analysis of encryption strength

• May not be sufficient alone for low probability determination

• Consider consulting with forensics expert

Password-Protected Only (Not Encrypted):

• Password-protected ≠ Encrypted

• Generally insufficient for low probability determination

• Requires extraordinary mitigating circumstances

No Protection:

• Almost never qualifies as low probability

• Notification required except in exceptional circumstances

Real Case: The Parking Lot Laptop

Remember the laptop I mentioned at the beginning? Here's how that situation unfolded.

The laptop was found in the parking lot after three months. It belonged to a nurse who had left the practice. Here's what we discovered:

Initial Information:

• Laptop contained PHI for approximately 2,200 patients

• Laptop was password-protected but NOT encrypted

• Laptop was in weather-damaged condition

• Found by a Good Samaritan who turned it in

Investigation Steps We Took:

1. Forensic Analysis ($4,500): Brought in a digital forensics firm to examine the device

2. Last Access Review: Determined last login was the day before the nurse's last day of work

3. Weather Damage Assessment: Laptop had significant water damage; would not power on

4. Hardware Analysis: Hard drive was physically damaged and unreadable

5. Good Samaritan Interview: Individual who found laptop provided signed statement that they did not attempt to access it

Four-Factor Analysis:

Decision: After legal review and extensive documentation, we determined this qualified as low probability of compromise.

Key Factor: The forensic evidence proving the device was physically damaged beyond access capability was decisive.

Cost: $12,500 in forensics, legal review, and documentation vs. estimated $185,000 for breach notification and management.

But here's the critical lesson: without the forensic analysis, this would have been a required notification. The password protection alone was insufficient.

Factor 4: Extent to Which Risk Has Been Mitigated

This is the most misunderstood factor, because organizations think mitigation can overcome other risk factors.

Let me be blunt: it can't.

What Mitigation Can and Cannot Do

What Mitigation CAN Help With:

What Mitigation CANNOT Overcome:

The Timeline Matters More Than You Think

In my experience, the speed of your mitigation response dramatically affects the strength of your low probability argument:

Response Timeline Impact:

• Within minutes: Strongest case; demonstrates immediate action prevented compromise

• Within hours: Strong case; rapid response limited exposure window

• Within 1-2 days: Moderate case; reasonable response but exposure window concerning

• Within 3-7 days: Weak case; extended exposure window difficult to justify

• Beyond 7 days: Very weak case; lengthy exposure undermines mitigation argument

Real Example: The Email That Almost Became a Breach

A specialty clinic accidentally emailed 43 patient records to a patient's personal email address instead of their secure patient portal message. The email included lab results, diagnoses, and treatment plans.

Timeline of Response:

• 4:32 PM: Email sent

• 4:47 PM: Error discovered by staff member

• 4:51 PM: IT contacted patient via phone

• 4:58 PM: Patient confirmed email received, unopened

• 5:03 PM: IT remotely accessed patient's email account (with verbal permission and documented consent)

• 5:07 PM: Email deleted from inbox, sent folder, and trash

• 5:15 PM: Email server logs pulled showing no forwarding or additional access

• 5:45 PM: Patient provided written confirmation via secure portal

Total Response Time: 73 minutes from send to complete mitigation.

Four-Factor Analysis:

1. Nature/Extent: Moderate sensitivity - lab results and diagnoses

2. Unauthorized Person: Wrong patient (not unrelated third party) under HIPAA

3. Actual Viewing: Strong evidence of non-viewing - unopened, remote deletion, patient cooperation

4. Mitigation: Exceptional - within one hour, complete evidence chain, cooperative recipient

Result: Low probability of compromise determination.

Key Success Factor: The speed and documentation of the response.

If they had discovered this error the next day, even with the same cooperation, the case for low probability would have been much weaker.

"In breach assessment, documentation isn't just important—it's everything. If you can't document it, it didn't happen in the eyes of the OCR."

The Assessment Documentation: What the OCR Wants to See

Here's something most people don't realize: the OCR doesn't just want your conclusion—they want to see your work.

I've reviewed hundreds of breach assessments, and the ones that survive OCR scrutiny share specific characteristics.

The Anatomy of a Defensible Breach Assessment

Required Components:

1. Incident Summary

   • Date and time of discovery

   • How the incident was discovered

   • Timeline of events

   • Individuals involved

2. Four-Factor Analysis (This is critical)

   • Detailed analysis of EACH factor

   • Specific evidence supporting each conclusion

   • Consideration of aggravating and mitigating circumstances

3. Evidence Documentation

   • Technical logs

   • Forensic reports

   • Witness statements

   • Correspondence with unauthorized recipients

   • Photographs or videos where applicable

4. Expert Consultation (when applicable)

   • Legal review

   • Forensic analysis

   • Technical security assessment

5. Decision Rationale

   • Clear explanation of why the specific facts support the conclusion

   • Acknowledgment of any uncertain factors

   • Explanation of how mitigating factors address risks

6. Alternative Scenarios Considered

   • What other outcomes were possible

   • Why they were less likely than your conclusion

Real Assessment Document Structure

Here's a redacted outline from an actual low probability determination I conducted:

BREACH RISK ASSESSMENT
Incident: Misdirected Fax Transmission
Date of Incident: [DATE]
Date of Assessment: [DATE]
Prepared By: [NAME/TITLE]

This assessment was 23 pages long for an incident involving 8 patients. That's the level of documentation needed to support a low probability determination.

Common Mistakes That Trigger OCR Investigation

After fifteen years, I've seen certain mistakes repeated over and over. Each one has resulted in OCR investigations for my clients or other organizations I've observed.

The Top 10 Assessment Failures

The "Red Flags" That Attract OCR Attention

The OCR looks for patterns. Here are the red flags that trigger deeper investigation:

Pattern Red Flags:

• Multiple low probability determinations in short timeframe

• Low probability determinations for obviously high-risk scenarios

• Consistent low probability determinations when peer organizations report similar incidents

• Low probability determination followed by patient complaints

Documentation Red Flags:

• Assessment completed months after incident

• Minimal documentation supporting conclusion

• No evidence of four-factor analysis

• Missing legal or technical expert review

• Inconsistent facts within assessment

Circumstantial Red Flags:

• Previous OCR investigation or settlement

• Industry sector with high breach notification rates

• Local media coverage of incident

• Patient advocacy group involvement

The Financial Reality: Cost-Benefit Analysis

Let me share some hard numbers from my experience.

Average Costs by Incident Type

Important Note: These costs include legal review, forensic analysis when needed, documentation, and decision-making time. Breach notification costs include notification letters, call center, credit monitoring (when appropriate), and incident management.

When Assessment Investment Doesn't Make Sense

Sometimes, the math just doesn't work. Here are scenarios where I typically recommend proceeding directly to breach notification:

1. Clear Public Disclosure: PHI posted online, sent to media, or otherwise publicly available

2. Malicious Intent Confirmed: Insider threat with documented exfiltration

3. Large Volume with Weak Mitigation: 10,000+ records with minimal security controls

4. Extended Exposure with Unknown Access: Device lost for months with no encryption

5. Very Low Assessment Cost vs. Notification Cost: Fewer than 10 affected individuals in straightforward scenario

"Sometimes the courage to notify is more important than the creativity to avoid notification. A defensible low probability determination is worth the investment. A questionable one is not."

Building Your Assessment Process

Most healthcare organizations I work with don't have a structured breach assessment process. They make it up each time an incident occurs. That's a recipe for inconsistent decisions and OCR trouble.

The Assessment Team Structure

Core Team (Every Assessment):

• Privacy Officer (lead)

• Security Officer (technical analysis)

• Legal Counsel (regulatory interpretation)

• Risk Management (organizational impact)

Extended Team (As Needed):

• Forensic Analyst (technical incidents)

• Clinical Leadership (patient care impact)

• Communications (if notification likely)

• IT Management (technical controls verification)

The Assessment Timeline

Based on hundreds of assessments, here's a realistic timeline:

Day 1: Immediate Response (0-24 hours)

• Incident containment

• Initial information gathering

• Preliminary determination of potential breach status

• Convene assessment team

Days 2-3: Investigation (24-72 hours)

• Detailed fact gathering

• Evidence collection

• Witness interviews

• Technical analysis

Days 4-7: Analysis (3-7 days)

• Four-factor evaluation

• Legal review

• Expert consultation if needed

• Draft assessment document

Days 8-14: Decision and Documentation (7-14 days)

• Final determination

• Complete documentation

• Leadership approval

• Retain records

Total Timeline: 14 days maximum from discovery to determination

The HIPAA Breach Notification Rule requires notification within 60 days of discovery. My recommendation: complete your assessment within 14 days. This gives you time to properly investigate while leaving buffer time for notification if required.

Decision-Making Framework

I use this framework with every client:

Step 1: Initial Screening

• Is this a potential breach?

• Is it clearly a reportable breach?

• Is there any possibility of low probability?

Step 2: Evidence Gathering

• What facts are known?

• What facts can be determined?

• What facts cannot be determined?

Step 3: Four-Factor Analysis

• Evaluate each factor independently

• Consider factors collectively

• Identify critical evidence gaps

Step 4: Risk-Benefit Analysis

• Cost of thorough assessment

• Probability of successful low probability determination

• Risk of incorrect determination

• Organizational risk tolerance

Step 5: Decision

• Low probability OR Notification

• If uncertain, lean toward notification

My Personal Assessment Philosophy

After 15 years and over 200 breach assessments, here's what I've learned:

1. When in doubt, notify. The risk of a wrong low probability determination far exceeds the cost of unnecessary notification.

2. Document everything. If your assessment can't survive OCR scrutiny three years later, don't make it.

3. Invest in prevention. The best breach assessment is the one you never have to do because encryption prevented the breach.

4. Speed matters. The faster your response, the stronger your mitigation argument.

5. Relationships matter. Good relationships with business associates, patients, and other healthcare entities can make the difference in successful mitigation.

6. Technology is your friend. Encryption, logging, DLP, and remote wipe capabilities aren't just security controls—they're breach assessment insurance.

7. Legal review is not optional. This is a legal determination with regulatory implications. Don't DIY it.

The Cases That Haunt Me

I'll end with two stories that have shaped how I approach every assessment.

The Case I Got Wrong (Almost): In 2017, I conducted an assessment for an employee who accessed records without authorization. The employee had viewed 127 patient records over six weeks. We determined low probability of compromise because:

• Employee was terminated

• No evidence of exfiltration

• Employee signed attestation of no disclosure

• Limited viewing time per record

Three months later, we discovered the employee had photographed screens with their personal phone. They posted them on social media after a dispute with the organization.

We immediately reported to OCR, conducted full notification, and implemented additional monitoring controls. The settlement was $445,000.

Lesson: Malicious intent is almost impossible to mitigate, and attestations from adverse parties are nearly worthless.

The Case I Got Right: In 2022, a clinic lost a laptop with 3,800 patient records. Unencrypted. Lost for two weeks. Found in a taxi.

Everything screamed "breach notification required." Except...

The forensic analysis revealed the laptop battery had died within hours of being lost (the nurse reported it was at 2% when she last used it). The laptop required AC power to boot—it couldn't run on battery alone due to a hardware defect. The taxi driver who found it confirmed it was dead and he couldn't charge it. The laptop had a BIOS password preventing boot even with AC power.

With forensic evidence proving the device couldn't have been accessed without: (a) AC power, (b) BIOS password, and (c) Windows password, we successfully determined low probability of compromise.

Total assessment cost: $27,000 Avoided notification cost: ~$320,000 OCR review: No investigation

Lesson: The right evidence can overcome even obviously bad scenarios, but you need expert analysis and thorough documentation.

Your Action Items

If you're responsible for HIPAA compliance:

Immediate Actions:

1. Review your current breach response procedures

2. Identify your assessment team members

3. Establish relationships with forensic and legal experts before you need them

4. Document your four-factor analysis framework

Short-term (30 days):

1. Conduct tabletop exercises for common breach scenarios

2. Create assessment documentation templates

3. Train your team on the four-factor analysis

4. Review your technical security controls (especially encryption)

Long-term (90 days):

1. Implement or improve encryption programs

2. Enhance logging and monitoring capabilities

3. Establish relationships with other healthcare entities for mutual mitigation

4. Create incident-specific assessment playbooks

Final Thoughts

The HIPAA breach assessment process isn't about avoiding your obligations. It's about making accurate, defensible determinations about when patient data has been compromised and when it hasn't.

In fifteen years, I've seen the OCR become increasingly sophisticated in their evaluation of low probability determinations. They're not looking to punish organizations for thoughtful, well-documented assessments. But they're absolutely looking for organizations trying to game the system.

The organizations that succeed are those that:

• Invest in prevention first

• Respond immediately when incidents occur

• Conduct thorough, documented assessments

• Make conservative decisions when facts are unclear

• Learn from each incident to prevent future ones

The organizations that fail are those that view breach assessment as a way to avoid notification rather than a framework for accurate determination.

"A low probability determination should be a conclusion you reach through evidence, not a goal you work backwards to justify."

Get it right. Document thoroughly. When in doubt, notify. And invest in security controls that make the determination clear.

Because the best breach assessment is the one where encryption, logging, and security controls make the answer obvious from the start.