DDQ Anatomy, Part 2 of 4: legal and privacy

A due diligence questionnaire (DDQ) is a procurement instrument that asks a vendor to disclose how it operates before the buyer signs anything. The legal and privacy section is the part everyone underestimates, because the questions look like checkboxes and they aren’t.

In Part 1 of this series I walked through the structure of a DDQ and the four sections that almost always appear: corporate, legal and privacy, security, and operations. This post is the second section. The next two cover security (Part 3) and operations and vendor management (Part 4).

What the section is for

Legal and privacy is where the buyer’s counsel asks two things in 45 different ways: can we contract with you under the laws that apply to our business, and will your handling of our data put us in violation of those laws. Every question maps back to one of those two intents.

If you read the section that way, the 45 questions stop looking like 45 things and start looking like five clusters with variants:

Corporate authority and standing — who can sign, jurisdiction of incorporation, current litigation, regulatory actions.
Data processing posture — controller vs. processor role, sub-processors, data residency, transfer mechanisms.
Data subject rights — DSAR handling, retention windows, deletion guarantees, breach notification timelines.
Regulatory mapping — GDPR articles applied, CCPA / CPRA applicability, HIPAA BAA availability, sector-specific rules (FERPA, GLBA, PCI-DSS).
Contractual artifacts — DPA template, standard contractual clauses, transfer impact assessments, audit rights.

Most DDQs ask roughly nine questions per cluster. The exact wording varies; the substance doesn’t.

The questions that always repeat

Here are 12 patterns I’ve seen in essentially every legal and privacy section I’ve responded to. Naming them is half the work — once you have a named answer in your KB, the next DDQ that asks a variant of the question is a paste-and-edit, not a new draft.

Authority. “List the legal name, jurisdiction of incorporation, registered office, and authorized signatory of the entity that will be party to this agreement.” This is a fill-in-the-blank if your KB has it, a four-hour fire drill if it doesn’t.

Pending litigation. “Disclose any current or threatened litigation, regulatory action, or governmental investigation against the entity or its principals.” Buyers are not asking you to confess everything that ever happened. They are asking you to disclose what a reasonable counsel would consider material. Have a written disclosure standard.

Controller / processor designation. “Describe your role under GDPR Art. 4 with respect to the personal data processed in the course of providing the services.” Almost every B2B SaaS is a processor for customer data and a controller for end-user telemetry. State both, and which is which.

Sub-processor list. “Provide a current list of sub-processors with name, function, location, and transfer mechanism.” This list lives at a published URL on most modern vendor sites (/legal/subprocessors). If yours doesn’t, that’s the first content artifact to build.

Cross-border transfers. “What is the transfer mechanism used for personal data leaving the EEA?” Standard contractual clauses 2021 (EU SCCs) plus a transfer impact assessment is the modern answer. The 2020 Schrems II decision invalidated Privacy Shield; do not cite Privacy Shield as your mechanism.

Data residency. “Can data be pinned to a specific region?” The honest answer is binary. Either the product supports region pinning at tenancy level, or it doesn’t. Do not say “we follow data residency best practices” — buyers’ counsel reads that as a no.

Retention. “What is your default retention window for customer data, and what is your deletion guarantee on contract termination?” 30 days is the modern default. 90 is acceptable. 12 months without justification reads as poor data hygiene.

Breach notification. “What is your notification timeline upon discovery of a personal data breach?” 72 hours mirrors GDPR Art. 33. Sub-72-hour commitments to enterprise customers are increasingly standard; 24 hours is becoming the asked-for floor.

DSAR handling. “Describe your process for responding to a data subject access request received via the customer.” Most B2B vendors route DSARs through the customer (the controller). State that. Then describe the technical mechanism by which you produce the data.

HIPAA / BAA. “Are you willing to sign a Business Associate Agreement?” Either yes (and here is the template) or no. There is no third option for healthcare buyers.

Audit rights. “Will you accept onsite audits, document audits, or pooled-audit arrangements?” Most modern vendors accept SOC 2 Type II as the audit substitute and decline onsite audits below a certain ACV threshold. Be explicit.

DPA template. “Provide your standard data processing addendum.” Have one. Have it published. The third time you negotiate a custom DPA from scratch, you will wish you had been a vendor with a published default.

That is 12 of the 45. The remaining 33 are variants of these — a different industry will probe HIPAA harder, a European buyer will probe SCCs harder, a regulated buyer will probe sub-processor transfers harder. The clusters are stable.

Where the section breaks for vendors

Three failure modes recur.

The DPA is in a Google Doc. A non-trivial number of vendors I’ve worked with do not have a current, published DPA. The DDQ asks for it; the vendor sends a four-page Word doc that someone wrote in 2022. Buyer counsel reads that as a maturity signal, not a legal artifact, and the response goes back asking for an updated template. The lost week is on you.

Sub-processor list is stale. A vendor’s sub-processors page lists eight services. Three of them were deprecated last quarter. Two new ones were added but the page wasn’t updated. Buyer counsel runs a check against current job postings and infrastructure references and discovers the discrepancy. The trust is gone before you’ve answered question 13.

Breach notification commits to faster than you can deliver. A sales-led answer says “24-hour notification on any breach.” Operationally the vendor cannot detect, classify, and notify in 24 hours. The first real incident is the one that exposes the gap and triggers contractual remedies. Commit to what you can ship. If your runbook says 72 hours, the answer is 72 hours.

What good looks like

A vendor that takes legal and privacy seriously has, on the public site:

A current DPA template at a stable URL.
A current sub-processors list, with a feed or webhook that buyers can subscribe to.
A privacy policy that is current within the last 12 months.
A trust page that names the current state of GDPR posture, US state-privacy posture (CCPA, CPRA, VCDPA, CPA, CTDPA), HIPAA availability, and breach notification commitments.

Internally, the same vendor has:

A KB block per question pattern from the 12 above, versioned and owned by counsel.
A standing review every 90 days of the DDQ-relevant content blocks against current law and current product state.
A named individual responsible for the DPA. The DPA does not “live with legal.” The DPA lives with a person.

When a DDQ lands and the legal and privacy section gets routed to you, the first 12 questions answer themselves from the KB. The remaining 33 are the same questions with new wording — pattern-match, paste, adjust the proper noun, ship.

The honest part

You will still hand-write some answers. A DDQ from a regulated buyer will ask something specific you have not seen before — a state-level rule, a sectoral certification, a clause from their own template that doesn’t map to anything you’ve published. That work will not go away. The point of a well-built KB and a named owner per question pattern is to compress the rote 45 to a few hours so you have your day Friday to handwrite the actual hard ones.

Part 3 lands next week and covers the security section — 60 questions, mostly SOC 2-shaped, where the failure modes are different.