The Security Questionnaire Evidence B2B SaaS Buyers Actually Accept

A 90-row security questionnaire just landed in a shared spreadsheet, the buyer's security team is CC'd, and the deal owner wants it back by Friday. A week later the auditor's PBC list (Provided By Client) asks for the same things in slightly different language. You start typing answers. Most of them begin with "We have a policy that..." or "Yes, we enforce...".

Here is what you need to know before you send it: the reviewer on the other end has read a thousand of those sentences. The trap most teams fall into: they answer the questionnaire in prose. Prose is what gets flagged, looped back, and turned into a follow-up call that delays the deal by two weeks. What clears the review on the first pass is a concrete export — a file, a config dump, a query result with real numbers in it.

This article maps the questions you will actually get to the artifacts that actually clear them, and names where to export each one.

Why prose gets rejected

A questionnaire answer is a claim. An auditor's job — and increasingly a buyer's security engineer's job — is to verify the claim, not believe it. "We enforce MFA for all admins" is unfalsifiable as written. An IdP export that lists every admin with their MFA enrollment status is falsifiable: the reviewer can count the rows and see zero exceptions. That is the entire difference.

So the rule for every row below is the same: answer with the artifact, not the adjective. Paste a one-line answer, then attach the file that proves it. The sections that follow give you both halves for each common question.

Access controls: IAM and least privilege

This is where most questionnaires lead, and where most get stuck.

What gets accepted: the AWS IAM credential report. One call — aws iam generate-credential-report then aws iam get-credential-report — gives you a CSV with every user, their MFA status, key age, and last-used timestamps. On GCP, gcloud projects get-iam-policy <project> --format=json dumps every binding. Reviewers accept these because they are machine-generated and you can't hand-edit them into looking better without it being obvious.

The artifact teams skip: the last-used column. A reviewer who asks about least privilege is really asking "do you have standing admins who never use it?" The credential report answers that in a column you already have.

MFA enforcement

Nearly every questionnaire asks it. Almost nobody answers it correctly.

The trap most teams fall into: confusing enabled with enforced. "Enabled" means the option exists. "Enforced" means a user with no second factor cannot sign in. Reviewers reject "enabled" because it permits exceptions. The accepted answer is the per-user enrollment report with no admin showing "not enrolled," plus the policy export proving the gate is mandatory.

Branch protection and change management

SOC 2 CC8.1 lives here. The buyer's concern is blunt: can one engineer push to production with nobody looking?

What gets accepted: the raw JSON from gh api repos/<org>/<repo>/branches/main/protection. It contains required_pull_request_reviews, required_status_checks, and the enforce_admins flag. A reviewer reads three fields and moves on. The prose version triggers "please confirm admins cannot bypass" — which is exactly the field you should have attached.

Audit logging

Auditors look for two things here: coverage (every prod account is logged) and proof the logs exist (not just that logging is turned on).

The artifact teams skip: the sample query result. Anyone can show that a trail exists. The accepted evidence is the trail config and a query — for example a CloudTrail Lake or Logs Insights query — that returns rows from the last 24 hours for each production account, plus one that returns the oldest entry to prove retention. Config proves intent; the query proves it actually works.

Backup and restore testing

The single highest-leverage artifact in any questionnaire: the restore-test report. Most teams have backups configured and have never restored from them. "Backups are enabled" gets accepted at the config level but rejected the moment the reviewer asks "when did you last restore?" The accepted answer is a one-page report: restored the 2026-06-20 snapshot into a staging target, 4.2M rows in the orders table verified against source, completed in 18m32s, integrity check passed. Row counts and wall-clock time are the signal that it actually happened.

Dependency and secret scanning

Scanning being on is the easy half. The half that gets rejected is the absence of a remediation trail.

The trap most teams fall into: answering "yes, scanning is enabled" to a question that is really about response. A buyer asking "do you remediate critical CVEs within 7 days?" wants one concrete instance proving it. "We have a policy" is not the answer; the dated alert-to-merge trail is. Export the alerts list once a quarter and keep the remediation log next to it.

Map your answers before you send them

The pattern is consistent across all six: a machine-generated export plus, where the question is about an outcome, one dated example proving the outcome. Gather these once into a private evidence repo and you answer every future questionnaire by pasting a short line and attaching the matching file.

The kit and the next step

The free Cloud Controls Evidence Kit ships this exact layout — including worked questionnaire-answer examples that pair each common question with the export that clears it and the prose that doesn't. Drop it into your private compliance repo and start filling it in.

If you'd rather have an engineer walk your stack and produce the populated evidence folder — the IAM report, the branch-protection export, the restore-test report, all filled in with your actual data — that is what a Controls Review delivers.

When the next questionnaire lands, you want to be attaching files, not writing sentences. If you want help getting there before your next enterprise deal, book a fit call.