DiGA penetration testing

DiGA Penetration Testing for BfArM Directory Listing

Test the application, backend, APIs, and cloud components in your DiGA scope with white-box testing, manual code review, and clear evidence for BfArM security requirements.

DiGA penetration testing for BfArM readiness

Assess the full technical scope of your Digital Health Application and turn validated findings into evidence your security, engineering, and regulatory teams can use.

BfArM readiness

Find security gaps before your DiGA submission

Test the DiGA version and technical components in scope, document validated findings, and address security issues before BfArM review.

Umbrella Web Application dashboard showing workflow status and severity with 8 findings in a donut chart.
Health data protection

Test the full DiGA attack surface

Assess the patient-facing app, backend services, APIs, identity flows, third-party integrations, and cloud infrastructure handling health data.

Remediation evidence

Verify fixes before they become submission blockers

Track validated findings, remediation owners, and agreed fix validation so your team can document the updated security state.

Where penetration testing fits into DiGA security

Support relevant DiGAV information-security requirements with technical testing aligned to BSI guidance and current OWASP methods. A pentest supports the process; it does not replace the broader BfArM assessment.

Requirement

Basis

How Blaze helps support it

Penetration testing of all components

BfArM DiGA guidance (incl. backend, since Feb 2024)

Full-scope pentest of app, backend, APIs, and infrastructure with manual code review and white-box testing.

BSI TR-03161

Technical security requirements for health apps

Testing aware of TR-03161 requirements; note the Dec 2025 guideline allows TR-03161 certification to replace the separate pentest.

OWASP (MASVS / ASVS / Top 10)

Application security baseline

Manual testing beyond the OWASP Top 10 across mobile, web, and API surfaces.

§139e SGB V

Legal basis for the DiGA directory

Evidence supporting the security requirements for directory listing and reimbursement.

GDPR Art. 32 / ISO 27001

Data protection & ISMS

Security-of-processing evidence and ISMS-aligned reporting (ISO 27000 series or BSI 200-2).

Technical evidence for DiGA security assurance

Get a clear test scope, validated findings, code-review evidence, remediation guidance, and reporting your security team can use alongside the broader BfArM and BSI assurance process.

Check Circle

DiGA-focused reporting

Document scope, methodology, validated findings, and remediation status against the DiGA security requirements relevant to the engagement.

Chart Donut

White-box testing & code review

Combine hands-on penetration testing with source-code analysis where the agreed DiGA scope and applicable BSI audit depth call for deeper implementation review.

Seal Check

Assurance-ready documentation

Receive technical reports and executive summaries that document the tested DiGA version, scope, findings, risk, and remediation status.

Lock Simple

Experienced security testing team

Work directly with named testers experienced in web, mobile, API, cloud, source-code, and regulated digital-health security assessments.

Stack

Reusable technical evidence

Reuse relevant findings in GDPR, ISO 27001, customer assurance, and other security work where the tested scope and requirements genuinely overlap.

Lightning

Fix validation

Re-verify agreed fixes and document the updated state when validation is included in the selected package or program.

Reuse relevant DiGA security findings

Where scope and requirements overlap, the same technical findings may support GDPR, ISO 27001, HIPAA, or DiPA work. Each framework still has its own obligations.

01

GDPR

Use relevant findings when demonstrating or improving security of processing for health data under GDPR.

Learn More
02

ISO 27001

Use relevant findings in ISMS risk treatment, vulnerability management, and control-improvement work.

Learn More
03

HIPAA

Use relevant application and infrastructure findings in US healthcare security work where systems and obligations overlap.

Learn More

DiGA penetration testing questions

Penetration testing is part of DiGA security assurance, but the exact evidence path depends on current DiGAV and BfArM requirements and the application's protection needs. BfArM's current guidance centers the BSI TR-03161 data-security certificate and also specifies penetration testing in applicable cases. Blaze supports the technical testing; it does not issue the certificate or decide BfArM listing.
BSI TR-03161 is the German technical guideline for applications in healthcare. It defines security objectives and audit characteristics for applications including DiGA and DiPA. At the deeper EXAMINE audit level, BSI says assessment generally includes comprehensive source-code analysis and penetration testing.
White-box testing gives testers implementation context such as source code, architecture, configuration, or credentials so they can examine weaknesses that black-box testing may miss. Under BSI TR-03161, deeper audit characteristics can require source-code analysis alongside penetration testing.
Not in every sense. The TR-03161 certificate is the formal data-security evidence called for by BfArM, while the certification audit can itself require source-code analysis and penetration testing depending on audit depth. Separate penetration-testing requirements may also apply. Treat the pentest as technical assurance evidence, not as a substitute for the certificate.
DiGA are Digital Health Applications listed under Germany's statutory health-insurance framework; DiPA are Digital Nursing Applications for long-term care. Both sit within BfArM's digital-application ecosystem and have specific data-protection and data-security requirements, but this page focuses on DiGA.
Test the systems in the authorized DiGA scope: the mobile or web application, backend services, APIs, identity and access flows, relevant third-party integrations, and the cloud or hosting environment supporting them.
Yes, where scope and requirements overlap. The same validated findings may support GDPR security-of-processing work, ISMS risk treatment, vulnerability management, and customer assurance. Those frameworks still have separate obligations beyond the pentest.
Related services

Security services for digital health teams

Complement DiGA penetration testing with broader product security validation, adversary simulation, or security program guidance.

Penetration Testing

Test web apps, APIs, mobile, cloud, and networks for exploitable weaknesses with validated findings and clear remediation guidance.

Learn More

Adversary Simulation

Red team and purple team exercises that test how your organization detects, responds to, and contains realistic attack scenarios.

Learn More

vCISO & Advisory

Build the security roadmap, remediation program, and assurance process around BfArM, GDPR, and broader customer requirements.

Learn More

Ready to scope your DiGA pentest?

Share your DiGA architecture, current version, submission timeline, and testing needs. We’ll help shape the right technical scope.