Penetration testing for European healthtech
Asteron tests web applications, APIs, mobile products and connected healthtech platforms against realistic attack paths. We validate findings manually, explain their technical and business impact, and give product and engineering teams practical remediation guidance. The service is designed for healthtech companies selling to hospitals and regulated healthcare markets in the Netherlands, Germany and across Europe.
- Manual, risk-led security testing
- Web, API, mobile and combined scopes
- Reproducible findings with remediation guidance
- Retesting available when included in scope
API from €5,900 · Web application from €6,900 · Mobile application from €7,900 · Combined product test from €11,900
What a penetration test proves
A penetration test is a focused, point-in-time assessment of whether weaknesses in a defined product or technical environment can be exploited. Unlike an automated vulnerability scan, it combines tools with manual investigation of authentication, authorisation, user roles, data flows and business logic.
For a healthtech product, severity cannot be judged by a technical score alone. A weakness may affect patient or clinician accounts, expose health data, cross tenant boundaries, interrupt a clinical workflow or provide access to administrative functions. The test therefore considers exploitability together with the product and business context.
A penetration test does not prove that a product is permanently secure. It covers the targets, versions, roles and environments agreed before testing. New releases, architecture changes and newly introduced integrations can change the risk profile.
A penetration test provides evidence about an agreed scope at a specific point in time. It is not a replacement for secure development, vulnerability management or ongoing security operations.
When European healthtech teams need testing
Healthtech companies usually commission testing when a concrete product, customer or regulatory decision requires credible technical evidence. Common triggers include:
Before a hospital or enterprise security review
Hospitals, insurers and healthcare platforms may request recent penetration-testing evidence before procurement, integration or contract renewal. The scope should reflect the product and data flows the customer will actually use.
Before release or after a material change
Testing is valuable before a major product launch and after significant changes to authentication, permissions, APIs, cloud architecture or multi-tenant boundaries. It can also verify that remediation of a serious vulnerability has been effective.
For the Dutch healthcare market
Dutch healthcare organisations and their technology suppliers commonly work within NEN 7510-based, risk-led information-security programmes. NEN 7510 does not impose an identical penetration test on every organisation, but testing can provide relevant evidence when the risk assessment, hospital procurement process or customer agreement calls for technical assurance.
For the German healthcare market
German healthtech and DiGA teams may need product-security evidence aligned with the applicable BSI TR-03161 requirements and certification route. A penetration test can support the wider security-assurance process, but the required evidence depends on the product, assessment scope and responsible certification body.
ISO 27001 and NEN 7510 do not automatically require the same penetration test for every organisation. The right test follows the actual risks, product boundaries, contractual requirements and target market.
Choose the right test
Four service scopes cover the situations European healthtech teams most often need. Every engagement is confirmed against the actual product, roles and environments before work begins.
API penetration test
For products whose API or backend services form an important security boundary. Testing may cover authentication, object-level authorisation, role enforcement, input handling, data exposure, rate controls and product-specific business logic.
Best suited to API-first products, integration platforms and healthtech services exchanging sensitive data with hospitals, partners or mobile applications.
Web application penetration test
For patient, clinician, customer and administrative web applications. The agreed scope may include authentication and recovery flows, sessions, permissions, tenant isolation, input handling, exposed functionality and realistic misuse of business processes.
The test is adapted to the application’s roles and architecture rather than treated as a generic website scan.
Mobile application penetration test
For iOS or Android applications handling health, identity or clinical information. Testing may address local data storage, network communication, authentication, platform interaction, application configuration and communication with backend services.
The platform, build, user roles and backend coverage are agreed before testing. Testing both operating systems or adding substantial backend scope may affect the price.
Combined product test
For connected products spanning more than one attack surface, such as a mobile application, web portal and shared API. A coordinated scope allows cross-channel permissions, account flows, data boundaries and business logic to be assessed together.
The final combination of targets, environments and roles is confirmed during scoping.
Prices are starting points and exclude VAT where applicable. The final price depends on the agreed targets, number of roles, authenticated access, API surface, environments, architecture, testing window, reporting requirements and whether a retest is included.
What can be tested
The final scope should follow the real product architecture and the decisions the test needs to support. Testing everything superficially is usually less useful than testing the most important data flows, trust boundaries and user roles properly.
Asteron may test externally accessible functions as well as authenticated workflows. Automated tools can support coverage, but findings are manually investigated and validated before they are reported.
Not every engagement includes every target or technique. The signed scope and rules of engagement define the exact coverage and exclusions.
Product surfaces
- – Web applications and administrative portals
- – APIs and backend services
- – iOS and Android applications
- – Cloud-exposed services and external infrastructure
Security boundaries
- – Authentication and account recovery
- – Authorisation, roles and tenant isolation
- – Sensitive health-data flows
- – Integrations and machine-to-machine access
- – Business-logic abuse cases
- – Input handling and exposed functionality
How the engagement works
Scope and rules of engagement
We identify the product surfaces, environments, user roles, data flows and decisions the test must support. Testing windows, exclusions, escalation contacts and permitted techniques are documented before testing begins.
The client confirms ownership of, or permission to test, every target.
Test preparation
Asteron reviews the available architecture and access information, confirms test accounts and establishes a safe route for reporting urgent issues. Where appropriate, test or synthetic data is used instead of real patient data.
Manual testing and validation
Testing follows the agreed scope and uses recognised guidance such as the OWASP Web Security Testing Guide and OWASP Mobile Application Security Testing Guide where relevant. Tools support the work, but confirmed findings rely on manual validation and product context.
Potential issues are checked for reproducibility, exploitability and realistic impact. Unexpected service impact or sensitive-data exposure is escalated through the agreed contact path.
Reporting, readout and retest
The final report separates confirmed vulnerabilities from observations and explains what should be fixed first. A readout helps product and engineering stakeholders understand attack paths, impact and remediation priorities.
Where a retest is included, corrected findings are tested again against the agreed conditions and their status is documented.
What the report gives your team
A useful penetration-test report must work for both decision-makers and engineers. Management needs a credible view of exposure and priorities; engineering needs enough evidence to reproduce and correct each confirmed weakness.
- – Executive summary and overall risk context
- – Confirmed scope, environments and testing conditions
- – Methodology and coverage
- – Risk-ranked confirmed findings
- – Reproduction steps and supporting evidence
- – Technical and business impact
- – Practical remediation guidance
- – Readout with product and engineering stakeholders
- – Retest status where commissioned
Severity reflects exploitability, affected data and workflows, available privileges and business impact. It should not be derived from an automated score alone.
Safe testing and shared responsibilities
Asteron
Asteron remains within the written scope and rules of engagement, uses proportionate techniques and escalates unexpected service impact or sensitive-data exposure promptly. Findings are validated before inclusion in the final report.
Your team
The client provides written authorisation, confirms permission for every target, supplies suitable accounts and technical contacts, and discloses production constraints and prohibited actions. Test windows and incident-escalation procedures must be agreed in advance. Where suitable test data can be used, real patient data should not be provided solely for testing.
Standard penetration testing does not automatically include source-code review, social-engineering or phishing exercises, red-team activity, physical-security testing, continuous vulnerability management or implementation of remediation. These activities require a separate scope.
Penetration testing, vulnerability management and compliance operations
These services can work together but are not automatically bundled. Penetration testing produces technical evidence; Vulnerability Management maintains the ongoing finding lifecycle; Compliance Operations manages the recurring compliance workflow.
Pricing summary
Starting prices exclude VAT where applicable. Final price depends on the agreed targets, roles, environments, testing window, reporting requirements and whether a retest is included in the proposal.
Frequently asked questions
What is a penetration test?
A penetration test is a controlled assessment of whether weaknesses in an agreed system, application or API can be exploited. It combines tools with manual investigation and reports only validated findings within the confirmed scope.
What can Asteron test?
Asteron can scope web applications, APIs, mobile applications and connected product environments. Exact coverage depends on the product architecture, roles, environments and purpose of the test.
How is a penetration test different from a vulnerability scan?
A scan uses automated tools to identify possible weaknesses. A penetration test adds manual investigation, validates whether issues are genuine and assesses realistic attack paths and business impact.
Is penetration testing required for ISO 27001 or NEN 7510?
Neither framework requires the same penetration test in every situation. Testing should follow the organisation’s risk assessment, product exposure, customer commitments and applicable regulatory or contractual requirements.
Is penetration testing relevant when entering the Netherlands?
It can be. Dutch hospitals and healthcare customers may request technical-security evidence, particularly when the product handles health information or connects to healthcare systems. The appropriate scope should follow the customer requirement and NEN 7510-based risk context.
What should a German DiGA company test?
The required evidence depends on the product and applicable BSI TR-03161 certification route. Testing may need to cover the mobile or web application, backend systems, APIs and relevant data flows. The assessment requirements should be confirmed before finalising the scope.
Can testing be performed in production?
Only when explicitly agreed and supported by suitable safeguards. The rules of engagement must define permitted techniques, test windows, excluded actions and escalation procedures.
Does the price include a retest?
A retest is included only when stated in the agreed proposal. Its scope normally covers remediation of the original confirmed findings rather than an unrestricted new assessment.
How long does penetration testing take?
Timing depends on the target count, roles, environments, architecture, access preparation and reporting requirements. A schedule is confirmed after scoping rather than promised as a generic duration.
Does a penetration test certify that the product is secure?
No. It provides evidence about the agreed scope and product version at a specific point in time. It does not guarantee that every possible weakness has been identified or that future changes will remain secure.
Related services and frameworks
Define the right test for your product
Tell us what you are testing, who needs the evidence and which markets or customers matter. We will help define a proportionate scope before preparing the proposal.