Your Third-Party Risk Program Is Probably a Fiction
Executive Summary
Most enterprise third-party risk programs have a fundamental structural problem: they measure the wrong things, at the wrong time, using the wrong methods — and then file the results in a system that nobody acts on.
The standard approach — send a questionnaire, receive a filled questionnaire, score it, archive it — creates an enormous amount of activity with remarkably little actual risk reduction. Vendors learn to answer questionnaires well. Security teams learn to process them efficiently. And the actual risk posture of the vendor relationship remains largely opaque.
This is not a criticism of the people running these programs. It is a systemic critique of a process architecture that has not kept pace with the reality of modern enterprise dependency on third parties.
Why This Matters Now
The attack surface has fundamentally changed. Enterprises no longer have a perimeter in any meaningful sense — they have a constellation of vendor relationships, each of which represents a potential attack path into their most sensitive systems and data.
The incidents that have defined enterprise cyber risk over the past several years — SolarWinds, Kaseya, MOVEit, and a long list of others — were not failures of the enterprise security team. They were failures of the ecosystem. Attackers found that targeting a trusted third party was dramatically more efficient than attacking the enterprise directly. One compromise, thousands of victims.
The regulatory response to this reality has been significant. Supply chain security is now a specific area of scrutiny in frameworks from NIST to NIS2 to DORA. But regulatory compliance and actual risk reduction are not the same thing — and most organizations are achieving the former without the latter.
CISO2CISO Insight
A questionnaire tells you what a vendor claims about their security posture on the day they answered it. It tells you almost nothing about what their actual posture is today, in production, under real operational conditions.
What Real Third-Party Risk Looks Like
The gap between a mature third-party risk program and a typical one comes down to three fundamental differences.
Continuous vs. point-in-time assessment. Annual questionnaires capture a snapshot of a vendor's self-reported posture at one moment in time. Real third-party risk management treats vendor relationships as dynamic — with ongoing monitoring that surfaces changes in posture, new exposures, leadership changes, financial stress, and emerging vulnerabilities in the vendor's own technology stack. External attack surface monitoring, breach intelligence feeds, and financial health monitoring are not luxuries — they are the minimum viable toolkit for understanding what is actually happening with your most critical vendors between assessment cycles.
Tiered materiality vs. uniform treatment. Most programs treat all vendors with roughly the same process — maybe with a light vs. full questionnaire distinction. But the risk calculus is radically different between a vendor with read access to a non-critical dataset and a vendor with privileged access to your production infrastructure or your core financial systems. Mature programs invest disproportionately in the relationships where a compromise would be genuinely material — with more rigorous technical assessment, contractual controls, and ongoing monitoring calibrated to the actual business impact of a breach.
Contractual consequence vs. wishful thinking. The contractual dimension of third-party risk is dramatically underinvested in most programs. Incident notification timelines, right-to-audit provisions, data handling obligations, breach liability allocation, and exit rights are not legal formalities — they are operational tools that determine whether your organization can actually respond effectively when something goes wrong with a vendor. The time to negotiate these terms is before the relationship starts, not during an incident.
Fourth-party visibility. Your vendor's risk is partly determined by their vendors. The SolarWinds attack chain ran through dependencies that most of SolarWinds' customers had never heard of. Understanding the third-party dependencies of your most critical vendors — even at a high level — is increasingly a requirement for meaningful risk assessment.
Executive Framework
| Gap | What it looks like in practice |
|---|---|
| Point-in-time assessment | Annual questionnaire, filed and forgotten |
| Uniform treatment | Same process for a SaaS tool and a core infrastructure partner |
| No continuous monitoring | First awareness of a vendor breach is a news article |
| Weak contractual position | Vendor notification obligation is "prompt" or "reasonable time" |
| No fourth-party visibility | Critical vendors' own supply chains are completely opaque |
What CISOs Should Do Next
- Identify your top 15 vendors by actual business impact — not spend, not questionnaire score, but genuine operational dependency. These are your tier-one relationships.
- For each tier-one vendor, assess whether your current controls and monitoring would tell you within 24 hours if that vendor was compromised.
- Audit your vendor contracts for the four critical provisions: notification timelines (hours, not days), right-to-audit, breach liability, and exit rights.
- Implement external attack surface monitoring for tier-one vendors — their exposed assets, leaked credentials, and dark web mentions should be on your radar continuously.
- Ask your tier-one vendors what their own top vendor dependencies are. The answer to that question is often more illuminating than any questionnaire.
- Report third-party risk to the board not as a compliance score but as a concentration analysis — where are we most dependent, and what is the blast radius if those dependencies fail?
Board-Level Questions
- Which of our vendor relationships, if compromised, would have a material impact on business continuity or data security?
- What is our actual notification timeline expectation from critical vendors in the event of a security incident?
- Are we monitoring our most critical vendors continuously, or only assessing them annually?
- Do we understand the third-party dependencies of our most critical vendors?
Final Executive Takeaway
Third-party risk is the area where the gap between governance theater and real risk management is most pronounced. The questionnaire-based model made sense when vendor relationships were simpler and less operationally critical. It does not make sense when a single vendor compromise can cascade across thousands of enterprise customers in hours.
The organizations that are getting this right are not doing more of the same thing. They are doing something fundamentally different: treating their most critical vendor relationships with the same rigor and continuous attention they apply to their own internal systems.
The question is not whether you have a third-party risk program. The question is whether your program would actually tell you — before the news does — that one of your most critical vendors has been compromised.
