HIPAA, FDA Submissions and Customer Security Reviews: Three Different Things Healthcare Software Has to Prove

A scoping call usually opens with a single sentence that presents three distinct problems. "We need a HIPAA penetration test for our FDA submission, because our biggest customer is asking for one."

HIPAA, an FDA premarket submission and an enterprise customer's security review come from three different askers and are satisfied by three different things. They overlap in testing work, which is why they get bundled, and they diverge completely in what must be produced at the end. Buying one and assuming you have covered the other two is how a team ends up with a report that nobody it was meant for will accept.

Who is asking, and for what

HIPAA is enforced by the HHS Office for Civil Rights, and it applies to covered entities and their business associates. It asks whether you have assessed your risk to electronic protected health information and acted on what you found.

FDA premarket review focuses on the device and the submission rather than on your organization-wide HIPAA posture. If you are submitting a device, it asks what you did to make that device secure and what evidence you can show inside the submission.

Your enterprise customer is not a regulator at all. Their security review asks whether buying from you is safe enough for them to sign, and they set their own bar.

A single engagement can produce evidence for all three. The documentation and evidence expected for each is typically different.

What HIPAA actually requires

The HIPAA Security Rule names a risk analysis. At 45 C.F.R. § 164.308(a)(1)(ii)(A), a covered entity or business associate must "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate." The paired risk management standard then requires you to "implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level".

Three things follow from that, and all three matter when you are deciding what to buy.

First, the requirement is the analysis, and the obligation continues into acting on it. HHS guidance calls risk analysis "the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule." HIPAA does not prescribe penetration testing as the required methodology. Testing is one way of producing evidence that feeds the analysis, alongside vulnerability scanning, configuration review and everything else you do to understand your exposure.

Second, there is a standard where testing fits more directly, and it is not the risk analysis one. The Evaluation standard at § 164.308(a)(8) requires you to "perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information". That is a requirement to evaluate periodically and to re-evaluate after relevant change. It sets no cadence, and it does not call for an annual penetration test. Testing can form part of how you meet it, alongside the nontechnical evaluation the standard also names.

Third, HHS does not tell you how. Its guidance states plainly that "the Security Rule does not prescribe a specific risk analysis methodology, recognizing that methods will vary dependent on the size, complexity, and capabilities of the organization." That flexibility is real, and it cuts both ways. Nobody can hand you a checklist that guarantees compliance, and nobody can tell you your approach is wrong just because it differs from theirs.

So when a vendor sells you a "HIPAA penetration test", read that as a penetration test scoped around systems that touch PHI, producing findings your risk analysis can cite. That is a useful thing to buy. It is not the risk analysis, and buying it does not complete the requirement. Our own healthcare testing page is explicit that reports map to Security Rule requirements including risk analysis documentation, which is a different claim from the test being the requirement.

What an FDA premarket submission expects

A premarket submission is a different regime with a different subject. HIPAA looks at your organization and the PHI it holds. The FDA looks at the device you are submitting.

The current guidance is Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, issued February 2026, which supersedes the June 2025 version and aligns its references to ISO 13485:2016 under the new Quality Management System Regulation. It builds on the statutory requirements in Section 524B of the Federal Food, Drug, and Cosmetic Act.

On testing specifically, the guidance recommends that manufacturers carry out cybersecurity testing that includes vulnerability testing and penetration testing. Testing is recommended there as part of a body of evidence, inside a submission that also covers threat modeling, architecture, the security controls you implemented and how you will handle vulnerabilities after the device ships.

What changes practically is the writing, not only the testing. A report that satisfies an internal security team can be the wrong document for a submission, because reviewers are reading for traceability: which threat, which control, which test, which result. If your report says "authentication bypass, high severity, fix it", it is a good finding and a poor piece of submission evidence. Ask for the mapping before the engagement starts, not after.

Device testing may also reach surfaces that ordinary software testing does not, including embedded systems, wireless protocols and clinical data formats. We cover that ground in a dedicated post on medical device penetration testing, and the medical device page sets out what the reports are formatted for.

What your enterprise customer asks for

The customer review is the ask that holds up deals, and it answers to neither of the above.

A hospital system, payer or large healthtech platform running a third-party risk review wants to know whether you are a safe supplier. Their questions tend to cluster in the same places: whether you will sign a business associate agreement, where PHI is stored and who can reach it, how you segregate one customer's data from another's, what happened the last time you were tested, and how quickly you patch. Most of that is answerable from work you have already done. The sticking point is often the final document. Some reviewers want a short summary they can file; others will ask for the full report under NDA. Which one you are dealing with is a question to settle early, because producing the wrong one costs time you usually do not have.

A SOC 2 report often reduces how much separate evidence a reviewer asks for, which is why SOC 2 testing turns up in healthcare sales cycles that have nothing to do with the FDA. It does not universally replace the review. Plenty of healthcare buyers run their own questionnaire anyway, and some carry requirements a SOC 2 does not speak to.

Timing catches people out too. HIPAA obligations and FDA premarket submissions have their own calendars. A customer security review arrives when the customer decides, usually late in a deal, with a deadline attached. Teams that scoped only for compliance often discover they have the testing but not the summary document, and that gap is measured in weeks.

What each one wants in writing

The testing can be shared. The documents usually cannot, and that gap is a recurring source of rework.

• A risk analysis wants findings expressed as risk to ePHI, with likelihood, impact and what you did about each one. The audience is you, and later possibly an OCR investigator asking what you knew and when

• A premarket submission wants traceability: the threat, the control that addresses it, the test that exercised the control, the result, and what happens to vulnerabilities found after the device ships. The audience is a reviewer who has to follow your reasoning without calling you

• A customer security review varies by customer. Some want a short attestation or summary naming the scope, the dates, the methodology and the current remediation status; others will ask for the full report under NDA. Ask which before you produce either

One engagement can feed all three, provided the engagement knows in advance that it has to. Retrofitting a submission-ready mapping onto a finished report costs more than scoping it that way from the start.

What changes inside a healthcare engagement

Healthcare work often introduces additional considerations, such as:

• Per-application or per-device scoping, because submissions and customer reviews are usually about a specific product rather than your whole estate

• How PHI is handled during testing, including whether testers work against synthetic data, a masked dataset or a controlled production environment

• Documentation written for its destination, since a submission reviewer, an OCR investigator and a customer's risk analyst are reading for different things

Engagements against production systems are scoped and controlled to minimize risk, with anything potentially disruptive agreed in advance. In clinical environments that conversation matters more than usual, and it belongs at the start.

We have published a healthcare case study covering a managed care network, which gives a sense of how multi-organization scoping plays out in practice.

Where testing ends and regulatory work begins

Blurring this line is how expectations get set that nobody can meet.

Red Sentry performs security testing and produces the evidence that comes out of it: findings, severity and reasoning, reproduction detail, remediation guidance, and documentation mapped to the framework you name, when that mapping is included in scope.

Red Sentry is not a regulatory consultancy. We do not prepare or file your FDA premarket submission, we do not author your risk analysis, and we do not certify that you are HIPAA compliant. On that last point, HHS and OCR do not endorse or recognize private certifications as a substitute for an organization's own compliance obligations, so a certificate from any testing firm would not carry the weight it appears to.

If you need submission preparation or a full risk analysis program, that is regulatory consulting work, and it is a different purchase from a different kind of firm. Good ones will ask for exactly the evidence a testing engagement produces, which is the honest reason to run the testing first.

Scope, stated plainly

A healthcare penetration test is scoped to agreed applications, devices, environments and components, over an agreed period. It produces evidence about the security of what was tested. It does not determine your regulatory status, and it does not cover anything outside the agreed scope.

If you are trying to work out which of the three asks is actually in front of you, that is a short conversation, and it belongs before you scope anything. Book a scoping call and bring whatever prompted this: the auditor's request, the submission timeline, or the customer's security questionnaire. We will tell you what testing can evidence, and what you will need to get somewhere else.