Vendor Due Diligence Without a SOC 2: What Evidence Can Actually Substitute

TL;DR

• “No SOC 2” is not a complete risk decision. Start with the vendor’s service, data access, system access, customer impact, and operational criticality.
• Build an evidence package by control objective: independent testing, scoped certifications, operational samples, walkthroughs, continuity tests, and contract rights. A security questionnaire alone proves very little.
• For a critical vendor, some gaps cannot be papered over. Limit the scope, add a customer-side control, delay launch, require future assurance, or reject the relationship.

A startup vendor says it has no SOC 2 because it is “too early.” Sales says the integration is urgent. Security says no report means no approval.

The useful answer sits between those positions: a vendor can sometimes pass due diligence without a SOC 2, but only when the substitute evidence provides enough assurance for the actual service risk. This vendor due diligence checklist shows how to make that judgment without turning “risk-based” into “whatever gets the deal signed.”

A SOC 2 is an assurance report, not a security force field. The AICPA describes SOC 2 as an examination of controls relevant to security, availability, processing integrity, confidentiality, or privacy. It can be highly useful because an independent CPA evaluates a defined system and reports against stated criteria. But possession of a report is not the same as complete coverage, and absence of one is not proof that controls do not exist.

The real question is: what evidence supports each control conclusion you need to make?

Start with the activity, not the certificate

OCC Bulletin 2023-17, which transmits the 2023 interagency third-party risk guidance, says third-party relationships do not all carry the same risk or operational criticality. The depth of due diligence should be proportionate to the bank’s risk profile, complexity, and the activity supported.

Before asking for substitute evidence, classify the relationship:

A graphic-design vendor with no system access should not face the same evidence burden as a payments processor. A customer-support platform holding recordings and authentication data should not receive a questionnaire-only approval because the company is small.

The agencies’ May 2024 Third-Party Risk Management: A Guide for Community Banks makes the operational point directly: if desired due-diligence information cannot be obtained, a bank may consider alternative information, controls, or monitoring. It may also retain a different third party. That sequence matters. Alternative evidence is a deliberate response to a gap, not an excuse to ignore it.

Use an evidence ladder, not a document swap

There is no universal document that equals a SOC 2 Type II report. Substitution works at the control-objective level.

For a higher-risk relationship, use multiple levels. A policy plus a signed questionnaire is still management assertion. A penetration test plus policies leaves governance and operational controls mostly untested. A scoped certification plus operational samples and a walkthrough creates a stronger chain.

The no-SOC-2 vendor due diligence checklist

1. Explain the absence

Capture whether the vendor has never pursued a report, is in an examination period, refuses to share it, or has a report whose scope excludes the service you are buying. Those facts imply different risks.

Request:

• reason the report is unavailable;
• expected report type and target date, if planned;
• auditor or CPA firm, if engaged;
• intended system and criteria scope;
• whether a prior report had exceptions or a modified opinion.

Do not count “we expect certification next quarter” as present assurance. Treat it as a future condition with an owner and due date.

2. Map the controls that matter to your use

Start with the data flow and shared-responsibility model. Identify who controls identity, encryption, logging, backups, secure development, incident handling, deletion, resilience, and subcontractors.

The FFIEC’s April 2020 Joint Statement on Security in a Cloud Computing Environment emphasizes due diligence, clear division of responsibilities, ongoing oversight, and review of independent assurance such as audits, penetration tests, and vulnerability assessments. It also warns that the institution retains overall responsibility for the safety and soundness of cloud services and protection of sensitive customer information.

Create a control-evidence map:

3. Review scope before admiring the logo

An ISO certificate, penetration-test letter, or security rating is useful only if it covers the environment delivering your service.

Check:

• legal entity and product covered;
• systems, locations, and subprocessors included;
• review or testing dates;
• exclusions and carve-outs;
• testing firm or certification body;
• open findings and remediation status;
• whether the evidence covers design only or operation over time.

A certificate for headquarters operations does not prove controls over the acquired platform processing your customer data. A penetration test of the marketing website does not cover the production API.

4. Ask for samples, not screenshots alone

A screenshot can show that MFA is enabled for one account today. A dated access-review record shows whether someone periodically evaluates privileged access. A ticket connecting a terminated employee to account disablement shows the process operating.

For higher-risk vendors, select samples yourself where feasible: a recent month, one privileged role, one terminated user, one production change, and one restored backup. Document how the sample was chosen. Vendor-selected “best examples” are still useful, but label the limitation.

5. Convert missing assurance into a decision condition

A gap should end in one of five outcomes:

1. Accept because exposure is low and evidence is proportionate.
2. Compensate with a control your organization operates.
3. Restrict data, access, customer segment, volume, or use case.
4. Condition approval on dated remediation, future assurance, and monitoring.
5. Reject or delay because the unresolved control is essential to safe operation.

The fifth option has to remain real. If the vendor will hold customer credentials but cannot show access control, logging, incident response, or independent testing, a roadmap and sales deadline do not create assurance.

A worked evidence-substitution decision

Realistic hypothetical: A fintech wants a young SaaS vendor to summarize internal quality-assurance calls. The vendor would receive call transcripts containing customer NPI. It has no SOC 2, but says an examination will begin in four months.

A defensible review could look like this:

• Risk tier: High because the vendor receives customer NPI at volume; it is not operationally critical because the process can return to manual review.
• Evidence received: ISO 27001 certificate and scope; statement of applicability; independent penetration-test executive summary; architecture and data-flow diagrams; privileged-access review sample; backup restore result; incident tabletop record; current subprocessor list.
• Gaps: No operating-period assurance; deletion process has no independent testing; one subprocessor receives transcript data.
• Customer controls: Tokenize direct identifiers before transfer; block audio upload; SSO and MFA; restrict use to a trained QA group; retain transcripts for the shortest approved period; reconcile deletion confirmations to uploaded batch IDs.
• Contract conditions: No model training or secondary use; named subprocessors; incident-notice requirement; deletion evidence; audit and information rights; SOC 2 Type II delivery after a sufficient operating period if the relationship continues.
• Approval: Six-month conditional approval by the authority named in the TPRM policy, with monthly control evidence for the first quarter.
• Stop triggers: Failure of tokenization, unapproved subprocessor, material security incident, missed deletion evidence, or refusal to provide agreed assurance.

Those timeframes are an illustrative starting design, not a regulatory benchmark. The team should set review frequency from data sensitivity, control maturity, change velocity, and internal risk appetite. It should verify the customer-side controls by matching uploaded batch IDs to tokenization logs and deletion records—not by accepting a project-status update.

What does not substitute for a SOC 2

Several artifacts are useful inputs but weak conclusions on their own:

• a completed security questionnaire;
• a one-page “SOC 2 compliant” statement;
• a penetration-test cover letter with no scope or finding status;
• a cyber-insurance certificate;
• a security rating score;
• cloud-provider certifications inherited by implication;
• policies with no operational samples;
• a promise that a report is coming;
• a contract clause that says the vendor follows “industry best practices.”

Cloud hosting is the classic trap. A vendor running on a certified hyperscaler does not inherit assurance over its own identities, application code, tenant isolation, configuration, logging, support access, or incident process. Shared infrastructure assurance answers only part of the question.

Document the exception so another reviewer can reproduce it

The approval record should contain:

• vendor and service scope;
• risk tier and rationale;
• required control objectives;
• requested, received, missing, and stale evidence;
• reviewer conclusion for each control objective;
• evidence limitations;
• compensating controls and their owners;
• residual risk;
• approval authority and date;
• contractual conditions;
• monitoring plan;
• expiry or reassessment trigger.

This extends the evidence-verification method in Vendor Due Diligence Techniques: What to Verify When the Questionnaire Comes Back. Track aging and missing artifacts using the vendor due diligence KRI guide, and connect any subprocessor gap to the fourth-party risk playbook.

So What?

Pick one high-risk vendor currently marked “SOC 2 unavailable.” Build the control-evidence map above and identify every conclusion supported only by a questionnaire or policy. Then decide whether to obtain operational evidence, add a customer-side control, narrow the scope, impose a dated condition, or stop the onboarding.

That is what risk-based due diligence looks like: not lowering the bar because a document is unavailable, but rebuilding the assurance chain around the risk you actually need to control.

The Third-Party Risk Management (TPRM) Kit includes the tiering, due-diligence, evidence-review, contract, monitoring, and exception artifacts needed to document that chain.