Customer Security Review Evidence Checklist for B2B SaaS Teams
The evidence buyers, auditors, Vanta, Drata, and Secureframe actually ask for — organized by control category, with what's typically acceptable and what's not.
A customer security questionnaire just landed in your inbox. Your buyer wants proof — not policy text — that you actually do what your security page claims. The auditor's PBC list (Provided By Client) lands a week later asking for the same things in slightly different language. Your compliance platform's evidence queue fills up.
What they all want is the same underlying set of artifacts, presented slightly differently. This checklist organizes those artifacts by control category so you can gather them once and serve every requester.
It's the engineering perspective: what the file looks like, where it lives, how often to refresh it. Not the legal perspective.
How to use this checklist
- Walk it once before your first questionnaire. Most of the work is one-time — exporting a config, taking a screenshot, writing one one-page document. Don't wait for the buyer to ask before you start gathering.
- File each artifact in a private evidence repo organized by category. The Cloud Controls Evidence Kit is a free MIT-licensed scaffold of this exact structure.
- Refresh on cadence. Quarterly for most operational evidence, annually for policy snapshots. Auditors and buyers both look for freshness.
- When a questionnaire arrives, paste short answers and attach the matching evidence files. Don't write fresh prose every time.
1. Access controls
The category most security reviews lead with. SOC 2 section CC6 covers it in detail and procurement teams treat it as table-stakes.
| What buyers ask | What evidence looks like | Refresh |
|---|---|---|
| MFA enforced for admins | IdP policy export (Okta / Google Workspace / Entra) showing MFA required, plus screenshot of the per-user enforcement status report | Quarterly |
| Least-privilege IAM | Role definitions + per-role member list (AWS IAM, GCP IAM, or Azure AAD export) | Quarterly |
| Service-account / API-key inventory | CSV listing every long-lived key with owner, purpose, last-rotated date | Quarterly |
| Offboarding revokes access | The offboarding checklist itself, plus 3–5 completed instances showing each step was done with timestamps | Per departure |
| Privileged-access review | Quarterly review minutes signed off by a named reviewer | Quarterly |
The trap most teams fall into: they have MFA enabled but can't quickly produce evidence that it's enforced. The fix is exporting the IdP's MFA-status report once per quarter and filing it. The export takes 30 seconds. Trying to recreate it under time pressure during a security review is what costs days.
The Cloud Controls Evidence Kit's
evidence-folder-template/01-access-controls/
has the templates for each.
2. Logging and monitoring
The second most-asked. Auditors look for coverage (every production account is logged) and retention (logs are kept long enough for the review period).
| What buyers ask | What evidence looks like | Refresh |
|---|---|---|
| Cloud audit logging on every prod account | Trail / log-sink config export plus a query result showing logs from each account | Quarterly |
| Log retention ≥ 365 days for the review period | Storage lifecycle policy (S3 lifecycle rule, GCS bucket lifecycle, Azure storage lifecycle) + sample query returning the oldest available log | Annually |
| Tamper-resistant log storage | Object-lock / bucket-lock / WORM configuration screenshot or export | Annually |
| Alerts route to a human | Alert rule definitions + at least one sample firing showing a person acknowledged | Annually |
The common gap: logs are configured somewhere, but coverage isn't complete. A new GCP project gets created without being added to the org-level log sink. A new AWS account is bootstrapped without CloudTrail org-trail membership. Auditors will sample-check this — having a coverage query that explicitly lists every prod account and shows recent log volume from each catches the drift before they do.
3. CI/CD and change management
SOC 2 CC8.1 lives here. Buyers care about this because it's the gate against "some engineer pushed prod without review."
| What buyers ask | What evidence looks like | Refresh |
|---|---|---|
| Required reviews on production deploy | Branch-protection rule export (GitHub gh api repos/<org>/<repo>/branches/main/protection) + CODEOWNERS file | Quarterly |
| Environment-protected production deploys | GitHub Environments / GitLab protected environments configuration screenshot or export | Quarterly |
| Release evidence: who shipped what, when | CSV or table of the last 30 production deploys with author + reviewer + timestamp | Per quarter |
| Rollback capability | Runbook + record of the most recent rollback exercise (real or drilled) | Annually |
The artifact most teams skip: the release evidence CSV. They have the
branch-protection config (because GitHub stores it), but reconstructing "who
shipped what when" from git log and CI history under pressure during a
review is tedious. Exporting it once a quarter into a flat file makes the
answer instant.
4. Vulnerability and secrets hygiene
| What buyers ask | What evidence looks like | Refresh |
|---|---|---|
| Dependency scanning with SLA on critical CVEs | Scanner config (Dependabot / Renovate / Snyk) + the remediation log showing recent critical CVEs were closed within SLA | Quarterly |
| Container / image scanning | Trivy / Artifact Registry / ECR scanning config + last 30 deploys' scan outcomes | Quarterly |
| Secret scanning, blocking on detection | GitHub Advanced Security or GitLab secret detection config + remediation log of any detected hits | Quarterly |
| Pen-test or red-team within 12 months | Engagement report or written summary | Annually |
The trap: scanning is enabled but the remediation log is missing. A buyer asking "do you remediate critical CVEs within 7 days?" wants to see a specific recent example of a critical CVE being closed within 7 days. "We have a policy" is not the answer; "here's the alert from 2026-04-12 closed on 2026-04-15" is.
5. Backups, recovery, and availability
| What buyers ask | What evidence looks like | Refresh |
|---|---|---|
| Production databases backed up | Backup configuration (RDS automated backups, Cloud SQL backup config, native managed-service equivalent) + last 7 successful backup timestamps | Quarterly |
| Backup restore tested | Restore-test runbook + the most recent test report (date, restored row counts, runtime, integrity-check outcome) | Quarterly |
| Incident runbook exists | The runbook itself, plus the last actual incident's postmortem | Annually |
| Stated RPO / RTO | Documented values (recovery point + time objectives) tied to the backup capability above | Annually |
The single highest-leverage artifact in this section: the quarterly-restore-test report. The vast majority of teams have backups configured but have never restored from them. A real restore test that recovers a recent backup into a non-production target environment, with row counts and wall-clock time recorded, is the difference between "we say we back up" and "we proved we can recover." Auditors love this; buyers love this; you'll thank yourself when you genuinely need it.
6. AI workload controls (if applicable)
For teams shipping AI features, buyers now ask AI-specific questions. The canonical list emerging from enterprise procurement:
| What buyers ask | What evidence looks like | Refresh |
|---|---|---|
| Model endpoints behind auth | Auth configuration (API gateway, VPC, IAM) + sample request denied without token | Quarterly |
| Prompt and tool-call logging | Policy document covering what's logged, retention period, who can read it | Annually |
| Per-tenant or per-org spend caps | Quota / rate-limit configuration + alert routing for cap breaches | Quarterly |
| Tenant-isolated retrieval / RAG indices | Tenant-isolation policy + a negative test showing cross-tenant query returns zero results | Quarterly |
| Customer data not used for training | Policy statement (and contractual terms in customer DPA) | Annually |
| Abuse / misuse handling | Runbook for prompt-injection reports, content-abuse reports, leaked-prompt incidents | Annually |
This category is new and most buyers don't yet have standardized language for it. The NIST AI Risk Management Framework is the closest thing to a public reference. Until standards stabilize, the practical move is to file documented controls for whatever AI features you ship and reference them when the questionnaire asks something AI-shaped.
Cross-walks to formal frameworks
Most buyers' procurement teams reference one or more of these as the question basis:
- SOC 2 Trust Service Criteria — CC6 (access), CC7 (monitoring + risk), CC8 (change management), CC9 (vendor risk), A1 (availability)
- NIST Cybersecurity Framework — PR.AC (access), DE.CM (monitoring), PR.IP (change management), RC.RP (recovery)
- CSA Cloud Controls Matrix / CAIQ — cloud-control-specific yes/no assessment questions, useful when you sell to enterprises in regulated industries
- ISO 27001 Annex A — broader controls catalog, asked when selling into European enterprises
The good news: the evidence doesn't change. The MFA policy export, the log sink configuration, the restore test report — all satisfy questions in all four frameworks. Gather once, map to whichever language the buyer uses.
What's NOT this checklist
This is the evidence layer. It's the things engineering can ship and operate. The checklist deliberately doesn't cover:
- Drafting policy text (privacy policy, acceptable-use policy, information-security policy) — talk to a lawyer; tools like StrongDM's Comply are designed for that
- Compliance-platform configuration (the specific knobs in Vanta, Drata, or Secureframe) — each platform has its own docs
- Threat modeling, formal risk assessments — different scope, different deliverables
This checklist covers what your buyer is actually asking for when they say "show me the evidence." Match the evidence to the question, attach the file, move on.
The kit
The Cloud Controls Evidence Kit ships this entire layout as ~34 markdown files: per-control template, per-category README, per-cloud guide (AWS, GCP, Azure, GitHub). Free, MIT-licensed, drop into your private compliance repo and start filling in. The categories above map 1:1 to the kit's folder structure.
If you'd rather have an engineer walk your stack and produce the populated evidence folder for you, that's what a Controls Review is. The output is exactly the checklist above, filled in with your actual data.