Listing on GP IT Futures: The Penetration Testing GP Software Suppliers Need

What GP IT Futures / DCS security assurance actually asks of suppliers

GP IT Futures asks suppliers to sign up to capabilities and standards covering clinical safety, interoperability, data protection and security, and NHS England typically looks for evidence, not assertions, that those standards are met. It is the route by which NHS England buys core clinical IT for general practice.

The Digital Care Services (DCS) Catalogue is where suppliers are listed once they have met those standards.

The security obligations are contractual for GP system suppliers and the services they provide. They sit alongside the Data Security and Protection Toolkit (DSPT), which any organisation with access to NHS patient data must complete. The catalogue does not publish a single clause that says “commission an annual penetration test”. What it does require is that suppliers demonstrate their software and hosting have been tested for security weaknesses, that vulnerabilities are managed, and that assurance evidence stands up to scrutiny during onboarding and ongoing compliance. In practice, an independent penetration test from a CREST-accredited firm is the evidence assurance reviewers accept without argument.

Why security assurance decides whether your product sells

Around 6,000 GP practices in England buy their clinical systems, online consultation platforms and patient-facing apps through catalogue arrangements, so if your product is not listed, or the listing stalls on thin security evidence, the primary care market is effectively closed to you.

For a GP software supplier the commercial logic is blunt, and digital health founders often discover it late, when the assurance stage asks for security testing evidence the company has never produced.

The pressure does not stop at listing. Integrated care boards and practices run their own due diligence, and a supplier holding patient-identifiable data will face questionnaires that ask directly when the last independent penetration test took place and what was found. A recent, well-scoped report shortens those conversations. A gap where it should be sometimes ends them.

The contractual driver: NHS England’s standards, not guesswork

Three strands of obligation converge on a supplier entering the catalogue. First, the framework’s own security and testing standards, which require suppliers to build, test and operate services securely and to evidence that work to NHS England. Second, the DSPT, which sets the baseline for any organisation touching NHS data and expects vulnerability management to be demonstrable. Third, UK GDPR: a supplier processing patient records is a processor, and Article 32 requires regular testing and evaluation of security measures.

The honest position is this: nothing in GP IT Futures names a specific test methodology or accreditation body. What the assurance process expects is credible, independent evidence that your estate has been attacked in a controlled way and the findings fixed. UK-based testers working under CREST-accredited penetration testing methodology meet that bar, and reports written against a recognised methodology travel well through NHS review processes.

What to test across a GP software estate

Scope should follow the data: anywhere patient-identifiable information is stored, processed or transmitted belongs in the test boundary. For most suppliers that means four areas.

The clinical web application

The core product: appointment booking, consultation records, prescribing workflows, document management. Testing focuses on authentication, session handling, role separation between clinicians, staff and patients, and whether one practice’s tenant can reach another’s data. Multi-tenancy flaws are the most damaging class of finding in primary care software because one bug exposes every customer at once.

APIs and NHS integrations

GP Connect, IM1 pairing integrations and your own product APIs move clinical data between systems, and they are where authorisation logic most often fails. API penetration testing checks token handling, object-level authorisation, rate limiting and data over-exposure per calling role.

Cloud hosting and configuration

Catalogue products commonly run on AWS or Azure. A cloud penetration test reviews identity and access management, storage exposure, network segmentation, secrets handling and logging, because a hardened application on a misconfigured cloud account is still a breach waiting to happen.

External infrastructure

Everything on your public perimeter: portals, mail, VPN endpoints, staging systems that were never meant to be internet-facing. External infrastructure testing is usually the quickest component and frequently surfaces forgotten assets.

How an engagement runs

A supplier engagement starts with scoping, a short call to map products, integrations, hosting and data flows, from which we agree the test boundary and day count. For GP software estates we then attack the authorisation model realistically in staging, with no live patient data ever entering the test.

To make that possible we ask suppliers to stand up a staging tenant seeded with synthetic patient records and role-based test accounts for clinician, administrator and patient users. Where an integration such as IM1 or GP Connect cannot be replicated in staging, we test the supplier-side components and document the boundary honestly.

Findings are reported with severity ratings, reproduction steps and remediation guidance for your engineers, plus an executive summary for assurance reviewers. Retesting of fixed issues follows, and the final report becomes the artefact you hand to NHS England, ICBs and practice-level questionnaires. Our penetration testing checklist walks through what to prepare before day one.

What it costs and how scope drives the price

UK penetration testing is priced by the day, and typical day rates run £1,100 to £1,400. The day count moves with the number of applications and APIs, the complexity of the role model, the size of the cloud estate and how much of the perimeter is in scope.

Component	Typical effort	Typical cost
External infrastructure	2 to 3 days	£2,200 to £4,200
Clinical web application	5 to 8 days	£5,500 to £11,200
API and integration testing	3 to 5 days	£3,300 to £7,000
Cloud configuration review	3 to 4 days	£3,300 to £5,600
Combined supplier assurance package	5 to 12 days	£5,500 to £16,800

Most suppliers preparing catalogue evidence land in the combined range of 5 to 12 days, £5,500 to £16,800, because a blended scope answers the assurance questions in one report. These are typical UK ranges rather than a quotation; our guide to penetration testing costs in the UK explains the drivers in more depth.

How EJN Labs approaches GP IT Futures supplier testing

EJN Labs is a UK firm holding CREST accreditation, Cyber Essentials Plus and ISO 27001, and every engagement is delivered by UK-based testers. Reports destined for NHS England assurance reviewers need to speak the language of NHS data security, and we write them that way, mapping findings to the DSPT expectations and framework standards a reviewer works from.

We scope around your listing timeline. If an assurance deadline is fixed, we sequence the perimeter and application work first so critical findings surface early enough to fix and retest before submission, and we include a free retest of remediated findings so the report you submit shows issues closed, not merely found.

Frequently Asked Questions

Does GP IT Futures require a penetration test?

Not by name. GP IT Futures security and testing standards are contractual and require suppliers to evidence that services have been securely built, tested and operated, but they do not prescribe a specific test type, so no clause forces you to commission a penetration test.

In practice an independent penetration test from a CREST-accredited firm is the evidence NHS England assurance reviewers and NHS buyers accept most readily, so nearly all listed suppliers commission one.

What does penetration testing cost for a GP software supplier?

Most GP software suppliers pay £5,500 to £16,800, which covers 5 to 12 days of testing at typical UK day rates of £1,100 to £1,400. A narrow external-only test starts around 2 to 3 days, £2,200 to £4,200, while a full package sits at the upper end.

That full package covers the application, APIs and cloud hosting. Exact pricing depends on scope.

What should a GP system supplier include in scope?

Include the clinical web application and its role model, any patient-facing apps, your product APIs and NHS integrations such as GP Connect or IM1, the cloud environment hosting it all, and your external perimeter. The rule is simple: follow the patient data.

Multi-tenant isolation deserves explicit attention, because a single tenancy flaw in primary care software exposes every practice using the platform at once.

How often should a catalogue supplier retest?

Retest annually as a baseline, and after any significant change: a new module, a re-platformed backend, a new NHS integration or a major authentication change. Annual testing keeps your evidence current for DSPT submissions and buyer questionnaires, which typically ask for a test within the last twelve months.

Change-driven testing matters because it catches the risks that yearly cycles miss.

Will testing put live patient data at risk?

No, and it should never need to. A properly scoped supplier engagement runs against a staging environment seeded with synthetic patient records and dedicated test accounts, so the authorisation model is attacked realistically without real records being touched. Rules of engagement are agreed in writing beforehand, covering what is in bounds, test windows and emergency contacts on both sides.

Get assurance evidence that clears NHS review first time

If a catalogue listing, DSPT submission or NHS buyer questionnaire is on your roadmap, tell us about your product, integrations and hosting and we will map the test boundary, day count and price. Request a CREST penetration testing quote and get a defensible scope back within one working day.