TL;DR
A completed CAIQ v4 questionnaire answers 261 yes/no questions, but enterprise deals stall for weeks not because of the answers but because vendors lack the supporting documents those answers point to—like SOC 2 reports, pen test attestations, and data flow diagrams. The single artifact that kills the most calendar time is the subprocessor list, required by GDPR Article 28 and increasingly demanded by US enterprises.
The article’s bottom line: assemble a standing "content kit" of seven buyer-safe documents—including a redacted pen test summary (never the full report), a security-focused architecture overview, and an incident response plan summary—before any sales cycle starts, and draw from that menu per deal to eliminate the scramble that kills enterprise revenue.
A B2B security review content kit is the standing set of documents a vendor keeps ready to prove its security posture to a prospect's due-diligence team: audit reports, a penetration test summary, a data flow diagram, a subprocessor list, and the certifications a buyer's security or procurement function will ask to see. Having it assembled before a deal reaches security review doesn't change what's true about your security program — but it removes the multi-week scramble of hunting down evidence, redacting it, and routing it through legal, which is where enterprise deals lose the most calendar time for reasons that have nothing to do with the product.
This is distinct from the workflow of answering a security questionnaire line by line (CAIQ, SIG, or a custom spreadsheet) — that's a separate, narrower problem covered elsewhere. This piece is about the underlying documentation those answers point back to: the pen test reports, architecture docs, and data flow maps that a completed questionnaire is supposed to be evidence for.
What "security review" actually means to a buyer
Direct answer: Enterprise and mid-market buyers run vendor due diligence through some combination of a few standardized instruments, plus their own custom questions layered on top:
- CAIQ (Consensus Assessments Initiative Questionnaire), published by the Cloud Security Alliance. Version 4 runs 261 yes/no questions mapped one-to-one to the Cloud Controls Matrix v4 (197 controls across 17 cloud-security domains). It's free, and a completed CAIQ can be published on the CSA's public STAR Registry, where it doubles as a standing answer to any buyer who checks there first.
- SIG (Standardized Information Gathering), from Shared Assessments, a nonprofit formed in 2005 by a group of large banks and consulting firms specifically to stop everyone from reinventing vendor questionnaires. SIG is broader than CAIQ — closer to twenty risk domains including data privacy, physical security, HR security, and business continuity, not just cloud controls. More than 500 organizations license it.
- VSAQ (Vendor Security Alliance Questionnaire), from the Vendor Security Alliance, founded by Airbnb, Atlassian, Docker, Dropbox, and Uber. It's shorter than SIG and tends to show up when the buyer is itself a tech company rather than a bank or hospital system.
- Bespoke spreadsheets built by the buyer's own GRC or procurement team, usually asking for the same underlying evidence in different language.
Every one of these instruments asks, in some form, for the same handful of underlying artifacts. That's the content kit.
What belongs in the kit
| Artifact | What it proves | Who typically asks | Grounded in |
|---|---|---|---|
| SOC 2 Type II report (or a bridge letter if the report is aging) | Controls were tested for design and operating effectiveness over a 6–12 month window, not just designed on paper | Enterprise security and procurement, almost universally in the US | AICPA Trust Services Criteria — Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are added based on what you actually commit to customers |
| ISO/IEC 27001:2022 certificate + Statement of Applicability | An accredited auditor certified your ISMS; the SoA shows exactly which of the 93 Annex A controls apply and why others were excluded | EU and international buyers, regulated industries | ISO/IEC 27001:2022 Annex A — 37 organizational, 8 people, 14 physical, 34 technological controls |
| Penetration test letter of attestation or redacted summary | Independent testing happened recently, without exposing exploit paths or unpatched findings | Nearly every technical security review | Attestation vs. redacted vs. full report practice — full reports stay internal; prospects get a one-to-two-page attestation or a redacted version with technical detail stripped |
| Data flow diagram | Where customer/personal data is collected, processed, stored, and transmitted, including any cross-border movement | Privacy and legal reviewers, especially for EU customers | Standard due-diligence request, tied to GDPR accountability obligations |
| Subprocessor list | Which third parties touch customer data and what they do with it | Any buyer subject to GDPR or a similar regime | GDPR Article 28 — a processor can't add a subprocessor without the controller's prior authorization, and must pass the same obligations down contractually |
| Data Processing Agreement (DPA) | Contractual commitment to Article 28 obligations: confidentiality, security measures, audit rights, breach notification | EU/UK customers, and increasingly US enterprises with EU operations | GDPR Article 28(3); non-compliance exposure runs up to €10M or 2% of global annual revenue under Article 83 |
| Architecture overview (security-focused) | Network segmentation, encryption in transit/at rest, IAM model, tenant isolation | Technical security reviewers | Standard due-diligence request |
| Incident response plan summary | A defined process exists for detecting, containing, and disclosing incidents — without revealing the runbook itself | Security and, increasingly, insurance/legal | Standard practice; expected content for SIG and custom questionnaires |
| CAIQ response / CSA STAR Registry listing | Standardized, publicly checkable cloud control self-assessment | Buyers who reference CSA STAR directly, or want a fast first pass | CSA CAIQ v4 |
Not every buyer wants all of it. A CAIQ published on the STAR Registry can pre-empt a chunk of requests before they're even sent. A DPA only matters once a buyer's data actually crosses into GDPR scope. The kit is a menu you draw from per deal, not a single document that ships as-is.
How to assemble it: seven steps
- Inventory what you already have and date it. Pull the current SOC 2 report, ISO certificate (if any), most recent pen test report, and existing DPA template. Note the audit period end date on the SOC 2 report — you'll need to know how close it is to expiring.
- Convert raw evidence into buyer-safe artifacts. A full penetration test report never goes to a prospect. Work with your testing provider up front on a letter of attestation or a redacted version — scope, methodology, and severity totals in, exploit payloads and internal architecture detail out.
- Build the data flow diagram and subprocessor list from actual production architecture, not an aspirational one. This is the artifact most likely to embarrass you in review if it drifts from reality — reviewers cross-check it against your DPA and your actual infrastructure.
- Map each artifact to the framework it answers. Tag documents by CAIQ domain, SIG section, or ISO Annex A clause so a reviewer (or a teammate fielding the request) can point to proof instead of re-explaining from scratch.
- Set an owner and a freshness policy per artifact. SOC 2 Type II reports cover 6–12 months; once a report ages past that window, industry practice is to issue a bridge letter covering the gap, and the convention is that a bridge letter itself shouldn't stretch past about three months before you need the next audit. ISO certificates run a three-year cycle with annual surveillance audits. Pen tests are typically annual. Put expiration dates on a calendar, not in someone's memory.
- Decide access tiers before a prospect asks. What's public (a CAIQ on the STAR Registry), what requires an NDA (the SOC 2 report itself, the pen test attestation), and what never leaves the building (the full pen test report, internal network diagrams with real IP ranges).
- Centralize and version it, then test it against a live deal. Whether that's a dedicated trust-center product or a well-organized shared drive with access logging, the goal — as Drata's guidance on security review best practices puts it — is a single source of truth rather than five slightly different copies scattered across old email threads. Run it against one real deal, note what got asked that wasn't in the kit, and add it.
Limitations
Direct answer: A documentation kit is not a substitute for the security posture being real. An attestation letter, a redacted pen test, and a tidy subprocessor list all describe controls that are supposed to already exist — they don't create them. A buyer who catches daylight between what the kit claims and what a technical review actually finds will trust you less than a vendor who had no kit at all and said so honestly.
Requirements vary by industry and regulation in ways no single kit covers. A DPA under GDPR Article 28 is close to mandatory once EU personal data is in scope, but irrelevant to a buyer that never touches EU data. Financial-services buyers lean harder on SIG's broader domain coverage; buyers referencing the Cloud Security Alliance often start and stop at CAIQ. Healthcare introduces HIPAA-specific asks this kit doesn't cover at all. Government buyers may expect FedRAMP, which is an entirely different, heavier process.
The frameworks also aren't interchangeable, despite covering overlapping ground. Passing a SOC 2 Type II audit doesn't automatically satisfy the Statement of Applicability questions an ISO 27001-focused reviewer will ask, and a completed CAIQ won't stand in for the SIG response a bank's third-party risk team expects. Treat each as a separate deliverable that happens to draw on the same underlying evidence, not as one document with different letterheads.
And a stale artifact is often worse than a missing one — an expired certificate or a bridge letter that's run well past its conventional window is exactly what a careful reviewer is trained to flag first.
FAQ
Is this the same as answering a security questionnaire?
No. Answering CAIQ, SIG, or a custom questionnaire is the workflow of filling in specific answers, often reusing prior responses. This kit is the underlying evidence those answers cite — the actual reports, diagrams, and lists a questionnaire answer points back to.
Can we send prospects the full penetration test report?
Generally no. Full reports contain exploit paths, affected systems, and reproduction steps that create real risk if they leak. Standard practice is a letter of attestation (proof testing happened) or a redacted summary (scope, methodology, severity totals) — the full report stays internal to security, engineering, and legal.
How current does the SOC 2 report need to be?
A Type II report covers a 6–12 month audit window. As that window ages, vendors typically issue a bridge (gap) letter self-attesting that controls are unchanged, on the general industry convention that a bridge letter shouldn't stretch past about three months before the next audit closes the gap.
Do we need both SOC 2 and ISO 27001?
Depends on your buyers. SOC 2 dominates US enterprise deals; ISO 27001 carries more weight internationally and in some regulated industries. They cover overlapping but not identical ground, and having only one will occasionally cost you a deal where the buyer specifically requires the other.
Where should the kit actually live?
Anywhere with access control and version history — a dedicated trust-center product, a permissioned data room, or a well-maintained shared drive. The failure mode to avoid is five different copies of the DPA circulating across old email threads, none of which is provably the current one.
What's the minimum viable kit for an early-stage company without SOC 2 yet?
A CAIQ response (free, and publishable on the STAR Registry), a DPA template, a data flow diagram, and a clear, honest timeline for when SOC 2 or ISO 27001 will land. Reviewers generally accept "in progress, audit scheduled for Q_" far better than silence or an overstated claim.
Where nqzai fits
nqzai is built for the outbound and content side of B2B go-to-market, not for security compliance itself — it doesn't run your pen tests, generate your SOC 2 report, or replace your security team's judgment about what's true. What it can help with is keeping the content half of your go-to-market operation — the pages, positioning, and prospect-facing material that reference your security posture — accurate and current, so a claim made on your marketing site doesn't drift out of sync with what your security team can actually back up. It won't tell you whether your controls are real; that part stays entirely yours.
