Is a PHI Breach Patient Harm? How the FDA Views Device Data Confidentiality

Clients often tell us that stolen PHI can harm a patient through emotional stress. The standards allow for that view. The FDA's guidance does not treat it as a direct safety issue. The question is where that risk is documented and how it is scored. Getting this right keeps your risk file defensible and your submission consistent.

Why This Matters

Reviewers read your threat model, security risk assessment, and safety risk file together. If they disagree, questions follow. Two mistakes are common.

The first is ignoring confidentiality because "it is not a safety issue." That leaves real security risks unassessed and controls unjustified.

The second is scoring every possible data leak as a high-severity patient harm. That inflates the safety file, hides the risks that can physically hurt a patient, and makes residual risk hard to explain.

Patient safety comes first. A clear method keeps the focus there while still protecting patient data.

Does the FDA care about PHI?

Yes, but narrowly. The FDA's guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, names five security objectives: authenticity (including integrity), authorization, availability, confidentiality, and secure and timely updatability and patchability. Its security control categories include authentication, authorization, cryptography, code, data, and execution integrity, confidentiality, event detection and logging, resiliency and recovery, and updatability and patchability.

In its confidentiality recommendations, the guidance asks manufacturers to protect any data whose disclosure could lead to patient harm. Its examples are credentials and cryptographic keys, because their disclosure could let an attacker misuse device functions or cause harm to many patients.

The same section has a footnote that answers the PHI question directly. It says loss of confidential health information is generally not considered a direct impact on safety and effectiveness, that protecting PHI is beyond the guidance's scope, and that manufacturers may still be obligated to protect PHI under laws such as HIPAA.

In practice, reviewers still look at encryption and access control, because the same controls protect credentials and device functions. Privacy enforcement sits mainly with the HHS Office for Civil Rights under HIPAA, and with the FTC for many consumer health products.

Security risk versus safety risk

The FDA expects security risk management to run alongside ISO 14971 safety risk management, not inside it. Security risk assessment looks at exploitability and impact on confidentiality, integrity, and availability. Safety risk assessment looks at the probability and severity of harm.

The two connect at defined points. A security risk that can lead to a hazardous situation is transferred to the safety file. A safety risk control that depends on security is traced back to the security controls.

When a PHI breach becomes patient harm

ISO/TR 24971 includes an example in which loss of data confidentiality leads to disclosure of health information, then to denial of insurance coverage and lack of treatment, with psychological stress and deterioration of health as the harms. That example shows psychological harm can be in scope.

See also: Benefit-Risk Analysis: When Medical Device Benefits Outweigh Remaining Risks, Premarket Cybersecurity in Your QMS: ISO 13485 & QMSR, and HIPAA and Medical Device Manufacturers.

Credibility depends on context. Ask these questions with your clinical and risk teams:

• What data is exposed? A device identifier differs from a mental health, HIV, fertility, or substance use record.
• Can a person be identified from it, alone or combined with other data?
• What could an attacker do with it? Consider harassment, extortion, discrimination, or loss of coverage.
• Could exposure change patient behavior? A patient who stops using a monitor because they no longer trust it may face clinical risk.

If the answers show a credible path to harm, carry the risk into the safety file and score severity with clinical judgment. If not, document the reasoning in the security risk assessment and control the risk there.

What HIPAA covers that the FDA does not

HIPAA covers emotional, financial, and reputational effects of a breach through the Privacy, Security, and Breach Notification Rules. It applies when a manufacturer is a Business Associate, usually through a cloud or remote monitoring service. See HIPAA and medical device manufacturers for when that happens, and de-identification versus anonymization for reducing what data you hold.

A single breach can create duties under both regimes. Plan your incident response so each one is met.

How Blue Goat Approaches This

We assess confidentiality in the threat model and security risk assessment for every device that handles patient data. We score security risks with CVSS and our documented exploitability method. Where a confidentiality risk has a credible path to harm, we flag it for transfer into your ISO 14971 file and trace the controls both ways. Your team owns the safety severity decision. Our medical device penetration testing then verifies that the confidentiality controls hold up under attack.

FAQ

CTA

Unsure how to score confidentiality risks in your device's risk file? Blue Goat has supported 275+ FDA submissions, with zero cybersecurity rejections. Schedule a discovery session →