Turn the NCSC AI Cyber Security Code into supplier contract controls

AI Trust & Governance

9 May 2026 | By Ashley Marshall

The Code is useful guidance. It becomes powerful when procurement turns it into evidence, ownership and remedies.

Treat the Code as a control map, not a policy badge

The useful way to read the UK AI Cyber Security Code of Practice is not as another voluntary statement to file beside ISO 27001. It is a practical map of what buyers need to know before they let an AI supplier near their data, workflows or customers. The GOV.UK Code of Practice sets out 13 principles across secure design, secure development, secure deployment, secure maintenance and secure end of life. It also names the AI supply chain roles that matter in contracts: Developers, System Operators, Data Custodians, End-users and Affected Entities.

That role split is the first procurement lesson. Most buyer questionnaires still ask a generic question such as, "Are you ISO 27001 certified?" Useful, but incomplete. A hosted LLM provider, an implementation partner, a CRM vendor with embedded AI and a customer operating a retrieval augmented generation workflow can each hold different parts of the risk. The Code says the same organisation may hold multiple stakeholder roles. Your contract should therefore state which party is responsible for each AI asset, control, log, user notice, model update and disposal step.

What this means in practice is simple: convert the 13 principles into a supplier obligations schedule. For each principle, define the required evidence, the owner, the review cadence and the remedy if the evidence is missing. Principle 2, for example, becomes a requirement to document the business purpose, AI security risks and mitigation strategy before deployment. Principle 7 becomes a supplier duty to evidence software and AI supply chain controls. Principle 12 becomes logging, monitoring and anomaly review obligations. The Code is voluntary, but once translated into contract controls, it stops being soft guidance and becomes enforceable delivery discipline.

Put evidence into the contract, not just answers into a questionnaire

The common procurement mistake is to ask AI suppliers whether they follow secure development practices, then accept a yes or no response. The Code demands a stronger pattern: risk assessment, documentation, testing, monitoring and evidence. DSIT says the intervention was endorsed by 80% of respondents to its 2024 call for views, with support for individual principles ranging from 83% to 90%. That matters because it shows the market broadly accepts the direction of travel. Buyers do not need to apologise for asking for evidence.

The evidence schedule should be specific. Ask for a current AI system inventory, data flow diagram, model card where appropriate, prompt and guardrail documentation, data retention policy, vulnerability disclosure process, incident response plan and a record of adversarial testing. For suppliers using third party models or open source components, require provenance records, version history, dependency lists and integrity checks. The NCSC Guidelines for secure AI system development already frame secure AI work across design, development, deployment, operation and maintenance, so the contract should ask for evidence across the same lifecycle rather than only at go-live.

Be careful with proportionality. A small supplier building an internal triage assistant cannot produce the same assurance pack as a major cloud AI platform. That does not mean the requirement should disappear. It means the evidence should scale with risk. A low-risk internal assistant might provide a concise threat model, DPIA input, access control evidence and release notes. A customer-facing system using personal data, automated recommendations or retrieval from confidential documents should provide deeper testing evidence, audit trails, log retention controls and human oversight procedures. The point is to buy assurance that matches the exposure, not to punish smaller providers with irrelevant paperwork.

Turn supply chain security into named AI clauses

Principle 7 is the contract clause most buyers will recognise, but it needs AI-specific wording. The implementation guide says secure supply chain controls should cover provenance and transparency, trusted sources, source, version, licensing, history, model cards, checksums and attestations. It also notes that classic SBOMs help with libraries and system components, but do not fully cover models and datasets. That is the gap buyers need to close in contract language.

A good supplier clause should require the vendor to identify all material AI components used to deliver the service, including foundation models, fine-tuned models, embedding models, orchestration frameworks, evaluation tools, safety filters, datasets and high-risk dependencies. Where available, the supplier should provide an SBOM and an AI or ML bill of materials. Where the tooling is immature, the supplier should maintain equivalent records in its MLOps platform. The contract should also require integrity verification, such as checksums or signed attestations for released model artefacts, and notification before replacing a model, dataset, guardrail or major dependency that could change security behaviour.

This is where procurement needs to be more precise than the usual "supplier shall follow good industry practice" wording. Specify remediation windows for vulnerabilities. The implementation guide gives an example of critical vulnerabilities patched within 48 hours, moderate vulnerabilities within 14 days and low-risk vulnerabilities within 30 days. You may adjust those numbers for your risk appetite, but write them down. Also require the supplier to justify any poorly documented or untrusted component, including alternatives considered and why no better option was selected. That clause prevents a high-performing but opaque model from being slipped into a critical workflow without a conscious risk decision.

Make testing, logging and incident response buyer rights

AI security assurance is not a one-off acceptance test. The Code expects appropriate testing and evaluation, regular updates, incident plans and monitoring of system behaviour. Those obligations should become buyer rights: the right to receive security test summaries, the right to preview major model changes, the right to audit relevant controls, the right to be notified of material incidents and the right to receive enough logs or reports to investigate harm without breaching data protection rules.

For testing, ask suppliers to show how they evaluate adversarial inputs, prompt injection, data poisoning, model extraction, membership inference, model inversion, jailbreaking, unsafe tool use and unexpected outputs. If the system uses retrieval augmented generation, include tests for poisoned documents, malicious embedded instructions and permissions leakage from connected knowledge bases. If the system has API access to email, CRM, finance or case management, require tests for least privilege, rate limiting, abuse detection and safe failure. Name frameworks where helpful: OWASP Top 10 for LLM Applications, MITRE ATLAS, NIST AI RMF and the NCSC machine learning principles are all useful reference points.

For logging, the contract needs balance. The implementation guide recommends capturing user interactions, access events, data flows and model outputs where needed, but also warns against logging full prompts or responses unless necessary, anonymised or explicitly justified. That fits the ICO position that AI governance must sit alongside data protection, fairness, transparency and accountability. Contract language should therefore require security useful logs, secure storage, retention limits, data minimisation and support for incident investigations. What this means in practice: do not accept either extreme. No logs means no investigation. Full prompt capture without controls may create a new personal data and confidentiality risk.

Connect AI security clauses to UK GDPR, public procurement and governance

The Code is cyber security guidance, but AI supplier contracts rarely sit in a pure cyber box. They touch UK GDPR, confidentiality, intellectual property, public procurement rules, operational resilience and board governance. GOV.UK's Guidelines for AI procurement tell public sector buyers to conduct data assessment before procurement, assess benefits and risks, develop governance and information assurance plans, avoid black box algorithms and vendor lock-in, and carry relevant codes and guidance into the contract where suitable. That is exactly the bridge commercial teams need.

Start with data. If personal data is involved, the supplier schedule should link AI security controls to controller and processor obligations, DPIA support, sub-processor approval, retention, deletion, international transfers, access control and breach notification. The ICO guidance on AI and data protection stresses accountability, governance, lawfulness, fairness, transparency and accuracy. Security evidence should not be separated from those duties. A supplier that cannot explain its data sources, retention or output monitoring may also struggle to support fairness, transparency and auditability.

Then look at governance. Require a named supplier security owner, a named buyer owner and a joint change control process for material AI changes. Define what counts as a material change: new foundation model, new training or fine-tuning data, altered retention, changed safety filter, new tool permission, new geography for processing, or a change that affects explainability or user impact. Public bodies and regulated firms should also map these clauses to their own governance frameworks, such as procurement approvals, Cyber Essentials expectations, ISO 27001 controls, operational resilience policies and board risk reporting. The contract is not the whole governance system. It is the place where supplier duties become visible, measurable and enforceable.

The counterargument: do not turn voluntary guidance into procurement theatre

The strongest counterargument is fair: if every buyer turns a voluntary Code into a heavy compliance questionnaire, procurement slows down, smaller suppliers are excluded and teams mistake paperwork for security. That risk is real. AI assurance can easily become theatre if buyers ask for documents nobody reads, demand enterprise-level certifications from early-stage vendors, or treat a model card as proof that a system is safe in its deployed context.

The answer is not to ignore the Code. It is to use it proportionately. Focus on the controls that match the use case. A low-risk internal summarisation tool may need clear data handling, access controls, user guidance, security update notifications and deletion rights. A system making fraud recommendations, handling HR data or integrating with customer records needs stronger evidence: threat modelling, adversarial testing, monitoring thresholds, human oversight, rollback procedures, incident support and contractual limits on model training with customer data. The Code helps buyers ask better questions, but the risk assessment should decide which answers are mandatory.

There is also a misconception that contract controls are only for the legal team. In reality, the useful controls come from a joint table involving procurement, legal, security, data protection, product owners and the technical team that will run the service. Legal can draft the obligation, but security needs to define the evidence, data protection needs to define retention and disclosure constraints, and operations needs to know what will actually happen at 2am when a model update breaks a workflow. The best supplier contracts are boring in the right way: clear obligations, named evidence, review dates, incident paths, exit rights and enough flexibility to adapt as ETSI turns the Code into a global standard.

Frequently Asked Questions

Is the UK AI Cyber Security Code legally binding?

No. It is voluntary guidance, but buyers can make relevant parts contractually binding by writing them into supplier obligations, evidence requirements and remedies.

Which suppliers should be covered by these controls?

Cover suppliers that develop, adapt, host, integrate or operate AI systems, plus suppliers that provide material AI components such as models, APIs, datasets or orchestration platforms.

Do ISO 27001 or Cyber Essentials replace AI-specific clauses?

No. They help with general assurance, but AI systems add risks such as prompt injection, data poisoning, model extraction, drift and unclear model provenance.

What evidence should procurement request first?

Start with a threat model, data flow, asset inventory, model and dependency records, testing summary, incident plan, vulnerability disclosure process and deletion policy.

How should contracts handle model updates?

Require notice for material model changes, preview access for high-risk systems, release notes, rollback options and evidence that the update has been tested against security and operational criteria.

Should buyers demand full prompts and outputs in logs?

Not by default. Logs need to support security investigations, but full prompt capture can create confidentiality and personal data risks. Use minimisation, anonymisation and retention limits.

How can smaller suppliers meet these expectations?

Use proportionate evidence. A concise risk assessment, clear data handling policy, component register, test notes and incident contact may be enough for a low-risk use case.

What is the biggest misconception about the Code?

That it is only a cyber policy document. Its real value for buyers is as a practical checklist for allocating supplier duties across the AI lifecycle.