A supplier provides an ISO 27001 certificate in response to your security assessment. What does the certificate actually tell you, and what does it not?

The mechanism

An ISO 27001 certificate says that an accredited body audited an information security management system, within a defined scope, at a point in time, and found it conformant. Each of those four qualifiers is doing work, and the one that matters most is scope.

The scope is written on the certificate, in a statement people rarely read. It names which organisational units, locations and services are covered. A certificate scoped to "the corporate IT function at the London office" tells you nothing about the platform you are buying, and that is not a trick — it is a legitimate certificate accurately describing what was audited.

The second qualifier is what conformance means. The standard requires that the organisation identify its risks, decide how to treat them, and operate the management system it designed. It does not prescribe a security level. An organisation can be conformant while having accepted risks you would not accept, and the document that would tell you is the Statement of Applicability, which lists the controls in scope and the justification for any excluded.

What it does and does not support

• It does tell you that a management system exists, that someone external looked at it, that risks are identified and reviewed, and that there is a process rather than good intentions.
• It does not tell you whether a specific control operated effectively over a period. That is what a SOC 2 Type II report provides, for a stated period and a set of trust criteria, with the auditor's exceptions written down. A Type I report, by contrast, covers design at a point in time and is much weaker.
• It does not tell you about the subcontractors. Your supplier's supplier is where an increasing share of real incidents originates, and the certificate covers the entity you contracted with.
• It does not tell you what happened since the audit. Certificates run on three-year cycles with surveillance audits between, so the evidence can be 12 months old and still perfectly current — a supplier certified in 2024 may have had a breach in 2025 and a valid certificate throughout.

Why this matters more than it sounds

Certificates are used as a substitute for assessment because they are cheap to request and cheap to supply, and a procurement process that collects them has the appearance of diligence with none of its content. The questions that actually reduce risk are specific: what is in the scope statement; which controls are excluded and why; what were the exceptions in the last report; how quickly will you notify us of a breach and in what form; which subprocessors handle our data; what happens to it if the contract ends.

None of those are answered by the certificate, and all of them belong in the contract, where they are enforceable. The trade being made when a procurement accepts the certificate instead is explicit once stated: it costs almost nothing and it buys almost nothing, and the bill arrives when a supplier fails and the recovery depends on terms nobody negotiated.

When the certificate is enough, and when not

For a low-risk supplier handling no personal data and holding no access to your systems — a training provider, a design agency — asking for a certificate and reading the scope statement is a proportionate control, and demanding a full assessment wastes everyone's time.

Choose the deeper assessment when the supplier processes personal data or can reach your production estate, and not before; below that line the certificate is enough. Above it, the certificate is the beginning of the conversation rather than the end, and the specific questions — scope statement, excluded controls, last report's exceptions, notification window, subprocessors, exit — go into the contract where they are enforceable.