DDQ Anatomy, Part 3 of 4: the security section

The security section of a vendor due diligence questionnaire is the longest section of the longest document procurement will send you. It runs 60 questions in a typical mid-market DDQ and 200-plus in a regulated-buyer security questionnaire. Safe Security has reported that enterprise security teams now process 500-plus questionnaires per year, with one engineer describing a year of doing essentially nothing else.

This is Part 3 of 4 in the DDQ Anatomy series. Part 1 framed the four sections; Part 2 covered legal and privacy. Part 4 closes with operations and vendor management.

What the section is for

A buyer’s security team reads the section to answer one question: can your operating posture pass the same controls our auditor holds us to. Every question is a probe against that. The probes cluster.

1. Certifications and audits. SOC 2 Type I/II, ISO 27001, PCI-DSS where relevant, FedRAMP for federal-adjacent buyers, HITRUST in healthcare.
2. Encryption. At rest, in transit, key management, BYOK availability.
3. Access control. Identity provider integration, SSO, MFA, role-based access, least-privilege internal controls.
4. Vulnerability management. Penetration tests, scan cadence, patch SLAs, bug bounty.
5. Incident response. Detection capability, response runbook, notification commitments, post-incident reporting.
6. Physical and personnel security. Datacenter posture (or cloud equivalent), background checks, security training.
7. Business continuity / disaster recovery. RTO, RPO, backup testing cadence, regional failover.
8. Application security. SDLC controls, code review, dependency scanning, third-party library posture.

Eight clusters. Roughly seven to eight questions per cluster. The exact wording varies; the substance doesn’t.

The 12 questions you will see in essentially every security DDQ

Naming the patterns first. A KB block per pattern is the ROI here.

SOC 2 Type II report. “Provide your most recent SOC 2 Type II report under NDA.” Have one. Have it under a current cover date. A SOC 2 letter that is 14 months old reads as expired even if the audit window technically still applies.

Encryption at rest. “What algorithm and key length protects data at rest, and where is the key stored?” AES-256 is the modern default. State the algorithm, the key length, the KMS provider, and whether keys are customer-managed.

Encryption in transit. “What protocol is required for traffic to your service?” TLS 1.2 minimum, 1.3 preferred. State the certificate authority chain. State whether older protocols are deprecated and as of when.

BYOK / customer-managed keys. “Do you support customer-managed encryption keys?” Either yes (and here are the integrations — AWS KMS, Azure Key Vault, GCP KMS) or not yet (and here is the roadmap commitment). “We are exploring” is not an answer.

SSO and identity provider integration. “List supported identity providers and the SAML/OIDC features you support.” Okta, Azure AD, Google Workspace, generic SAML 2.0, SCIM provisioning. Be explicit.

Multi-factor authentication. “Is MFA available, required, enforceable per-tenant?” The modern enterprise answer is yes, yes, and yes — with WebAuthn / FIDO2 support a meaningful differentiator.

Role-based access control internal to the vendor. “What’s your internal least-privilege model for support engineers accessing customer data?” This question is asked because most vendors fail it. Have a written answer that names the access tier, the time-bounded approval flow, the audit log, and how a customer can review accesses against their tenant.

Penetration test. “Provide your most recent third-party penetration test report under NDA, and describe remediation status.” Annual minimum. The remediation status portion is non-optional — a current pen-test that lists open findings and no remediation tracker reads worse than no pen-test.

Vulnerability scan cadence. “What is your scan cadence for application, container, and infrastructure layers?” Continuous container, weekly infrastructure, in-CI dependency scanning are the modern defaults.

Incident response runbook. “Describe your incident detection, escalation, and notification process.” A runbook with named roles, defined severity tiers, and time-bounded notification commitments per tier. Generic answers (“we have an incident response process”) get rejected.

Notification timeline on a security incident affecting customer data. “Within how many hours of confirmed incident will customers be notified?” 72 mirrors GDPR; 24 is the modern enterprise asked-for floor; sub-24 is increasingly asked but operationally rare to deliver. Commit to what you can deliver.

Backup and disaster recovery testing. “What is your RTO, RPO, and backup-restore test cadence?” RTO and RPO must be specific time durations. A vendor that answers “backups are tested regularly” fails this question.

That’s 12. The remaining 48 are variants — different industries probe pen-test results harder, different buyers probe key-management sovereignty harder, different sectors probe BCP/DR harder. The patterns hold.

Where the section breaks for vendors

Three failure modes recur.

Sales-led answers that promise more than ops can deliver. The most common. Sales sees “24-hour incident notification” and writes back “yes, 24 hours.” The vendor’s actual runbook says 72. The first real incident reveals the gap, and the gap becomes a contractual remedy. Commit to the runbook number. If the runbook number is too slow for the buyer, that is a roadmap conversation, not a DDQ answer.

Stale evidence artifacts. A SOC 2 letter from 14 months ago. A pen-test report from 2024. An ISO certificate that lapsed. The KB has the document; nobody updated it; the DDQ ships it. The buyer’s security team checks the cover date and rejects on the spot. Have a 90-day review cadence on every evidence artifact in the security KB.

Generic answers that read as evasive. “We follow industry-standard practices” is an answer that says nothing. The buyer’s security team reads it as a no. Be specific. “All customer data is encrypted at rest with AES-256 in CBC mode using customer-isolated keys managed in AWS KMS, with key rotation enforced every 90 days” takes ten more seconds to write and tells the truth.

What good looks like

A vendor that takes the security section seriously has, on the public site or behind a clickwrap NDA portal:

• A current SOC 2 Type II report.
• A current pen-test report with remediation tracker.
• An ISO 27001 or HITRUST certificate where relevant.
• A trust page that names the encryption posture, identity-provider integrations, MFA model, BYOK availability, RTO/RPO, and incident response commitment.

Internally, the same vendor has:

• A KB block per question pattern from the 12 above.
• A 90-day review cadence on every evidence artifact, owned by a named individual.
• A standing weekly check that the answers shipped on outbound DDQs match the current operational state, not last quarter’s state.
• A red-line process where any sales-side answer to a security question requires a second pair of eyes from security ops before the response goes out.

The 60 questions become a 90-minute pass instead of a three-day grind, and the ones you spend the 90 minutes on are the ones that matter — the buyer-specific corner cases that don’t pattern-match.

The honest part

The security section is the section where the temptation to over-promise is highest, because security buyers will reject vendors whose posture is genuinely behind the asked-for floor. There is a difference between describing your current posture honestly and over-promising; the second one is what kills the deal six months later when the first incident hits. Don’t over-promise. Build the posture. Update the evidence. Then write the answer once and reuse it.

Part 4 covers operations and vendor management — incident response from the operational side, BCP/DR drills, vendor risk management, the questions that close the DDQ.