A security questionnaire almost never arrives on its own. It comes with a request for supporting documents, and those documents are frequently the longer pole — you can write answers on a deadline, but you cannot produce a SOC 2 report in a fortnight. Knowing what usually travels with a questionnaire lets you start gathering on day one instead of day nine.
This article covers the nine documents buyers most commonly request, what each one actually is, why a reviewer wants it, what to send when you do not have it, and the specific traps in each — including the two documents most often requested and most often missing at companies under twenty people.
The attestations
SOC 2 report. The most requested document in US enterprise procurement. It comes in two forms and the difference matters: a Type I report assesses whether your controls are designed appropriately at a single point in time, while a Type II assesses whether they operated effectively over a period, typically several months to a year. Buyers who know the difference want Type II. If you have a Type I, say which you have rather than sending it labelled as "our SOC 2" and letting them discover it.
Send the full report under NDA, not the marketing summary. Reviewers read the exceptions section, and a vendor who supplies only a one-page badge signals they would rather the exceptions were not read.
If you have neither, say so plainly and describe the compensating position: what controls you run, what evidence you can supply directly, and whether an audit is genuinely planned. A stated Q3 date that slips is worse than no date.
ISO 27001 certificate. Sought more often by European and international buyers. Three things get requested together and vendors usually send only the first: the certificate itself, the scope statement, and the Statement of Applicability. The scope matters because a certificate covering only your London office says nothing about the product; the SoA matters because it lists which Annex A controls you applied and which you excluded, with justification. A reviewer asking for the SoA is asking what you left out.
Note that ISO 27001:2022 restructured Annex A, so a certificate issued against the older revision will look different from a current one. That is normal during a transition and worth a sentence of explanation rather than leaving the reviewer to wonder.
Penetration test report. Usually the most recent one, within twelve months. Most vendors send an executive summary rather than the full report, which is standard and accepted — the full document contains exploitable detail and reasonable buyers do not expect it. What they do expect is the date, the scope, the tester, the severity counts, and evidence that findings were remediated. A summary showing three high-severity findings and a remediation letter reads considerably better than a summary showing zero findings, which mostly signals a narrow scope.
The contracts and lists
Data Processing Agreement. Requested whenever the buyer has EU customers or operates under GDPR, which is most B2B software buyers of any size. They want your standard DPA, and increasingly they want to see it before legal review rather than during. Our guide to what a DPA is and what it must contain covers the required clauses; if you are drafting one, the DPA template guide is a reasonable starting point.
The trap is having a DPA that exists as a Word document someone drafted in 2023 and which nobody can find. If the request takes you three days to answer, that is three days visible to the buyer.
Subprocessor list. Every third party that touches customer data, what each processes, and where it sits. This is one of the two documents most commonly requested and most commonly missing at small companies, and it is entirely within your control to fix. Buyers increasingly want it published rather than emailed, along with a mechanism for notifying customers of changes. Our guide to subprocessors under GDPR covers what belongs in the inventory and the notification obligations attached to it.
Certificate of cyber liability insurance. Frequently requested by procurement rather than security, often with a minimum coverage figure attached. It is a quick win when you have it and a slow one when you do not, because binding a policy takes weeks. Worth checking your coverage limits before a deal depends on them.
The internal documentation
Security policies. Typically information security, access control, and incident response, sometimes also acceptable use and business continuity. The common trap is claiming policies you do not have in document form. If your access control policy is four paragraphs in a shared document, send those four paragraphs. A short real policy is defensible; a claimed policy that does not exist collapses the moment a reviewer asks for it.
Architecture or data flow diagram. What the system looks like, where personal data enters, where it is stored, which third parties it reaches, and where it crosses borders. Many vendors do not have one and draw it under deadline. Drawing it once, properly, pays for itself immediately — it answers a document request, it feeds your records of processing activities, and it makes the data residency questions in the questionnaire answerable rather than guessed. Our guide to records of processing activities covers the inventory this feeds into.
Business continuity and disaster recovery plan. Reviewers want RTO and RPO figures, single points of failure, and — the question that catches people — the last date you actually tested a restore. "We back up nightly" is not an answer to "when did you last verify you could restore." If you have never tested, say so and schedule one, because it will be asked again.
What to send when you do not have it
The same structure works for every gap: name it, describe what you do instead, offer what you can evidence, and give a date only if the date is real.
"We do not currently hold a SOC 2 report. We run annual third-party penetration testing, enforce MFA on all production access with quarterly access reviews, and can provide our cloud provider's attestations for the infrastructure layer. We are scoping a Type II audit and expect to begin the observation window next year."
That answer is a no, and it will pass at most buyers, because it demonstrates that you understand what the document is for. The version that fails is silence, and the version that fails worse is a document sent under a label it does not deserve.
Common mistakes with supporting documents
Discovering the document requests on day nine. They arrive with the questionnaire. Read the covering email properly and start gathering immediately, because these depend on other people.
Sending a SOC 2 Type I as "our SOC 2." Reviewers check. Name which type you hold.
Sending only the ISO certificate. Scope statement and Statement of Applicability are usually part of the same request. Sending one of three generates a follow-up round.
Claiming policies that exist only as intentions. A short real policy beats a claimed one that cannot be produced.
Treating the subprocessor list as a one-off email. It changes, buyers are entitled to notice, and publishing it converts a recurring request into a URL.
FAQ
What documents do buyers ask for with a security questionnaire?
Most commonly a SOC 2 report or ISO 27001 certificate, a recent penetration test summary, your DPA, a subprocessor list, security policies, an architecture or data flow diagram, a business continuity plan, and a cyber liability insurance certificate. Not every buyer asks for all of them.
Do I need a SOC 2 report to sell to enterprise?
Not always, but its absence needs an explanation and compensating evidence. Some enterprise buyers treat it as a hard requirement; many will proceed with a thorough questionnaire, a penetration test summary, and clear documentation if the risk profile is moderate.
Should I send the full penetration test report?
Usually not. An executive summary showing date, scope, tester, severity counts, and remediation status is standard and accepted, since the full report contains exploitable detail. Be ready to discuss findings if asked.
What is a Statement of Applicability?
An ISO 27001 document listing which Annex A controls you have applied, which you have excluded, and the justification for each exclusion. Buyers request it alongside the certificate because it shows the shape of your implementation rather than just its existence.
Closing thought
The document request is where security reviews actually stall. Questionnaire answers can be written quickly under pressure; a subprocessor list that has never existed, a DPA nobody can find, and a data flow diagram that lives in one engineer's head cannot be. Each is a small job done calmly and a genuine problem done on a deadline in front of a customer.
Several of the documents on this list are also things a buyer would rather look up than request. ComplyDog hosts a compliance portal on your own domain covering your DPA, subprocessor list, data subject request process, and security overview, kept current, so the recurring half of the pack is already published when the questionnaire arrives. The SOC 2 report still has to come from an auditor. The rest does not have to come from a scramble.
