DTAC v2 for NHS Suppliers: The Recent Compliance Guide

In October 2025, the Journal of Medical Internet Research published a national study of clinical safety compliance across the NHS in England.

• Of 239 NHS organisations surveyed, 204 responded and 178 provided deployment data covering 14,747 digital health tools.
• The median organisation had 25.6% of its deployed digital health technologies fully assured against both standards. This organisational median was based on data from 147 organisations.
• Across the 9,292 deployments for which assurance status was reported, 17.3% were fully assured against both DCB0129 and DCB0160. 
• Across all deployments with reported assurance data, organizations fully assured 17.3% of them against both standards.

DTAC v2 asks fewer questions and cuts down on information already covered by other assurance processes. Suppliers still need to provide evidence for all five assessment areas. There is also a change to the technical security section: suppliers that have signed the Cyber Security Charter for Suppliers to the NHS now have a different route through this part of the assessment.

This guide covers what changed in v2, the evidence NHS buyers expect, and where submissions stall. It targets security leads, compliance managers, and CTOs at small health-tech companies preparing a DTAC assessment.

What Is DTAC v2 and Who Completes It?

DTAC v2 is the current version of the Digital Technology Assessment Criteria (DTAC), the NHS England assessment framework for software-based digital health technologies. Manufacturers complete the DTAC form for each product version, and NHS buyers review the submission as part of procurement due diligence.

DTAC v2 was published on 24 February 2026 and aligns its scope with NICE’s definition of digital health technologies.

In scope

• Mobile apps, web platforms, and SaaS tools built for care recipients, clinicians, or care staff
• Clinical software designed to improve health outcomes
• Operational software built to help the health and care system run more efficiently, manage staffing, or organise resources; a rostering tool or a population health dashboard can qualify

Out of scope

• Firmware and software embedded in hardware devices. This exclusion does not apply when hardware and software are supplied as a single system. In that case, the DCB0129 documentation must cover both components.
• General-purpose systems used in healthcare settings but not built for care, such as payroll or finance software

If a reseller supplies the product to an NHS organisation, the reseller must share the completed DTAC documents, with manufacturer input where needed. The DTAC is not a certificate, and completing it does not give permanent approval to sell into every NHS organisation.

DTAC v1 vs v2: What Changed?

DTAC v2 has about 25% fewer questions than v1. It removed the CSO training requirement and revised the technical security questions.

Most of the question reduction came from removing questions already covered by the Data Security and Protection Toolkit and the pre-acquisition questionnaire. Cyber Essentials at C3.1 and external penetration testing at C3.3 are both still asked for. The Cyber Security Charter route was added at C3.2, which can reduce the technical security evidence required under section C3. NHS England also dropped the code-level security checks and load-testing questions from technical security.

The organization removed the CSO training requirement, though suppliers still need a named Clinical Safety Officer with clinical risk management experience.

DTAC v2 was published in February 2026. The v1 form was retired on 6 April 2026. Any DTAC assessment submitted after that date must use v2.

DTAC v2 Evidence Checklist: What NHS Buyers Expect

An NHS DTAC assessment requires evidence in five areas. Each area asks for documents an NHS buyer can review:

• Clinical safety
• Data protection
• Technical security
• Interoperability
• Usability and accessibility

1. Clinical Safety

Under DCB0129, manufacturers of applicable health IT systems maintain three documents:

• Clinical Risk Management Plan – the process for identifying and managing clinical risks across the product lifecycle.
• Hazard Log – a live record of identified hazards, their severity, and mitigation status. It must be updated as the product changes, not produced once and archived.
• Clinical Safety Case Report – the argument that the product is clinically safe for its intended use, signed off by the named Clinical Safety Officer.

A named Clinical Safety Officer oversees the manufacturer’s clinical risk management activities. The previous requirement for the CSO to complete NHS Digital-specific training has been removed. The CSO must still be a suitably qualified registered clinician with clinical risk management experience.

DCB0129 applies to the manufacturer. DCB0160 applies to the NHS organisation deploying the product. The supplier’s DCB0129 evidence supports the buyer’s DCB0160 assessment. Incomplete or outdated manufacturer evidence creates additional work for the buyer.

2. Data Protection

NHS buyers may ask you to complete the DSPT and reach Standards Met or Standards Exceeded if your product has access to NHS systems or patient data. The DSPT is an annual self-assessment against the National Data Guardian’s ten data security standards. The requirement depends on the supplier’s role and the type of access involved.

ICO registration and a Data Protection Impact Assessment are separate obligations. They sit alongside the DSPT, not inside it. Keep product transparency information, data handling terms, and user agreements ready for the buyer to review.

3. Technical Security

Section C3 of DTAC v2 asks for specific security evidence:

• Cyber Essentials certification at C3.1. The certificate must be valid at the point of submission.
• External penetration test at C3.3. If an existing report is older than 12 months, or was scoped before the current product version, Qualysec can review the gap and test ahead of submission.
• Cyber Security Charter at C3.2. Suppliers that have signed the Charter answer yes at C3.2, which can reduce the technical security evidence required under section C3.

A penetration test report does not automatically satisfy C3.3. Buyers check the tested scope, the methodology, the findings and severity, and the remediation status. The test should cover the web application, APIs, and cloud infrastructure that handle patient data, and it should be carried out by a CREST-accredited firm. A report that tested an older product version, excluded APIs or cloud components, or contains unresolved 7.0+ findings does not provide the assurance the form asks for.

Cyber Essentials confirms baseline controls. A penetration test confirms what happens when those controls are attacked. ISO 27001 can support a supplier’s security assurance, but it does not automatically replace either requirement.

4. Interoperability

Interoperability evidence shows whether the product works with NHS data standards. The usual reference points are HL7 FHIR UK Core, SNOMED CT, NHS Number, and dm+d.

Evidence depends on what the product does:

• FHIR – a FHIR conformance statement and API documentation showing which UK Core profiles the product supports.
• SNOMED CT – evidence of implementation where clinical terms are recorded.
• dm+d – evidence of implementation where medicines are recorded.
• NHS Number – documentation of how the product uses it for patient matching.

A buyer should be able to verify the interoperability claim from the documentation provided. A statement that the product is “interoperable” without the supporting documents does not answer the question.

5. Usability and Accessibility

Suppliers should provide evidence that the product has been tested with its intended users, such as clinicians, patients, or care staff. For patient-facing products, accessibility evidence should show compliance with WCAG 2.2 AA. A verified Accessibility Conformance Report (VPAT or ACR) is the format NHS buyers increasingly expect before contract award. Design specifications alone do not show how the product works for the people who use it.

How to Prepare a DTAC v2 Submission: A 10-Step Checklist

Preparation means auditing the evidence you already hold against the five DTAC areas before opening the form, then fixing the weakest area and confirming every document is current.

1. Fix the product scope and version.

Decide precisely which product, version, and configuration the pack describes. Write the intended use first because almost every other answer depends on it.

2. Download the current DTAC NHS form.

Download the current DTAC NHS form from NHS England at the point of use. Do not reuse a saved copy or a locally amended version. The v1 form was retired on 6 April 2026, and submitting it can stall the assessment.

3. Inventory the evidence you already hold against the five areas.

DSPT covers much of C2. Cyber Essentials or ISO 27001 covers parts of C3. DCB0129 covers C1. A supplier holding those is most of the way through the pack before answering a DTAC-specific question.

4. Start with clinical safety, not technical security.

C1 has the longest lead time and is the most common hard stop. A supplier with no clinical safety case and no named CSO reaches C1 with nothing to submit.

5. Check the DSPT position.

DSPT “Standards Met” pre-answers multiple DTAC questions because v2 removed duplication with DSPT and the PAQ. Most small suppliers fall into Category 3. Category 2 applies only when all three conditions are met: 50+ staff, £10m+ turnover, and supplying digital goods or services to the NHS. An out-of-date DSPT is one of the recurring reasons submissions stall.

6. Check the penetration test report against the C3.3 conditions set out above.

Confirm that the test was completed within the previous 12 months, addresses the OWASP Top 10, and covers the current production environment, including APIs and cloud infrastructure handling patient data. High and critical findings should show verified remediation. Where a buyer accepts residual risk, document the decision and its justification. The report must still meet the stated C3.3 vulnerability threshold

7. Check the DPIA against the real data flows.

A template DPIA, a stale one, or one missing the lawful basis or transfer position is a common stall point. The DPIA should reflect how data moves through the product today.

8. Check the currency of every document.

Buyers will question evidence older than your last significant product release. The Hazard Log needs to be live and product-specific. The Clinical Safety Case Report must match the version being deployed.

9. Assign a named owner for each of the five areas.

Each owner needs to be able to answer follow-up questions in a review call.

10. Keep the pack current for each product version.

NHS England expects manufacturers to maintain an up-to-date form and supporting documents for every version. Review the pack whenever the product changes or evidence expires.

How Qualysec Supports DTAC V2 Technical Security Requirements

Question C3.3 asks for an external penetration test summary, and that is what Qualysec produces for health-tech vendors. Testing teams cover web applications, APIs, and cloud networks, scoring findings against CVSS so that they flag anything at 7.0 or above for remediation before the report reaches the buyer. Qualysec holds CREST accreditation for penetration testing, which NHS buyers check when they ask who carried out the test.

The report sets out vulnerability severity, potential impact, and remediation steps, with an executive summary for readers who will not work through the full technical document. A supplier without a dedicated security function can forward it to a buyer without rewriting it first.

If an existing report is older than 12 months, or was scoped before the current product version, Qualysec can review the gap and test ahead of submission.

Speak to Qualysec about a C3.3-ready penetration test summary.

Conclusion

NHS buyers start with three documents. They ask for your DSPT status, your DCB0129 pack, and your C3 penetration test summary. Each one expires on a different schedule.

The DSPT renews annually. Clinical safety documentation has to follow each product release. Buyers will question a penetration test older than 12 months, or one scoped before your current architecture, even when the findings were clean at the time.

DTAC compliance means updating the pack when the product changes, not rebuilding it when a buyer asks.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

DTAC v2 FAQs

1. Is DTAC v2 mandatory for NHS suppliers?

NHS buyers ask for a completed DTAC form during procurement, and since 6 April 2026 they ask for v2.0. A supplier without one usually stalls at the assurance stage.

The form is not a statutory certificate, so the obligation comes from the buyer’s due diligence and the contract terms, not from the framework itself.

2. Does DTAC v2 require penetration testing?

Yes, for internet-facing products. Question C3.3 asks for an external penetration test summary from the previous 12 months, covering the OWASP Top 10, with no vulnerability scoring 7.0 or above on CVSS.

A recent report can still fail if the tested scope excluded APIs or cloud infrastructure handling patient data, or if a 7.0+ finding remains open.

3. Does DTAC v2 replace the DSPT or DCB0129?

No. DSPT is the supplier’s annual data security self-assessment, and DTAC removed the questions already covered by it. DCB0129 is the manufacturer’s clinical risk documentation, and DTAC asks for it directly.

DTAC sits on top of both and reuses their evidence rather than replacing either.