US healthcare software · scope and evidence
Planning a penetration test
for US healthcare software.
Start with the systems you operate, the information they handle and the responsibilities that apply to your organisation. Use this guide to prepare a test brief and identify any wider assurance work.
Start with your context
Identify what applies
to your organisation.
| Your situation | Why it matters | What to establish |
|---|---|---|
| HIPAA-regulated work | You are a covered entity, business associate or relevant subcontractor handling electronic protected health information (ePHI). | The HIPAA administrative safeguards include risk analysis and evaluation. A scoped pentest can inform that work; it does not replace the organisation’s full risk analysis. |
| Consumer health products | You provide a health app or service whose activities may sit outside HIPAA. | Being outside HIPAA does not settle your obligations. The FTC health-app tool helps identify other potentially applicable rules, including the Health Breach Notification Rule. Confirm relevant state requirements too. |
| Medical-device software | Your product may fall within an applicable medical-device submission route. | For relevant cyber devices, section 524B and FDA cybersecurity guidance bring additional expectations. Establish the device and submission context before deciding what evidence to commission. |
These situations can overlap. Use them to identify questions for your legal, privacy or regulatory owner; product features and contractual roles determine applicability.
Make the scope concrete
Prepare the information
your assessment needs.
| Area | What to prepare | What this helps define |
|---|---|---|
| Your role and requirements | Identify your organisation’s role, applicable agreements, internal policies and the decision the assessment supports. | A scope connected to your own responsibilities, including a separate external evidence request if one exists. |
| Systems and data flows | Describe applications, APIs, users, data categories, integrations and where information is processed. | A defined boundary for technical testing, including patient/clinician/admin workflows where relevant. |
| Assessment data and access | Start with representative synthetic records where suitable. Identify any need for real PHI and settle permissions and agreements before access. | An approved approach to test information. Business-associate responsibilities depend on the role and activity, not merely where a model is hosted. |
| Application coverage | Identify important workflows, input handling, information in responses/exports/logs, API behaviour and relevant configuration. | Coverage across the agreed system rather than access-control checks alone, with limitations clearly recorded. |
| Reporting and remediation | Confirm recipients, severity/impact expectations, evidence restrictions, remediation owners and the decision date. | Actionable findings and an agreed plan for retesting. For applicable devices, confirm how the assessment fits your wider submission evidence plan. |
Useful outputs
Ask for evidence
you can act on.
Your MurtaSec report includes an executive summary, a summary of findings and detailed findings with descriptions, reproduction steps, remediation steps and references. For a relevant device submission, confirm additional requirements such as documentation of tester expertise and independence with your regulatory owner. A product report is one piece of evidence, not a claim of HIPAA certification, clinical validation or FDA authorisation.
Common questions
Resolve the decisions
before testing starts.
Does HIPAA currently require every organisation to buy an annual pentest?
The linked HHS rulemaking fact sheet proposes annual penetration testing; the current administrative safeguards require risk analysis and periodic evaluation. Do not treat the proposal as an existing blanket mandate. Your contracts or other applicable requirements may separately specify a frequency.
Do we have to use real patient information for testing?
Not necessarily. Representative synthetic data may support the agreed objectives. If PHI is needed, establish the applicable permissions, business-associate arrangements and handling requirements before access.
We are a health app outside HIPAA. Is this guide still relevant?
Yes: the planning steps still help define a useful assessment. Confirm whether FTC or state requirements apply to your activities rather than assuming HIPAA is the only relevant framework.
Sources & related guidance
Check the source
for your requirement.
Reviewed 25 September 2026. HIPAA administrative safeguards, HHS guidance, the proposal status, FTC guidance and FDA’s February 2026 guidance were checked. Confirm applicability and changes before relying on a requirement.
Let’s plan
your assessment.
Tell us about the system you need assessed, the questions you want answered and any specific requirements. We can help you shape a practical scope.