ISO 27001 for Vendor Risk: What the Certificate Covers

What ISO 27001 actually certifies

ISO/IEC 27001 certifies that a vendor runs an Information Security Management System (ISMS) that conforms to the standard - a working, documented, independently audited system for identifying security risks and managing controls against them. The thing being certified is the management system: that the vendor has a real, governed process for security, not a one-off snapshot of good intentions.

Here is the framing correction worth making up front, especially if you have been reviewing SOC 2 reports. A SOC 2 is a report, with no pass/fail badge; ISO 27001 is a certificate, with a badge. But that difference cuts the opposite way from how most people read it. A SOC 2 Type II tests whether specific controls actually operated over a period and lists the exceptions where they did not. An ISO 27001 certificate attests that the management system conforms - it does not, on its face, show you the operating effectiveness of every individual control or where any of them fell short. The badge tells you a system exists and was audited. It does not, by itself, tell you what that system protects or how.

Read the scope line first

Every ISO 27001 certificate carries a scope statement, and it is the single most important line on the document. The scope names which legal entity is certified, which services or products are covered, and which locations or sites sit inside the ISMS boundary. Everything outside that boundary is uncertified, even if the same company name is on the badge.

This is the number-one trap in an ISO 27001 vendor assessment: a vendor presents a certificate whose scope is their corporate ISMS, a single headquarters office, or an internal IT function - not the product or service you are actually buying. The badge looks identical either way. A cert scoped to 'the information security management system supporting corporate IT operations at the London office' tells you nothing useful about the SaaS platform you are about to send customer data into. Before you accept the certificate, read the scope and confirm the product you are buying is named inside it.

The Statement of Applicability is the real document

The certificate proves a system exists and is in scope. The Statement of Applicability (SoA) tells you what that system actually does. The SoA is the central control document of an ISMS: it lists every Annex A control, marks which ones apply, marks which are excluded, and gives a justification for each decision. It is where the abstract certificate becomes a concrete list of what is and is not implemented.

The certificate does not include the SoA - you have to request it, or at least a summary, from the vendor. A vendor confident in their program will share it or walk you through it. When you read it, the exclusions are where the risk hides. A control marked 'not applicable' with a thin justification - cryptography excluded for a product that handles sensitive data, supplier-relationship controls excluded by a vendor that itself relies on sub-processors - is exactly the gap a badge-only review would never surface. Read the exclusions before you read the inclusions.

Annex A controls, and the ISO 27002 confusion

Annex A of ISO/IEC 27001:2022 is the catalog of security controls an ISMS can draw on. The 2022 revision reorganized the prior set into 93 controls grouped under four themes: Organizational (37 controls), People (8), Physical (14), and Technological (34). The SoA is essentially the vendor's response to this catalog - which of the 93 they apply and which they exclude.

One point that trips up reviewers: ISO 27002 is the companion standard that provides the detailed implementation guidance for those Annex A controls. A vendor is certified to ISO 27001 (the management-system standard you can be audited and certified against), not to ISO 27002 (guidance, which has no certification). If a vendor claims to be 'ISO 27002 certified,' that is a red flag worth a question - it is not a thing.

Check the accreditation, not just the certificate

Not every ISO 27001 certificate carries equal weight. A meaningful certificate is issued by a certification body that is itself accredited by a national accreditation body - for example UKAS in the United Kingdom or ANAB in the United States. That accreditation chain is what gives the certificate independent assurance: the auditor was itself audited for competence and impartiality.

A self-declared certificate, or one from an unaccredited certification body, looks much like an accredited one at a glance but carries far less assurance - no one independent vouched for the auditor. Look for the accreditation mark on the certificate (the accreditation body's logo and a reference number), and when a vendor is critical, confirm the certification body's accreditation rather than taking the badge at face value.

Confirm the cert is current and not lapsed

An ISO 27001 certificate is valid for a three-year cycle, and that cycle has a rhythm you should check. After the initial certification audit, the certification body conducts annual surveillance audits in years one and two to confirm the ISMS is still operating, then a full recertification audit before the end of year three - completed ahead of the certificate's expiry date so a new certificate issues without a gap - restarts the cycle. Certification is a continuous obligation, not a one-time event.

So a current date on the certificate is necessary but not sufficient. Check that the certificate is within its three-year validity window and that surveillance is ongoing rather than lapsed - a vendor that passed the initial audit but quietly stopped maintaining the system can still wave a certificate that has not technically expired. Treat the dates as live data: an expired certificate filed as if it were current is one of the easiest review failures to avoid and one of the most common.

ISO 27001 vs SOC 2 for a vendor review

These two artifacts answer different questions, and a mature reviewer values both. ISO 27001 gives you management-system assurance: the vendor has a governed, audited process for managing security risk over time, and the scope plus SoA tell you what that process covers and excludes. SOC 2 Type II gives you control-operation assurance: independent testing of whether specific controls actually operated over a defined period, with the exceptions named.

For a low-tier vendor, either one in proper scope is often enough. The point worth making here is narrower: for a critical vendor, the two are complementary rather than redundant - which is why experienced reviewers frequently want the ISO 27001 scope and SoA AND a SOC 2 Type II. The ISO documents tell you a real security system exists and what it is responsible for; the SOC 2 tells you the controls inside it were tested and held. One without the other leaves a gap: a certificate with no operating evidence, or operating evidence with no system context.

Common mistakes to avoid

Most weak ISO 27001 vendor assessments fail in the same handful of ways. Watch for these:

• Accepting the badge without ever reading the scope statement or requesting the SoA - the two documents that make the certificate mean anything.
• Missing a scope gap: filing a certificate whose scope is the corporate ISMS or one office rather than the product or service you actually buy.
• Ignoring the exclusions in the SoA, where a control marked not-applicable can quietly drop a protection your data depends on.
• Not checking accreditation - treating a self-declared or unaccredited certificate as equivalent to an accredited one.
• Filing an expired certificate as current, or missing that surveillance audits have lapsed even though the date has not.

Where ISO 27001 fits in your program

ISO 27001 belongs in your review file as management-system assurance - proof that a vendor runs a real, audited security program - but only once you have read past the badge to what the certificate actually covers. The badge is the start of the review, not the end of it. For a critical vendor, pair it with a SOC 2 Type II so you have both the system context and the operating evidence.

The hard part in practice is keeping all of that answerable over time: the scope, the exclusions, the accreditation, and the recertification date - and noticing when a cert quietly ages out of its three-year cycle before an auditor asks. That is where review most often breaks down in a spreadsheet. v3ndor's interface lets you record each vendor's certificate details - the ISMS scope, the Statement of Applicability notes, and the recertification date - on the vendor record and surfaces expiring attestations before they lapse, so 'is their ISO 27001 current and in-scope?' is answerable at a glance. Request access at /request-access to see it on your own vendors.