A vendor's attestation tells you they had controls on the audit date. It does not tell you their product is actually hard to break. When you cannot take a SOC 2 report at face value, validate the claims that decide whether they belong in your supply chain.
File · Answer first
Sort your vendors by what their compromise would cost you, then validate the top of that list rather than trusting its paperwork. A SOC 2 report proves a process operated during a closed window; it says nothing about whether the product resists attack today, whether the API enforces authorization, or whether the external footprint is clean. For a low-criticality vendor that gap is acceptable. For a vendor holding your data or sitting in your supply chain it is the exact gap an attacker uses. You close it two ways: ask the questions a polished response document cannot survive, and where the relationship warrants it, test the surface yourself. The rest of this page is both.
File · What a
Trusting a vendor because they handed you a clean SOC 2 is like trusting a building is secure because it passed a fire inspection two quarters ago. Useful, bounded, and silent on the things that actually get you breached.
File · The questions
Most vendor questionnaires are noise: every vendor answers them the same way. A short list of pointed questions separates a vendor with a real security program from one with a polished response document. We maintain that list as the penetration test vendor evaluation checklist, and the same discipline applies to evaluating any third party: ask who tests the product and how often, ask to see a recent test's scope and a redacted finding, ask how they handle a critical disclosed against them, and watch whether the answers are specific or rehearsed.
Operator Note
Your third parties are an attack path into you, not a separate risk you can outsource. The breaches that hurt most enter through a trusted vendor's integration, their API key, or their access into your environment. A vendor's attestation does not protect you from the vendor being the way in.
“A SOC 2 report tells you a vendor passed an exam under conditions they helped define. It does not tell you their product survives contact with someone trying to break it. Those are different facts, and only one of them is yours to verify.”
File · Validating the
When a vendor relationship is material enough, do not rely on their paperwork alone. With authorization, we test the surface that actually carries your risk.
File · Third party
The point of validating a vendor is not to grade their security for its own sake. It is to decide whether connecting them to you raises your risk past what you can accept. Weight the assessment by how the vendor touches your environment: data they hold, access they hold, and integration they have. A low-criticality vendor gets a questionnaire and a pointed question or two. A vendor with an API key into your production or your customers' data gets validated. The standard you apply to your own testing is the standard worth applying to theirs.
File · FAQ
Q1 Is a SOC 2 report enough to trust a vendor?
For a low-criticality vendor, often yes. For a vendor that holds your data, holds access into your environment, or carries an integration, no. A SOC 2 report attests that controls existed during a closed audit window inside a defined scope. It does not prove the vendor's product resists attack today, and no examiner was trying to break the application or API. Validate the vendors whose compromise would become your incident.
Q2 How do you validate a vendor's security claims?
Two layers. First, the questions that discriminate a real program from a polished response: who tests the product, how often, what a recent test found, and how they handle a critical disclosed against them. Second, with authorization, an independent test of the surface that carries your risk: the web application, the API, and the external footprint, including assets their own SOC 2 scope never covered.
Q3 We cannot get authorization to test the vendor. What then?
Then you lean on the discriminating questions and require evidence: a recent independent test's scope, a redacted critical finding and its remediation, and their disclosure handling. A vendor with a real program can produce those quickly. A vendor that cannot, or will not, is telling you something. The evaluation checklist gives you the full list to work from.
Talk to an Operator
Real operators. Real attack paths. Real business impact. Talk to us about your security goals.
Related
The checklist that frames the questions, and the tests that prove the answers.
The questions that separate a real program from a response document.
Tenant isolation, authorization, and logic flaws in the product.
Where multi-tenant SaaS actually leaks.
The footprint a vendor's own scope never covered.