Questionnaires Don't Stop Breaches: Why Third-Party Vetting Is Failing Enterprise Security

There is a particular kind of institutional confidence that builds when a vendor returns a completed risk questionnaire. Boxes are checked. Attestations are signed. Scores are logged. The third party is cleared, onboarded, and granted access to systems that touch your most sensitive data — and the security team moves on to the next item in the queue.

That confidence is often misplaced. Some of the most consequential enterprise breaches of the past decade originated with vendors who passed every standard vetting checkpoint. The 2013 Target breach, traced to an HVAC contractor with legitimate network credentials, remains the canonical example. But the pattern has repeated itself across industries with alarming consistency: a trusted third party, properly vetted on paper, becomes the entry point for an attack that no questionnaire was designed to prevent.

Understanding why this keeps happening requires an honest examination of what third-party risk assessments actually measure — and what they systematically fail to reveal.

The Illusion of Due Diligence

Most enterprise vendor assessments are built around standardized frameworks: SIG questionnaires, CAIQ forms, NIST-aligned checklists, and SOC 2 report reviews. These tools serve a legitimate purpose. They establish a common language for discussing security posture and create documented evidence of due diligence — evidence that regulators and auditors recognize and reward.

The problem is that documentation is not the same as security. A vendor can truthfully answer every question on a SIG questionnaire and still maintain a network environment riddled with unpatched systems, misconfigured access controls, and shadow IT assets that no one in their organization has mapped. The questionnaire asks about policies. It cannot ask about what happens when those policies are not followed on a Tuesday afternoon in a regional office.

Standardized frameworks are also, by definition, known quantities. Vendors who complete assessments regularly — particularly large managed service providers and SaaS platforms that serve hundreds of enterprise clients — develop institutional fluency with these forms. Their responses become polished and consistent. Whether that polish reflects genuine security maturity or practiced document management is a question the questionnaire cannot answer.

Why Self-Reporting Is a Structural Flaw

The foundational assumption embedded in most third-party risk programs is that vendors will accurately represent their own security posture. This assumption is not cynically wrong — most vendor security teams are not deliberately falsifying responses. But it is naively optimistic in ways that create real exposure.

Vendors assess themselves against criteria they may not fully understand. A small software development firm that integrates with your financial systems may lack the internal expertise to accurately evaluate whether their development pipeline meets your standards. Their self-assessment reflects their own frame of reference, not yours. Gaps they have never identified cannot appear in a response they genuinely believe is accurate.

There is also the matter of incentive. Vendors have a commercial interest in passing your assessment. When a question is ambiguous — and many are — the natural tendency is to interpret it in the most favorable light. This is not dishonesty. It is human nature operating within a system that invites generous self-interpretation.

The result is a dataset that reflects how vendors perceive and present their security posture, not what their security posture actually is. Decisions made from that dataset carry risk that is invisible on the scorecard.

The Access Problem: What Happens After Onboarding

Even when a vendor's security posture is accurately assessed at the point of onboarding, that posture changes. Staff turns over. Systems are updated — or not updated when they should be. Business pressures lead to security shortcuts. Vendors acquire smaller companies with unknown risk profiles. The clean snapshot captured during initial vetting degrades over time, often without any corresponding reassessment.

Enterprise security teams frequently operate on annual or biennial reassessment cycles. A vendor who was genuinely well-secured eighteen months ago may be operating with a critical vulnerability today. The access they were granted based on that earlier assessment remains in place, and the enterprise has no visibility into the change.

This temporal gap is one of the most underappreciated dimensions of third-party risk. Access management and risk assessment are often treated as separate workflows when they need to function as a continuous, integrated process.

Building a Vetting Framework That Reflects Operational Reality

Moving beyond checkbox compliance requires a shift in philosophy — from assessing what vendors claim to observing what vendors do. Several operational adjustments make this possible at enterprise scale.

Prioritize evidence over attestation. Where possible, replace or supplement self-reported responses with verifiable artifacts. Penetration test reports from qualified third parties, actual configuration exports, and live demonstrations of security controls provide a materially different quality of information than a checked box. Not every vendor relationship warrants this level of scrutiny, but your highest-risk integrations — those with access to sensitive data, privileged network segments, or critical infrastructure — should require it.

Conduct continuous monitoring, not periodic snapshots. Automated external attack surface monitoring tools can provide ongoing visibility into a vendor's internet-facing posture without requiring vendor cooperation. Changes in exposed ports, certificate anomalies, and newly discovered subdomains can signal security degradation between formal assessment cycles. This is not a replacement for structured assessment; it is an early warning layer that makes your program dynamic rather than static.

Tier your vendor population by actual risk, not perceived importance. Many enterprises apply their most rigorous assessments to their largest vendors — the major cloud providers, the well-known SaaS platforms — while applying lighter scrutiny to smaller, less prominent integrations. Threat actors have noticed this pattern. A boutique software vendor with deep API access to your core systems may present substantially more risk than a Fortune 500 provider with a mature security program. Risk tiering should be driven by access scope and data sensitivity, not vendor size or brand recognition.

Build behavioral indicators into your ongoing relationship. How a vendor responds to your security inquiries is itself a data point. Vendors who push back on reasonable requests for documentation, who take extended periods to respond to security questionnaires, or who are unable to produce evidence of basic controls are signaling something about their operational culture. Formal assessment frameworks rarely capture this texture. Relationship managers and procurement teams need to be trained to surface and escalate these signals.

Require contractual notification of material security changes. Vendors should be contractually obligated to notify your security team of significant changes to their environment — major infrastructure migrations, acquisitions, significant personnel changes in security leadership, or known incidents affecting their systems. This does not guarantee compliance, but it establishes accountability and creates a documented basis for reassessment when changes occur.

Accepting the Limits of Any Assessment Framework

No vetting process, however rigorous, eliminates third-party risk. The goal is not a false certainty that mirrors the false certainty generated by checkbox compliance — it is a more accurate and current understanding of where exposure exists so that risk decisions can be made deliberately.

Enterprise security programs that acknowledge this limitation invest not only in vendor assessment but in containment architecture: network segmentation that limits what a compromised vendor can reach, privileged access management that constrains what credentials a third party can use, and monitoring capabilities that detect anomalous behavior originating from vendor-associated accounts.

The questionnaire is a starting point, not a safeguard. Treating it as the latter is how enterprises continue to be surprised by partners they believed they understood.