The Security Audit Questions Your Vendor Won't Think to Ask

Every vendor security audit follows the same script. The vendor submits a completed questionnaire. Your team reviews it. The boxes are checked. The risk register is updated. The vendor is approved. Six months later, a breach occurs through that vendor's API integration — and the post-mortem reveals that the questionnaire asked the wrong questions entirely.

This is not a failure of process. It's a failure of imagination. Security questionnaires are designed to confirm compliance with known frameworks. They are not designed to surface the specific, contextual risks introduced by how this vendor integrates with your environment. The gap between those two things is where most vendor-related security incidents originate.

The Questions Standard Questionnaires Don't Ask

Standard vendor security questionnaires — whether based on SIG Lite, CAIQ, or a homegrown template — tend to ask variations of the same questions: Do you have a SOC 2 Type II? Do you encrypt data at rest and in transit? Do you have a vulnerability management program? Do you conduct annual penetration testing?

These are necessary questions. They are not sufficient ones. Here are the questions your vendor won't think to answer — and that most security teams won't think to ask:

1. What does your blast radius look like if your environment is compromised? Not "what security controls do you have" — but "if an attacker gained access to your systems, what of ours could they reach, and how quickly?" Map the integration points. Understand the data flows. Most vendors haven't thought through this scenario at the integration level. Their answer will tell you more about their security maturity than any certification.

2. Who in your organization has access to our data, and under what circumstances? SOC 2 confirms that access controls exist. It doesn't tell you that three offshore contractors with admin access to the production database are technically employees of a subcontractor two levels removed from the contract you signed. Ask for a specific enumeration of personnel with access to your data — including subcontractors and their subcontractors.

3. What is your mean time to patch critical CVEs, and can you show the last six months of data? Every vendor claims to have a vulnerability management program. Almost none can show you their actual patching velocity against CVSS 9.0+ vulnerabilities. Request the data. The gap between policy and practice is the risk.

4. How would you notify us of a breach, and how quickly? Not "do you have an incident response plan" — but "walk me through the specific communication chain that ends with my security team being notified." Who calls whom? What's the SLA for notification? What's the threshold for escalation? Vendors who haven't rehearsed this will give you a vague answer. Vague answers in a breach scenario cost you the notification window that determines your regulatory exposure.

5. What data do you retain after our contract ends, and for how long? Data retention post-contract is one of the most consistently underspecified areas in vendor agreements. Your data doesn't disappear when you offboard. Backup retention policies, compliance archive requirements, and subprocessor data flows all create persistence that outlasts the relationship. Know what stays, where it stays, and who can access it.

6. Have you ever had a security incident involving a customer's data? If yes, describe it. This question is almost never asked directly. Vendors are not legally required to disclose incidents that weren't reportable under applicable regulations — and many incidents fall below that threshold while still being materially relevant to your risk assessment. A vendor who has had a minor incident, handled it well, and learned from it is less risky than a vendor who has never had an incident and therefore has never tested their response capability.

7. What are your subprocessors, and what security requirements do you impose on them? Your vendor's SOC 2 covers your vendor. It does not cover the analytics platform they pipe your data through, the infrastructure monitoring tool that has read access to their production environment, or the offshore development team that has access to the staging environment containing a copy of production data. Map the full subprocessor chain. Require evidence of equivalent security standards.

8. What would a sophisticated attacker target in your environment to reach ours? This is the adversarial thinking question. It requires the vendor to reason from an attacker's perspective rather than a compliance checklist. Vendors with mature security programs will be able to answer this specifically. Vendors who haven't done threat modeling will be unable to answer it at all — which is itself the answer you needed.

A Synthesized and Logikal Process That Works

Effective vendor security assessment isn't a questionnaire review. It's a structured conversation that combines the questionnaire with technical validation and relationship-level accountability.

Technical validation means verifying, not just accepting. Request evidence for critical claims: penetration test executive summaries (not just confirmation that testing occurred), vulnerability scan results from the last 90 days, access logs showing who accessed your data and when. Vendors who can't or won't provide this evidence have answered the question.

Relationship-level accountability means having a named, accessible security contact at the vendor — not a generic security inbox. It means establishing the communication protocol before an incident occurs. It means annual reviews that revisit the integration architecture as both environments evolve.

Contractual specificity means ensuring the agreement captures what the questionnaire revealed: specific data retention limits, specific subprocessor restrictions, specific breach notification timelines, and specific remediation SLAs for high-severity vulnerabilities affecting your data.

The Risk You're Actually Managing

Third-party and fourth-party vendor risk is consistently among the top sources of enterprise security incidents. The 2024 Verizon Data Breach Investigations Report found that 15% of breaches involved a third party — up from 9% the prior year. The SolarWinds breach, the MOVEit vulnerability, the Okta support system compromise — each demonstrated that sophisticated attackers have learned that the fastest path to a well-defended enterprise is through a less-defended vendor.

The questionnaire didn't catch any of those. It never does. What catches them — before they become incidents — is asking the questions that go beyond the framework, understanding the actual integration architecture, and maintaining the relationship accountability that turns a vendor audit from an annual checkbox into a continuous risk partnership.

Your vendor's security is now your security. Ownership is inherited. The audit chain is multi-directional.