Evidence is what turns an answer into something a reviewer can check without taking your word for it. Buyers typically ask for it on a minority of questions — the ones where the answer is high-impact, easy to overstate, or inconsistent with something else you wrote — and the request is usually for a document, a configuration export, a system-generated report, or a third-party attestation.
This article covers the difference between an answer and evidence, the six kinds of proof reviewers request and what makes each acceptable, what you should never send, how to redact properly, and how to build an evidence pack so requests take an hour rather than a week.
Answer versus evidence
Every questionnaire answer is an assertion. You are saying what you do. A completed SIG is a structured set of vendor assertions, and a STAR Level 1 CAIQ entry is a self-assessment — neither is independently verified by the act of submitting it.
Evidence is what a reviewer asks for when an assertion matters enough to check. That is not distrust; it is the job. Third-party risk exists because vendors sometimes describe an intended state rather than the current one, usually without meaning to.
Three things reliably trigger an evidence request. High impact: encryption, access control, backups, and incident response get checked more than personnel policies. Easy to overstate: anything phrased as always, all, or fully. Inconsistency: an answer that does not sit comfortably beside another one — you claimed quarterly access reviews in one section and annual in another, so now both get checked.
The practical implication is that the questions you were tempted to answer generously are exactly the ones most likely to be examined.
The six kinds of evidence
Configuration exports and screenshots. The most common request for technical controls. Your identity provider's MFA enforcement policy, your cloud storage encryption settings, your password policy, your logging configuration. What makes these acceptable is that they are system-generated rather than described: a screenshot of the actual setting, showing the date, beats a sentence saying the setting is enabled.
Policy documents. Information security, access control, incident response, acceptable use, business continuity. Reviewers check three things — that it exists, that it has a version and a review date, and that it says what you said it says. A policy last reviewed in 2022 is a finding even if its contents are perfect.
System-generated reports. Access review exports, vulnerability scan results, backup completion logs, patch status reports. These carry more weight than anything narrative because they were produced by a system rather than a person. An access review export with a date and a reviewer name is close to unarguable.
Third-party attestations. SOC 2 reports, ISO 27001 certificates with scope and Statement of Applicability, penetration test summaries, your cloud provider's own compliance documentation. The strongest form, because someone independent checked.
Records and tickets. Evidence that a process ran, not just that it exists. An incident ticket showing detection, escalation, and resolution. An onboarding checklist. A change approval record. This category is what separates a documented process from a practised one, and reviewers increasingly ask for it specifically.
Contracts and agreements. DPAs with your subprocessors, confidentiality agreements, and your own customer-facing DPA. Buyers assessing your vendor chain want to see that the obligations you accepted have been passed down. Our guide to GDPR subprocessor management covers the contractual chain reviewers are looking for here.
What makes evidence acceptable
Four properties, and most rejected evidence fails on one of them.
It is dated, and recently. Undated evidence proves nothing about the present. Most reviewers work to a twelve-month window and a shorter one for anything operational.
It is system-generated where possible. A configuration export outranks a description. A description outranks a promise.
Its scope is visible. A vulnerability scan covering one repository is not evidence about your estate. State what the evidence covers, because a reviewer who has to guess will assume the narrow reading.
It matches the claim. The commonest failure is evidence that is adjacent to the question. Asked for proof of quarterly access reviews, vendors send their access control policy — which proves they intend to do reviews, not that reviews happened. The policy answers "do you have a process." The export answers "did you run it."
What never to send
Full penetration test reports without careful thought. They contain exploitable detail. An executive summary with dates, scope, tester, severity counts, and remediation status is standard and accepted.
Anything containing customer data. Screenshots of production systems showing real records are a data protection incident, not evidence. Use a test tenant or redact thoroughly.
Credentials, keys, tokens, or internal hostnames. These appear in screenshots more often than people expect. Check the whole image, including browser tabs, notification banners, and terminal scrollback.
Named individuals beyond what is necessary. Access review exports listing every employee with role and email are frequently sent unredacted. Redact to what the reviewer actually needs.
Raw architecture detail that maps your attack surface. A logical data flow diagram is appropriate; a network diagram with internal IP ranges is not.
Redaction has its own trap: black rectangles drawn over text in a PDF frequently leave the text underneath extractable. Flatten the image or export to a format that discards the original layer, then reopen the file and try to select the redacted text before sending it.
Building the pack before you need it
Evidence requests are predictable, which means the pack is buildable in advance. Assemble a folder covering the controls that get checked most: encryption settings, MFA enforcement, access review output, backup and restore verification, vulnerability scanning, incident response records, and your policy set. For each item, store the artifact, the date it was captured, and a one-line note on what it demonstrates.
The item almost everyone is missing is restore verification. Reviewers ask when you last tested a restore, and "we back up nightly" does not answer it. Running a restore test once and keeping the record makes an otherwise awkward question routine.
Refresh the pack quarterly. Stale evidence is worse than none, because it will be sent with confidence and then dated by the reviewer. Our guide to running a GDPR compliance audit covers the same discipline applied to privacy documentation, where the evidence expectations increasingly mirror security ones.
Common mistakes with security evidence
Sending the policy when asked for the record. A policy proves intent. An export proves execution. Reviewers asking for evidence usually want the second.
Sending undated artifacts. Evidence without a date establishes nothing about the current state.
Redacting badly. Black boxes over PDF text often leave the text selectable. Flatten, then verify before sending.
Screenshotting production with real customer data. That is an incident, not evidence. Use test data or redact fully.
Letting the pack go stale. Quarterly refresh, or you will send twelve-month-old configuration exports with confidence.
FAQ
What evidence do buyers ask for in a security review?
Most commonly configuration exports or screenshots for technical controls, policy documents, system-generated reports such as access reviews and scan results, third-party attestations like SOC 2 or ISO 27001, records showing a process actually ran, and contracts including subprocessor DPAs.
Do I have to provide evidence for every questionnaire answer?
No. Evidence is typically requested on a minority of answers — the high-impact controls, anything phrased in absolutes, and anything that appears inconsistent with another answer. A well-organised evidence pack covering the common ones handles most requests.
Can I refuse to share security evidence?
You can decline specific items and frequently should, particularly full penetration test reports, anything containing customer data, and detailed network topology. Decline with a reason and an alternative — an executive summary, a redacted export — rather than a flat refusal.
How recent does security evidence need to be?
Most reviewers work to a twelve-month window for attestations and penetration tests, and expect operational evidence such as access reviews and scan results to be considerably more recent, typically within the last quarter.
Closing thought
The distinction worth internalising is between documenting a control and demonstrating it. Most small companies are reasonably good at the first and have never been asked for the second, which is why the evidence request rather than the questionnaire is where reviews slow down. The questions can be answered from knowledge. The evidence has to be found.
A meaningful share of what gets requested is data protection rather than security engineering — subprocessor DPAs, your customer-facing agreement, deletion and retention records, how data subject requests are actually handled. ComplyDog keeps those maintained and published on a portal at your own domain, which means that portion of an evidence request is answered by a link to a live page rather than a search through a shared drive. The configuration exports still have to come from your systems. They should just be the only part you have to go looking for.
