DSPT 2025/26 is in. Your evidence is at its freshest right now. Never do June again →

Who we serve

What a GP software provider needs to do to be compliant

An annual DSPT, a DTAC for every buying organisation, DCB 0129 with a named Clinical Safety Officer, Cyber Essentials plus a pen test under twelve months old, and integration assurance for anything touching GP systems. Products that inform clinical decisions add MHRA device rules.

Reviewed 5 July 2026 · Neil Chandarana, founder, Highguard

The requirements

Every requirement for a GP software provider, in plain English.

DSPT, every year

  • Publish annually by 30 June
  • Largest IT suppliers need an independent audit
  • Category depends on size

Any supplier handling NHS patient data publishes the DSPT annually by 30 June. The largest IT suppliers, judged on staff numbers and turnover, sit in a category that now requires an independent audit of their submission; smaller firms complete a lower category with self-assessment. Which side of that line you fall on changes the cost and the calendar, so check it before the year starts rather than after.

Sources: DSPT Toolkit · DSPT Toolkit

DTAC, per buying organisation

  • Standard form mandatory since 6 April 2026
  • Assessed by each buying organisation
  • Needs Cyber Essentials and a recent pen test

The Digital Technology Assessment Criteria is the NHS baseline check for digital health tools, refreshed in February 2026 with the standard form mandatory since 6 April 2026. It covers clinical safety, data protection, security, interoperability and usability. The refreshed form is about a quarter shorter, drops questions your DSPT already answers, and adds a decision tree for medical-device classification. Each buyer runs its own review, so expect to complete it more than once; the security section wants Cyber Essentials and a penetration test less than twelve months old.

Sources: NHS England · HTN

DCB 0129 and a Clinical Safety Officer

  • Requires a registered-clinician CSO
  • Hazard log and clinical safety case
  • Checked through DTAC

DCB 0129 is the clinical risk management standard for health IT manufacturers. It requires a named Clinical Safety Officer who is a registered clinician trained in clinical risk management, and who owns the clinical risk management plan, a maintained hazard log and a clinical safety case across the product's lifecycle. Buyers check for it through DTAC, and it is not something you can backfill the week a deal closes.

Sources: NHS Digital · NHS England

UK GDPR, ICO fee and possibly a DPO

  • ICO fee renews annually
  • DPO required for large-scale health data

Processing patient data means the annual ICO fee, records of processing and data protection impact assessments where warranted. If your core activity is large-scale processing of health data, which describes most GP software, a Data Protection Officer is required rather than optional. The role can be outsourced, but it must be named and resourced.

Sources: ICO · ICO

NHS integration assurance

  • IM1 pairing needs SCAL and witness testing
  • GP Connect has its own conformance
  • Core GP IT via the Tech Innovation Framework

Connecting to GP systems has its own assurance layer. IM1 pairing runs through a Supplier Conformance Assessment List, witness testing with each foundation system supplier and a formal recommendation to connect. GP Connect has its own conformance process for record access, and NHS App onboarding starts with NHS login integration. Core GP IT is now bought through the Tech Innovation Framework, which expects public-cloud, browser-based products with open APIs.

Sources: NHS Digital · NHS Digital · NHS Digital · NHS England

MHRA and UKCA, when the product decides things

  • Applies when software informs clinical decisions
  • MHRA registration and UKCA marking

Software that informs clinical decisions, such as triage, diagnosis support or dose calculation, can qualify as a medical device. That means MHRA registration and UKCA marking, and symptom checkers that enable diagnosis can land in Class IIa, which needs a UK Approved Body rather than self-declaration. Worth settling early with a documented determination, because the answer shapes your whole evidence base.

Sources: GOV.UK (MHRA)

How it grows

GP software compliance as you grow.

Stage 1

First pilot

ICO registration, a first DSPT publication, DCB 0129 with a named CSO, one DTAC for the pilot buyer and Cyber Essentials. Enough to be taken seriously.

Stage 2

Multi-ICB

Repeated DTACs for each new buyer, Cyber Essentials Plus, annual penetration tests, IM1 and GP Connect integrations, and a DPO as processing scales.

Stage 3

National

The audited DSPT tier, Tech Innovation Framework listing, ISO 27001 as a standing expectation in tenders, and MHRA registration where the product qualifies.

Common questions

GP software compliance, asked and answered.

What is DTAC and when do we need it?

DTAC is the NHS baseline assessment for digital health technologies, covering clinical safety, data protection, security, interoperability and usability. You need it whenever an NHS organisation buys your product, and the standard form has been mandatory since 6 April 2026.

Do we need a Clinical Safety Officer?

Yes, if you make health IT used in care. DCB 0129 requires a named Clinical Safety Officer who is a registered clinician, plus a hazard log and clinical safety case. DTAC checks for all three.

Is Cyber Essentials mandatory for selling to general practice?

In practice yes. The DTAC security section asks for Cyber Essentials and a penetration test less than twelve months old, and buyers treat both as pass or fail.

Does a completed DTAC carry over to the next buyer?

No. Each buying organisation runs its own assessment. The underlying evidence is reusable, so the second and third submissions should be far faster than the first.

Is our software a medical device?

If it informs clinical decisions, it might be. Software as a medical device needs MHRA registration and UKCA marking, and Class IIa and above needs a UK Approved Body. Get a documented determination either way.

Highguard

Why this list keeps getting longer.

Somewhere along the way, compliance stopped being about security and became about admin. Portals, spreadsheets, evidence uploaded again and again, policy templates nobody reads.

The result is organisations that are certified but not secure. Teams that are busy but not protected.

It should not work like this. Compliance should be a side effect of good practice. Evidence of the work you already do, not a second job on top of it.

That is why Highguard exists. We are your compliance department. Specialists and AI agents do the work on this page, and you approve every word before anything is submitted.

Every engagement starts with an audit. In your first week you get a report of where you are compliant and where you are exposed, specific to your organisation.

Talk to us →
Get started

Talk to us.

Book a 15-minute call. We'll show you where you stand and how fast we can get you certified.