A SOC 2 report or ISO 27001 certificate is useful evidence, but neither should be treated as proof that every product, region, or service a vendor offers is covered. This guide provides a repeatable workflow for checking scope, dates, report type, control coverage, exceptions, and continuing validity before you approve a cybersecurity, identity, hosting, or infrastructure provider.
Overview
Security claims often appear in short forms: “SOC 2 compliant,” “ISO certified,” or “independently audited.” Those labels are not specific enough for vendor due diligence. The relevant question is whether the evidence applies to the exact service and operating arrangement you are evaluating.
For example, a vendor may have a SOC 2 report for its enterprise platform while your contract uses a separate application, data center, support model, or regional environment. An ISO 27001 certificate may cover a defined information security management system (ISMS), but not every product sold under the same company name. Scope, dates, exclusions, and dependencies determine how useful the claim is.
SOC 2 and ISO 27001 are also different types of assurance. A SOC 2 report describes controls examined against selected Trust Services Criteria, while ISO 27001 certification confirms that an accredited certification process assessed an ISMS against the ISO/IEC 27001 standard. Neither document automatically demonstrates compliance with every law, regulation, customer requirement, or technical framework.
Use the following review as one part of a broader cybersecurity vendor due diligence and scoring process. The goal is not to reject a vendor because its evidence is narrower than expected. The goal is to identify what the evidence establishes, what it does not establish, and what additional safeguards or contractual commitments may be needed.
What to track
Record evidence in a vendor assurance register rather than relying on a sales presentation or a screenshot. Track the following fields for each vendor and each in-scope service.
Report or certificate type
| Evidence | What it generally tells you | Questions to ask |
|---|---|---|
| SOC 2 Type I | Controls were designed and implemented at a specified point in time. | What was the examination date? Has the vendor completed a Type II review or other continuing assurance? |
| SOC 2 Type II | Controls were examined for operation over a stated period. | What period was tested, and were there exceptions or complementary user entity controls? |
| ISO 27001 certificate | An ISMS was certified within a stated organizational and technical scope. | What exact scope is printed on the certificate? Who issued it, and is the certificate currently valid? |
| Attestation or summary letter | A limited communication about an assessment or report. | Is the underlying report or certificate available for review under confidentiality terms? |
A SOC 2 Type II report is not automatically “better” for every decision, and a certificate alone is not a complete technical assessment. Match the evidence to your risk: data sensitivity, availability needs, administrative access, integration depth, geographic requirements, and recovery expectations.
Scope and applicability
Capture the legal entity named in the report or certificate, the product and service names, production environments, hosting locations, data types, and relevant regions. Check whether the evidence covers the service you will actually buy or only a parent company, internal platform, or limited business unit.
For SOC 2, read the system description. Look for the in-scope infrastructure, software, people, procedures, and boundaries. Note the Trust Services Criteria included, such as security, availability, confidentiality, processing integrity, or privacy. Also identify subservice organizations and the selected carve-out or inclusive method, because a vendor may rely on cloud, hosting, payment, or support providers that are outside the vendor’s own testing.
For ISO 27001, read the statement of applicability and the scope wording where available. The certificate may describe an ISMS by function, location, product, or process. Confirm that the controls and locations relevant to your deployment fall inside that boundary. Certification of a corporate security program does not by itself confirm that a particular customer environment is configured securely.
Dates, exceptions, and dependencies
Record the SOC 2 examination period, report issue date, and the date of any bridge letter. For ISO 27001, record the certification date, expiry date, surveillance or recertification status, and any certificate identifier or verification route provided by the certification body.
Read the independent service auditor’s opinion and the testing results. Exceptions do not automatically make a report unusable, but they require interpretation. Note the affected control, time period, system component, and vendor response. Also record complementary user entity controls: actions your organization must perform for the vendor’s controls to work as intended.
A practical evidence request can be concise:
Please provide the current SOC 2 report or ISO 27001 certificate for the service under evaluation. Include the covered legal entity, product and environment scope, relevant regions and data centers, examination or certification dates, included criteria or ISMS boundaries, subservice organization treatment, stated exceptions, complementary customer controls, and the process for confirming continuing validity. Please identify any material changes to scope since the evidence was issued.
If the full report cannot be shared, ask whether it can be reviewed under a nondisclosure agreement. A polished summary may support initial screening, but it is rarely enough for a higher-risk decision.
Cadence and checkpoints
Verification should happen at onboarding, renewal, and whenever the vendor or your use of the service changes. A quarterly review is reasonable for critical vendors when your risk program has the capacity; a less critical provider may be reviewed annually, subject to internal policy.
- Before selection: Request the evidence early. Confirm scope before treating a vendor as a “SOC 2 compliant vendor” or ISO-certified provider in your comparison notes.
- During security review: Map the report or certificate to your architecture. Check data flows, administrative access, integrations, support channels, backups, and subprocessors.
- At contract approval: Document evidence delivery obligations, incident notification terms, audit or review rights, subprocessor notices, data location commitments, and termination assistance where relevant.
- At renewal: Request the latest report, certificate status, bridge letter, or explanation of any gap. Compare the new scope with the prior version instead of filing it without review.
- After a material change: Reassess when the vendor launches a new product, changes hosting regions, acquires a business, changes subprocessors, suffers a significant incident, or changes the service architecture.
Maintain a simple status such as verified, verified with conditions, pending evidence, or not applicable. Add an owner, next review date, evidence location, and open questions. This makes the register useful during audits and procurement renewals rather than turning it into a document archive.
The same discipline applies when comparing secure hosting providers for HIPAA, PCI DSS, and SOC 2 requirements, evaluating IAM vendors, or reviewing infrastructure services such as DNS, CDN, and domain protection providers.
How to interpret changes
Not every change signals increased risk, and not every unchanged certificate means the vendor’s current service is adequately covered. Interpret evidence in context.
- Narrower scope: Treat removal of a product, region, environment, or legal entity as a material change until its effect on your service is clear.
- New subservice organization: Determine whether the provider’s controls depend on a new cloud, hosting, payment, support, or monitoring service. Review the vendor’s treatment of that dependency and any customer responsibilities.
- Changed report period: A newer report is not automatically more relevant if your deployment moved to a different environment or product after the period ended.
- Control exception: Ask whether the exception affected confidentiality, availability, access control, change management, backup, or another control relevant to your use. Request the vendor’s corrective action and current status.
- Different certification body or report format: Verify the issuer, accreditation or professional standing where applicable, and the continuity of the certification or examination. Do not infer equivalence from branding alone.
- Bridge letter only: Use it to understand the period between reports, but confirm what changed, who authorized the statement, and whether it addresses the exact service and scope you use.
Red flags include a vendor that supplies only a logo, refuses to identify the covered service, uses “certified” without naming the standard or certificate scope, provides an expired document without a current status explanation, or treats a penetration test as a substitute for SOC 2 or ISO 27001 evidence. Another warning sign is a report that places essential controls in the customer’s responsibility without explaining how your team is expected to operate them.
When evidence is incomplete, record the limitation and compensate proportionately. Possible measures include a restricted deployment, stronger access controls, additional contractual terms, independent technical testing, shorter review intervals, or selecting another provider. Link the decision to risk rather than to a simple pass-or-fail label.
When to revisit
Revisit this verification process at least at every vendor renewal and on a quarterly or annual cadence based on criticality. Set an earlier checkpoint when a report period ends, a certificate approaches expiry, a bridge letter covers an extended gap, or the vendor announces a material architectural or organizational change.
Before each review, compare five items: the service you use, the evidence scope, the evidence dates, the control exceptions, and the dependencies your organization must manage. If any one of these has changed, reopen the assessment rather than simply updating the document’s expiration date.
For an efficient next step, create a one-page record for every important vendor. Attach the report or certificate, highlight the scope statement, list open questions, assign an owner, and set the next checkpoint. Then use the findings alongside your broader vendor due diligence checklist. This recurring process produces a more defensible view of vendor security than a badge, a sales claim, or an old compliance document alone.
