UK AI Regulation, in depth: the security layer, from the AI cyber code of practice and ETSI EN 304 223 to the chatbot powers and the cyber bill (October 2026)

What binds and what guides

Start by separating what binds you from what guides you, because teams routinely get this backwards: they treat the voluntary code as optional and forget that the general security duty, which is not optional, is judged against exactly the kind of practice the code describes.

The code: roles, phases and 13 principles

The Department for Science, Innovation and Technology published the code with the National Cyber Security Centre, together with an implementation guide. It assigns provisions to five stakeholder roles: Developers, who create or adapt a model or system; System Operators, who embed and deploy it in their infrastructure; Data Custodians, who control data permissions and integrity; End-users; and Affected Entities, people and systems affected by the system without using it. One organisation often holds several roles. A company that fine-tunes a hosted model and deploys it in its own product is a Developer and a System Operator at once, and inherits both sets of provisions.

The 13 principles, grouped by phase, are: secure design, 1 raise awareness of AI security threats and risks, 2 design the system for security as well as functionality and performance, 3 evaluate the threats and manage the risks, 4 enable human responsibility for AI systems; secure development, 5 identify, track and protect assets, 6 secure infrastructure, 7 secure the supply chain, 8 document data, models and prompts, 9 conduct appropriate testing and evaluation; secure deployment, 10 communication and processes associated with End-users and Affected Entities; secure maintenance, 11 maintain regular security updates, patches and mitigations, 12 monitor system behaviour; and secure end of life, 13 ensure proper data and model disposal.

The government submitted the code and guide to ETSI, which published them as Technical Specification TS 104 223 with Technical Report TR 104 128 as the implementation guide, and then progressed the specification to a European Standard, EN 304 223, announced in January 2026. ETSI has described a further report, TR 104 159, applying the baseline to generative AI. An ETSI EN is not automatically a harmonised standard under the EU AI Act, so do not claim presumption of conformity from it, and read the published provisions rather than summaries, including this one.

From principles to controls

The principles become useful when each is tied to a control you can build and an artefact that proves it runs. For a typical LLM application with retrieval and tool calls, a reasonable starting map is:

The map is a starting point, not the code's text. The code words each provision with shall for a requirement, should for a recommendation or may for a possibility, and the shall provisions are where to start. Testing for principle 9 is the most work; the method is in AI red teaming, in depth.

Evidence as code

Evidence goes stale silently. A threat model written at launch says nothing about the agent features added since. The fix is to keep the register as data in the repository and fail the release when a control has no evidence, or evidence older than its allowed age. Each evidence file carries its own generation date, because file modification times are reset by every checkout and cannot be trusted.

# controls/ai_code_register.toml
system = "support-agent"
roles = ["developer", "system_operator"]

[not_applicable]
13 = "No models retired yet; disposal runbook drafted in docs/disposal.md"

[[control]]
id = "P6-rate-limit"
principle = 6
level = "required"
owner = "platform-team"
evidence = "evidence/rate_limits.json"
max_age_days = 90

[[control]]
id = "P9-redteam"
principle = 9
level = "required"
owner = "security"
evidence = "evidence/redteam_latest.json"
max_age_days = 30

import json, sys, tomllib
from datetime import date
from pathlib import Path

def check(register_path, today=None):
    today = today or date.today()
    reg = tomllib.loads(Path(register_path).read_text(encoding="utf-8"))
    controls, na = reg.get("control", []), reg.get("not_applicable", {})
    problems = []
    covered = {c["principle"] for c in controls}
    for p in range(1, 14):
        if p not in covered and str(p) not in na:
            problems.append(f"principle {p}: no control and no not-applicable reason")
    for c in controls:
        ev = Path(c["evidence"])
        if not ev.is_file():
            problems.append(f"{c['id']}: evidence missing at {ev}")
            continue
        meta = json.loads(ev.read_text(encoding="utf-8"))
        made = date.fromisoformat(meta["generated_at"][:10])
        if (today - made).days > c["max_age_days"]:
            problems.append(f"{c['id']}: evidence {(today - made).days} days old")
        if meta.get("result") == "fail":
            problems.append(f"{c['id']}: latest evidence records a failure")
    return problems

if __name__ == "__main__":
    issues = check(sys.argv[1])
    print("\n".join(issues) or "register ok")
    sys.exit(1 if issues else 0)

Wire the check into the release pipeline next to the tests. When a buyer's questionnaire asks how you meet the code or EN 304 223, the register is the answer, and the same evidence serves the UK GDPR security duty and, if you also sell into the EU, the controls in the EU AI Act.

The binding layer around the code

Three binding or near-binding instruments sit around the code. The first is the UK GDPR. Almost every LLM application processes personal data in prompts, logs or retrieved documents, so the duty to apply appropriate technical and organisational security measures already applies. What counts as appropriate is judged against the state of the art, and a national code and European standard are strong evidence of what that is. An exfiltration through unmitigated prompt injection is hard to defend as appropriate.

The second is the NIS Regulations 2018 and the Cyber Security and Resilience Bill that would extend them. The bill was introduced on 12 November 2025, passed its Commons third reading on 16 June 2026 and finished Lords committee stage in September 2026. It is not yet law. As introduced, it brings data centre operators and managed service providers into scope, lets regulators designate critical suppliers, and tightens incident reporting, with an initial notification within 24 hours and a fuller report within 72 hours as proposed. If you host models for others or run AI platforms as a managed service, track it; Lords amendments can still change scope and timings.

The third is the Online Safety Act 2023 as amended by the Crime and Policing Act 2026, which received Royal Assent on 29 April 2026. The Online Safety Act reaches user-to-user services, search services and pornography providers, so a standalone chatbot used one to one could fall outside it. The 2026 Act gives the Secretary of State power to make regulations to minimise or mitigate harms from illegal AI-generated content and from the use of AI services to commit or facilitate priority offences. Commentary after Royal Assent reported that no regulations had yet been made; check whether that has changed. Meanwhile an illegal-content risk assessment, output filtering and an abuse-report route are good practice under principle 10 anyway.

The AI Security Institute and the limits of red teaming

Two more points trip up security teams. The AI Security Institute, renamed from the AI Safety Institute in February 2025, evaluates frontier models for risks with security implications and publishes research and its open-source evaluation framework, Inspect. It is not a regulator and does not certify products; a provider's mention of its testing is not evidence about your deployment.

Second, red teaming has legal limits. The Computer Misuse Act 1990 makes unauthorised access to computer material an offence, and has historically had no general defence for good-faith research. The government has announced a narrow statutory defence for some accredited researchers but, as far as we could confirm, it is not yet law; check the current position. Testing your own deployment is fine; probing a third party's model, plugin or agent beyond its terms is not. Get written authorisation naming systems and techniques, and file it with the principle 9 evidence.

Worked example: a support agent

A UK software company runs a support agent on a hosted model, with an adapter fine-tuned on past tickets, a help-centre index, and tools to issue small refunds and update addresses.

• Roles. The provider is the Developer of the base model. The company is a Developer for the adapter, a System Operator for the deployment, and a Data Custodian for the ticket data.
• Binding law. Tickets contain personal data, so the UK GDPR security duty applies. The company is not an operator of essential services, and as a single SaaS product it is unlikely to be a managed service provider under the bill as introduced; record that reasoning and revisit it after Royal Assent.
• Online safety. Customers talk to the agent one to one and cannot share its outputs with other users, so the service is outside the user-to-user rules today. Note the 2026 regulation-making power in the register and set a review date.
• Controls. Principle 2: refunds and address changes go through a provenance gate, so ticket or retrieved text cannot trigger them without customer confirmation. Principle 7: pin the model version and the adapter hash. Principle 9: a red-team suite with injection cases in tickets and help-centre pages, run before each release. Principle 12: alert on refund calls in turns flagged by the injection scanner. Principle 13: delete fine-tuning data copies and old adapters when an adapter is retired.
• Evidence. One register file, 13 principles covered or justified as not applicable, CI failing on stale red-team results older than 30 days.

Traps

• Treating voluntary as irrelevant. The code describes what appropriate security looks like; the binding duty is judged against it.
• Citing the bill as law. Plans that quote the cyber bill's reporting windows as current obligations are wrong until Royal Assent and commencement.
• Claiming EU conformity from the ETSI EN. Presumption of conformity under the EU AI Act needs harmonised standards; check which standards are cited before claiming it.
• Static registers. Track changes through a process such as an AI regulatory watch.

What to do next

1. List each AI system and the roles your organisation holds for it under the code.
2. Read the code and EN 304 223 provisions marked required for those roles.
3. Build a register mapping all 13 principles to a control, evidence file, owner and maximum age, or a not-applicable reason.
4. Add the register check to CI and make it block releases.
5. Record your position on the cyber bill and the 2026 chatbot powers, with a review date for each.
6. Get written authorisation before testing any system you do not own.