Many vendor security reviews fail because the team does not know what to ask for. They send a generic questionnaire, get back a PDF assurance document, and mark the vendor as reviewed. Then a breach happens through a subprocessor nobody asked about, and the review turns out to have been a formality.
A structured collection checklist changes this. You need different evidence at different tiers, organized by control domain, with clear rules about what counts as acceptable evidence and what does not.
Start With What You Are Protecting
Before requesting anything from a vendor, define what you are trying to protect. Collection depth depends on data sensitivity, system access level, and business impact if the vendor fails.
Map the vendor against these dimensions before you send a single document request:
| Dimension | Questions to Answer |
|---|---|
| Data sensitivity | What classification of data will the vendor access, store, or process? |
| System access | Will the vendor connect to your production environment, or only a sandbox? |
| Business criticality | How quickly would operations suffer if this vendor became unavailable? |
| Integration depth | Does the vendor sit in your network, or operate as a standalone SaaS? |
This mapping determines your risk tier (critical, high, medium, low) and directly controls what evidence you collect. Sending an oversized questionnaire to a low-risk marketing tool wastes everyone's time. Requesting a detailed assurance package from a vendor with no data access misses the point entirely.
For more detail on how to structure the tiering itself, see our Vendor Risk Assessment.
The Evidence Categories
Regardless of tier, vendor evidence falls into seven control domains. The documents you request within each domain scale with risk, but the domains themselves stay constant.
1. Assurance documents and Audit Reports
Request current, scoped assurance evidence, not just badge-style statements. A vendor may have an assurance report that covers only part of its business while your data sits elsewhere. Always ask for the scope description, not just the headline statement.
| Risk Tier | What to Request |
|---|---|
| Critical | Full independent assurance report where available, assurance document or audit scope description, management response to exceptions, recent penetration test executive summary |
| High | Independent assurance report or scoped security assurance document where available, recent penetration test summary |
| Medium | Security questionnaire plus evidence of a relevant assurance document |
| Low | Vendor self-declaration or public security page |
Red flags to watch for:
- Assurance reports scoped to the wrong period, entity, or geography
- Penetration test reports scoped to a different product than the one you are procuring
2. Security Policies and Governance
Ask for policies that describe intent, then ask for evidence that shows practice. A policy says what should happen. You need to verify what actually happens.
At minimum, request:
- Information security policy (dated and recently reviewed)
- Access control policy (describes role-based access, least privilege, MFA requirements)
- Vulnerability management policy (patch cadence by severity)
- Incident response plan (not just the policy document, but evidence of testing)
For critical and high-risk vendors, also ask for the policy review cadence, who approved the current version, and whether the board or executive leadership receives security reporting. This reveals whether security has organizational backing or lives in a side department nobody visits.
3. Data Protection Evidence
Data protection is where many vendors get vague. Ask for specifics, not statements.
Request:
- Encryption standards for data at rest and in transit (what algorithms, what key management)
- Data residency documentation (where is your data physically stored, which jurisdiction)
- Data retention and deletion procedures (how long do they keep your data after contract termination)
- Data segregation approach (how they separate your data from other customers in multi-tenant environments)
For critical vendors handling sensitive or regulated data, also request evidence of their data processing terms, cross-border transfer approach where relevant, and any privacy or data protection assessments they have conducted for your use case.
4. Access Controls and Identity Management
Vendor access to your systems is one of the highest-risk vectors in the relationship. This is not a policy question; it is an operational question.
Ask for:
- MFA enforcement evidence (configuration screenshots, IdP policy exports)
- Privileged access management procedures (who has admin access, how is it approved and reviewed)
- Access review cadence and last review date (when were access rights last audited)
- Offboarding procedure (how quickly is access revoked when a vendor employee leaves or the contract ends)
For critical vendors with direct system access, request evidence of just-in-time access provisioning, session recording for privileged sessions, and the specific individuals who currently hold access to your environment. This is uncomfortable for vendors but necessary for high-risk relationships.
5. Vulnerability and Patch Management
Vulnerability management is the control domain many likely to reveal the gap between what a vendor statements and what they do.
Request:
- Vulnerability scan frequency and tooling (what they use, how often they scan)
- Patch cadence by severity (critical patches within how many days, high, medium)
- Penetration testing frequency, scope, and provider (internal team or third party)
- Remediation timelines for critical and high findings
A vendor that conducts annual penetration tests but does not patch critical findings promptly has a testing program without a remediation program. Both matter.
6. Incident Response and Business Continuity
How a vendor responds to incidents tells you more than their prevention posture. Ask for:
- Incident response plan (documented and recently tested)
- Breach notification timeline and procedure (how they will notify you, what information they will include)
- Business continuity and disaster recovery plans (RTO and RPO commitments, last test date)
- Evidence of tabletop exercises (who participated, what scenarios were tested)
For critical vendors, request the actual tabletop exercise results, not just confirmation that one was conducted. You want to know whether the exercise revealed gaps and whether those gaps were addressed.
7. Subprocessor and Fourth-Party Risk
Subprocessor visibility is an evidence category worth collecting clearly. Request:
- Complete subprocessor list (every third party that touches your data or provides a component of the service)
- Subprocessor notification procedure (how you are told when they add or change a subprocessor)
- Subprocessor risk assessment approach (how the vendor evaluates their own vendors)
For critical vendors, ask for the subprocessor's own assurance documents or evidence of the vendor's due diligence on their subprocessors. This is where fourth-party risk lives, and it is increasingly an audit finding.
Building the Collection Checklist
Map your evidence requests to your tier using this structure:
| Category | Critical | High | Medium | Low |
|---|---|---|---|---|
| Assurance documents | Full assurance report or scoped assurance document + pen test summary | Assurance report or assurance document + pen test summary | A relevant assurance document or questionnaire | Vendor self-declaration |
| Policies | Full policy suite + review dates + governance structure | Key policies (access, IR, vuln management) | Security questionnaire | Public security page |
| Data protection | Encryption evidence + data residency + DPA + DPIA | Encryption standards + data residency statement | Data classification self-report | None |
| Access controls | MFA evidence + PAM procedures + access review dates + offboarding SLA | MFA evidence + access review procedure | MFA statement | None |
| Vulnerability mgmt | Pen test summary + patch cadence + scan frequency | Pen test summary or vulnerability scan results | Patch cadence statement | None |
| Incident response | IR plan + tabletop results + breach notification SLA + BCP/DR test | IR plan + breach notification procedure | IR statement | None |
| Subprocessors | Full subprocessor list + change notification + fourth-party evidence | Subprocessor list + change notification | Subprocessor statement | None |
This table is a starting point. Adjust it based on your risk profile, customer commitments, and review scope. Control expectations define the evidence language; the collection checklist translates that language into specific documents.
For guidance on structuring the overall assessment workflow around these evidence requests, see our Vendor Security Questionnaire Workflow.
How to Validate What You Receive
Collecting documents is not the same as verifying them. An assurance report with exceptions, a pen test scoped to the wrong product, or an assurance document covering a different legal entity looks like evidence but provides little assurance.
Build validation rules for each document type:
- Independent assurance reports: Read the reviewer's opinion or conclusion. Exceptions, qualifications, or exclusions matter. Verify the testing period dates and scope cover the services you are procuring. Check the management response section for how they addressed exceptions.
- Security assurance documents: Confirm the document is current, issued by the right source, and covers the correct scope. For critical vendors, ask for supporting evidence that the assurance document remains current.
- Penetration test reports: Verify the test was conducted by a qualified third party, not the vendor's internal team. Confirm the scope covers the production environment you use, not a different product line. Check that critical and high findings have remediation status.
- Questionnaire responses: Cross-reference statements against the assurance documents and reports you already have. If a vendor statements independent assurance but cannot provide supporting evidence, treat the statement as unverified.
A completed review should produce a documented assessment for each control domain, not a binary pass or fail. A vendor with a minor exception and a compensating control can still be approved, but the remaining exposure needs to be written down and accepted by someone with authority.
When to Collect, Not Just at Onboarding
One-time collection at contract signing creates a snapshot that expires the moment conditions change. Define reassessment triggers alongside your collection requirements:
- Assurance document or assurance-report expiry
- Vendor-reported breach or security incident
- Addition of new subprocessors
- Change in data sensitivity or access scope
- Vendor ownership change, merger, or acquisition
- Contract renewal
Each trigger should map back to the specific evidence categories that need updating. A subprocessor change, for example, triggers a fresh subprocessor list request and a review of the new entity's assurance documents.
Connecting Collection to Your Compliance Program
Evidence you collect from vendors becomes part of your own audit trail. Organize vendor evidence so your auditors can trace it: store it in a centralized repository indexed by vendor name, risk tier, evidence type, collection date, and expiry date.
When someone asks "how do you verify third-party controls?", the answer should be a documented process with specific evidence attached, not a general statement that you "review vendor assurance documents."
This also means maintaining a gap register. When a vendor cannot provide requested evidence, document what was missing, what compensating controls you applied, and who accepted the remaining exposure. This is the record that demonstrates your program is rigorous, not perfunctory.
FAQ
What is the minimum set of documents to collect from a vendor? At minimum, request a completed security questionnaire, evidence of relevant independent assurance or assurance document where available, a data processing agreement if personal data is involved, and the vendor's breach notification procedure. This baseline applies to medium-risk and above. Low-risk vendors may only need a vendor self-declaration.
How often should we re-collect evidence from existing vendors? Critical and high-risk vendors should have evidence refreshed on a defined review cadence, with additional collection triggered by assurance document expiry, breaches, subprocessor changes, or contract renewal. Medium-risk vendors can follow a lighter cadence with change-based triggers.
What do we do if a vendor refuses to share a document? A refusal to share evidence is itself a data point. For critical vendors, refusal to provide an assurance report or penetration test summary is a significant gap that should be documented and escalated. Consider whether compensating controls (such as your own monitoring or contractual audit rights) can bridge the gap, or whether the refusal signals a maturity problem that affects the risk decision.
How do we handle vendors that reference assurance but cannot produce the document? Treat the statement as unverified. Request the assurance document with scope description and issuing body. If the vendor cannot produce it within a reasonable timeframe, flag the finding and decide whether to proceed with the relationship under documented accepted risk or to pause the evaluation.
Should we use the same questionnaire for all vendors? No. Questionnaire depth should match the vendor's risk tier. Use a short triage for low-risk vendors, a standard assessment for medium-risk vendors, and a comprehensive assessment for critical vendors. The categories stay consistent, but the depth within each category scales with risk.
CASK and Vendor Evidence Collection
CASK by Truvara manages vendor evidence collection by linking documents to controls, flagging expirations, and maintaining a single source of truth. Try CASK now.