The AI Cyber Security Code of Practice is a voluntary UK government code from DSIT with the NCSC, setting 13 baseline principles for securing AI systems. It applies across five roles: developers, system operators, data custodians, end-users and affected entities. DSIT submitted it to ETSI, where it became the basis of ETSI TS 104 223.
What is the AI Cyber Security Code of Practice?
It is a voluntary code published by the Department for Science, Innovation and Technology, developed with the National Cyber Security Centre, setting out baseline security expectations for AI systems. It was published on 31 January 2025 and contains 13 principles. It is not law, and there is no certificate attached to it. It is a statement of what the UK government considers a reasonable floor.
The code exists because AI systems fail in ways that ordinary secure development guidance does not fully cover. Data poisoning, model inversion, indirect prompt injection and model theft are not variations on familiar web vulnerabilities. They are new failure modes attached to assets most organisations do not yet track properly: training data, model weights, prompts, embeddings, fine-tuning adapters. The useful thing the code does is name those assets and assign responsibility for them to somebody specific.
Read it as the checklist you will be measured against in eighteen months, not as an obligation you can safely defer today.
Who does the code apply to, and which role are you?
The code assigns its principles across five stakeholder roles: developers, system operators, data custodians, end-users and affected entities. Most organisations hold more than one role at once, and the common mistake is assuming you are only a buyer.
If you build, train or fine-tune a model, you are a developer. If you deploy and run an AI system in your own environment, you are a system operator. If you hold data used to train, tune or evaluate a model, you are a data custodian. End-users interact with the system directly. Affected entities are the people its outputs land on, and they carry no obligations at all: they are who several of the principles exist to protect.
A firm that runs a vendor's model on infrastructure it controls, fine-tuned on its own case records, is a developer, a system operator and a data custodian simultaneously. Work out which roles you occupy before you read the principles, because that determines which ones are yours.
What do the 13 principles ask for?
They cover the whole life of a system, from the first design conversation to the day you destroy it. In the published order, they ask you to: raise awareness of AI security threats and risks; design your system for security as well as functionality and performance; evaluate the threats and manage the risks; enable human responsibility for AI systems; identify, track and protect your assets; secure your infrastructure; secure your supply chain; document your data, models and prompts; conduct appropriate testing and evaluation; handle communication and processes with end-users and affected entities; maintain regular security updates, patches and mitigations; monitor your system's behaviour; and ensure proper data and model disposal.
Three of those carry most of the weight. Human responsibility means a named person is accountable for what the system does and can intervene before it acts. Asset identification means you can produce an inventory of models, weights, prompts and data, and say where each one physically sits. Monitoring means you can reconstruct behaviour after the fact, not just watch a dashboard in real time.
Is the code mandatory, and what happens if you ignore it?
Nothing happens directly. No regulator enforces it, no penalty attaches to non-conformance, and there is no audit you can fail against it today. That is the wrong reason to ignore it.
Two things follow from a voluntary code with government authorship. The first is that it becomes a reference point for what reasonable security looks like once an AI system is in scope. If you process personal data you already owe security obligations under UK GDPR, including the requirement in Article 32 to implement appropriate technical and organisational measures. A published government baseline is the sort of document an assessor reaches for when deciding whether your measures were appropriate. That is my reading of how these things tend to go, not a position attributed to the Information Commissioner's Office.
The second is procurement. A voluntary code becomes mandatory the moment a buyer pastes it into a supplier questionnaire, and that is already happening. I am already seeing the principles turn up in diligence packs sent by organisations that have no formal duty to apply them at all.
How does the code relate to ETSI TS 104 223 and other standards?
DSIT and the NCSC submitted the code to ETSI, the European Telecommunications Standards Institute, where it became the basis of ETSI TS 104 223, "Securing Artificial Intelligence (SAI); Baseline Cyber Security Requirements for AI Models and Systems", at version 1.1.1. Same substance, restructured as a technical specification: numbered provisions a contract can reference and an assessor can work through. If you want the assessable version, read the ETSI document. If you want the plain-English intent, read the code.
The other standards fit around it rather than overlapping it. The NCSC's Guidelines for secure AI system development, published with international partners, organise the same territory by lifecycle phase: secure design, secure development, secure deployment, and secure operation and maintenance. Cyber Essentials and ISO/IEC 27001 cover the estate the AI system runs on and say nothing specific about models. ISO/IEC 42001 addresses AI management and governance rather than security controls. None of them replaces another.
Which principles are hardest to evidence with a cloud AI service?
The asset, infrastructure, monitoring and disposal principles. Not because the large providers are careless, but because the evidence sits on the other side of a boundary you do not control.
Identifying and protecting assets is hard when the weights live in a vendor's estate: you can inventory the endpoint, not the asset. Securing your infrastructure becomes inheriting a control description and a third-party attestation report. Monitoring system behaviour means the logs your vendor chose to export, in their format, retained for their period, with no way for you to prove they were not edited in transit. Proper disposal becomes a contractual assurance that data and derived artefacts were destroyed, and nothing you can independently verify.
Every one of those is a reasonable answer for work that is not regulated, and cloud remains the right choice for a great deal of it. The difficulty starts when the question stops being "what does your policy say" and becomes "show me, for this decision, on this date, who approved it".
How does an on-premise deployment help you meet the principles?
It changes who holds the evidence. That is the whole of the benefit, and it is worth more than it sounds.
The MICKAI® Sovereign Intelligence Operating System (SIOS) runs on hardware the customer owns. It is offline capable, with no data egress. Weights, prompts and logs stay inside a perimeter that already appears on your own asset register, which turns the asset and infrastructure principles into a question about your existing controls rather than a vendor's paperwork. Consequential actions wait for a named person to approve them, which is what human responsibility looks like in practice rather than in policy. Connected work such as browsing, research and OSINT runs inside a sandboxed cell that is isolated from the regulated data plane, which is where untrusted content and prompt injection get contained.
For monitoring and forensics, the Open Audit Record seals every consequential action under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. Keys are operator-held. The record is tamper-evident rather than tamper-proof, and that distinction is the point: sealing does not prevent someone altering an entry, it ensures an altered entry fails verification. An auditor exports the record and checks it offline with a public key, using tooling that is not ours.
To be clear about what I am not claiming. Mickai is not certified against the code or against ETSI TS 104 223, and no certification scheme for either exists. The properties above are described, not accredited.
What should you do first if you are a system operator?
Four steps, in this order.
Write down which of the five roles you actually hold, including the ones you would rather not. Then inventory your AI assets properly: models, weights, prompts, system instructions, training and evaluation data, embeddings, adapters, and where each one physically sits. Then walk the 13 principles and put two names against each, the person accountable and the artefact that proves it. Then look at the rows where your only artefact is somebody else's assurance.
That last list is the decision in front of you. For plenty of workloads a vendor assurance is sufficient. For the ones where a regulator, a court or an insurer may eventually ask you to prove what happened, you want the evidence on hardware you own, signed at the moment it was created, and verifiable by someone who does not work for your supplier. That is the argument for sovereign AI as a cyber security position rather than a political one.
Frequently asked questions
Is the AI Cyber Security Code of Practice mandatory?
No. It is a voluntary code, published by DSIT with the NCSC, with no regulator enforcing it and no certification scheme behind it. In practice it is becoming a procurement baseline: buyers reference it in supplier questionnaires, and assessors treat it as a view of what reasonable AI security looks like when other duties apply.
Are we a developer or a system operator under the code?
Usually both. You are a developer if you build, train or fine-tune a model, and a system operator if you deploy and run an AI system in your own environment. Fine-tuning a vendor model on your own data makes you a developer, a system operator and a data custodian at once. Map your roles before you read the principles.
What is the difference between the code and ETSI TS 104 223?
Substance is the same, format is not. The code is the plain-English government publication setting out the principles. ETSI TS 104 223 is the technical specification built on it, structured as numbered provisions that a contract can reference and an assessor can test against. Use the code to understand intent and the ETSI document for assessment.
Does the code replace Cyber Essentials or ISO standards?
No. They sit alongside each other. Cyber Essentials and ISO/IEC 27001 cover the estate your AI system runs on and say nothing specific about models, data or prompts. ISO/IEC 42001 addresses AI management and governance rather than security controls. The code fills the gap those leave, which is the security of the model and its assets.
Most of them still apply, because buying does not remove operator duties. You remain a system operator and probably a data custodian, so asset identification, infrastructure security, supply chain assurance, human responsibility, monitoring, updates and disposal are all yours. What changes is that some of your evidence becomes a vendor's assurance rather than your own artefact.
How do we show an auditor we have followed the code?
Roles, inventory, and evidence per principle. Show which of the five roles you hold, produce an asset inventory covering models, weights, prompts and data with locations, then go principle by principle naming the accountable person and the artefact. Signed records the auditor can verify independently, offline and with a public key, are worth far more than policy documents.
Written by Micky Irons, founder and chief executive of Mickai LTD, which builds a sovereign AI operating system for regulated organisations. More at mickai.co.uk.
Top comments (0)