TPRM wasn't built for the world we're in now.
Third-party risk management was designed in the early 2000s for a different environment: fewer vendors, slower software cycles, stable relationships you could assess once and revisit annually.
The assumptions baked into most programs still reflect that era. Fixed review cycles. Questionnaire-based assessments. SOC 2 reports as the primary evidence. Annual reassessments regardless of what changed.Meanwhile, the vendors themselves have changed completely. They ship code weekly. They add AI capabilities and subprocessors without disclosure. They run on shared infrastructure that creates fourth- and fifth-party dependencies invisible to anyone doing a standard assessment.A vendor's risk profile can shift materially between one annual review and the next, and nothing in the traditional TPRM workflow is designed to catch it.
The result is a growing gap between the rate at which vendor risk changes and the rate at which organizations can assess it. Survey data from procurement and security leaders at Fortune 500 companies shows the operational consequences:
- 96% of organizations take more than two weeks to approve a vendor
- Half cite evidence collection as their primary bottleneck
- Only 40% learn about vendor incidents before impact
The model isn't failing because teams aren't working hard enough. It's failing because manual, periodic oversight can't keep pace with continuous change.
What was the original TPRM model built for?
TPRM programs emerged in the early 2000s, mostly in regulated industries dealing with outsourcing risk and post-SOX governance.
The core assumption was that vendors were stable. Software changed slowly. You could evaluate risk at onboarding, check back in a year, and that was fine.
Programs were built around:
Inherent risk tiering to decide how much effort to spend
Standardized questionnaires
Annual or biennial reassessments
SOC 2 reports and ISO certs as baseline evidence
For a long time, this worked. Vendor populations were smaller, dependency chains were shallow, and not much changed between review cycles.
That environment doesn't exist anymore.
Why doesn't traditional TPRM work anymore?
Software deploys weekly or daily. Cloud platforms, shared infrastructure, and AI-enabled services introduce dependencies that sit outside the direct vendor relationship and change without anyone telling you.
A vendor's risk profile can shift when they:
- Launch a new product
- Add subprocessors
- Expand data access
- Change infrastructure
- Add AI features
None of that triggers a "new vendor" flag in your system. The vendor looks the same, but the risk changed and you didn't get notified.
MOVEit showed what this looks like in practice. One vulnerable service provider dependency cascaded across thousands of organizations, many of which didn't know they were exposed.
CrowdStrike in 2024 was similar: a shared security platform update took down banks, airlines, and critical services worldwide.
Organizations can add headcount and still feel behind. The issue isn't effort. It's that you're managing modern dependencies with a playbook built for simpler vendor relationships.
How long does vendor risk assessment actually take?
Most enterprises take more than two weeks to approve a vendor, and nearly half take two months or longer.
We asked practitioners what's actually happening in their programs.
How many new or changed vendors need review each month?
46% review 10+ vendors a month; 21% review 6 to 10. Two-thirds are reviewing 6+ vendors a month. That's just the job now.
All responses: 10 or more (46%), 6 to 10 (21%), 2 to 5 (29%), and 0 or 1 (4%).
- 0 or 1 vendors4%
- 2 to 5 vendors29%
- 6 to 10 vendors21%
- 10 or more vendors46%
Source: The State of Third-Party Risk Management in the Age of AI.
How do you reassess after onboarding?
96% use fixed calendar cycles; only 36% use continuous monitoring. Almost everyone still relies on calendar-based reviews. Only a third have continuous monitoring, and even then it's usually layered on top of the annual cycle, not replacing it.
All responses: fixed calendar cycles (96%), material changes (68%), incidents (43%), continuous monitoring (36%), and ad hoc reviews (21%).
- Fixed calendar cycle96%
- Triggered by material changes68%
- Triggered by incidents43%
- Continuous monitoring36%
- Ad hoc21%
Source: The State of Third-Party Risk Management in the Age of AI. Respondents could choose more than one method, so totals exceed 100%.
How often do you learn about vendor incidents before they impact you?
Only 40% say they find out reliably before impact (often and almost always combined). Everyone else is getting surprised at least half the time.
All responses: almost always (4%), often (36%), sometimes (46%), and rarely (11%).
- Almost always4%
- Often36%
- Sometimes46%
- Rarely11%
Source: The State of Third-Party Risk Management in the Age of AI.
What is fourth-party risk in vendor management?
Fourth-party risk is the exposure created by your vendors' own vendors and shared infrastructure — dependencies invisible to a standard assessment, as seen in MOVEit and CrowdStrike.
Traditional TPRM treats vendors as independent. In practice, you're operating inside layered dependency structures that go well beyond the vendor you're assessing.
We’ve seen other data that shows over a third of breaches now involve third- or fourth-party relationships. Usually through shared platforms, not isolated vendor failures.
CrowdStrike and Snowflake both fit this pattern. Organizations got hit not because they picked bad vendors, but because they shared dependencies that failed at scale.
It's concentration risk disguised as diversification.
What we asked
When we asked what would most improve their programs, fourth-party visibility came up repeatedly:
What respondents said
"Monitoring 4th parties and proactively have alerts of impact"
"Ability to map full supply chain of a vendor to follow the data flow"
The question isn't just "is this vendor compliant?"
It's "what dependencies does this vendor introduce, and can I see them."
Why isn't a SOC 2 report enough to assess vendor risk?
SOC 2 reports are retrospective, generic, and policy-focused — they describe what was true months ago and what should happen, not what's running in a vendor's environment today.
SOC 2s, ISO certs, and questionnaires are still the default.
They're familiar, auditable, and scale reasonably well.
Limitations of SOC 2 reports
Retrospective
Tells you what was true months ago
Generic
Not specific to how you're actually using the vendor
Slow
Updated annually while systems change weekly
Policy-focused
Describes what should happen, not what's running
Industry data shows certification doesn't correlate with fewer breaches. Almost every organization has vendors who've been breached while holding current compliance reports.
What happens after an assessment?
Mostly documentation. Contractual language gets added. Sometimes access gets scoped down or a follow-up review gets scheduled. Vendors rarely get rejected outright.
One respondent put it plainly:
"We more or less turn vendors loose in the environment without real controls to prevent bad actions."
The failure isn't lack of diligence.
It's that a governance model built around static documents can't represent risk that emerges from live systems
What's the biggest bottleneck in vendor risk assessment?
Half of practitioners point to evidence collection and vendor communication as their top source of friction — more than scoping, backlog, or internal coordination combined.
What causes the most friction in vendor intake and assessment?
Half the respondents pointed at the same thing: getting documents from vendors.
- Evidence collection and vendor communication50%
- Scoping inherent risk at intake18%
- Reassessments and backlog11%
- Vendor pushback or fatigue7%
- Internal coordination4%
- Business pressure4%
Source: The State of Third-Party Risk Management in the Age of AI.
How long does approval take?
96% take more than two weeks. 43% take two months or longer.
Traditional TPRM relies on static, questionnaire-based assessments. Vendors respond to standardized questions, supporting documents are collected and mapped to controls, and the results are captured in point-in-time reports. While additional staff can help manage throughput, the underlying approach does not scale with the pace or variability of modern vendor risk.
"The biggest issue is capturing a clear use case from the requester upfront. Vendor response time is often cited as the bottleneck, but it's frequently a downstream effect of an incomplete or poorly defined use case."
"Risk decisions get fragmented across intake tickets, email threads, procurement systems, ad hoc approvals..."
The bottleneck isn't expertise. It's chasing documents, managing email threads, waiting for responses, reconciling incomplete evidence.
What do risk teams want from a TPRM platform?
When asked what would improve their programs, the answers clustered around a few themes:
Respondents didn’t ask for more controls or heavier governance.
They want systems that do the work so they can focus on decisions.
What does a modern TPRM operating model look like?
Principles
Evidence-first
Evidence supports decisions, doesn't replace them
Intake-led scoping
Risk assessed based on use case, data access, and dependencies
Trigger-based reassessment
Changes drive reviews, not calendars
Dependency awareness
Fourth-party and shared infrastructure risks are explicit
Human judgment with system support
Automation handles the noise, people make decisions
Procurement integration
Risk gets involved early, less rework later
The Direction
The future of TPRM is not heavier governance, but systems designed for continuous change.Organizations anchored to static reviews, questionnaire-based assessments, and manual coordination will continue to experience structural friction: slow procurement, delayed risk discovery, and preventable surprises.
Agentic programs move faster not by accepting more risk, but by maintaining an accurate, continuously updated understanding of risk as it evolves.
Coverbase
Coverbase uses agentic AI to orchestrate intake, assessment, monitoring, and evidence reuse as a single system.
The goal isn't replacing human judgment. It's making sure your people spend time on decisions, not admin.
FAQ
How long does third-party vendor approval typically take?
96% of organizations take more than two weeks to approve a vendor, and 43% take two months or longer, according to Coverbase's 2026 survey of Fortune 500 procurement and security leaders.
What's the biggest bottleneck in vendor risk assessment?
Evidence collection and vendor communication — cited by 50% of practitioners as their top source of friction, ahead of intake scoping, reassessment backlog, or internal coordination.
Why don't SOC 2 reports fully address vendor risk?
SOC 2 reports are retrospective (describe what was true months ago), generic (not specific to how a vendor is actually used), and policy-focused (describe intended controls, not what's currently running).
What is fourth-party risk?
Fourth-party risk is exposure introduced by a vendor's own vendors, subprocessors, or shared infrastructure — dependencies that sit outside the direct vendor relationship and can change without notice.
How often do organizations learn about vendor incidents before impact?
Only 40% of practitioners say they reliably learn about vendor incidents before those incidents affect their organization.
Methodology
This report is based on:
Survey responses from procurement and security leaders at Fortune 500 companies and leading financial institutions, including top global cryptocurrency exchanges, leading pharmaceutical and healthcare companies, top U.S. banks, leading telecommunications providers, global asset managers, leading wealth and investment management firms, and enterprise technology and cybersecurity companies.
Industry research from analysts, regulators, and security firms.
Operational experience working with organizations managing large, regulated vendor ecosystems.
Survey conducted January 2026.
