MICKAI®ArticlesWhat ISO 27001 Actually Requires …
Team
Article · 20 October 2026

What ISO 27001 Actually Requires (And What It Doesn't Promise)

A plain explanation of the information security standard business buyers keep seeing on vendor websites, written for people evaluating AI suppliers rather than security specialists.

Author
Micky Irons
Published
20 October 2026
Follow Micky Irons
LinkedInX
ISO 27001Information SecurityVendor Due DiligenceAI ProcurementRisk Management

A Standard That Gets Mentioned More Than It Gets Explained

Most business buyers evaluating AI vendors will have seen "ISO 27001 certified" or "ISO 27001 aligned" somewhere in a pitch deck, a security questionnaire, or a vendor's trust page. The phrase gets used often and explained rarely, which is a problem, because the two claims (certified and aligned) mean genuinely different things, and the standard itself covers a lot more ground than a logo on a website suggests.

ISO/IEC 27001:2022 is an international standard, published jointly by the International Organization for Standardization and the International Electrotechnical Commission, that sets out requirements for an information security management system, usually shortened to ISMS. It is not a piece of software, a technical certification for a specific product, or a one off checklist an engineer ticks through. It is a management framework: a set of processes an organisation runs continuously to identify information security risks, decide how to treat them, and prove, to an independent party, that it is actually doing what it claims.

The 2022 revision reorganised the standard's reference controls into four categories (organisational, people, physical and technological) and added a small number of new ones covering areas such as cloud security and threat intelligence. The underlying logic hasn't changed: assess risk, choose and implement controls, document the reasoning, review continuously, and submit to an outside audit.

What Certification Actually Involves

Certification is a multi stage undertaking that typically runs for months before a certificate is issued, and it does not stop once the certificate arrives.

It starts with a risk assessment. The organisation identifies its information assets (customer data, source code, infrastructure, credentials, and so on), works out what could realistically go wrong with each one, and rates the likelihood and impact. This produces a risk register, and everything that follows is built on it.

From the risk assessment comes the Statement of Applicability, one of the core documents in any ISO 27001 certification. The standard's Annex A lists 93 reference controls in the 2022 version, covering areas such as access control, cryptography, supplier relationships, incident management and physical security. The organisation decides, based on its own risk assessment, which of those controls apply, implements the ones it keeps, and records why it has excluded the rest.

Running alongside the controls is a continuous layer of documentation and operational evidence: a security policy, an incident response plan, access control procedures, records of approvals, and proof that staff training actually happened. None of this is produced once and filed away. It has to keep being produced as the business operates.

Before any outside party is involved, the organisation audits itself and senior management formally reviews the results. That internal audit and management review step is a requirement of the standard, not a nice to have.

Only then does an accredited certification body carry out an external audit, normally in two stages. Stage one checks whether the documentation meets the standard's requirements. Stage two, usually some weeks later, checks whether the organisation is actually operating the system it documented, through interviews, evidence sampling and site or system checks. A successful audit results in a certificate valid for three years, with lighter annual surveillance audits in between and a full recertification audit at the end of the cycle.

So "ISO 27001 certified" is a specific, checkable claim. It means an accredited third party has reviewed the organisation's management system against the standard and keeps checking it on a schedule, not that someone wrote a security policy once and moved on.

What It Does, and Doesn't, Guarantee

Certification is evidence of a mature, audited process. It is not a guarantee of a specific security outcome, and buyers who treat it as one are setting themselves up to be disappointed.

It does not certify that a product is unhackable or that a breach cannot happen. Certified organisations have suffered breaches before, and will again. What certification shows is that the organisation had a documented process for assessing risk and a process for responding and learning when something goes wrong, not that incidents become impossible.

It does not fix which controls a vendor must implement. Because the Statement of Applicability is risk based, two certified organisations can end up with meaningfully different control sets, both legitimately certified. The certification tells a buyer that the organisation went through a rigorous, audited process. It does not by itself tell the buyer which specific protections were chosen, which is exactly why asking to see the Statement of Applicability is worth doing.

It does not necessarily cover everything the vendor does. Certification is scoped, sometimes to one business unit, one data centre, or one product line, while other parts of the same business sit outside that scope. The scope statement on the certificate, not the marketing page that mentions it, defines what was actually audited.

It is a point in time plus ongoing surveillance, not a permanent state. A lapsed certificate, a failed surveillance audit, or an unannounced change in scope all change what the certification actually covers at the moment a buyer is relying on it.

Alignment Versus Certification: The Questions Worth Asking

Some vendors describe themselves as "ISO 27001 aligned" or say they follow the standard's "best practice" without being certified. That can be a reasonable position, particularly for a smaller or newer organisation partway through the process, but it is a different claim from certification, and it deserves a different level of scrutiny.

"Aligned" generally means the vendor has studied the standard and modelled its practices on it, with no accredited third party checking the result and no certificate to verify. "Certified" means an accredited body has checked, and keeps checking, on a fixed schedule.

A buyer evaluating any AI vendor that raises ISO 27001 should be comfortable asking a short, direct set of questions. Are you certified against the standard, or aligned with it. These are different claims and the answer should be unambiguous rather than implied. If certified, who is the certification body, is it accredited (in the UK, for example, by UKAS), and can the certificate itself, including its scope and expiry date, be shared. What exactly does the scope of certification cover, and does it include the specific product, service or data processing the buyer would actually be using, or a different part of the vendor's business. Can the buyer see, or get a reasonable summary of, the Statement of Applicability, including which Annex A controls are implemented and which have been excluded, and why. If the vendor is aligned rather than certified, is certification an actual stated goal with a timeline, and has a gap assessment, internal or external, been carried out against the standard. Finally, how does the vendor handle security incidents in practice, and is there a documented record of how past incidents, if any, were handled.

A vendor who answers each of those clearly, whether the answer is "yes, certified, here is the certificate" or "not yet, here is our timeline and our gap assessment", is a safer bet than one who simply states "ISO 27001" on a page and leaves it there.

Where We Stand

We are not ISO/IEC 27001 certified today, and we are not going to imply otherwise. As the Sovereign Intelligence Operating System moves towards wider commercial deployment, we treat ISO 27001 readiness as a genuine target, assessed against the same process described above, rather than a line to drop into marketing copy.

The purpose of this piece is not to position Mickai. It is to give a business buyer the working knowledge to ask the right questions of any AI vendor, including us, and to tell the difference between a certificate that has been through an accredited audit and a claim that has not.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. Delivered through our email service provider. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/what-iso-27001-actually-requires-and-what-it-doesnt-promise. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles