Questionnaire-Based TPRM Programs and Their Measurement Failures
Questionnaires measure compliance work, not the vendor risk that actually matters.
Questionnaire-based third-party risk management programs have problems with what they measure as well as how they carry out the work. Their primary outputs show how much assessment work a team has completed. Effective TPRM therefore requires a change in what counts as evidence, from completed forms to ongoing information about vendor behavior, control performance, and the exposure created by each relationship.
Why questionnaire-based TPRM programs are built around the wrong output
An activity measure shows how much work was done, while a risk measure shows the exposure and the controls that limit it. Questionnaire completion belongs to the first category, even when it appears on a risk dashboard. Most TPRM programs were designed to document compliance rather than prevent or detect risk, so their workflows naturally produce evidence that a process was followed. The completed form is the deliverable around which the work is organized. Evidence of actual vendor behavior and control performance is a different output, which the form alone cannot supply.
ISACA's 2026 analysis states that questionnaires and point-in-time audits “create the appearance of due diligence.” That distinction limits what questionnaire results can establish. A completed questionnaire can document a vendor's representations without demonstrating that its controls work. Yet completion rates and response volumes become the default measures of performance because they are readily available from the process. Better scores on those measures help teams get documentation done with less effort, but may not help them manage risk any better.
What a questionnaire actually measures versus what it claims to measure
A questionnaire captures a vendor's description of its controls at a single moment. It does not establish whether those controls are enforced or how well they protect the organization's data. Self-reporting creates the first gap because the vendor chooses what to disclose. Generic yes/no questions reinforce that gap by rewarding an affirmative answer. RiskRecon's 2026 guide distinguishes between asking whether controls exist and determining whether they actually protect data.
Time creates a separate limitation, even when every response is accurate. The completed questionnaire begins to go stale as the vendor's environment changes between reviews. ISACA's 2026 analysis identifies expanding use cases without reassessment, downstream vendors and data path changes, and continuous deployment and control drift as sources of that volatility. An accurate statement at assessment time cannot establish the state of those conditions later.
Context creates the third gap because a vendor's general security posture is not the same as the risk of a particular relationship. ISACA's example contrasts a marketing analytics platform storing anonymized data with the same platform handling regulated PII that feeds executive reporting. The platform is the same, but the exposure is not. A standard questionnaire treats both uses identically, leaving the assessment detached from the data and business processes that make the relationship consequential.
How scale turns a measurement problem into an operational breakdown
Across hundreds of vendor relationships, these limits become an allocation problem as well as a measurement problem. Teams must send questionnaires, track progress, chase responses, and keep track of what is still waiting before they can make sense of the answers. RiskRecon's 2026 guide describes teams that spend more time chasing responses than analyzing risk once they have hundreds or thousands of vendors. The operational consequence is visible in assessment duration, with 64% of large organizations reporting cycles longer than four months. That delay widens the distance between the conditions a response describes and the conditions under which the assessment is used.
Volume also weakens the input on the vendor side. Vendors with large numbers of questionnaires to fill out rush and use copy-and-paste responses that can look thorough without showing their actual security posture. RiskRecon's 2026 guide describes this as “questionnaire fatigue,” which leaves teams with incomplete information. Meanwhile, applying the same broad questionnaire regardless of criticality consumes capacity on low-risk vendors while leaving insufficient analytical depth for critical relationships. More completed assessments can therefore coexist with less attention to the exposures that matter most.
Fourth-party dependencies make that uneven coverage especially dangerous. A vendor may introduce new sub-processors, change cloud infrastructure, or reroute data without a questionnaire-based program learning about it until the next annual cycle, if then. Several vendors that have been assessed may also rely on the same underlying service, which creates concentration risk that forms for each vendor do not show well. An outage at that shared provider could affect multiple business processes simultaneously. The program can then report that it covers a wide range of vendors even as the links between them stay hidden, giving teams more confidence than the evidence supports.
The false-confidence loop that keeps failing programs in place
Completion rates, response volumes, and vendor counts are easy to report upward because they are concrete outputs of the workflow. They also resemble evidence of control, particularly when supported by standardized assessments, defined procedures, and formal governance. Those features can demonstrate process discipline, but they do not distinguish documentation from risk reduction. A program can become more orderly without becoming more informative about supplier exposure.
This loop can keep reinforcing itself even when the people doing the work make sound decisions. If leadership evaluates the program through completed assessments, improving completion is a rational operational priority. Auditors and regulators have historically reinforced that priority by accepting documentation as evidence of due diligence. The resulting audit trail validates the process, while the process continues to produce the same kinds of evidence. ISACA's 2026 analysis raises a question that is rarely asked within this loop, whether TPRM works as risk management or risk documentation.
Recurring third-party breaches expose the weakness of treating those functions as equivalent. Third-party vendors were the origin point of 35.5% of data breaches in 2024. That figure shows why a team's confidence alone is too weak a test of how well its program works. External requirements are now making that distinction harder to leave unresolved.
Where regulatory frameworks are exposing the questionnaire model's limits
DORA, which came into full force across EU financial services in January 2025, requires more than a record of vendor answers. Firms must maintain formal ICT risk frameworks and oversee all ICT third-party providers through proportionate structured programmes. Providers that support critical or important functions must be watched more closely. Firms must also keep a complete Register of Information that covers every contractual arrangement for ICT services from ICT third-party service providers. That scope requires an account of contractual relationships.
The contractual requirements deepen the distinction between documentation and operational control. DORA requires provisions including data location, audit rights, exit clauses, and incident notification timelines. It also requires incident reporting and formal controls for concentration risk. An annual questionnaire can collect statements relevant to these duties, but it cannot by itself perform the oversight or maintain the continuing evidence they demand. A documentation-first design therefore creates regulatory exposure as well as an incomplete risk picture.
Other frameworks push in the same direction, though their requirements differ. SOC 2 CC9.2, ISO 27001 Annex A.5 controls 5.19–5.22, and NIST CSF require identification and ongoing assessment of vendor risks. NIST CSF 2.0 added a Govern function of its own, with supply chain risk management as a category within it. The shared direction is toward continuous, evidence-based oversight rather than acceptance of a completed assessment as the endpoint. Programs built for an earlier regulatory environment cannot close that structural gap by increasing questionnaire throughput.
Non-human identities as the fastest-growing vendor risk surface questionnaires have no architecture to assess
Non-human identities show what these measures miss because a general description of vendor controls cannot fully show the access these identities have. Service accounts, API keys, OAuth tokens, machine certificates, and AI agent credentials substantially outnumber human users in typical enterprise environments, with a still higher ratio in cloud-native environments. These identities make up a large third-party attack surface that goes unreviewed as a matter of course. Standard questionnaires do not ask about them, and vendors themselves often cannot fully inventory them. The missing evidence concerns the actual connections and permissions through which exposure exists.
The provisioning model adds a governance problem distinct from earlier credential risks. Traditional service accounts required engineering review, but an employee can increasingly connect an AI agent to a SaaS tool through OAuth just by clicking through a consent screen. ISACA's 2026 analysis identifies the proliferation of AI vendors as a pressure that could dramatically increase TPRM overwhelm. Non-human identity exposure grows with that proliferation, without a corresponding mechanism in the questionnaire process to observe it.
The Salesloft-Drift incident, spanning March–September 2025, illustrates the consequences. Attackers compromised Salesloft's GitHub account, pivoted into the AWS environment of its Drift chatbot product, and stole OAuth tokens used to integrate with hundreds of customers' Salesforce tenants and other platforms. Those tokens were long-lived, over-scoped, and unrotated. Cloudflare disclosed that 104 of its API tokens were found in exfiltrated support case data and rotated as a precaution, with no suspicious activity identified against them. One vendor compromise cascaded across its customer base through token lifecycle failures that no questionnaire captured.
The OWASP Non-Human Identities Top 10 for 2025, released December 2024, formalizes the broader category through its Vulnerable Third-Party NHI entry. It covers compromised third-party NHIs associated with integrations such as IDE extensions, plugins, and third-party SaaS that can enable credential theft or misuse of granted permissions. A compromised SaaS-to-SaaS OAuth grant is one manifestation of that risk. Even an honestly answered questionnaire cannot establish the state of an OAuth grant inventory, token rotation, or downstream connection that the vendor cannot see. Adding a question can record the visibility gap, but it does not create a means to close it.
What a program that measures actual risk looks like instead
The alternative begins by changing the program's primary output to ongoing, audit-defensible risk intelligence. RiskRecon's 2026 guide describes five maturity stages, with the relevant transition running from documentation-first work at Stage 1–2 to real-time monitoring and defensible risk scoring at Stage 4–5. Continuous monitoring becomes the main signal, taking on a larger role than adding to the annual assessment. Its findings feed back into risk scores and contract obligations in real time. The measure of progress is then the quality of the risk picture.
That evidence must be interpreted in the context of each relationship. Vendor risk tiering should reflect how a supplier interacts with the organization's data, systems, and processes rather than rely on a generic high/medium/low category applied uniformly. Zero-touch assessment for genuinely low-risk vendors frees analyst capacity for relationships where human judgment adds value. This replaces the same 200-question process for every vendor with an allocation of effort that reflects exposure. Non-human identity visibility also becomes a standing component, supported by an active inventory of OAuth grants, API token lifecycle, and SaaS-to-SaaS connections that changes in real time.
DORA Article 30's mandatory provisions, including data location, audit rights, exit clauses, and incident notification timelines, must be monitored against real vendor behavior. AI-assisted programs can support this shift when they adapt to the organization's own control frameworks and learn from team decisions. Generic automation that does not adapt merely accelerates manual work, while a risk-measuring program changes what that work can establish.
