The Marathon Health breach highlights a critical vulnerability in healthcare data security: social engineering. An unauthorized individual posed as a Marathon IT worker, tricking an employee into revealing credentials. These credentials accessed a cloud-hosted application, leading to data export in just a few hours on August 24, 2026. Approximately 5.7 million people were affected, including those who never received care from the company but had their plan enrollment data shared for coverage verification.
No malware was involved; the breach resulted from a human decision and access that allowed one set of credentials to reach a vast data set. This checklist addresses these issues under the HIPAA Security Rule and the HIPAA Privacy Rule. Each item includes a done/not-done test and a description of what effective implementation looks like.
Prerequisites
Before using this checklist, ensure you have:
- An up-to-date inventory of systems that create, receive, maintain, or transmit ePHI, including cloud-hosted applications.
- A completed, dated Security Risk Analysis (45 CFR 164.308(a)(1)(ii)(A)).
- An inventory of business associate and plan-sponsor data flows, including data on non-patients.
- Designated owners for security incidents, workforce training, and breach notification.
Checklist
1. Social engineering is a named threat in your risk analysis.
Reference: 45 CFR 164.308(a)(1)(ii)(A) and (B). Done when your risk analysis lists IT-impersonation and credential-phishing scenarios against specific systems, with likelihood and impact ratings. Effective implementation includes a risk register entry tracing a stolen credential to the specific application and data set it would expose.
2. Workforce training covers IT-impersonation pretexts.
Reference: 45 CFR 164.308(a)(5). Done when training content includes scenarios of a caller or message posing as internal IT and requesting credentials, MFA codes, or remote access. Effective training means staff can state the rule without prompting: IT never asks for your password or a one-time code, and every such request gets reported.
3. Training is tested, not just delivered.
Done when you run simulated vishing and phishing exercises regularly and track report rates, not just click rates. Effective implementation shows a documented trend of employees reporting suspicious contact, with results feeding the next training cycle.
4. A verified call-back procedure exists for IT requests.
Done when help desk and employees have a written procedure to verify any IT contact through a known channel before acting. Effective procedures are memorable and followed by the help desk, including for executives.
5. Phishing-resistant multi-factor authentication protects every ePHI application.
Reference: 45 CFR 164.312(d), person or entity authentication. Done when MFA is enforced on all cloud applications holding ePHI, with hardware keys or passkeys for administrators and high-volume data users. Effective implementation ensures a stolen password alone cannot open a session, and push-approval fatigue and code relay are blocked by design.
6. Access follows the Principle of Least Privilege.
Reference: 45 CFR 164.308(a)(4) and 164.312(a)(1). Done when Role-Based Access Control limits who can query or export bulk records, and you can show quarterly access reviews. Effective implementation means one compromised employee account cannot reach an entire patient and plan-member population.
7. Bulk export is restricted and monitored.
Reference: 45 CFR 164.312(b), audit controls. Done when exports above a defined volume require approval or trigger an alert, and export events are logged. Effective implementation means an unusual multi-hour extraction produces a real-time alert to the Computer Security Incident Response Team.
8. Session and anomaly detection catch unfamiliar behavior.
Done when you alert on logins from unusual locations, devices, or times, and on credential use immediately after a reset or MFA change. Effective implementation detects suspicious account activity quickly and disables the account before the export finishes.
9. Incident response plan includes a credential-compromise playbook.
Reference: 45 CFR 164.308(a)(6). Done when the plan has a tested playbook covering account disablement, session revocation, scoping of accessed data, and evidence preservation. Effective implementation includes a tabletop exercise within the past twelve months showing the team can scope what a single compromised account touched.
10. Data scoping and review can be completed fast.
Done when you can identify which individuals' data sat in an affected application and in what fields. Effective implementation includes data mapping that lets you move from containment to a confirmed affected-population list without rebuilding the picture from scratch.
11. Breach notification clocks are mapped and rehearsed.
Reference: 45 CFR 164.404 (individuals), 164.406 (media), 164.408 (HHS). Done when your plan states the 60-day outer limit from discovery, who decides on a breach determination, and who drafts letters and regulator filings. Effective implementation ensures individual notices are mailed well inside the outer limit, with state attorney general and HHS Office for Civil Rights filings prepared in parallel.
12. Business associate and plan-sponsor data flows are accounted for.
Done when your notification process covers individuals who are not patients but whose data you hold, and your contracts define who notifies whom. Effective implementation means you can explain to a recipient why you hold their data, and your notice does not confuse people who never used your services.
13. Remediation after an incident is documented.
Reference: 45 CFR 164.316(b), documentation retention. Done when corrective actions, dates, owners, and evidence are retained for six years. Effective implementation means an OCR investigator can read your file and see cause, fix, and verification without interviews.
Common Mistakes
- Treating annual training as the control. One yearly module doesn't stop a convincing caller. Without a verification procedure and technical limits, training alone shifts all risk onto one employee's judgment.
- Standard MFA everywhere, phishing-resistant MFA nowhere. If an employee will hand over a password, they may hand over a code too.
- Broad standing access. When a single account can export an entire data set, one successful pretext becomes a large-scale breach.
- Forgetting non-patient data. Enrollment feeds from plan sponsors put people in your systems who don't know you exist. Your risk analysis and notification plan must include them.
- Slow scoping. Detection can be fast, but breach determination still takes weeks if your data isn't mapped.
Next Steps
Score each item as done or not done, then rank the gaps by how much data one compromised credential could reach. Items 5, 6, and 7 usually shrink exposure fastest. Schedule a tabletop exercise built around the IT-impersonation scenario, and have your breach notification lead walk the 60-day clock end to end with a realistic affected-population size. Feed the results into your next Security Risk Analysis update, and brief leadership on residual gaps with owners and dates attached.
