Why the NCSC AI Cyber Security Code Should Shape Every UK AI Supplier Contract

AI Trust & Governance

21 April 2026 | By Ashley Marshall

Most UK businesses buying AI in 2025 wrote contracts that treat it like ordinary software. That is now a governance gap, not just a best-practice miss.

What the NCSC AI Cyber Security Code of Practice Actually Is

In January 2025, the UK Department for Science, Innovation and Technology (DSIT), working closely with the National Cyber Security Centre (NCSC), published the AI Cyber Security Code of Practice. It was not a sudden announcement. It followed a formal Call for Views held between May and August 2024, which attracted responses from across industry, academia, and civil society. The result was striking: 80% of respondents endorsed the government's proposed intervention, and support for each individual principle within the Code ranged from 83% to 90%.

The Code sets out baseline cyber security requirements for AI systems throughout their full lifecycle. It covers five phases: secure design, secure development, secure deployment, secure maintenance, and secure end of life. Structured around 13 specific principles, it defines obligations across five stakeholder groups - developers, system operators, data custodians, end-users, and affected entities. That final category matters: it extends accountability beyond the direct users of an AI system to anyone affected by its outputs, even indirectly.

Crucially, the Code is not just a UK document. DSIT and NCSC collaborated with international counterparts and submitted the Code to the European Telecommunications Standards Institute (ETSI), where it formed the basis for a new global standard, TS 104 223 - published in May 2025. The NCSC described this as "the first global standard that sets minimum security requirements across the entire AI lifecycle for all stakeholders in the AI supply chain." That is not a modest claim, and it is an accurate one.

What this means in practice for UK businesses is that the Code is not an internal policy document sitting on a civil servant's shelf. It is the architecture for an international benchmark that will travel into procurement frameworks, insurance requirements, and regulatory expectations whether you are ready for it or not. The accompanying implementation guide, developed by John Sotiropoulos - Senior Security Architect at Kainos and co-lead of the OWASP Top 10 for LLM Applications - translates these principles into actionable requirements with real-world examples mapped to frameworks including NIST, ISO 27001, and OWASP 2024.

Before any organisation asks how to embed this Code into contracts, it first needs to understand which stakeholder role it occupies. A firm that buys a third-party AI tool and deploys it within its own infrastructure is a system operator. One that fine-tunes a foundation model is both a developer and a system operator. Many businesses will hold multiple roles simultaneously, and the obligations that attach to each role differ. Getting this classification right is the necessary first step before any contractual language can be meaningful.

The 13 Principles and Why Software Contracts Miss Them

The 13 principles in the Code are structured around the AI development lifecycle rather than the more familiar perimeter-and-patch model used in traditional IT security. This distinction matters enormously for contracts, because most standard software procurement agreements were written with the assumption that security is a property you can assess at the point of purchase and then leave largely alone. AI does not work like that.

Consider Principle 3, which requires developers and system operators to evaluate threats and manage security risks continuously, including reviews whenever a new configuration or setting is updated at any stage of the AI lifecycle. That is a live, iterative obligation - not a one-time checklist. Principle 12 requires ongoing monitoring of system behaviour. Principle 11 mandates regular security updates, patches, and mitigations. None of these fit neatly into a standard SLA that specifies uptime and response times but says nothing about how the model itself is maintained over time.

Principle 5 is particularly relevant for procurement teams: it requires developers, data custodians, and system operators to maintain a comprehensive inventory of their assets, including interdependencies and connectivity. In AI terms, this includes training datasets, model weights, prompts, and the data pipelines feeding the system. A supplier that cannot produce an AI-specific asset inventory on request is not compliant with Principle 5, and any contract that does not require this creates an accountability gap from day one.

Principle 8 - document your data, models, and prompts - maps directly to what is increasingly called an AI Bill of Materials (AI BOM), the AI equivalent of the Software Bill of Materials (SBOM) that has become a fixture in US federal procurement and is growing in prominence here. If a supplier cannot tell you which foundation model underpins their product, which version it is, how it was fine-tuned, and what data it was trained on, you cannot assess the risk you are taking on. The Code makes this documentation a baseline expectation.

Principle 4, enabling human responsibility for AI systems, has direct governance implications. It requires developers and system operators to incorporate and maintain capabilities for human oversight, and to make end-users aware of prohibited use cases. In contract terms, this should translate into clauses specifying what the AI system is and is not permitted to do, who retains responsibility for outputs, and what override or intervention capabilities must be available. Without this, customers routinely discover after deployment that their AI supplier regards model outputs as fully autonomous and disclaimed.

The combined effect of the 13 principles is to create a security posture that is dynamic, documented, and distributed across the supply chain. Standard IT contracts are not built for this. Updating them is not optional if you want your AI governance to be credible.

Principle 7 and the Supply Chain Obligation in Practice

If there is one principle that organisations buying AI should prioritise when reviewing supplier contracts, it is Principle 7: Secure your supply chain. This principle applies primarily to developers and system operators, and it sits within the Secure Development phase of the lifecycle. Its implications cascade across every tier of an AI vendor relationship.

The Code's language here is deliberately specific. Principle 2.4 requires that where a developer or system operator uses an external component, they must conduct an AI security risk assessment and due diligence process that assesses AI-specific risks. Principle 2.7 goes further: if a developer or system operator chooses to work with an external provider, "they shall undertake a due diligence assessment and should ensure that the provider is adhering to this Code of Practice." That phrase - ensure that the provider is adhering - is not satisfied by asking a supplier to sign a self-certification checkbox. It requires ongoing assurance.

Principle 6.6 is the contractual hook: "Developers and System Operators should ensure that, where they are using cloud service operators to help to deliver the capability, their contractual agreements support compliance with the above requirements." This is a direct instruction to write the Code's requirements into contracts. It also extends liability upward: if your AI supplier is using AWS, Azure, or Google Cloud to deliver their model inference, their contractual agreements with those cloud providers need to support compliance too. You need to know this before you sign.

What this looks like in practice is a tiered due diligence approach. Before contracting with an AI supplier, you need answers to questions such as: Which foundation models does your product use, and from which providers? Do you maintain a comprehensive asset inventory that includes model versions, training data provenance, and prompt configurations? How do you identify, track, and communicate security threats that arise from new model configurations or updates? What is your process for security patching and model updates, and how will we be notified? Can you demonstrate that your cloud infrastructure providers' contractual obligations support the AI Code of Practice requirements?

These are not unreasonable questions. They are baseline questions. UK public sector procurement is already moving in this direction - the Crown Commercial Service has published guidance on AI supplier assessments that references NCSC guidance, and central government departments are increasingly requiring suppliers to demonstrate alignment with the Code as a condition of contract. Private sector procurement teams that have not yet followed suit are taking on liability that their insurance policies may not cover.

It is also worth noting that the Cyber Security and Resilience (Network and Information Systems) Bill, published in draft in November 2025, creates new regulatory powers over supply chains for essential and digital services. While the Code itself remains voluntary, the broader legislative environment is contracting around it. Suppliers who cannot evidence alignment with the Code's principles will face growing difficulty passing procurement gates regardless of sector.

Drafting Contract Clauses That Actually Reflect the Code

One of the most common mistakes organisations make when they discover a new regulatory framework is to add a generic compliance clause to their contracts - something like "the supplier warrants compliance with all applicable laws and industry codes of practice." This provides almost no protection. The AI Cyber Security Code of Practice is specific enough that it deserves specific contractual treatment, and the effort of getting it right now is far lower than the cost of dispute or incident response later.

Start with the definition of the AI system being procured. Contracts should require suppliers to document the components of the AI system at a level of specificity sufficient to perform a risk assessment: which foundation model or models are in use, which version, who the upstream provider is, what fine-tuning has been applied and on what data, and what the inference infrastructure looks like. This maps to Principles 5 and 8 and is the contractual equivalent of requiring an AI BOM. Without it, you cannot assess your exposure and you cannot demonstrate that you have exercised due diligence.

Next, address the dynamic nature of AI security. Static compliance snapshots are not enough. Contracts should require suppliers to notify you within a defined timeframe - typically 24 to 72 hours - if a security threat is identified that relates to the AI components in the product. This reflects Principle 3.2, which requires that where AI security threats are identified that cannot be resolved by developers, this must be communicated to system operators so they can threat-model their own systems. If your contract has no notification obligation for AI-specific threats, you will not receive that communication unless the supplier volunteers it.

Include explicit obligations around model updates. Principle 11 requires regular security updates, patches, and mitigations. But in AI, a model update is not the same as a software patch - it can change outputs in ways that affect your customers, your regulators, and your liability position. Contracts should specify that material model updates require advance notice, a description of what changed and why, and an assessment of how the change affects the security posture of the deployed system. This is routine in regulated sectors such as financial services for system changes generally; it needs to become routine for AI specifically.

Human oversight and prohibited use cases should be explicit in the contract. Principle 4.5 requires developers and system operators to make end-users aware of prohibited use cases. In practice, this means the contract should define what the AI system is scoped to do, what it is explicitly not permitted to do, and who bears liability for outputs generated outside the defined scope. If your supplier's terms of service disclaim responsibility for any output, you have accepted unlimited liability for their model's behaviour within your deployment. That is a risk that needs to be consciously accepted and disclosed to your own board, not buried in standard terms.

Finally, build in audit rights. The Code's requirements around documentation, asset inventories, threat modelling, and supply chain assurance are only meaningful if you have the right to verify them. Contracts should include a right to audit or require a recognised third-party assessment - such as alignment with ISO 27001 or a formal self-assessment against the ETSI TS 104 223 standard - on a periodic basis or following a material security incident. This is standard in financial services and healthcare supplier contracts. It should be standard for AI suppliers too.

The Counterargument: Is This Overkill for Smaller AI Purchases?

The most common pushback when organisations are presented with a rigorous AI supplier contract framework is that it is disproportionate. If you are buying a mid-market SaaS tool that uses AI to summarise customer support tickets, do you really need to require the vendor to produce an AI asset inventory and give you audit rights over their model updates? The answer requires nuance, but it tends to come out closer to yes than most procurement teams expect.

The argument for proportionality is not wrong in principle. The Code itself is structured so that the intensity of requirements scales with the nature of the AI system and the associated risks. A low-stakes productivity tool used internally by a small team carries a different risk profile to an AI system making credit decisions or triaging medical referrals. The implementation guide published alongside the Code explicitly acknowledges this, providing examples that are calibrated to different deployment contexts and organisational sizes.

However, the proportionality argument is often misapplied. It becomes an excuse to do nothing, when what it actually permits is doing less - but still doing something. Even for a straightforward AI writing assistant, you need to know which foundation model is being used and from which provider, because that determines your data processing obligations under UK GDPR and the ICO's guidance on AI and data protection. You need to know whether the model is continuously retrained on user inputs, because if it is, your staff's inputs may be training the model that your competitors also use. You need to know how the supplier communicates security incidents, because even a writing tool can become a vector for prompt injection attacks that expose confidential information.

The proportionality principle also breaks down as AI becomes embedded. Tools that seem low-stakes at point of purchase tend to acquire higher-stakes use cases over time, as teams discover new applications. A contract written for low-risk use with no meaningful AI security obligations becomes dangerously thin once the tool is being used to draft legal documents, generate financial analysis, or communicate with customers. Building baseline Code-aligned obligations into every AI supplier contract - scaled to the initial risk but with provisions that allow for re-assessment as use expands - is the more defensible position.

There is also a market dynamic worth acknowledging. AI suppliers who cannot meet baseline Code-aligned obligations are suppliers you should be cautious about regardless of price. The Code's requirements are not onerous for any supplier with a mature security posture. A supplier that pushes back hard on documenting their model components or providing security notification obligations is telling you something important about how they view their own accountability. That is information worth having before you sign.

What Changes as the ETSI Standard Lands and Legislation Advances

The AI Cyber Security Code of Practice is described as voluntary. That label is accurate in the narrow sense that there is no current statutory obligation to comply with it. But the environment around it is shifting in ways that make treating it as optional increasingly risky, and procurement teams would be wise to understand the trajectory rather than just the current position.

The publication of the ETSI TS 104 223 standard in May 2025 was a significant step. This is the first global standard covering AI security across the full lifecycle, and it was built directly from the UK Code by DSIT, NCSC, and international partners in ETSI's Technical Committee on Securing AI. The standard is free to download and has already been referenced by procurement frameworks in both government and large enterprise contexts. As the NCSC noted in its May 2025 blog post, it "will allow developers of AI systems to demonstrate to prospects and partners that they are adhering to a framework created by cross-disciplinary collaboration, with requirements that are both globally relevant and practically implementable." That framing signals an intent to make ETSI TS 104 223 alignment a mark of supplier credibility in commercial markets, not just regulated ones.

The Cyber Security and Resilience Bill, published in draft in November 2025, is the legislative backdrop. While it does not directly mandate adherence to the AI Code, it strengthens supply chain oversight obligations for operators of essential and digital services, gives regulators new powers to investigate vulnerabilities in supply chains, and expands the range of organisations in scope. The ICO has responded positively to the Bill's supply chain provisions. The trajectory is one of increasing regulatory density around AI security - and the Code represents the current best available definition of what adequate AI security looks like.

For public sector organisations, the picture is clearer still. Central government departments and the wider public sector are already moving toward requiring alignment with the Code in AI procurement. The Crown Commercial Service's guidance on AI and digital marketplace suppliers explicitly references NCSC guidance, and that reference point is the Code. Local authorities, NHS trusts, and other public bodies that procure AI without Code-aligned contract terms are increasingly exposed - not just to security incidents but to audit findings and accountability questions if something goes wrong.

What this means in practice is that the window for retrofitting Code-aligned terms into existing supplier agreements is now, not later. The cost of renegotiation rises as contracts embed and suppliers become harder to move away from. For new contracts, there is no legitimate reason to omit Code-aligned terms. The ETSI standard and the accompanying implementation guide provide enough specificity to draft meaningful clauses without requiring deep AI security expertise. Organisations that want to lead rather than react will build a standard AI supplier contract annex now - one that references the Code's 13 principles, requires an AI BOM, specifies notification timelines, mandates human oversight provisions, and includes audit rights. The Code exists. The standard exists. The only remaining question is whether your contracts reflect them.

Frequently Asked Questions

Is the NCSC AI Cyber Security Code of Practice legally binding?

No - it is currently voluntary. However, it has been submitted to ETSI and now underpins a global standard (TS 104 223). The Cyber Security and Resilience Bill strengthens supply chain oversight obligations in adjacent legislation, and public sector procurement is already referencing the Code as a condition of contract. Treating it as optional carries growing risk.

Which organisations does the Code apply to?

The Code applies across five stakeholder groups: developers, system operators, data custodians, end-users, and affected entities. Most UK organisations buying AI are system operators; those fine-tuning or building on foundation models may also be developers. A single organisation can hold multiple roles, each with different obligations.

What is the difference between the UK AI Code of Practice and ETSI TS 104 223?

The UK Code of Practice was the source document. DSIT and NCSC submitted it to ETSI's Technical Committee on Securing AI, where it was developed into ETSI TS 104 223 - the first global standard for AI security across the full lifecycle. The UK government will update the Code to mirror the ETSI standard going forward.

What is an AI Bill of Materials and why does it matter for supplier contracts?

An AI BOM is a documented inventory of all components in an AI system: the foundation model, version, provider, fine-tuning data, prompt configurations, and inference infrastructure. It maps to Principles 5 and 8 of the Code. Without it, you cannot assess the risk you are taking on or demonstrate due diligence in procurement.

How does the Code interact with UK GDPR and the ICO's AI guidance?

They are complementary. The Code addresses cyber security risks to AI systems, while UK GDPR and the ICO's guidance on AI and data protection address privacy obligations. The Code explicitly notes that where AI systems use personal data, organisations also have data protection obligations and should consult ICO guidance. Both frameworks apply simultaneously.

Do small businesses need to comply with the Code when buying AI tools?

The Code is proportionate to the nature of the AI system and the risks involved. Even for smaller purchases, some baseline obligations apply - knowing which foundation model is in use, how security incidents are notified, and whether user inputs are used for training. The question is not whether to engage but how deeply, scaled to actual risk.

What should we do if an existing AI supplier refuses to engage with Code-aligned contract terms?

Treat it as a risk signal rather than just a commercial negotiation. A supplier unwilling to document their model components or provide security notification obligations is signalling limited accountability for their AI system's behaviour. Escalate the conversation to their legal or security team, and if they remain unresponsive, factor it into your supplier risk assessment and renewal decision.

How does the Cyber Security and Resilience Bill relate to the AI Code of Practice?

The Bill, published in draft in November 2025, strengthens supply chain oversight obligations for operators of essential and digital services and gives regulators new powers to investigate supply chain vulnerabilities. While it does not mandate the AI Code directly, the two instruments are part of the same legislative direction. Organisations in scope of the Bill should treat Code alignment as part of their compliance preparation.