The annual questionnaire, the scoring matrix, the RAG status report to the board. These processes were designed for a world that no longer exists. Third-party risk management is not failing because the questionnaire is poorly designed. It is failing because the operating assumptions behind traditional TPRM were built for a slower era, and the world has not been slower for some time.
The era that built traditional TPRM
Traditional third-party risk management emerged from an environment where vendor relationships were formal, procurement cycles were measured in months, and the number of external dependencies an organisation carried was small enough to assess individually.
In that world, the annual review made sense. Vendors were few. Relationships were contractually anchored and relatively stable. The IT estate changed slowly. When a significant vendor was onboarded, it went through legal, procurement, and usually a security review before access was granted. Assessments were laborious but proportionate to the scale of the problem. A security team with a questionnaire template and a spreadsheet could, in theory, maintain a defensible picture of the organisation's third-party exposure.
That model was never perfect. But it was at least calibrated to the conditions that existed when it was created. The difficulty is that almost every one of those conditions has since changed.
How the assumptions collapsed
The failure was not sudden. It was a convergence of pressures that accelerated over roughly a decade and are now simply the operating environment.
SaaS procurement became frictionless. A developer can add a data processing service, an analytics tool, or a collaboration platform to their workflow in minutes, usually without involving procurement or security. Engineering teams procure infrastructure, monitoring tooling, and development platforms directly, frequently using company cards that bypass corporate procurement controls entirely. The vendor register, if it exists at all, represents a fraction of the actual dependency surface.
Start-up velocity compounded this. A vendor a security team assessed eighteen months ago may have scaled from twenty to two thousand employees, changed their architecture three times, migrated their infrastructure to a different cloud provider, acquired another company, and brought in entirely new engineering leadership. The assessment sits in the register showing green, representing an organisation that no longer exists in that form.
Procurement cycles now operate on timescales measured in days rather than months. Business teams evaluating a SaaS product expect a decision within a sprint. The governance process that requires a security review before contracts are signed creates friction that business units route around. The practical result is a large and growing class of vendor relationships that were never formally assessed and are not in scope for the annual review.
The aggregate of these pressures is a mismatch that questionnaire design alone cannot resolve. Assurance teams expected to maintain risk visibility across hundreds or thousands of vendors are using manual processes built for a universe an order of magnitude smaller.
The theatre of assurance
The questionnaire-driven model persists not because it works, but because it produces artefacts that are auditable.
The questionnaire went out, the response came back, the score was calculated, the RAG status was set, and the evidence file is complete. Viewed from inside a governance framework, that is a satisfying set of outputs. Viewed from inside the risk, it is almost meaningless.
The core problem is the distinction between evidence of control existence and evidence of operational effectiveness. A questionnaire asks whether a control exists. It almost never tests whether the control works. A vendor can have a patch management policy, an access review process, an incident response plan, and a penetration test programme, all correctly described in their response, and none of them may be functioning as described. The designed interface is documented. The actual state of the programme is invisible.
Certifications compound this. An ISO 27001 certificate attests that a management system existed and met the standard's requirements at the time of the audit. It says nothing about whether the controls are adequate to the specific risks of the vendor's operating environment, nor whether they have been maintained since the certificate was issued. A SOC 2 Type II report is more informative, covering a defined period rather than a moment in time, but its scope is chosen by the organisation being assessed, and the controls tested are the controls the organisation elected to include. Neither artefact tells you whether a specific dependency is likely to affect you.
Annual review cycles add a further structural weakness. The vendor risk universe changes continuously. Acquisitions happen. Key personnel leave. Architectures shift. An annual cycle cannot detect any of these changes in the eleven months between assessments. By the time the next review is due, a significant vendor's risk profile may have shifted considerably, and the programme will have no record of that shift until the cycle repeats.
The optimisation for auditability over effectiveness is not irrational from the perspective of the teams designing these programmes. Demonstrating that a programme ran requires evidence that can be pointed to. Risk reduction is harder to evidence than process completion. The result is that programmes gradually come to serve the audit cycle rather than the risk picture, and the gap between the compliance artefacts and the actual exposure quietly widens.
- Has this vendor completed our assessment?
- Point-in-time snapshot of stated controls
- Annual review cycle
- Scales with analyst headcount
- Output: RAG status, evidence file
- What do we know about this dependency right now?
- Continuously updated signal synthesis
- Event-driven reassessment
- Scales with automation
- Output: current exposure picture, change alerts
What modern supply chains actually look like
The term "third-party risk" implies a simple bilateral relationship: your organisation and the vendor. Modern supply chains are considerably more complex, and the complexity is not evenly distributed.
Cloud infrastructure providers sit at the base of most digital operations and represent concentration risk that traditional TPRM frameworks were not designed to address. When a significant fraction of global business operations run on the infrastructure of three hyperscalers, a prolonged outage or security incident at any of them is not a bilateral vendor risk event for the organisations affected. It is a sector-wide event with systemic consequences that no individual assessment programme could have anticipated or prevented.
SaaS platforms form the operational layer above that. Email, identity, collaboration, development tooling, customer relationship management, finance: these are no longer applications running on infrastructure the organisation controls. They are services delivered by companies with their own engineering teams, their own subcontractors, and their own security postures. A compromise of an identity platform used by tens of thousands of organisations is not a risk to be managed through better questionnaires sent to that vendor. It is a category of systemic dependency that requires a different kind of thinking.
Data brokers and analytics vendors represent a category that traditional TPRM rarely captures adequately. These organisations hold access not to systems but to information: about customers, employees, and competitive position. The exposure is not operational disruption but data exposure, and the questionnaire model handles this poorly because the risk does not lie in whether the vendor has a firewall policy. It lies in what they do with the data, under what contractual terms, and with whom they share it.
Software supply chains introduce a different order of risk. Events of recent years have demonstrated that the software running on your systems is itself a dependency chain, and that compromise at any point in it can propagate downstream to every organisation using the affected component. The XZ Utils backdoor required nearly two years of patient social engineering before it reached a position where exploitation at scale became possible. The SolarWinds incident demonstrated that a trusted software update mechanism could become a vector for targeting organisations that had assessed and approved the vendor. These are not risks that a vendor questionnaire would surface. They exist below the level at which traditional TPRM operates.
Managed service providers occupy a specific position of concern. An MSP with administrative access to multiple client environments is not simply a vendor. It is a potential pivot point: a single compromise can cascade simultaneously to every client in the portfolio. The fourth-party dependencies that sit beneath a direct vendor, their cloud providers, their identity platforms, their development tooling, are largely invisible to most assurance programmes and compound the risk further in ways that bilateral assessments cannot capture.
The AI dimension
The emergence of AI services as a mainstream vendor category has created a new set of supply chain risks whilst simultaneously offering, for the first time, genuinely new approaches to managing assurance at scale.
New risks from AI adoption
The pace of AI adoption has outrun the assurance frameworks designed to govern it. Engineers are connecting business data to foundation model APIs on timescales of hours. Business teams are procuring AI-enabled tools through self-service channels with minimal security review. Products that were previously discrete software applications are embedding AI components from third-party providers, sometimes without meaningful disclosure to the customer about what those components do or where data flows.
The vendor that passed your assessment last year may now be routing your data through a foundation model from a provider you have never assessed. That provider's own subcontractor chain may extend through inference infrastructure, fine-tuning data suppliers, and hardware manufacturers in ways that neither you nor your direct vendor can fully articulate. The architecture is changing rapidly enough that a review from twelve months ago may describe a fundamentally different system.
Data sent to AI services for processing may be retained by the provider, used to improve models, or accessible to other parties under terms that legal and data protection teams have not reviewed in detail. Model behaviour can change with a provider update without a formal release cycle, creating a category of operational risk where the incident is not a breach but an unexpected change in how a product behaves. These are risk classes that traditional vendor assessments were not designed to evaluate.
The regulatory landscape governing AI and data processing is still being written across most jurisdictions. This uncertainty means that the compliance posture of an AI vendor at the time of assessment may change materially within months, creating ongoing obligations that annual review cycles cannot track.
The compound problem. AI adoption is simultaneously adding new vendor risk categories and accelerating the pace at which vendor architectures change. Both effects make annual assessments less adequate, not more.
New capabilities from AI-assisted assurance
On the assurance side, AI capabilities are beginning to change what is genuinely achievable at scale. Automated intelligence gathering can now collect and synthesise publicly available information about a vendor's security posture at a speed and breadth that no human analyst can match. Trust centres, security.txt files, public CVE databases, regulatory enforcement records, bug bounty disclosures, and security researcher publications can be monitored and cross-referenced continuously across a large vendor population, not just the priority tier that human analysts can realistically manage.
Evidence review that previously required an analyst to read a SOC 2 report and manually extract relevant controls can be accelerated materially by language models capable of parsing documentation, identifying relevant claims, and surfacing gaps or inconsistencies between stated controls and known vulnerabilities. Automated parsing of trust centres and security portals can feed a continuously updated view of a vendor's stated posture, with change alerts triggered when material updates occur.
More significantly, AI enables the kind of continuous monitoring that was previously impractical to operate at scale. Tracking changes to a vendor's external attack surface, correlating CVE disclosures against mapped dependencies, parsing regulatory enforcement actions across sectors, and monitoring breach disclosures in real time are all tasks that benefit from automation and that can, when automated, operate across the full vendor population.
Traditional TPRM scaled linearly with analyst headcount. AI-assisted approaches have the potential to monitor the full dependency surface continuously. The technology does not eliminate the need for analytical judgement; it changes the ratio between what requires human interpretation and what can be automated.
Vendor risk as an intelligence problem
The most significant reframing available to security teams is to stop treating vendor risk as a compliance process and to start treating it as an intelligence problem.
A compliance process asks whether the assessment has been completed. An intelligence approach asks what you know about this dependency right now, and whether anything has changed since yesterday. The difference is not cosmetic. Intelligence requires a different set of inputs, different tooling, and a different organisational attitude toward uncertainty and continuous change.
Rather than assembling questionnaire responses and certification artefacts at annual intervals, an intelligence-driven programme ingests and synthesises signals from multiple sources continuously. The signal landscape is richer than most programmes currently exploit.
External attack surface monitoring tracks the infrastructure, certificates, and services a vendor presents to the internet. Changes to that surface are often early indicators of architectural shifts, security posture changes, or active compromise before formal disclosure occurs. CVE intelligence, cross-referenced against a map of vendor dependencies, provides continuous visibility of the vulnerability landscape for the specific platforms each vendor uses, rather than a generic snapshot of whether they have a patching process.
Trust centre monitoring, still underused by most programmes, provides a direct feed of changes to a vendor's stated security posture. Subprocessor additions, certification lapses, privacy policy revisions, and infrastructure migrations are published changes that carry real risk signal, but they are rarely consumed systematically because no one has configured a watch on them. Regulatory enforcement actions against a vendor or its sector peers reveal how programmes perform under external scrutiny in ways that questionnaire responses cannot.
The aggregate of these signals builds a continuously updated picture of vendor risk that bears little resemblance to what an annual questionnaire produces. More importantly, it surfaces material changes when they happen rather than when the next review is scheduled. Regulators across the EU and UK are increasingly reflecting this expectation: NIS 2, DORA, and the UK Cyber Security and Resilience Bill all push organisations toward demonstrating active, ongoing oversight of supply chain dependencies rather than periodic documentation exercises.
Where the market is going
The vendor security market has been responding to these pressures, with uneven results.
External security rating services, which score vendors based on passively observed signals about their internet-facing posture, provided an early answer to the question of how to monitor vendors at scale. Their limitations are well documented: scores correlate poorly with actual breach likelihood, they measure only the externally visible surface, and their methodologies can be gamed by organisations that understand them. They are useful as a triage signal, particularly for identifying vendors with obviously poor hygiene or suddenly degraded posture, but they are not a substitute for depth.
Continuous controls monitoring platforms are beginning to provide ongoing visibility of the control environment rather than point-in-time attestations. Trust centre automation, which standardises the format and update cadence of vendor security posture information, is a meaningful step toward a world where security evidence is machine-readable and continuously current rather than a PDF produced at audit time and stale within weeks. Evidence aggregation platforms that can ingest, normalise, and cross-reference SOC reports, questionnaire responses, penetration test summaries, and trust centre data are reducing the manual burden on assurance teams and enabling a more complete picture to be assembled more quickly.
The direction of travel points toward something that resembles a security intelligence capability applied to the vendor population rather than a compliance programme. The organisations moving in this direction are building stacks that combine external attack surface data, threat intelligence, OSINT, trust centre monitoring, CVE feeds, and assurance evidence into a continuously updated view of each significant dependency. The combination is qualitatively different from the sum of its parts: signals that are individually weak become informative when correlated, and patterns that would be invisible in annual reviews become visible when you are watching continuously.
This represents a significant opportunity for organisations that can execute it. Vendor risk management becomes a source of genuine operational intelligence rather than a compliance overhead. The ability to ask, with confidence, what the current exposure looks like for any significant dependency, and to answer that question based on real-time signals rather than last year's questionnaire, is a material advantage in incident response, in procurement decisions, and in regulatory engagement.
The investment is not trivial. It requires data engineering capability, tooling integration, and willingness to replace comfortable artefacts with something harder to summarise in a board slide but more closely connected to reality. The organisations that make it will be in a fundamentally different position when incidents occur, when regulators ask questions, and when procurement decisions require a confident answer about a new dependency. Those that do not will continue managing the gap between their register and their actual exposure with a questionnaire that goes out once a year.
The question is different now
Traditional third-party risk management was designed to answer one question: has this vendor completed our assessment? The answer, when it could be obtained, was a snapshot of what the vendor chose to tell you about their controls at a point in time, filtered through a questionnaire generic enough to apply to everyone and therefore penetrating for almost no one.
That question is no longer adequate to the risk environment organisations are actually operating in. Vendor ecosystems grow faster than assurance teams. Architectures change between assessment cycles. Dependencies compound through layers that questionnaires never reach. AI adoption is adding new risk categories and accelerating the pace at which vendor architectures change, simultaneously. The compliance artefacts that made traditional TPRM auditable are increasingly disconnected from the actual exposure they are supposed to represent.
The future of vendor risk management is not better questionnaires. It is the transition from periodic compliance exercises to continuously updated intelligence about the dependencies that actually matter. That transition requires accepting that vendor risk is not primarily a documentation problem. It is a question of what you know about your dependencies in real time, how quickly that knowledge becomes stale, and whether your programme is capable of detecting material changes before they become incidents.
The central question has changed. It is no longer "has this vendor completed our assessment?" It is "what do we know about this dependency right now, and has anything changed since yesterday?"
The gap between organisations that can answer the second question and those that cannot is widening. The tools to close it exist, and they are becoming significantly more capable. The programme design choices required to make use of them are not especially complicated. What they require is a willingness to measure the programme by what it reveals rather than by what it files.