Module 02E — HIPAA Security Rule: The Federal Law That Turns a Pen Test Into a Criminal Exposure

Non-Lawyers Summary

HIPAA is not just a compliance checkbox — it is a federal regulatory regime with civil fines up to $1.9 million per violation category per year, criminal penalties up to 10 years, and an HHS public "Wall of Shame" that names every organization that breaches 500 or more patient records. For security researchers, healthcare pen testers, and red teamers, HIPAA creates obligations and risks that do not exist in ordinary commercial engagements. The data you touch during a test — even temporarily, even accidentally — is likely protected health information (PHI) subject to federal law. Your client's authorization letter does not automatically make you compliant. You need a Business Associate Agreement (BAA), a defined scope that avoids unnecessary PHI access, and a data destruction protocol for anything you do encounter. This module maps the full statute, enforcement history, and practical do/don't matrix so you can work in healthcare environments without becoming a defendant.

1. HIPAA Architecture: Three Rules, One Ecosystem

Just before dawn on February 21, 2024, somewhere deep inside the infrastructure of Change Healthcare — a company most Americans had never heard of but whose systems quietly processed one in three U.S. medical claims — a threat actor moved laterally across the network. They had been inside for weeks. No alarm had fired. No human had noticed. By the time the sun rose, they had their hands on an estimated 100 million patient records. The ransom demand arrived shortly after.

What happened next would define HIPAA enforcement for years.

But that wasn't the real story. The real story was simpler, and more damning: the attackers got in through a Citrix portal with no multi-factor authentication. A control that costs almost nothing to implement. A control that every reasonable risk analysis under the Security Rule would have flagged as non-negotiable. The law had been there all along. The safeguard had been ignored.

This is the world HIPAA operates in.

HIPAA is not a single rule. It is a statutory framework — the Health Insurance Portability and Accountability Act of 1996, Pub. L. 104-191 — implemented through three interconnected regulations that together form a surveillance-grade legal cage around the most sensitive data human beings generate:

1.1 The Privacy Rule — 45 C.F.R. Part 164, Subpart E

The Privacy Rule governs who can see, use, and disclose individually identifiable health information in any form — paper, oral, or electronic. It applies to covered entities: health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. The Privacy Rule establishes patient rights — the right to access their own records, request amendments, and receive an accounting of disclosures.

Relevance to security researchers: The Privacy Rule is background law. When you access a production healthcare system during a pen test and inadvertently view a patient record, the Privacy Rule's prohibitions on unauthorized use and disclosure apply — even if you never exfiltrate the data. Accessing records you are not authorized to see violates the Privacy Rule regardless of your intent.

1.2 The Security Rule — 45 C.F.R. Parts 160 and 164, Subparts A and C

The Security Rule is the technical and operational core. It applies only to electronic protected health information (ePHI). It requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect ePHI. This is the rule that drives pen test scope letters, risk analyses, and security program requirements.

Relevance to security researchers: The Security Rule defines the standards your healthcare clients must meet — which means it defines what you are testing for. Understanding the Security Rule tells you what controls should exist, what gaps look like, and what the legal consequences of a failed control are.

1.3 The Breach Notification Rule — 45 C.F.R. Part 164, Subpart D

The Breach Notification Rule requires covered entities to notify affected individuals, HHS, and — for large breaches — the media within specific timeframes after discovering a breach of unsecured PHI. Business associates must notify the covered entity within 60 days of discovering a breach.

Relevance to security researchers: If your pen test discovers — or creates — a breach of unsecured PHI, you may have triggered your client's notification obligations. Your engagement should define in advance how discovered vulnerabilities involving actual PHI exposure are handled, including who bears responsibility for notifying affected parties.

2. Who Is Bound: Covered Entities, Business Associates, and the Subcontractor Chain

There is a category of professional who walks into a hospital's network with a Kali Linux laptop and a signed scope letter and believes, with genuine confidence, that they are operating outside the blast radius of federal health data law.

They are wrong.

2.1 Covered Entities

The Security Rule directly applies to three categories:

2.2 Business Associates

A Business Associate (BA) is any person or entity that performs functions or services on behalf of a covered entity that involve access to PHI — and is not a member of the covered entity's workforce. This definition is broader than most people realize.

Business associates include:

• Third-party billing services
• EHR vendors
• Cloud hosting providers who store ePHI
• Medical transcription services
• Attorneys, accountants, and consultants who access PHI in the course of providing services
• Penetration testers and security firms who access or may access ePHI during an engagement

The HITECH Act of 2009 (Health Information Technology for Economic and Clinical Health Act, Pub. L. 111-5) changed everything. It extended direct Security Rule liability to business associates. Prior to HITECH, BAs had contractual obligations to covered entities but were not directly regulated by HHS. Post-HITECH, HHS OCR can directly enforce the Security Rule against a BA — regardless of whether the covered entity suffered a breach.

The pen tester who assumed their scope letter was their only legal exposure had not read HITECH.

2.3 PHI vs. ePHI

Protected Health Information (PHI) is individually identifiable health information that relates to:

• An individual's past, present, or future physical or mental health condition;
• The provision of healthcare to an individual; or
• The past, present, or future payment for healthcare provided to an individual.

PHI includes 18 specific categories of identifiers under the Privacy Rule (45 C.F.R. § 164.514(b)): names, geographic data smaller than a state, dates (other than year), phone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate/license numbers, VINs, device identifiers and serial numbers, web URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code.

ePHI is PHI that is created, received, maintained, or transmitted in electronic form. The Security Rule applies exclusively to ePHI. A paper chart with patient information is governed by the Privacy Rule but not the Security Rule. A scanned image of that same chart stored on a server is ePHI subject to the Security Rule.

Practical implication for pen testers: If you are testing an EHR application and you can pull patient records through a BOLA vulnerability, every record you retrieve — even to prove the bug — is ePHI. Your legal exposure does not depend on whether you intended to access it. It depends on whether you accessed it without proper authorization and appropriate safeguards in place.

3. The Three Safeguard Categories Under the Security Rule

The Security Rule does not mandate specific technologies. It is more demanding than that. It requires covered entities and BAs to implement "reasonable and appropriate" safeguards calibrated to size, complexity, capabilities, and risk — which means the law is always watching what you chose not to do.

The framework is built on three pillars:

3.1 Administrative Safeguards — 45 C.F.R. § 164.308

Administrative safeguards are the policies, procedures, and management decisions that govern how an organization implements its security program. They include:

Security Management Process (Required):

• Risk analysis — a thorough, accurate assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI
• Risk management — implementing security measures sufficient to reduce identified risks to a reasonable and appropriate level
• Sanction policy — applying appropriate sanctions against workforce members who fail to comply with security policies
• Information system activity review — regularly reviewing records of information system activity (audit logs, access reports, security incident tracking reports)

Assigned Security Responsibility (Required): A covered entity must designate a Security Officer responsible for developing and implementing security policies. For small practices, this can be the same person as the Privacy Officer. For large health systems, it is typically a CISO or equivalent.

Workforce Security (Addressable):

• Authorization and supervision of workforce members who work with ePHI
• Workforce clearance procedures
• Termination procedures to revoke access upon departure

Information Access Management (Addressable):

• Policies for authorizing access to ePHI consistent with the minimum necessary standard
• Access establishment and modification procedures

Security Awareness and Training (Addressable):

• Security reminders
• Protection from malicious software
• Log-in monitoring
• Password management

Security Incident Procedures (Required): Policies and procedures for responding to and reporting security incidents, including documentation of incidents and their outcomes.

Contingency Plan (Addressable/Required mix):

• Data backup plan (Required)
• Disaster recovery plan (Required)
• Emergency mode operation plan (Required)
• Testing and revision procedures (Addressable)
• Applications and data criticality analysis (Addressable)

Evaluation (Required): Periodic technical and nontechnical evaluation of security policies and procedures, triggered by environmental or operational changes.

Business Associate Contracts (Required): Written contracts (BAAs) with all business associates. See Section 7 for BAA content requirements.

3.2 Physical Safeguards — 45 C.F.R. § 164.310

Physical safeguards govern physical access to systems that contain ePHI.

Facility Access Controls (Addressable):

• Contingency operations (access during emergencies)
• Facility security plans
• Access control and validation procedures
• Maintenance records for physical access controls

Workstation Use (Required): Policies specifying proper functions performed on workstations that access ePHI, and the physical attributes of the surroundings.

Workstation Security (Required): Physical safeguards for workstations — positioning monitors away from public view, locking workstations when unattended, securing laptop computers.

Device and Media Controls (Addressable/Required mix):

• Disposal of ePHI on hardware and electronic media (Required)
• Media reuse policies (Required)
• Accountability tracking for hardware and media movement (Addressable)
• Data backup and storage (Addressable)

3.3 Technical Safeguards — 45 C.F.R. § 164.312

Technical safeguards are the technology controls that protect ePHI and control access to it.

Access Controls (Required/Addressable mix):

• Unique user identification (Required) — every user gets a unique ID; no shared accounts
• Emergency access procedure (Required) — mechanism to obtain ePHI during an emergency
• Automatic logoff (Addressable) — electronic session termination after inactivity
• Encryption and decryption (Addressable) — encrypting ePHI at rest

Audit Controls (Required): Hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI. Under the 2025 NPRM, HHS proposed requiring audit log retention for 6 years.

Integrity (Addressable): Policies and procedures to protect ePHI from improper alteration or destruction, including electronic mechanisms to authenticate that ePHI has not been altered or destroyed in an unauthorized manner.

Person or Entity Authentication (Required): Verification that a person or entity seeking access to ePHI is who they claim to be.

Transmission Security (Addressable): Guards against unauthorized access to ePHI transmitted over an electronic communications network. Includes encryption of ePHI in transit.

4. Required vs. Addressable Controls: The Most Dangerous Misconception in Healthcare Security

Somewhere in a boardroom, every few months, a healthcare executive hears the word "addressable" and feels relief.

They shouldn't.

4.1 The "Addressable" Myth

"Addressable" does not mean optional. It does not mean "nice to have." It does not mean you can skip it.

The regulatory text at 45 C.F.R. § 164.306(d)(3) defines "addressable implementation specification" precisely: a covered entity must assess whether the specification is a reasonable and appropriate safeguard in its environment. If it is reasonable and appropriate, the entity must implement it. If it is not reasonable and appropriate, the entity must document why — with specificity — and implement an equivalent alternative measure that achieves the same purpose.

In practice, this means:

• A covered entity cannot simply decline to implement encryption of ePHI in transit and claim the control was "addressable." It must document a specific, reasoned analysis showing why encryption is not reasonable and appropriate in its specific environment — an analysis that is essentially impossible to sustain given modern threat landscapes — or it must implement an equally effective alternative.
• OCR has assessed civil monetary penalties against covered entities that treated "addressable" specifications as optional without conducting the required analysis or implementing alternatives.

The organizations that paid those penalties believed they had a defense. They did not.

4.2 Required Specifications

Required implementation specifications must be implemented. There is no flexibility — no documented analysis can excuse non-implementation. Examples include:

• Unique user identification (no shared accounts)
• Emergency access procedures
• Audit controls
• Security incident procedures
• Risk analysis
• Risk management
• BAAs with all business associates

4.3 Practical Impact on Pen Testers

When you conduct a healthcare pen test and find:

• Shared administrative accounts — this is a Required specification violation (unique user identification)
• No audit logging of ePHI access — this is a Required specification violation
• ePHI transmitted unencrypted over internal networks — this is an Addressable specification finding, but the entity must have a documented analysis justifying the alternative; if there is no such analysis, it is a Security Rule violation
• No BAA with your firm — this is a Required specification violation before the test even begins

5. The Breach Notification Rule: Clocks, Thresholds, and the Wall of Shame

5.1 What Triggers the Rule

A "breach" under 45 C.F.R. § 164.402 is the acquisition, access, use, or disclosure of unsecured PHI in a manner not permitted by the Privacy Rule. There is a presumption of breach — the covered entity or BA bears the burden of demonstrating, through a risk assessment, that there is a low probability that the PHI was compromised.

Unsecured PHI is PHI that has not been rendered unusable, unreadable, or indecipherable through the use of approved encryption or destruction methods specified in HHS guidance (currently NIST SP 800-111 for encryption at rest and FIPS 140-2 validated encryption for ePHI in transit). PHI that is properly encrypted according to HHS guidance is not subject to the Breach Notification Rule — this is the encryption "safe harbor" that makes encryption strategically valuable beyond pure security.

5.2 The 60-Day Clock for Covered Entities

Once the clock starts, it does not pause.

A covered entity must provide notice to affected individuals without unreasonable delay and in no case later than 60 calendar days after discovery of the breach (45 C.F.R. § 164.404(b)). Discovery occurs when the breach is known to any member of the covered entity's workforce, or with the exercise of reasonable diligence would have been known.

Individual notice must be provided in written form — by first-class mail, or email if the individual has agreed — and must contain (45 C.F.R. § 164.404(c)):

• A brief description of what happened, including the date of the breach and discovery
• A description of the types of unsecured PHI involved
• Any steps individuals should take to protect themselves
• A brief description of what the covered entity is doing to investigate, mitigate, and prevent future occurrences
• Contact procedures for individuals to ask questions

5.3 The 500-Person Threshold and the HHS Wall of Shame

For breaches affecting 500 or more individuals: The covered entity must notify the Secretary of HHS contemporaneously with individual notice — within the 60-day window. HHS posts these breaches to its publicly accessible database — colloquially known as the "Wall of Shame" — at hhs.gov/hipaa/for-professionals/breach-notification/breach-reporting. The database identifies the covered entity by name, the state, the number of individuals affected, the type of breach, and the location of the breached information.

This is reputationally devastating. Large healthcare breaches are covered by mainstream media. The Wall of Shame is searchable by anyone — patients, journalists, plaintiffs' attorneys, and state attorneys general.

For breaches affecting fewer than 500 individuals: The covered entity must maintain a log and notify HHS annually no later than 60 days after the close of the calendar year (45 C.F.R. § 164.408(c)).

5.4 Media Notice — 500 Individuals in a State or Jurisdiction

For breaches affecting more than 500 residents of a state or jurisdiction, the covered entity must also notify "prominent media outlets serving a State or jurisdiction" (45 C.F.R. § 164.406). This media notice must be provided without unreasonable delay and no later than 60 days after discovery. The notice must contain the same information required for individual notice.

5.5 Surrogate Notice

When the covered entity does not have sufficient contact information for affected individuals, it must provide "substitute notice" (45 C.F.R. § 164.404(d)). For breaches affecting more than 10 individuals for whom contact information is insufficient:

• Conspicuous posting on the covered entity's website for at least 90 days; or
• Notice in major print or broadcast media in the geographic area where the affected individuals likely reside.

5.6 Business Associate Notification

A business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay and in no case later than 60 days after discovery (45 C.F.R. § 164.410). The BA must provide the CE with the identification of each individual whose PHI was or is reasonably believed to have been involved in the breach.

Critical for pen testers: If your firm is a BA — and it almost certainly is if you access ePHI during testing — and your testing reveals or creates a breach, you have an obligation to notify your covered entity client. This obligation runs regardless of whether the breach was disclosed to you by the client, discovered by your own tools, or caused by your own testing activity.

6. Enforcement: Civil Penalties and Criminal Prosecution

6.1 HHS Office for Civil Rights (OCR) — Civil Monetary Penalties

HHS OCR has primary civil enforcement authority over HIPAA. The HITECH Act restructured the civil monetary penalty (CMP) framework into four tiers based on culpability (42 U.S.C. § 1320d-5, as amended). Read these numbers slowly:

"Per violation" means per impermissible use or disclosure, per patient record, per day of noncompliance — OCR has broad discretion in how it counts violations. In a breach affecting millions of patients, OCR can theoretically calculate penalties as one violation per patient, creating theoretical exposure in the hundreds of millions — though in practice, resolution agreements cap penalties at negotiated amounts.

State attorneys general may also bring HIPAA enforcement actions (42 U.S.C. § 1320d-5(d)), recovering civil damages for affected residents up to $25,000 per violation per year, plus attorneys' fees.

6.2 DOJ — Criminal Prosecution Under 42 U.S.C. § 1320d-6

The criminal HIPAA provision creates three tiers of criminal liability for knowingly obtaining or disclosing individually identifiable health information in violation of HIPAA:

"Knowingly" in the base offense means the defendant knew that the conduct was wrong — it does not require knowing that it violated HIPAA specifically. United States v. Zhou (8th Cir. 2012) addressed this in the context of a hospital employee who wrongfully accessed patient records.

Who gets charged criminally: Prosecutions under § 1320d-6 are primarily directed at healthcare employees who access patient records for personal reasons, insiders who sell patient data to medical identity theft rings, and individuals who impersonate healthcare personnel to obtain records.

Security researchers and pen testers are not the intended targets of § 1320d-6 prosecutions. But the statute does not contain an express security research exception. A pen tester who accesses ePHI without authorization — without a BAA, outside the agreed scope, or without the covered entity's knowledge — faces the same theoretical exposure as any other knowing unauthorized accessor.

7. Business Associate Agreements: Required Content, Downstream Liability, and the Subcontractor Chain

7.1 What a BAA Must Contain

A Business Associate Agreement (BAA) is a contract required by the Security Rule (45 C.F.R. § 164.308(b)(3)). Without a valid BAA, the covered entity is out of compliance regardless of whether the BA actually misused PHI. BAA requirements are specified at 45 C.F.R. § 164.504(e):

Required provisions — the BA must:

• Not use or further disclose PHI other than as permitted by the contract or required by law
• Use appropriate safeguards to prevent unauthorized use or disclosure
• Report to the covered entity any use or disclosure not provided for by the contract, including breaches of unsecured PHI
• Ensure that agents (including subcontractors) that create or receive PHI on the BA's behalf agree to the same restrictions
• Make its internal practices, books, and records available to HHS for determining the CE's compliance
• Return or destroy PHI at termination of the contract (or retain with continued protections if return/destruction is infeasible)
• Authorize the covered entity to terminate the contract if the BA violates a material term

For security researchers: Your Statement of Work and your BAA must explicitly address:

• The scope of ePHI you may encounter or access
• The minimum necessary standard — access only to what is needed for the engagement
• What happens to any ePHI captured during testing (screenshots, packet captures, tool outputs)
• Data destruction timelines and certification

7.2 Downstream Liability: Subcontractors

Under 45 C.F.R. § 164.308(b)(4), a BA must obtain written satisfactory assurances from any subcontractors who create, receive, maintain, or transmit PHI on the BA's behalf. This means:

• If your security firm subcontracts any portion of a healthcare pen test to another firm, you must have a BAA with that subcontractor.
• The subcontractor is directly liable to HHS OCR for its own Security Rule violations.
• A breach caused by a subcontractor can expose both the subcontractor and the prime contractor BA to penalties.

The subcontractor chain creates liability that flows downhill. The covered entity is responsible for ensuring it has BAAs with its direct BAs. Each BA is responsible for ensuring it has BAAs with its subcontractors. There is no direct contractual relationship between the CE and a sub-BA — but HHS can still directly enforce against the sub-BA.

8. Recent Enforcement: What Actually Gets Penalized

8.1 Change Healthcare Breach (2024) — The Largest Healthcare Breach in U.S. History

In February 2024, ALPHV/BlackCat ransomware attacked Change Healthcare. Without warning, systems that processed approximately one-third of all U.S. healthcare transactions went dark. Pharmacies could not fill prescriptions. Hospitals could not verify insurance. An estimated 100 million patient records were exfiltrated — the largest healthcare data breach in U.S. history.

What happened next would define the political conversation around healthcare cybersecurity for years.

Legal and regulatory aftermath:

• HHS OCR opened a formal investigation into UnitedHealth Group and Change Healthcare in April 2024
• The Senate Finance Committee and Senate Judiciary Committee launched congressional investigations
• Class action litigation was filed in multiple federal courts
• The American Hospital Association estimated the attack caused $1.6 billion in financial impacts to U.S. hospitals and health systems in the first two months alone
• Change Healthcare paid ALPHV/BlackCat a $22 million ransom — and then allegedly faced a secondary extortion demand from RansomHub, which claimed to have obtained the same exfiltrated data

Security failures at issue: Attackers gained initial access through Citrix remote access credentials that did not have multi-factor authentication enabled. MFA for remote access to ePHI systems is the type of safeguard that would be Required under an updated Security Rule and has long been considered baseline security practice under any reasonable risk analysis.

The lesson that now applies to everyone: the control was known. The gap was documented in a thousand pen test reports. And still it was not implemented. That's what willful neglect looks like.

8.2 Advocate Aurora Health — Pixel Tracking (2022-2023)

The attack came not from a foreign APT group. It came from a JavaScript snippet embedded in a patient scheduling widget — code that Advocate Aurora Health had installed voluntarily, believing it was a marketing tool.

Advocate Aurora Health, a large health system operating in Wisconsin and Illinois, disclosed in October 2022 that it had inadvertently shared the protected health information of up to 3 million patients with Meta and Google through tracking pixels embedded in its patient portal (MyChart) and scheduling widgets.

The technology: The Meta Pixel is JavaScript that transmits user activity data — including URL paths, button clicks, and form inputs — to Meta servers for advertising optimization. When embedded in authenticated patient portals, it transmitted ePHI (the fact that a patient was logged in, the scheduling actions they took, the health conditions visible in URL parameters) to Meta.

Legal significance: HHS OCR issued a bulletin in December 2022 clarifying that the use of tracking technologies on HIPAA-covered platforms constitutes a potential HIPAA violation when those technologies transmit ePHI to third parties without proper authorization. For security researchers: pixel tracking in authenticated healthcare applications is a legitimate finding with direct HIPAA enforcement implications.

8.3 HCA Healthcare (2023)

In July 2023, HCA Healthcare disclosed that data for approximately 11 million patients had been stolen from an external storage system. The stolen data appeared on a hacking forum. The data included patient names, addresses, dates of birth, email addresses, telephone numbers, appointment information, and partial payment information — constituting PHI under HIPAA.

HCA Healthcare faced class action lawsuits and congressional scrutiny. OCR's investigation into the breach was ongoing as of the time of this writing.

9. Medical Device Security: FDA 2023 Cybersecurity Guidance and § 524B FD&C Act

9.1 The Regulatory Framework Shift

For most of HIPAA's existence, medical device security was a regulatory gap. The FDA had general authority over device safety but had not specifically mandated cybersecurity requirements for premarket submissions.

Then came the Omnibus Consolidated Appropriations Act of 2023 (Pub. L. 117-328, signed December 2022), which added Section 524B to the Federal Food, Drug, and Cosmetic Act. The gap closed.

9.2 Section 524B of the FD&C Act — Premarket Requirements

Effective March 29, 2023, manufacturers submitting premarket approval (PMA) applications, 510(k) submissions, or de novo requests for "cyber devices" — defined as devices that contain software and have the ability to connect to the internet — must submit:

A software bill of materials (SBOM): A list of commercial, open-source, and off-the-shelf software components included in the device, including version numbers. This enables identification of known vulnerabilities in device components.

A plan to monitor, identify, and address postmarket cybersecurity vulnerabilities: The manufacturer must have a postmarket surveillance program specifically for cybersecurity.

Reasonable assurances of cybersecurity: The manufacturer must demonstrate that the device is designed to:

• Protect the security and privacy of healthcare providers and patients
• Prevent unauthorized access to the device
• Detect and report security incidents
• Respond to security incidents in a timely manner
• Update, patch, and otherwise remediate vulnerabilities

The FDA 2023 Cybersecurity Guidance ("Select Updates for the Premarket Submission and Consideration for Medical Device Cybersecurity," September 2023): This guidance elaborates on the § 524B requirements and specifies that manufacturers should follow the NIST Cybersecurity Framework and NIST SP 800-53. It requires a Cybersecurity Risk Management Plan that includes threat modeling, vulnerability testing protocols, and a coordinated vulnerability disclosure policy.

9.3 Post-Market Obligations

Section 524B also imposes post-market obligations. Manufacturers must:

• Provide patches and updates to address vulnerabilities on a reasonably justified schedule
• For critical vulnerabilities — those that could cause harm to patients — provide patches out-of-band as quickly as possible

9.4 HIPAA and Medical Devices

Medical devices that create, receive, maintain, or transmit ePHI are subject to both FDA jurisdiction (for device safety) and HIPAA Security Rule requirements (when operated by a covered entity or BA). An infusion pump connected to a hospital network that transmits medication dosing data is both a regulated medical device and a system containing ePHI.

For pen testers: Medical device testing requires navigating two regulatory frameworks simultaneously. Testing a networked medical device in a production healthcare environment without explicit written authorization from both the healthcare operator and potentially the device manufacturer could implicate HIPAA, CFAA, and the FD&C Act — particularly if the testing disrupts device functionality in a way that could affect patient safety.

10. HIPAA and Pen Testing: The Legal Specifics

10.1 Are Pen Testers Business Associates?

Almost certainly yes, if you will access or may access ePHI during the engagement. The definition of BA under 45 C.F.R. § 160.103 includes entities that perform functions "on behalf of" a covered entity or BA that involve PHI. Security testing to assess the protection of ePHI is a function performed on behalf of the covered entity. The fact that accessing ePHI is incidental to — rather than the purpose of — the engagement does not eliminate BA status.

The alternative approach: Some covered entities attempt to structure pen tests so that testers work only against de-identified systems or test environments containing synthetic data. If no PHI is involved, no BAA is required. This approach works well for application security testing in staging environments but is often impractical for network pen tests, red team operations, or EDR/detection validation exercises that require production network access.

10.2 What the Scope Letter Must Contain

A scope letter (rules of engagement) for a healthcare engagement must address:

Authorization chain: The letter must be signed by an authorized representative of the covered entity — ideally the CISO or Security Officer, with confirmation that the legal and privacy teams have reviewed it. Verbal authorization is insufficient.

ePHI handling protocol: Explicitly state whether the tester is or is not authorized to access, view, copy, or retain ePHI. If the engagement requires accessing production systems where ePHI may be encountered, the scope letter must address:

• What the tester should do if they access ePHI accidentally (stop, document, notify)
• Whether the tester is authorized to retain ePHI temporarily as evidence of a vulnerability
• Data retention limits (typically: minimum necessary time, then destruction)
• How the tester will document the existence of the vulnerability without retaining actual PHI

System boundaries: Enumerate systems that are in scope. For medical device testing, explicitly identify the device, its network segment, and confirm that patient-safety systems are in a test mode or isolated environment.

Incident notification protocol: Define who the tester notifies if they discover a breach. This is distinct from the pen test itself — discovering that an external attacker has already exfiltrated patient records triggers the covered entity's Breach Notification Rule obligations.

10.3 Data Destruction Obligations

Any ePHI accessed during a pen test — including tool outputs, packet captures, screenshots, or reports — must be handled according to HHS guidance on destruction of ePHI (45 C.F.R. § 164.310(d)(2)(i)). Physical media must be destroyed beyond reconstruction (shredding, degaussing). Electronic data must be cleared, purged, or destroyed using NIST SP 800-88 standards.

Practical implication: Your penetration testing tools may log data automatically. Burp Suite captures request/response data, including ePHI in HTTP responses. Your terminal emulator may have a scroll-back buffer containing patient records. Your report drafts may contain actual PHI used as evidence. All of this must be inventoried and destroyed, and you should certify destruction in writing to your covered entity client.

10.4 Tester Status: BA vs. CE Employee

If the covered entity has contracted with your firm as a BA, your firm has direct Security Rule obligations and OCR can directly enforce against you. If the covered entity has hired you as a temporary employee (W-2 status), you are part of the covered entity's workforce — subject to its security policies but not directly liable to OCR as a BA.

Most engagements are contractor/BA relationships. Understand which structure you are operating under before the engagement begins.

11. State Law Overlay

HIPAA sets a federal floor, not a ceiling. States can enact stricter health privacy laws, and many have. Where state law is more stringent, state law applies.

11.1 California Confidentiality of Medical Information Act (CMIA) — Cal. Civ. Code § 56 et seq.

California's CMIA predates HIPAA and is generally more protective of patient rights. Key provisions:

• Broader definition of covered entities: The CMIA applies not only to HIPAA covered entities but also to any "provider of health care" in California, which includes entities that would not be HIPAA covered entities — a wellness app that is not electronically transmitting health information for billing purposes is potentially covered.
• Private right of action: Cal. Civ. Code § 56.35 creates a private right of action for individuals. Nominal damages of $1,000 per violation plus actual damages, plus punitive damages, plus attorneys' fees. This is significantly more powerful than HIPAA's lack of a private right of action.
• Employer-provided health benefits: The CMIA has specific provisions protecting the medical information of employees receiving employer-sponsored health benefits, limiting employer access.
• No research exception matching HIPAA: HIPAA permits use and disclosure of PHI for research purposes with a waiver from an IRB or Privacy Board. The CMIA's research exception is narrower, requiring patient authorization in more circumstances.

For pen testers: A healthcare company headquartered in California, or one that treats California patients, faces CMIA exposure in addition to HIPAA exposure. A breach affecting California patients creates private right of action exposure from day one — class actions can be filed immediately upon breach discovery, before OCR even opens an investigation.

11.2 Texas Health & Safety Code § 181 — Texas Medical Records Privacy Act (TMRPA)

Texas enacted its own health privacy law that applies more broadly than HIPAA. Key differences:

• Broader scope of covered entities: The TMRPA covers any "covered entity" that "assembles, collects, analyzes, uses, evaluates, stores, or transmits" protected health information — a broader definition than HIPAA that captures entities that handle health data even if they are not HIPAA-covered entities.
• Civil penalties: The Texas Attorney General may assess civil penalties up to $5,000 per violation per day per individual whose information was improperly used or disclosed (Tex. Health & Safety Code § 181.201).
• Stricter marketing and sale restrictions: Texas prohibits the sale of PHI, with narrower exceptions than HIPAA.

11.3 New York SHIELD Act and Health Data

New York's SHIELD Act (Stop Hacks and Improve Electronic Data Security Act, signed 2019) amended New York's breach notification law and created new data security obligations. While the SHIELD Act is not a health-specific law, it applies to "private information" which includes health information combined with a person's name. Key provisions relevant to healthcare:

• Reasonable security program: The SHIELD Act requires any business that owns or licenses computerized data including private information of New York residents to implement and maintain reasonable safeguards — even if the business is not a HIPAA covered entity.
• No healthcare carve-out from SHIELD: Unlike some state privacy laws that carve out HIPAA-covered entities from their requirements, the SHIELD Act's data security requirements apply independently of HIPAA compliance. A healthcare entity must comply with both.
• AG enforcement: New York AG can seek injunctive relief and civil penalties up to $5,000 per violation for intentional violations and $20 per failed notification up to $250,000 for notification failures.

New York also has a separate health privacy provision under Public Health Law § 18 governing patient access to medical records, and NY Insurance Law § 4224 governing health plan disclosures — creating a multi-statute compliance landscape for health data in New York.

12. Safe/Grey/Red Matrix: Healthcare Pen Testing Scenarios

Key Concepts Cheatsheet

ePHI — Electronic protected health information. Any individually identifiable health information created, received, maintained, or transmitted electronically. The Security Rule applies only to ePHI.

Business Associate (BA) — Any entity that performs functions on behalf of a covered entity involving PHI and is not part of the covered entity's workforce. Pen testers accessing healthcare environments are typically BAs.

BAA — Business Associate Agreement. Required contract before a BA may access PHI. Without it, the CE is automatically non-compliant and the tester has no contractual authorization.

Addressable ≠ Optional — Addressable implementation specifications must be implemented or replaced with an equivalent alternative backed by documented analysis. Treating them as optional is a Security Rule violation.

60-day clock — Maximum time from breach discovery to individual notification. Discovery means actual or constructive knowledge.

500-person threshold — Breaches affecting 500+ individuals trigger HHS Wall of Shame listing and (if 500+ in one state) media notice.

Willful neglect — The highest civil penalty tier ($50K per violation, $1.9M annual cap). OCR has found willful neglect where organizations knew about vulnerabilities and failed to act.

§ 1320d-6 criminal tiers — Knowing = 1 year; false pretenses = 5 years; personal gain/malicious harm = 10 years.

Practitioner Takeaways

• Get a BAA signed before any engagement where production healthcare systems will be tested. No exceptions, no verbal agreements.
• Structure engagements to avoid accessing real ePHI wherever possible. Synthetic data in test environments eliminates Security Rule exposure entirely.
• When real ePHI is unavoidably encountered, access the minimum necessary, document what you saw without retaining the actual data, and destroy any captures immediately after the report is finalized.
• The Breach Notification Rule 60-day clock starts on discovery, not on the date you report findings to your client. If you discover evidence of an existing breach during a pen test, notify your client contact immediately — that is when "discovery" occurs for Breach Notification purposes.
• State law can be stricter than HIPAA. California's CMIA creates a private right of action for patients. Texas TMRPA covers entities HIPAA does not reach. New York SHIELD imposes independent security obligations. Check state law for every healthcare engagement.
• Medical device testing is a distinct discipline requiring safety isolation, FDA regulatory awareness, and explicit manufacturer coordination for production environment testing.

Quiz

See: artifacts/quizzes/quiz-02e.md