What the NHS DTAC Means for Healthcare Software Suppliers

Any supplier selling digital health technology into the NHS in England will be asked for a completed DTAC form, usually early in procurement and often before a demonstration has finished. The Digital Technology Assessment Criteria bring together the baseline standards a product must meet, and a DTAC NHS assessment is where buyers check that evidence. Building software with those criteria in mind from the first sprint is part of the bespoke software development for healthcare suppliers that Priority Pixels provides.

The form changed in February 2026, so suppliers still working from an older template have some catching up to do. Knowing what each section asks for, and which documents sit behind each answer, makes DTAC a normal output of good delivery rather than a hurdle at the end of a sales cycle. Our article on where software makes the difference in healthcare digital transformation looks at the wider programmes these products sit within.

What Changed in the 2026 DTAC Form

NHS England reviewed DTAC with industry in 2024 and introduced a new version of the form in February 2026. The NHS England DTAC guidance confirms the new form has 25% fewer questions and removes duplication with the Data Security and Protection Toolkit and the pre-acquisition questionnaire for medical devices. It also focuses DTAC on software-based digital health technologies in line with NICE.

Two further changes matter to suppliers. The requirement for the named Clinical Safety Officer to have completed NHS training specific to DTAC no longer applies, although the role must still be filled by a suitably qualified and registered clinician. Buyers are also told to accept the standard national form rather than creating their own versions, and to ask for anything extra as a separate request.

The form also records the version of the product it describes. NHS England’s explanation of how DTAC works expects manufacturers to keep an up to date form and supporting documents for each product version, so the evidence has to move with every significant release.

What a DTAC NHS Assessment Looks At

The form is divided into lettered sections. Sections A and B collect company details and the product’s intended use and benefits. Neither is scored, although section B asks for data flows and user journeys that assessors rely on throughout. Sections C1 to C4 hold the assessed criteria, and a product must meet them to pass, while section D covers usability and accessibility and gives buyers a comparative score rather than a pass or fail.

NHS England’s guidance on conducting a DTAC assessment gives each assessed section its own accountable officer within the buying organisation, from the chief clinical information officer for clinical safety to the data protection officer for data protection. The same handful of terms comes up in every section, and suppliers new to NHS work often meet them all at once.

Safety case

The clinical safety case report sets out the argument and evidence that a product is safe for a given use at a given point in its life. It is maintained throughout the product lifecycle rather than written once.

Hazard log

A running record of identified clinical hazards and how each one is controlled. It shows which risks need action from the buyer to reach an acceptable level.

CSO

The Clinical Safety Officer is a registered, experienced clinician responsible for making sure clinical risk management is followed. Suppliers can provide this role through an outsourced arrangement.

DPIA

A Data Protection Impact Assessment describing how the product uses personal data and the risks involved. Buyers use the supplier’s version when completing their own as data controller.

DSPT

The Data Security and Protection Toolkit, an annual self-assessment for organisations with access to NHS patient data and systems. Suppliers need a standards met status or higher.

None of these documents is unique to DTAC. They are the working records of a supplier that manages clinical risk, data protection and security properly, which is why the strongest submissions draw on material that already exists.

Clinical Safety and Data Protection Evidence

Clinical safety in section C1 rests on the DCB0129 standard for manufacturers of health IT. If a product provides information that can influence, support or manage the real time or near real time direct care of patients, the supplier must show a compliant clinical risk management system and name a Clinical Safety Officer, as well as supplying a clinical safety case report and hazard log. Products outside that definition need a written justification, and buyers are entitled to challenge it.

Section C2 checks data protection under UK GDPR. Suppliers with access to patient data or national NHS systems must meet the annual toolkit standard, and any product processing personal data needs evidence of ICO registration, a DPIA, transparency information and fair terms of use. The form also asks where data is stored and processed, and anything held outside the UK needs a lawful transfer mechanism such as an adequacy decision or an International Data Transfer Agreement.

Technical Security and Interoperability Evidence

Section C3 opens with a valid Cyber Essentials certificate. Suppliers that have not signed the Cyber Security Charter for suppliers to the NHS then need an external penetration test from the previous 12 months that tested for the common web application risks catalogued by OWASP, with no vulnerabilities scoring 7.0 or above on the Common Vulnerability Scoring System. They must also confirm their development follows the government’s Software Security Code of Practice, show a plan for multi-factor authentication and confirm that logging requirements are defined.

Interoperability in section C4 asks whether any APIs the product exposes use appropriate standards, follow government open API guidance and are documented for third parties. Where patient data moves between systems, the product should identify patients by NHS number and ideally validate it against the Personal Demographics Service, and patient-facing products are expected to use NHS login or explain an alternative that protects privacy. Our guide to API integration covers the wider principles behind documented, well-behaved interfaces.

Usability and Accessibility Scoring

Section D1 is not pass or fail, but it can decide which product a buyer chooses when several meet the baseline. Suppliers are asked for user journeys showing how the product fits a care pathway, whether they test with intended users and whether they have considered the Accessible Information Standard in their design.

Web and mobile products are asked whether they meet WCAG 2.2 AA and to link to a published accessibility statement, and suppliers also report average service availability over the previous 12 months. Accessibility designed in from the start costs far less than remediation, and Priority Pixels offers accessibility audit and remediation services against the same WCAG 2.2 AA standard.

Building DTAC Evidence Into Delivery

Suppliers who treat DTAC as a form to complete at the end of a project tend to find gaps they cannot close quickly, such as a penetration test that was never booked or a hazard log that was never started. Suppliers who produce the evidence as they build usually find the form becomes a matter of collating documents that already exist. It also means the answers are accurate for the version being sold, which matters when buyers check dates on certificates and test reports. Buyers see the same obligations from the other side, which our guide to healthcare software development for UK buyers covers.

NHS organisations commissioning bespoke software face the same question from the other side, because products built on their behalf must still meet DTAC standards even when internal governance handles the assurance. A simple sequence keeps the evidence current across the life of the product.

Priority Pixels holds Cyber Essentials certification and starts every software project with a discovery stage that maps the process, the systems and the exceptions before any code is scoped. For health and care products, that stage is where DTAC scope, clinical safety roles and integration requirements get agreed, so the written proposal covers the assurance work as well as the build.