By EJN Labs · 19 Aug 2026 · 8 min read
IEC 62304 does not require a penetration test. It is a software lifecycle standard, and its verification activities focus on safety rather than security. Hospital and NHS security reviews still ask device software vendors for independent test evidence, so vendors commonly commission an annual CREST-accredited penetration test, typically 4 to 6 days at £1,100 to £1,400 per day, £4,400 to £8,400.
Why IEC 62304 security assurance comes up in customer security reviews
IEC 62304 security assurance comes up because hospital trusts, integrated care boards and private healthcare groups routinely pair “confirm IEC 62304 compliance” with “provide your most recent penetration test report”. The two are not the same thing, and vendors who treat them as one usually stall the review.
If you sell software that runs on, connects to or controls a medical device, expect these questions in almost every procurement you enter.
The clinical safety reviewer wants lifecycle evidence: your safety classification, development plan and risk management file. The security reviewer wants proof that someone independent has attacked your product and that you fixed what they found. Vendors who answer both cleanly move through in days; vendors who answer the pen test question with “we follow IEC 62304” get clarification calls and stalled deals.
What IEC 62304 actually asks for, and what it does not
IEC 62304 asks manufacturers to run lifecycle processes: development planning, requirements analysis, architectural design, verification, risk management, configuration management, problem resolution and SOUP handling. It classifies software by the harm it could cause and scales the required rigour to match.
It is the international standard for the medical device software lifecycle, published by the IEC, and SOUP stands for software of unknown provenance.
Here is the honest position: nowhere does IEC 62304 mandate a penetration test. The standard is voluntary in the strict sense, but it functions as regulatory evidence, because regulators and notified bodies treat conformance as the accepted way to show device software was built under a controlled lifecycle. Security testing sits alongside it as supporting evidence that the software stays safe on a hostile network, not as a named clause you can quote. If a questionnaire implies otherwise, the accurate answer is that your testing programme supports the standard’s risk management and verification activities rather than satisfying a specific requirement in it.
What security reviewers expect device software vendors to show
Across UK healthcare procurement, the evidence pack that satisfies reviewers is remarkably stable:
- A recent penetration test report from a CREST-accredited firm, with retest confirmation that high and critical findings were fixed
- A scope summary: which applications, APIs, cloud services and device interfaces were tested, and when
- Your secure development lifecycle description, ideally referencing IEC 81001-5-1, the health software security lifecycle standard that extends IEC 62304
- A vulnerability management and disclosure policy with defined remediation timescales
- Anchor certifications: Cyber Essentials Plus at minimum, ISO 27001 where the buyer is a trust or national programme
The IEC 81001-5-1 reference matters more each year: where IEC 62304 defines the lifecycle, IEC 81001-5-1 adds the security activities expected within it, including security verification and testing. Vendors who map their penetration testing programme to it give reviewers a framework-shaped answer instead of a marketing one.
What to test across a device software estate
When we scope these engagements at EJN Labs, we start from a simple question: where does patient or clinical data enter, move and rest? That usually surfaces four layers worth testing.
Clinician-facing applications and APIs
The portal clinicians use, and the APIs behind it, carry the richest data and broadest attack surface. Authentication, authorisation between tenants and roles, and the handling of clinical identifiers all need adversarial testing. Where the product exposes HL7 FHIR or bespoke integration endpoints, we test those directly, because integration APIs are often built permissive for interoperability and stay that way in production. Our API penetration testing service covers this layer.
Mobile and companion apps
Patient-facing companion apps store tokens, cache readings and talk to devices over Bluetooth. Mobile application testing examines local storage, certificate pinning, session handling and the app-to-device pairing model.
Cloud platform and infrastructure
Vendors commonly run multi-tenant cloud back ends. A cloud penetration test reviews what questionnaires ask about directly: tenant isolation, storage permissions, key management, logging and the blast radius of a compromised service credential, alongside the small public footprint of VPNs and admin panels.
Device interfaces and SOUP exposure
Where device-adjacent components are in scope, we test the interfaces the software exposes to and consumes from the device, and review how the SOUP inventory your IEC 62304 file already tracks affects the attack surface. Testing runs against staging with synthetic data, never against systems holding live patient records.
How an engagement runs
Engagements run in five stages: a scoping call, agreed rules of engagement, one to two weeks of testing, a report delivered within days, and a retest that confirms fixes. The retest letter is the document most security reviews actually want attached.
Scoping is a short call that establishes the applications, APIs, cloud services and user roles in play, plus the safety classification of the components involved. Rules of engagement cover the staging environment, test accounts per role and any out-of-bounds interfaces. The report is written so both an information security reviewer and a clinical safety officer can use it, with severity-rated findings mapped to affected components and actionable remediation guidance.
If you are preparing for your first engagement, our penetration testing checklist walks through what to have ready before testing starts.
What it costs and how scope drives the price
Testing is priced on effort, and effort follows scope: the number of applications, API endpoints, user roles and cloud services in play. UK day rates for CREST-accredited testing typically run £1,100 to £1,400 per day. The ranges below are typical UK engagements; your exact price comes from a short scoping call.
| Scope | Typical effort | Typical UK cost |
|---|---|---|
| Clinician-facing web app and API | 4 to 6 days | £4,400 to £8,400 |
| Mobile app plus supporting API | 3 to 5 days | £3,300 to £7,000 |
| Cloud platform review plus external infrastructure | 5 to 8 days | £5,500 to £11,200 |
| Full estate: app, API, cloud and external | 8 to 12 days | £8,800 to £16,800 |
For a fuller breakdown of what moves the price, see our guide to penetration testing costs in the UK. A single well-scoped annual test, reused across every security review that year, costs less than the sales time lost re-answering questionnaires without one.
How EJN Labs approaches IEC 62304-aligned security testing
EJN Labs is a CREST-accredited penetration testing firm, certified to ISO 27001 and Cyber Essentials Plus, with all testing delivered by UK-based testers. We scope from your architecture and SOUP inventory rather than a generic checklist, so the test exercises the components your IEC 62304 file classifies as higher risk, and reports are written to hand straight to a hospital security reviewer: clear scope statement, severity-rated findings, and a retest letter once fixes land.
Because the same report often decides whether a procurement stalls or closes, we time engagements around your sales cycle where we can. Our CREST penetration testing page explains the methodology in full, and if you are comparing suppliers, our guide to choosing the best UK penetration testing provider sets out the questions worth asking any firm, including us.
Frequently Asked Questions
Does IEC 62304 require penetration testing?
No. IEC 62304 does not name penetration testing as a requirement. The standard defines the medical device software lifecycle, while security testing supports its risk management and verification activities. Buyers ask for pen test reports as independent evidence, not because the standard demands them.
The lifecycle the standard defines covers planning, requirements, design, verification, risk management and SOUP control, and IEC 81001-5-1 extends it with explicit security activities.
What should a vendor say when a security review asks for IEC 62304 pen test evidence?
Say that IEC 62304 does not itself mandate penetration testing, then provide your most recent independent test report and retest confirmation as security evidence supporting your lifecycle documentation. Reference IEC 81001-5-1 if your secure development process follows it, and supply both evidence types unprompted.
Reviewers respond well to vendors who answer precisely and separate lifecycle evidence from security evidence, supplying both without being chased.
What does a penetration test cost for a device software vendor?
Expect £4,400 to £8,400 for a clinician-facing web app and API over 4 to 6 days, at UK CREST-accredited day rates of £1,100 to £1,400. A full estate covering app, API, cloud and external infrastructure runs 8 to 12 days, £8,800 to £16,800.
Scope is the variable that moves the price between those brackets, so an exact figure comes from a short scoping call.
Is testing performed against live patient data?
No. Testing runs against a staging environment populated with representative synthetic data, using dedicated test accounts for each user role. This keeps patient confidentiality protected and the engagement outside clinical service risk, and buyers should expect any vendor to say exactly that when asked.
The arrangement is also what hospital security reviewers expect to see documented in the scope statement of your report.
How often should a device software vendor retest?
Retest annually as a baseline, plus after significant change: a new module, a major API version, a change of cloud architecture or a new device interface. Most UK healthcare buyers treat a report older than twelve months as expired, so the annual cycle is the minimum worth planning around.
Aligning the annual test with your busiest procurement season keeps a current report available whenever a security review lands.
Turn security review questions into a closed deal
If IEC 62304 pen test questions are slowing your sales cycle, one well-scoped independent test resolves them for a full year of procurements. Get a CREST penetration testing quote and have your evidence pack ready before the next security review asks for it.




Leave a Reply