The DDQ response playbook, end to end

A DDQ — due-diligence questionnaire — is a specialized RFP. It looks like the eight-stage RFP pipeline but it has a different rhythm. The questions repeat across bids more than RFP questions do. The SMEs are more senior. The penalty for fabricating an answer is larger. And the volume has metastasized.

Safe Security’s research puts the volume at over 500 questionnaires per year for some enterprise vendors, with 200 to 400 questions each. One engineer they profiled “spent his entire week responding to questionnaires rather than securing systems.” Loopio’s DDQ guide puts response time at 15 to 40 hours per questionnaire. Qorus’s research on the SME bottleneck — the same 48% number, holding steady for five years — applies to DDQs harder than to anything else, because DDQ SMEs are senior security and finance staff whose calendars are denser than presales engineers’ calendars.

This post is the canonical playbook. Seven stages. What each one owns, where it breaks, and what good looks like. The ambition is concrete: the same DDQ from the same buyer next year should take half the time. The playbook is the way to make that ambition a discipline instead of a slogan.

Stage 1 — Intake & classification

What it is. A DDQ arrives. The team turns it into a structured response project: a record of the buyer, the questionnaire, the deadline, the format, the bucket distribution, and the assigned ownership.

Why DDQs are special at intake. RFPs arrive in a small number of formats — usually a PDF or a Word document with a portal upload. DDQs arrive in roughly five formats, each with different intake mechanics:

CAIQ (Consensus Assessment Initiative Questionnaire) — Cloud Security Alliance’s standard. ~270 questions, structured, predictable.
SIG (Standardized Information Gathering) — Shared Assessments’ standard. SIG Lite (~120 questions), SIG Core (~600 questions), SIG Plus (~2,000+ questions). Predictable structure.
Custom Excel. A buyer’s own spreadsheet, often a hand-built fork of CAIQ or SIG with the buyer’s additions. Structure varies by buyer.
Portal-only. The questionnaire lives inside the buyer’s GRC platform (OneTrust, Whistic, ProcessUnity). The team has to log in to answer. Export is sometimes possible, sometimes not.
PDF. A flat document, often a PDF generated from the buyer’s underlying system. The hardest format because there’s no native structure.

The intake team has to recognize the format on day one and pick the right ingest path. CAIQ and SIG can be auto-extracted by question identifier — the question text is identical to a known reference and the response slot is structured. Custom Excel needs a parse that finds the question and answer columns, which vary. Portal-only needs a strategy: copy questions out, draft offline, paste back, or work in the portal directly. PDF needs the heaviest extraction — OCR plus a parse that distinguishes question rows from instructions and table headers.

Classification. Once the questions are extracted, every question gets a bucket assignment. We covered the bucket structure in Day 37’s DDQ classification changelog: finance, legal & privacy, security, operations & vendor management. Classification is what lets the work distribute. Without it, every reviewer scrolls through every question to find their slice.

What goes wrong. Three patterns.

Format misidentification. Teams treat a custom Excel as a PDF and lose two hours typing questions into a tracker by hand. Or treat a SIG Lite as a CAIQ and miss the question identifiers. Naming the format right is a five-minute task that saves hours downstream.

Late classification. Teams answer the questions that come up first instead of the questions that distribute right. The finance person ends up answering security questions because the security person is busy, and the answer doesn’t pass review.

Missed addenda. Buyers post follow-up questions or scope clarifications mid-cycle. Without intake hygiene, the addenda land in someone’s email and don’t make it to the response.

What good looks like. A single owner — usually the proposal manager or a security operations lead — receives every DDQ. The owner identifies the format, runs the extraction, applies the classifier, and assigns the buckets to reviewers within four hours of receipt. Addenda flow back to the same record automatically. The clock for the deadline starts at intake, not at the first answer.

Stage 2 — Retrieval from the KB

What it is. For every classified question, the team’s knowledge base is searched for prior answers that map to the same underlying ask. The output is a draft, sourced from the KB, that the SME can review and approve instead of writing from scratch.

Why DDQ retrieval is not copy-paste. The 1up.ai team phrased this exactly right: “Most questionnaires are quite similar, but just different enough that you can’t copy/paste every answer, and re-writing takes just as long as creating a response from scratch.”

The “just different enough” is the thing that breaks naive systems. The buyer’s CAIQ question is “Describe your encryption key management process.” Your KB has an answer to “How are encryption keys rotated and stored?” The questions are not literally identical. A keyword search returns the wrong block, or no block, or three loosely related blocks. The drafter’s time savings vanish in the triage.

What good retrieval looks like for DDQ specifically:

Hybrid search. Both dense embeddings (paraphrase coverage) and BM25 (numeric identifier coverage) — we covered this in yesterday’s post. DDQs are full of both kinds of queries; pure-anything fails.
Span-level matched evidence. The retriever returns not just the block but the specific span within the block that most closely matches the question. The drafter sees “this block matches because of these three sentences,” not “this block matched, good luck finding the relevant part.”
Question-identifier shortcuts. For CAIQ and SIG, the question identifier (e.g., AIS-01 in CAIQ) matches across questionnaires from different buyers. A KB indexed by identifier as well as by content can return the answer that’s already been refined for that exact question across previous responses.
Freshness signals. When the retriever returns a candidate block, the UI shows when it was last verified. A six-month-old answer to a SOC question is suspect; a two-week-old answer is current. The drafter sees this before accepting.

What goes wrong. Retrieval that returns too many candidates. The drafter wades through five blocks for every question. Or retrieval that misses on the discrete-token failure modes — Type II vs Type I, AES-256 vs AES-128 — and returns the wrong answer with a confident score. Or retrieval against a stale KB, where the surfaced answer is technically correct for a year ago but no longer represents the current posture.

What good looks like. For 80% of DDQ questions, the retriever returns one block, with a span highlighted, with a freshness indicator, and the drafter accepts without modification. For the remaining 20%, the retriever surfaces the relevant blocks and the drafter composes from them, but the composition is from existing content, not from scratch.

Stage 3 — Drafting with grounding

What it is. Generating the answer text from the retrieved blocks, with a citation back to the source.

Why grounding matters more on DDQs than on RFPs. Numeric precision is more load-bearing in DDQ answers than in RFP answers. An RFP answer that says “we typically deliver in 8-12 weeks” is acceptable boilerplate. A DDQ answer that says “we maintain SOC 2 Type II certification with annual audits” is a contractual commitment that can be fact-checked against a public report.

The categories of numeric and named-entity claims in DDQ answers that are most often falsified — sometimes innocently, by drafters working from memory:

Audit type and period. SOC 2 Type II vs Type I. Audit period start and end.
Encryption algorithms. AES-256 vs AES-128 vs ChaCha20.
Compliance frameworks. FedRAMP Moderate vs FedRAMP Low. ISO 27001 vs ISO 27017.
Data residency. Specific region names. “US-East and EU-West” vs “North America and Europe” (the latter is broader than the former; the difference matters).
Retention periods. “30 days” vs “90 days” in log retention.

AutogenAI’s research on proposal hallucination names this exact failure mode: hallucinations in proposals appear as “incorrect compliance claims” delivered with confidence and passing early reviews unnoticed. DDQs are the proposals where this gets a vendor disqualified.

What grounded drafting looks like for DDQ:

Rewrite-only prompting. The drafting model is constrained to rewrite from the retrieved source, not to generate from training data. We covered this in the Pledge enforcement post.
Claim-level entailment. Every numeric and named-entity claim in the draft is verified against the source block. Mismatches are refused.
Refusal as a feature. When the system can’t entail the answer, it surfaces a refusal — not a hallucinated guess. The drafter sees the refusal and either escalates to an SME (Stage 4) or marks the answer “we don’t do this” (a different kind of escalation, also Stage 4).

What goes wrong. Drafting from training data instead of from the KB. Drafting an answer that paraphrases the source so loosely that the numeric anchor is lost (“we maintain encryption” when the source says “AES-256 at rest”). Drafting compound claims that cross blocks the verifier can’t compose. We covered each of these in Grounded Retrieval 101 Part 4.

What good looks like. Every drafted DDQ answer ships with a verified citation that the reviewer can click. Numeric claims match the source exactly. Compound claims are flagged for the reviewer when the system isn’t sure. The drafter’s time on a CAIQ question drops from “15 minutes of writing” to “30 seconds of accepting a verified draft” for the 60-70% of questions where the KB has good content.

Stage 4 — SME escalation

What it is. When the KB doesn’t have the answer, or when the answer requires judgment a generic system can’t provide, the question escalates to a subject-matter expert.

The two kinds of escalation. This is the distinction most DDQ playbooks miss. There are two operationally different escalations.

“We don’t do X” — product or policy escalation. The buyer is asking about a capability the company doesn’t have. The answer is no. But the answer “no” has to be cleared with the right person — usually a product or policy lead — because the answer is also a future commitment. “We don’t currently support FedRAMP High” is different from “We don’t and won’t support FedRAMP High.” The escalation asks the right SME to decide which of those is the answer.

“Not yet” — roadmap escalation. The buyer is asking about a capability the company is building. The answer is qualified. The escalation goes to the roadmap owner to confirm the timeline. “We’re targeting Q3 2026 for FedRAMP High ATO” is a commitment that has to be authorized.

These are not the same escalation and they don’t go to the same person. A playbook that treats them as one queue ends up with product leads answering roadmap questions and roadmap leads answering policy questions, and the answers come back inconsistent.

The ticketed SME-ask pattern. Every escalation creates a ticket with:

The question text (verbatim, from the DDQ).
The classification (which bucket, which sub-bucket).
The reason for escalation (KB-miss, policy-decision-required, or roadmap-confirmation-required).
The SLA (how long does this SME have before the question becomes a blocker).
The proposed answer, if the drafter has one. SMEs review faster than they write.

The ticket goes to the SME’s queue with a clear deadline. Not “as soon as you can.” A specific date and time, derived from the DDQ deadline minus the review and submission buffer.

SLAs. A typical DDQ deadline is two weeks. Working backwards: submit on Day 14, gold-team review on Day 13, compliance on Day 12, SME-answers-due on Day 9. An SME who gets a ticket on Day 4 has five days. An SME who gets a ticket on Day 12 has zero days, and the ticket is a fire drill.

The earlier the escalations land, the calmer the response. Stage 1 + Stage 2 should clear within 48 hours of intake to give the escalations the lead time they need.

What goes wrong. The same things Lohfeld and Qorus document for RFPs apply harder to DDQs: SMEs respond late, or in fragments, or not at all. The Qorus research on the SME bottleneck — 48% of teams citing this as their top challenge for five years — is essentially a DDQ research finding. Security and finance leads are scarce and senior; their queue is the bottleneck.

What good looks like. Escalations are batched and distributed within 48 hours of intake. Each escalation has a clear SLA tied to the DDQ deadline. The SME sees a ticket with a proposed answer they can approve, edit, or reject — they’re not writing from scratch. The proposal manager runs a daily standup on open escalations until the queue clears.

Stage 5 — Review & sign-off

What it is. The drafted, escalated, and consolidated DDQ runs through a structured review before submission.

Why InfoSec is the bottleneck. In most enterprises, the InfoSec team is the long pole. Security is 40-60% of a DDQ. The InfoSec reviewer has a day job that doesn’t pause for the DDQ. They review by exception — they look at flagged answers, not at every answer.

This means the review tooling matters. A review UI that surfaces only the changed-since-last-time answers, the low-confidence answers, and the escalated answers compresses InfoSec’s review time. A review UI that asks them to read the whole questionnaire from the top burns review hours that don’t exist.

The 3-signer pattern. Every DDQ goes through three signers:

Author / lead writer. Confirms the draft is internally consistent and matches the KB.
Compliance reviewer. Confirms the answers don’t promise things the company can’t deliver. This is the InfoSec lead for security questions, the legal lead for privacy questions, etc.
Signing officer. A senior leader (usually the CISO, COO, or General Counsel) who attests on behalf of the company. This is a literal signature in many DDQs.

Each signer has a different concern and a different review surface. The author reads for accuracy. The compliance reviewer reads for risk. The signing officer reads for liability. A single review pass that conflates them ships answers that none of the three would have signed off on individually.

Compressing the cycle. Three things that consistently compress the review cycle:

Pre-flag the high-risk answers. The author marks any answer that creates a contractual commitment, names a specific number, or describes a process not yet fully implemented. Compliance reviewer reads pre-flagged first.

Use diffs against the previous DDQ. For repeat buyers, the previous DDQ’s answers are the baseline. The reviewer reads only the diffs.

Lock answers as they’re approved. An answer that’s been signed off doesn’t get re-edited unless explicitly reopened. This prevents the late-stage “well I changed this” problem that creates last-minute review work.

What goes wrong. Review is compressed into the last 48 hours and becomes a rubber-stamp. Or review surfaces issues that don’t get fixed because the deadline has arrived. Or review happens but the signing officer doesn’t actually read the document because they didn’t get it until the morning of submission.

What good looks like. Each signer has a calendared review block. The questionnaire arrives in the signer’s inbox at the agreed time, with the relevant slice highlighted. Sign-offs are tracked and visible. The submission can’t be released until all three signatures are recorded.

Stage 6 — Submission

What it is. Sending the answered questionnaire back to the buyer.

Portal gotchas. Different buyers use different portals — OneTrust, Whistic, ProcessUnity, Vendr, Vanta’s vendor product, custom GRC tools — and each has its own quirks. Common failure modes:

File-naming requirements. Some portals reject uploads if the filename doesn’t match a specific pattern.
Format requirements. Some portals require the response in a specific format (XLSX with a specific schema, JSON with a specific structure, PDF with embedded form fields).
Attachment limits. Some portals cap the number or size of attachments. A team that planned to upload SOC 2, ISO certificates, insurance certificates, and a parent-company letter discovers at submission time that the portal allows three.
Single-shot submission. Some portals don’t allow edits after submission. A typo at 11:58 PM is a typo.
Time-zone discrepancies. A deadline of 5 PM “buyer time” with no time zone specified is a recurring trap.

File naming. The convention that travels best across portals: [VendorName]_[BuyerName]_[QuestionnaireType]_[Date].pdf. Some portals will accept it as-is. Others will reject it; their rejection message tells you the format they want. Read the portal’s instructions before the day of submission.

What gets rejected. Submissions get rejected for:

Wrong format (XLSX when the buyer wanted PDF).
Missing attachments (the SOC 2 wasn’t included).
Unsigned cover letter (some buyers require a signed transmittal).
Late submission (one minute past the deadline is late).

What good looks like. Submission is a checklist run on Day 13 (with the deadline on Day 14). The checklist includes a sandbox upload to confirm the portal accepts the file. The actual submission happens at least 4 hours before the deadline. A submission log records the time, the upload confirmation, and the screenshot of the success message.

Stage 7 — Post-mortem write-back

What it is. After the DDQ is submitted, the team updates the KB with what changed.

Why this is the compounding stage. This is the stage that makes the same DDQ next year take half the time. Without it, every DDQ starts from where the last one left off, plus or minus a few cleanup tasks. With it, every DDQ leaves the KB in better shape than it found it.

The write-back is not optional. It is the entire reason the playbook works.

What gets written back.

New answers. Questions the buyer asked that weren’t in the KB. The drafted-and-approved answer becomes a new KB block, classified, dated, owned.

Updated answers. Questions where the existing KB block had stale content (a SOC report from a previous period, an outdated retention policy). The block gets a new version with the current content.

Deprecated answers. Answers that were technically still in the KB but were superseded by something newer. Demote or archive.

New evidence attachments. The buyer asked for a new piece of supporting documentation that the team had to create. Add it to the KB so it’s available for the next questionnaire.

Promoting and demoting blocks. A block that gets used 8 times across questionnaires in a quarter is a high-confidence block. A block that gets used once and then is overwritten by a fresh drafter without reference to the existing block is a low-confidence block. The KB tracks usage. High-confidence blocks rank up in retrieval; low-confidence blocks get flagged for review.

The quarterly content-health sweep. Every quarter, the KB owner runs a sweep:

Find blocks that haven’t been touched in 90 days but reference time-sensitive facts (SOC reports, insurance certificates, audit periods).
Find blocks that are duplicates or near-duplicates of newer blocks.
Find blocks that contradict each other.
Find clusters of questions that don’t have a KB answer yet but are coming up repeatedly.

The sweep is calendared. It does not happen by exception.

What goes wrong. Post-mortems don’t happen. The team submits the questionnaire and moves to the next one. Six months later, a new drafter starts a new questionnaire and finds the same KB they would have found before — minus the work the previous team did, which was never written back. This is the failure mode the eight-stage RFP pipeline post names as the difference between compounding teams and non-compounding teams.

What good looks like. Post-mortem is a one-hour task on Day 15, the day after submission. The KB owner walks through the answered questionnaire, flags blocks for promote / demote / update / new, and assigns the actions. The actions close within 14 days. The next questionnaire from any buyer benefits from the work.

The compounding claim

A DDQ from Buyer X this year takes 30 hours. The same DDQ from the same Buyer X next year should take 15. The pattern is mechanical:

Stage 1 (intake) — same time. The format hasn’t changed.
Stage 2 (retrieval) — faster. The KB now has answers tuned to this buyer’s questions.
Stage 3 (drafting) — significantly faster. Most answers are pre-drafted.
Stage 4 (escalation) — far fewer escalations. The KB covers more.
Stage 5 (review) — diff-based, much faster.
Stage 6 (submission) — same time.
Stage 7 (post-mortem) — same time, but with less to write back because less changed.

The savings stack in stages 2-5. They depend entirely on stage 7 having happened the previous year. A team that does stages 1-6 well and skips 7 is on a treadmill. A team that does 1-7 is on a flywheel.

This is the entire reason the playbook is end-to-end. Cutting any stage breaks the compounding. The playbook is the discipline that makes the second DDQ from the same buyer cost half what the first one did.

The category’s incumbents will tell you they help with stages 2 and 3. The truth is stages 1, 4, 5, 6, and 7 are where most of the work and most of the avoidable rework live. A DDQ workflow that doesn’t put structure on all seven is a workflow that ships the same answer twice and forgets where it lives.

Stages 2 and 3 are where AI helps most directly. Stages 1 and 7 are where the team’s discipline has to do the work. Stages 4, 5, and 6 are where the workflow tooling earns its keep. Each stage is a different kind of investment, and each one has to land for the playbook to work.