How to verify a vendor's ISO 27001 and SOC 2 claims

Why logos are not evidence

Security certifications appear in almost every testing vendor's proposal, often as a logo. A logo tells you that someone, somewhere in the vendor's group, may hold a certificate. It does not tell you whether it covers the team that will test your product, whether it is current, or whether the body that issued it is accredited. The red flags checker flags "certification claimed without scope or number" for this reason.

Your testers will hold credentials to your environments, see unreleased features and sometimes personal data. The checks below are quick to run and belong in your due diligence.

Verifying an ISO 27001 certificate

ISO/IEC 27001 is the international standard for an information security management system. A certificate means an independent certification body audited that system against the standard. Four checks:

1. The entity. The certificate names a legal entity. Compare it with the entity that will sign your contract. Groups often certify one company and sell through another. If they differ, ask how the certified entity relates to your delivery team.

2. The scope. The scope statement says which activities, sites and services the management system covers. This is where most gaps are. A certificate scoped to "the head office in city X" or "software development services" may not cover a testing team in another country. Ask for the statement of applicability, which lists the controls the vendor applies and any it excludes.

3. The certification body and its accreditation. The certificate should name the body that issued it. Accredited certification bodies are overseen by a national accreditation body that is a member of the International Accreditation Forum (IAF). Certificates from unaccredited bodies exist and carry much less weight.

4. The dates and version. Check the issue and expiry dates, and that it refers to the current edition of the standard, ISO/IEC 27001:2022.

Using IAF CertSearch

IAF CertSearch is a public database of accredited management system certificates. Search by company name or certificate number and compare the result with the copy you were given: entity, scope, status and dates. If it is not listed, that is not proof of a problem, because not every certification body publishes there. Confirm directly with the certification body and record the answer.

Reading a SOC 2 report

A SOC 2 report is an auditor's report on a service organisation's controls against the AICPA Trust Services Criteria. It is shared under NDA, not published. What to read, in order:

Part	What to check
Report type	Type II, not Type I
Period	The audit period, and how long ago it ended
Auditor's opinion	Unqualified, or qualified with reasons
System description	The services, locations and systems in scope; is testing delivery included?
Criteria in scope	Security is always included; availability, processing integrity, confidentiality and privacy only if chosen
Subservice organisations	Carved out (not tested) or included; which ones matter to you
Tests and exceptions	Each exception, what failed and how often
Complementary user entity controls	Controls the report assumes you operate

The period. If the period ended many months ago, ask for a bridge letter in which the vendor states whether controls have changed since.

Exceptions. An exception is a control that did not operate as described in some tests. A few exceptions with clear remediation are normal. Ask how each was fixed. Repeated exceptions in access control or staff offboarding matter most for a testing vendor, because its people hold access to your systems.

Carve-outs. If the vendor relies on a hosting provider or subcontractor that is carved out, the report says nothing about that party's controls. Ask how the vendor oversees it.

Complementary user entity controls. These are controls the report expects you, the customer, to operate, such as reviewing the vendor's access to your systems. Assign each one an owner on your side, or the assurance in the report does not hold.

When there is no certificate or report

Use a structured questionnaire, such as the Cloud Security Alliance CAIQ or your own, and ask for evidence behind key answers: an access review record, an offboarding checklist, an incident response policy. Keep the depth in proportion to the access the vendor will have. ISO/IEC 27036 describes this kind of supplier relationship security in general terms. The questionnaire includes the security questions to send.

Put it into the contract

Verification tells you where the vendor stands today. The contract keeps it there: an obligation to maintain the certification or provide annual reports, to tell you if scope changes or a certificate lapses, and security obligations that apply whether or not a certificate exists. See exit planning for access removal at the end, and how to check references properly for asking other clients about security incidents.