Yes. Cyber Essentials treats any cloud service holding or processing your organisation's data as in scope, and you cannot exclude it. A cloud AI assistant used through a business account is in scope. So is AI running on your own servers, as part of your infrastructure. You stay responsible for making sure every control is implemented.
What does Cyber Essentials actually certify?
It certifies that five technical controls are in place across the IT that touches the internet and handles your organisation's data: firewalls, secure configuration, security update management, user access control and malware protection. It does not certify that a product is safe. It certifies your configuration of the estate you declared.
That distinction decides the whole AI question. Cyber Essentials is a self-assessed certification, owned by the NCSC and delivered through IASME, assessed against a scope you define and sign a declaration for. Nothing in it evaluates what a model does, how it was trained, or whether an output can be relied on. It asks whether the unglamorous hygiene is done on everything inside the boundary you drew. If an AI tool sits inside that boundary, and nearly all of them do, the five controls have to be demonstrable for it.
Are cloud AI services inside the Cyber Essentials scope?
Yes, and you cannot leave them out. The requirements are explicit that cloud services are in scope wherever the organisation's data or services are hosted in them, and that cloud services cannot be removed from scope. That rule was written for storage, email and line of business platforms. An AI assistant on a business account is the same thing wearing a newer label.
Scope defaults to the whole organisation. You may certify a defined sub-set, but it has to be genuinely separated from the rest by a firewall or network segregation, and the certificate then names that sub-set, which is the line a procurement team reads. Carving out "the AI pilot" is rarely credible anyway: the pilot runs on the same laptops, the same identity provider and the same browser sessions as everything else.
How do the five technical controls apply to an AI tool?
Map them one at a time against the account and the device, not against the model. Most of the work lands on access control and update management.
User access control. Every person needs their own account, accounts are approved and removed through a documented process, administrative accounts are separated from everyday ones, and multi-factor authentication is required on cloud services. A shared team login to an AI service, which is the most common shortcut I see, fails this outright.
Security update management. Software in scope must be supported and receiving fixes, with updates for vulnerabilities rated high or critical applied within 14 days of release. That covers the browser, the desktop client and any local runtime.
Secure configuration. Remove what you do not need, change default settings, and switch off features you have not deliberately chosen. For an AI service that means the administration console: sharing defaults, connector permissions, retention options.
Firewalls and malware protection. These land on the devices staff use and on any server you run yourself.
Who implements the controls for software, platform and infrastructure services?
It depends on the service model, and the requirements document sets out the split for infrastructure, platform and software services control by control. The pattern is simple: the further up the stack you buy, the more the provider implements, and the less you can see for yourself.
With an infrastructure service you are running the operating system, so patching, malware protection and configuration are yours. With a platform service, the provider maintains the layers underneath your application. With a software service, which is what an AI assistant sold as a finished product is, the provider implements most of the technical controls inside its own estate. User access control never leaves you completely: accounts, permissions and multi-factor authentication are set by your administrators.
The trap is reading "the provider does it" as "we do not have to think about it". Responsibility for ensuring each control is implemented stays with you, which means you need evidence. If a provider will not say how it handles security updates, or cannot confirm what certification it holds, you have a scope you cannot honestly attest to. That is a procurement problem before it is an assessment problem.
Does self-hosted AI on your own servers change the scope?
It changes who does the work, not whether the tool is in scope. AI running on hardware you own sits inside your in-scope infrastructure like any other server application, so the same five controls apply and you implement them yourself.
That is more responsibility. It is also more visibility, because none of it is behind a supplier's boundary. You can show an assessor the patch level, the account list, the firewall rules and the network segregation on request, without waiting on a supplier ticket. Cloud stays valuable for work that is not regulated. For the regulated case, this is the approach behind MICKAI® and the Mickai Sovereign Intelligence Operating System (SIOS): it runs on hardware the customer owns, it is offline capable, and there is no data egress. Consequential actions wait for a named person to approve them, and each one is sealed into the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor verifies an exported record offline with a public key, using tools that are not ours. That record is tamper-evident, not tamper-proof, and the distinction is the point: nobody can promise a file cannot be altered, but an altered record fails verification, and a failed verification is something an assessor or a regulator can act on.
Self-hosting does not simplify certification. You take on patching a stack you may not have run before, and an unsupported component inside your own boundary fails the update control like any neglected laptop.
What about AI tools staff sign up for without approval?
They are in scope if organisational data goes into them, and the fact that nobody approved them does not remove them from the assessment. It makes the assessment wrong, which is the worse outcome, because you signed a declaration saying otherwise.
The way in is almost always a browser on a device that is already in scope. Personal equipment counts too: staff-owned laptops and phones that access organisational data or services are in scope, with a narrow exception for devices used only for calls, text messages and multi-factor authentication apps. A personal laptop with a free AI account and a pasted client document is inside the boundary twice over.
Two things work. Find out what is actually in use, from expense claims, browser telemetry and asking people directly without punishing the answer. Then give them something sanctioned, because the demand is real and a flat ban produces concealment rather than compliance. We put new tooling through a gated sandbox first, with a named owner, before it goes anywhere near live data.
Where does Cyber Essentials stop, and what covers the rest?
It stops at commodity, internet-borne attacks. The NCSC presents Cyber Essentials as protection against the most common cyber attacks, and that is what the certificate is worth: a floor, not a ceiling. It is not an AI assurance regime and was never written as one.
What it does not reach: prompt injection, indirect injection through documents or web pages a model reads, training data provenance, integrity of the model supply chain, retention by a provider, and whether anyone can establish later what an automated step actually did and who sanctioned it. For that layer, the UK references are DSIT's voluntary AI Cyber Security Code of Practice and the NCSC's guidelines for secure AI system development. Data protection sits separately again, under UK GDPR, where the ICO has published guidance on AI. Incoming UK resilience legislation will add duties for some operators and their suppliers, which is worth reading early.
Certification proves hygiene. Being able to show what an AI system did is a separate piece of engineering, and you either built it in or you did not.
What should you do before your next assessment?
Inventory first, because you cannot scope what you have not listed. Write down every AI tool in use, who owns it, what data goes into it, whether accounts are individual, whether multi-factor authentication is enforced, and what the provider is contractually responsible for.
Then, in order: remove shared logins; enforce multi-factor authentication on every cloud service; review each administration console against the secure configuration control instead of accepting defaults; confirm that every client, browser and local runtime is supported and inside the 14 day window for high and critical fixes; and record the responsibility split for each service so the answer exists before an assessor asks for it. Where a provider cannot evidence its side, log it as a supplier finding and chase it.
Then ask the question the certificate does not answer. If a regulator asked what your AI system did last Tuesday, on whose authority, and to whose data, could you show them? What we think that takes is set out on our security page, and in our note on sovereign AI for mid-market organisations. Cyber Essentials will not get you there. It will stop you failing at the first fence, which is worth having, and it is not the same thing as assurance.
Frequently asked questions
Can we exclude a cloud AI service from our Cyber Essentials scope?
No. The requirements state that cloud services holding your organisation's data or services are in scope and cannot be removed from it. That applies whether the account is paid or free, and whether IT arranged it or a team did. You can certify a genuinely segregated sub-set of the organisation instead, but the certificate then says so.
Which of the five technical controls apply to an AI assistant?
All five, though the weight differs. User access control and security update management do most of the work: individual accounts, separated administrative accounts, multi-factor authentication on cloud services, and high or critical fixes applied within 14 days. Secure configuration covers the administration console defaults. Firewalls and malware protection apply to the devices staff use and any server you host.
Who is responsible for controls in a software-as-a-service AI tool?
The provider implements most of the technical controls inside its own platform, but responsibility for ensuring they are implemented stays with you, and user access control remains partly yours in every case. Practically, you configure accounts, permissions and multi-factor authentication, and you collect evidence about the provider's side. If a provider will not evidence it, that is a supplier decision to make.
Does Cyber Essentials Plus test AI tools differently?
No. Plus is an independent technical audit of the same five controls, with an assessor testing a sample of in-scope devices and cloud service accounts rather than relying on your self-assessment. An AI tool is examined as an account and a client: patch level, supported versions, account separation, multi-factor authentication. Nothing in the audit examines model behaviour.
Does Cyber Essentials cover AI-specific risks such as prompt injection?
No. It is a baseline against common internet-borne attacks and says nothing about prompt injection, indirect injection through content a model reads, training data provenance, model supply chain integrity or output retention. For those, look at DSIT's voluntary AI Cyber Security Code of Practice and the NCSC's guidelines for secure AI system development, then at your own audit trail.
Related briefings
UK AI regulation
- Is There a UK AI Act? How the UK Regulates AI Today
- AI Cyber Security Code of Practice: Who It Applies To
- ICO Code of Practice on AI and Automated Decision-Making
- ISO 42001 vs ISO 27001: Do You Need Both Standards?
- AI for Essential Services: What UK Regulation Requires
Data protection and UK GDPR
- UK GDPR and AI: Does Your Data Have to Stay in the UK?
- UK Data Storage vs AI Processing: What Is the Difference
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)