A healthtech founder told me in the spring that her team had spent four weeks completing a Digital Technology Assessment Criteria pack for an NHS trust, only to be told partway through the procurement that the trust was no longer working to it. The pack was not wasted, because most of the underlying evidence transfers. The four weeks of assuming it was the finished article were.
That experience is now common enough to be worth writing down. The assurance route into NHS digital procurement has changed, the change happened without much noise outside the specialist press, and a supplier working from a 2024 playbook will produce the wrong evidence at the wrong depth.
What follows is a practitioner read on where things stand as at August 2026. NHS England's assurance architecture has moved several times in recent years and continues to move, so treat the specifics here as a prompt to verify against current NHS England publications rather than as a settled position. Where I am not confident, I say so.
What changed and when
DTAC was introduced as a common baseline assessment for digital health technologies, covering clinical safety, data protection, technical security, interoperability, and usability and accessibility. Its purpose was to stop every trust inventing its own questionnaire. In practice it became a document suppliers completed once and reused, and buyers accepted with varying degrees of scrutiny.
What I can state with confidence is that DTAC has been revised rather than left alone, with NHS England describing a refreshed and shortened form intended to create a simpler and more trusted pathway. Alongside that, procurement of AI specifically is being routed increasingly through dedicated framework agreements rather than through generic digital assurance, with large AI-specific commercial frameworks now in the market.
The direction of travel is clear enough: from one broad criteria document applied to everything from a scheduling tool to a diagnostic algorithm, toward domain-specific assurance attached to a procurement route, and from a per-procurement completion exercise toward something closer to a standing assured position that buyers can rely on.
What I would not have you take from me are the specifics that circulate in secondary commentary and that I have not been able to confirm against a primary NHS England publication. I have seen it asserted that DTAC was retired outright at the end of 2025 and replaced by a named Digital Frameworks or assured supplier product, and I have seen a December 2026 date cited as the point at which an AI framework becomes compulsory for procurements under the AI Diagnostic Fund. Neither is something I can evidence from an NHS England source, and neither should be used to set a bid timeline. If your bid depends on either, ask the commissioning body directly and get the answer in writing.
What the AI framework asks that DTAC did not
The substantive change for AI vendors is depth rather than subject matter.
DTAC touched AI only glancingly. Its clinical safety section asked whether DCB0129 had been complied with. Its data protection section asked the standard UK GDPR questions. Nothing in it required a supplier to describe the model, its training data, its performance characteristics across patient subgroups, or the arrangements for monitoring it after deployment.
An AI-specific assurance route asks those questions directly. Expect to be asked what the model does and on what basis, what data it was trained on and how representative that data is of the population it will be used on, how performance was validated and against what reference standard, how performance varies across demographic subgroups and what was done about any variation found, what the human oversight arrangement is and what authority the clinician has to override, how model drift is detected in operation, what happens when the model is updated and whether the update is revalidated, and who is accountable.
That last cluster, the post-deployment questions, is where suppliers are weakest. A vendor can usually evidence how a model performed at validation. Far fewer can evidence how it is performing now, in the deploying organisation, on that organisation's population.
There is also an equality dimension that suppliers underestimate. NHS organisations carry the public sector equality duty, and a deploying trust asking about subgroup performance is not being difficult. It is discharging its own statutory obligation, and a supplier who cannot answer creates a problem the trust cannot solve locally.
Clinical safety is separate, and mandatory
The most expensive misunderstanding I see is a supplier treating the framework assurance route as the whole of the requirement.
Clinical safety runs on a separate track and is mandatory. DCB0129 applies to manufacturers of health IT systems. DCB0160 applies to health and care organisations deploying and using them. Both are information standards published under section 250 of the Health and Social Care Act 2012, which gives them statutory footing rather than the status of best practice.
The practical consequences are concrete. A manufacturer must appoint a suitably qualified and experienced Clinical Safety Officer, who must be a registered clinician with current registration and appropriate training. That person owns the clinical risk management process, the hazard log, and the clinical safety case report. The deploying organisation must do the equivalent under DCB0160 for its own local implementation, and its Clinical Safety Officer will want your safety case report as an input.
None of this is discharged by framework assurance and none of it is discharged by ISO 42001. A supplier that has an assured status and no clinical safety case will be stopped by the trust's own safety officer, and that conversation happens after the procurement rather than during it.
For AI specifically, the hazard analysis is harder than for conventional software, because the failure modes are probabilistic rather than deterministic. False negatives, false positives, automation bias in the reviewing clinician, degradation as the population shifts, and behaviour on cases outside the training distribution all have to appear in the hazard log with controls attached. A safety case written for a rules-based system and lightly adapted will not survive scrutiny.
Where ISO 42001 fits, and where it does not
ISO 42001 gives you the management system. That is a real contribution and it is not the whole answer.
What it does provide maps well onto what an AI assurance route asks for. The AI system inventory, the impact assessment process, the risk management approach applied to AI-specific risk, the data governance controls covering training and operational data, the human oversight determination, the post-deployment monitoring requirement, the supplier governance for third-party models, and the internal audit and management review architecture that keeps all of it honest. A vendor with an operating AIMS answers a large share of an AI assurance questionnaire from documents that already exist.
What it does not provide is anything clinical. ISO 42001 has no concept of clinical risk, no hazard log, no Clinical Safety Officer, and no relationship to DCB0129 or DCB0160. Nor does it touch medical device conformity assessment. An auditor certifying your AIMS will not look at your safety case and would not be competent to.
The honest framing for a healthtech board is that ISO 42001 covers the governance layer that NHS AI assurance increasingly expects and that no other single instrument provides, and that clinical safety and, where applicable, device regulation sit alongside it as separate and non-negotiable obligations.
The medical device question
Software with a medical purpose may be regulated as a medical device in the UK, and this is where I would urge the most caution.
If your software is intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, it may fall within the medical device definition and require conformity assessment before being placed on the UK market. AI-enabled diagnostic and triage products commonly do. Products that support administration, scheduling, or general wellbeing commonly do not. The boundary cases are genuinely difficult and turn on intended purpose as you state it, including in your marketing.
The UK regulatory framework in this area is also changing. The MHRA has been developing its approach to software and AI as a medical device, including work on the post-market surveillance regime and on how adaptive systems are handled. I am not going to summarise the current position in a paragraph, because a summary that is right in August 2026 may not be right in six months and a supplier that relied on it would be worse off than one that took advice.
The instruction is simple. Determine your own classification, with regulatory advice, and document the reasoning. Do it before the bid rather than after the award. A trust that discovers mid-deployment that an unclassified product should have been a device has an incident on its hands, and the supplier relationship does not usually survive it.
What transfers from your DTAC pack
If you completed DTAC in the last two years, most of the underlying evidence still has value even though the wrapper does not.
The clinical safety evidence transfers directly, because DCB0129 and DCB0160 were never part of DTAC in substance. DTAC asked whether you complied. The obligation itself is unchanged and statutory, so a current safety case report and hazard log remain live assets.
The data protection evidence transfers. Your record of processing, DPIA, data flow documentation, retention position and sub-processor list are all still required and still in the same shape.
The technical security evidence transfers, and if you hold ISO 27001 or Cyber Essentials Plus those remain the most efficient way to answer that domain.
The interoperability and accessibility content transfers, with the caveat that accessibility expectations are tightening rather than loosening.
What does not transfer is the depth of the AI answer. DTAC's treatment of AI was thin enough that a supplier could pass it without describing the model at all. That is the section to rebuild, and it is the section most likely to be scrutinised by someone with the expertise to test it.
What a vendor bidding into the NHS should do now
Establish your regulatory position first. Are you a medical device, and if so what class. That answer determines the size of everything else and cannot be deferred.
Appoint or contract a Clinical Safety Officer and produce the DCB0129 clinical safety case report for your product as it currently stands. This is the item with the longest lead time that a supplier can control, and it is the one most often started last.
Build the AI evidence set in parallel: model documentation, training data description and representativeness, validation methodology and results, subgroup performance analysis, human oversight design, drift monitoring, and update and revalidation policy. Write these as artefacts a reviewer can read rather than as internal engineering notes.
Put the management system underneath it. ISO 42001 is the instrument that keeps that evidence current rather than a snapshot, and it is increasingly what enterprise and public sector buyers outside health are asking for too, so the investment travels.
Then confirm the framework requirement directly with the commissioning route you are bidding into. Ask which framework applies, what assured supplier status requires, what evidence is expected at what depth, and what the deadline actually is for your procurement. Verify rather than infer. The assurance landscape has changed twice in recent years and the people running the procurement are the authoritative source for what they will accept.
If you are preparing NHS or enterprise AI assurance evidence and need the artefacts assembled rather than the process described, the AI Trust Evidence Pack produces them. See what it contains.
Last reviewed: August 2026.