Healthcare penetration testing for health-tech platforms
C-YBER provides healthcare penetration testing for patient portals, telemedicine apps and health-data APIs.
A CTO or CISO at a health-tech company may be arranging the test.
The starting point may be a hospital’s or health insurer’s security checklist, or a request to test your platform from a hospital or other healthcare customer.
We test web applications, mobile apps and APIs. We do not audit or certify compliance with any regulation or standard.
On this page
Testing from patient sign-in to consultation
We test patient portals, telemedicine and mobile apps, and health-data APIs. Medical devices and their firmware are out of scope.
Portals, appointments and consultations
- Patient portals on the web
- Appointment scheduling applications
- Telemedicine consultation apps
- FHIR and HL7 APIs
- Patient and clinician mobile apps
Sign-in permissions and consultation actions
- Session handling: whether a password reset invalidates the existing session used to manage a patient’s appointments
- Authentication, authorisation and least-privilege access control: whether a patient can submit a clinician-only approval for a prescription request without signing in as a clinician
- Data exposure through FHIR and HL7 APIs: whether searching by an appointment identifier returns consultation notes outside the signed-in clinician’s permissions
- Logic flaws and chained vulnerabilities: whether editing a cancelled consultation and then submitting a prescription request bypasses the platform’s consultation requirement
- Input validation: whether an appointment request accepts a clinician identifier supplied as a list when only one identifier is expected
- Rate limiting and throttling: whether the patient sign-in endpoint limits repeated attempts to guess an account’s password
- Encryption and data integrity: whether a clinician app accepts a prescription-request response that has been altered or delivered over an unencrypted connection
- Server configuration and database security: whether a web application’s database permissions allow an appointment search to modify consultation entries
- Error handling and logging: whether a failed consultation booking puts a patient’s health information into an error response or an application log exposed through the portal
When your patient or clinician mobile app relies on platform APIs, we can test both within one engagement. Scoping establishes which apps and endpoints are included.
When hospitals, health insurers and partners review the platform
During a platform review, a hospital, health insurer or partner may request testing of the applications it intends to use or connect to.
The report is evidence you can give your auditors, supervisors and customers. What they accept is their decision.
Our reports include an executive summary, the scope of work, the test type and methods, the methodology, how risk is calculated, a summary of findings, detailed results for each finding, and a conclusion.
You can request our sample web application penetration test report through the contact form or by email.
Regulatory context for a health-platform test
NIS2 when the healthcare customer is covered
If you receive a test request from a hospital or another healthcare customer and NIS2 covers that customer, the directive says this about testing:
In the EU, NIS2 Article 21(2)(f) requires the cybersecurity risk-management measures of essential and important entities to include policies and procedures to assess their effectiveness. NIS2 does not require a penetration test by name. A test is one way to provide that evidence.
The GDPR testing provision
Among the security measures GDPR Article 32(1) expects controllers and processors to implement where appropriate is a process for regularly testing, assessing and evaluating their effectiveness (point (d); the UK GDPR has the same text). A penetration test is one way to evidence that process for the systems it covers.
We provide testing evidence. We do not audit or certify compliance with any regulation or standard.
Arranging testing around patient-facing services
Select the patient and clinician workflows
Every test starts with planning: we agree the scope, the systems to test and the rules that avoid disruption. We scope each test with you, either through our scoping questionnaire or in a scoping meeting where we ask the same questions.For your patient portal, consultation app or health-data API, the testing type is agreed at scoping: black-box, grey-box or white-box.
Environment options
We test on live systems and on staging environments. Roughly 70% of our tests run on live systems and 30% on staging.Account for bookings and video consultations
Include appointment booking and video consultation hours in planning for live patient-facing services.Testing is conducted under controlled conditions with agreed rules of engagement. We schedule around your business needs.
Duration in your project plan
Testing takes from a few days to a few weeks, depending on the project. The average testing period is 1–2 weeks.Ask about an opening in our schedule
When testing can start depends on our current schedule. If you need it sooner, contact us and we will do our best to accommodate you.
Report and retest
Every report lists the vulnerabilities found, rates each by risk, and gives remediation steps. A penetration test report also sets out the exploitation methods demonstrated during testing, and a priority-based action plan.
The health-platform test is documented in 20–100+ pages. Each finding is rated by severity, including those concerning patient sign-in, appointment booking or consultations.
After you fix the findings, we re-test them.
A retest covers the findings only, not the full application. It is usually quoted in the same offer as the test. The retest window is about 4 weeks, or sooner if you have fixed the findings earlier and our schedule has an opening.
Experience and method
With over 7 years of experience in testing, we have built extensive expertise in web applications and websites, e-commerce platforms, mobile applications, APIs and SaaS solutions.
Our penetration tests can follow OWASP, ISSAF, PTES or OSSTMM at your request or on our recommendation. What we follow and how much of it we cover are agreed at scoping.
Testing uses Burp Suite, manual testing and our own tools.
Our pentesters hold certificates including PNPT, eCPPTv2, CAP, CompTIA PenTest+ and CompTIA Security+, and their published research includes five CVEs.
Questions
How much of our patient portal and telemedicine platform can a test cover?
The scope of a health-platform test can encompass patient portals, appointment scheduling, telemedicine apps, mobile apps, and FHIR and HL7 APIs. Checks address authentication, session handling, access control, least privilege and data exposure across those applications and APIs.
One check asks whether a clinician whose consultation assignment has been removed can still open that consultation’s notes.
Are medical devices included in your testing?
We test patient portals, telemedicine and mobile apps, and health-data APIs. Medical devices and their firmware are out of scope.
Could one test include our patient mobile app as well as the API it calls?
A patient or clinician app’s appointment and consultation APIs can be tested with the mobile app in one engagement. Before testing starts, scoping settles the mobile app functions and APIs to include.
What goes into the report a hospital or health insurer has requested during our platform review?
The report is evidence you can give your auditors, supervisors and customers. What they accept is their decision.
Every report lists the vulnerabilities found, rates each by risk, and gives remediation steps. A penetration test report also sets out the exploitation methods demonstrated during testing, and a priority-based action plan.
In a security discussion with our hospital customer, does NIS2 require a penetration test?
If your hospital or other healthcare customer is covered by NIS2, NIS2 addresses testing this way:
In the EU, NIS2 Article 21(2)(f) requires the cybersecurity risk-management measures of essential and important entities to include policies and procedures to assess their effectiveness. NIS2 does not require a penetration test by name. A test is one way to provide that evidence.
Does GDPR require a penetration test of our patient portal, telemedicine app or health-data APIs?
Among the security measures GDPR Article 32(1) expects controllers and processors to implement where appropriate is a process for regularly testing, assessing and evaluating their effectiveness (point (d); the UK GDPR has the same text). A penetration test is one way to evidence that process for the systems it covers.
Could testing interrupt a patient’s appointment booking or video consultation on our live platform?
Testing is conducted under controlled conditions with agreed rules of engagement. We schedule around your business needs.
Tell us when patients book appointments and when clinicians hold video consultations as we plan the test.
What information sets the cost of a patient-portal or telemedicine test?
Pricing a patient-portal or telemedicine test starts with four inputs: your timeline, the environment’s complexity, the testing type and how many systems or applications are in scope.
The common questions on pricing and test planning are a further reference when budgeting for your health platform.
Is scanning our patient portal the same as attempting to exploit it?
A vulnerability assessment scans your systems with Burp Suite, and an expert verifies and prioritises what the scan finds. A penetration test goes further: testers try to exploit what they find and show you the impact.
Start with the vulnerability assessment service and penetration testing service descriptions when deciding how to assess your patient portal.
Related services
Discuss your testing needs
You can request our sample web application penetration test report through the contact form or by email.
Or email us at info@c-yber.com
What to include
Describe what needs testing (web app, mobile app or API), the approximate scope, why and when you need the test, and whether you want the sample report.
What to leave out
Do not send passwords, API keys, tokens or other access details, source code, details of unfixed vulnerabilities, or your customers’ personal data.