This repository contains a sanitized security vulnerability disclosure report (SVDR) documenting HIPAA Security Rule violations observed at a healthcare facility during routine patient visits. The vulnerabilities — plaintext credentials displayed on clinical workstations, unattended authenticated sessions, and exposed EHR login portals — were identified through passive observation only. No systems were accessed, tested, or manipulated in any way.
The report was written independently and submitted to the affected organization's compliance leadership. All identifying information has been sanitized for public disclosure.
I created this report because the vulnerabilities I observed posed a genuine risk to patient privacy, and I believed the organization needed a clear, actionable document to understand the severity and prioritize remediation. I'm sharing it here because the work demonstrates skills that don't always come through on a resume: the ability to identify real-world security gaps, map them to a regulatory framework, assess business risk, and communicate findings to a non-technical audience in a way that drives action.
- Regulatory Analysis: Mapping of observed conditions to specific HIPAA Security Rule provisions (45 CFR §§ 164.308, 164.310, 164.312), including the distinction between "required" and "addressable" implementation specifications
- Financial Risk Assessment: Tiered penalty exposure under the current OCR enforcement structure, including enforcement discretion adjustments
- Technical Findings: Detailed documentation of each vulnerability, its observable characteristics, and its security impact
- Threat Modeling: Four attack scenarios ranging from opportunistic patient access to coordinated data exfiltration, illustrating how low-complexity physical vulnerabilities enable high-impact outcomes
- Remediation Roadmap: Phased corrective actions (immediate, short-term, medium-term) with resource considerations scaled to typical clinic IT budgets
- Security Assessment & Risk Analysis — Identifying and documenting vulnerabilities with a structured methodology, including clear scoping of what was and was not done during observation
- Regulatory Knowledge (HIPAA) — Applying the HIPAA Security Rule to real-world conditions, including proper handling of "addressable" vs. "required" specifications and current penalty structures
- Threat Modeling — Developing realistic attack scenarios that connect physical security gaps to their downstream consequences
- Responsible Disclosure — Conducting observations ethically (passive only, no credential use, no system access), clearly documenting that ethical boundary, and reporting findings to the appropriate parties
- Technical Writing & Stakeholder Communication — Translating technical findings into a format accessible to compliance officers, administrators, and legal counsel
Were the vulnerabilities actually reported to the organization?
Yes. The report was submitted to the organization's compliance leadership. I chose to formalize the findings in a structured disclosure report rather than an informal complaint because the severity warranted documentation that could support remediation planning and, if necessary, regulatory response.
Why did the observation period span four months?
The initial observation occurred during a routine appointment. Subsequent visits over the following months confirmed that the conditions were persistent and systemic rather than a one-time lapse. Establishing that pattern was important — a single unlocked workstation on a single day is a procedural miss; the same conditions observed repeatedly over months indicates a policy or configuration gap.
Did you access any systems or attempt to use the credentials you observed?
No. The report's Disclosure Statement and Operational Safety sections address this directly. All observations were made passively from patient-accessible areas. No credentials were entered, no systems were touched, and no attempts were made to verify what the displayed credentials corresponded to. That boundary was deliberate and non-negotiable.
How thoroughly is this sanitized?
The organization's name, specific location, staff identifiers, and any details that could directly identify the facility have been removed. References to prior security incidents are described by category only (e.g., "unauthorized employee access," "vendor-related ransomware") — these categories are unfortunately common enough across the healthcare sector that they do not meaningfully narrow identification.
Is this a real report or a hypothetical exercise?
This is a real report based on real observations. That's the point. It's easy to write a theoretical vulnerability assessment against a textbook scenario. The value of this document is that it was written in response to actual conditions, under the constraint of ethical observation, with findings that had to be accurate enough to present to organizational leadership.
| File | Description |
|---|---|
SVDR_Sanitized.pdf |
The sanitized Security Vulnerability Disclosure Report |
README.md |
This file |
If you'd like to discuss this project, my approach to security assessment, or my qualifications, feel free to reach out via https://www.linkedin.com/in/mdues/.
This report reflects my independent analysis and does not represent the views of the affected organization. All observations were made lawfully during routine patient visits in publicly accessible areas. All visits were for legitimate healthcare purposes.