FDA Deficiency: Insufficient Penetration Testing Evidence
An 'insufficient penetration testing evidence' deficiency almost never means 'you should have done more testing.' It means the report you submitted does not let the reviewer answer four questions: what was in scope, what methodology was applied, who performed the work and what was their independence from the design team, and what residual risk remains after remediation. A 200-page tool dump is not pen test evidence; a 20-page report that answers those four questions is.
What FDA reviewer language looks like
Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.
- Pattern 1
The penetration testing report does not clearly describe the scope of testing relative to the security architecture views. Provide a scope statement that maps tested interfaces and components to the architecture and identifies any interface that was excluded along with rationale.
- Pattern 2
The methodology section does not describe the test approach in sufficient detail. Provide the testing methodology, including the standards or frameworks used, the test environment, and the tester's level of access (e.g., black-box, gray-box, white-box).
- Pattern 3
It is unclear whether the penetration testers were independent of the device development team. Provide evidence of tester independence and qualifications.
Why this happens
- Teams submit raw vulnerability scanner output instead of a pen test report and call it penetration testing.
- Pen testing is scoped to the application layer only, leaving wireless, hardware, debug, update, and cloud interfaces untested.
- Internal QA performs the testing without documented independence from the development team, and the report does not address tester qualifications.
- The report describes findings but not methodology — reviewers cannot tell whether the absence of findings means a clean device or a shallow test.
How to fix it
- Open the report with a scope diagram that overlays the test boundary on the security architecture views. Explicitly mark every interface as in-scope, out-of-scope (with rationale), or deferred.
- Document methodology against a recognized framework (OWASP MASVS/ASVS for apps, NIST SP 800-115 for general, plus device-class-specific guidance) and identify the test access level for each phase.
- Provide tester qualifications (certifications, prior medical-device testing experience) and an independence statement showing testers did not author the device's security controls.
- For each finding: severity, exploitability, root cause, remediation status, residual risk after remediation, and link to the corresponding entry in the cybersecurity risk assessment.
- Include a re-test summary showing remediated findings have been verified, not just closed in a tracker.
Scope is the deficiency hiding behind every other pen test deficiency
When a reviewer writes 'insufficient penetration testing evidence,' the implicit follow-on is almost always a scope concern. They have looked at your architecture views, identified an interface (commonly the service port, the wireless update channel, or the cloud-to-device control path), and could not find evidence it was tested. The remediation is rarely 'do more testing of new things' — it is to retroactively map what you did test to the architecture and either justify the exclusions or add targeted retests for the gaps. Teams that try to fix this with a longer list of CVEs without addressing the scope mapping receive a second deficiency.
Independence is now graded, not assumed
Under the 2026 guidance, reviewers explicitly look for tester independence from the development team. Internal QA performing pen testing is not disqualifying, but it requires explicit documentation of organizational separation, supervision, and the tester's lack of involvement in designing the controls under test. Most submissions that draw an independence-related deficiency simply did not address the topic at all in the report. A short, factual statement on independence — names, roles, reporting line, prior involvement — usually closes that thread.
Standards involved
Already responding to this deficiency?
Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.
FDA Cybersecurity Deficiency Response serviceFacing a "insufficient penetration testing evidence" finding?
Bring us the letter. We will map a clean response and rebuild the underlying artifact to FDA 2026 expectations.