Third-Party Risk Program Maturity Models Compared
Framework maturity matters only when scores measure risk reduction, not just completed assessments.
Third-party risk program maturity models are useful only when their scores distinguish completed work from effective control. Comparing their architecture reveals the central test of maturity. A program must show that assessments, governance, monitoring, and contracts reduce risk.
Why activity-based maturity models create a false sense of program health
A CISO can reasonably believe a program is mature because assessments are going out, the vendor list exists, and ownership has been assigned. Those are visible signs of organized work. They do not establish that controls are effective. A program can possess all three and still lack the evidence needed to withstand a regulatory examination, because its records document effort.
Questionnaires sent and assessments completed describe throughput, while risk reduction depends on what the program detects, changes, and resolves. A maturity score built around completion can therefore reward a program whose understanding of vendor exposure is already stale. Third-party incidents account for a substantial share of breaches, approaching half, and take materially longer to detect than internally sourced incidents. Measuring activity without effectiveness leaves that detection problem largely outside the score.
What the major frameworks actually measure across their five levels
The canonical models share a five-level spine, but their scoring dimensions differ. Neotas’s 2026 model and Atlan Systems’ model both use that structure for all sectors but recognize that each sector takes a different path through it. Financial services, healthcare, and manufacturing face different regulatory pressures, which shape what their programs learn to do first. The shared scale makes comparison possible.
A free NIST-anchored alternative builds maturity scoring on three complementary foundations. NIST SP 800-53 supplies the supply chain risk management controls, while NIST SP 800-161 Rev 1 provides the primary guidance for identifying, assessing, and mitigating cybersecurity supply chain risk. NIST CSF 2.0 places its GV.SC supply-chain outcomes category within the Govern function. The model scores five dimensions separately. That structure allows a program to identify the capability holding it back.
The models also differ in how they organize progress. SureCloud’s 2026 model treats tiering as one of seven distinct capability areas and places continuous monitoring at the top of a sequential seven-stage structure built on due diligence and governance. That is a different architectural view from the five-level spine. It describes the capabilities that develop through the program, rather than treating one overall stage as a complete account of maturity.
The dimensions that separate audit artifacts from genuine risk reduction
At Level 2, a vendor inventory may exist without being complete, current, or consistently tiered. Assessments may go deep for high-risk vendors but vary in how closely they examine mid-tier vendors. Level 3 requires a risk-based methodology that determines assessment frequency and depth by tier. By Level 4, current evidence and monitoring make those classifications part of an operating decision process.
Monitoring shows most clearly whether controls work in practice as well as on paper. A Level 2 program reviews vendors when the calendar or an analyst prompts it, capturing risk as it was at that point. A Level 4 program updates its view as evidence changes. Its leadership dashboards use live data in place of periodic exports, and its records show what remediation achieved as well as what the findings were. A closed assessment is not the same as a resolved exposure.
Naming the CISO as owner does not settle who is responsible across functions, who handles escalation, or how to apply policy the same way each time. A more mature program has named owners for each function, applies the same methodology across vendors in the same tier, and can map vendor controls to applicable regulatory frameworks. Atlan’s model tests these features together with inventory, monitoring, dashboards, and remediation evidence. Four or more “no” or “partially” answers across its seven questions signal Level 2, regardless of the program’s age.
Where programs stall and why the Level 2-to-3 transition is the hardest
The Level 2-to-3 transition requires several changes at once. The program must set a consistent risk-based methodology, put every vendor in a tier, and assign owners across functions while keeping up with its assessment backlog. Teams driven by compliance must split their efforts between finishing today’s requests and building the operating model that would change tomorrow’s workload.
In this analytical comparison, most regulated firms are at Level 2 or 3, but regulators in effect expect them to have Level 4 capabilities. DORA itself does not assign maturity levels, but its requirements for structured programs, contractual controls, continuous monitoring, and a complete Register of Information resemble that higher operating standard.
HIPAA requires records of business associate risk management, a requirement that Level 1 programs cannot meet and Level 2 programs may meet only in part. In healthcare, manual spreadsheets and reactive processes are especially limiting because vendor networks can be extensive. Yet organizations often add analysts or questionnaire tooling before correcting governance. More capacity can absorb the backlog without changing the structure that creates it, leaving perceived maturity ahead of actual capability.
What DORA's Pillar 4 reveals about the gap between process documentation and program accountability
DORA’s ICT third-party risk requirements in Articles 28–44 provide the sharpest regulatory test of the distinction between documentation and accountability. Articles 28, 29, and 30 require a formal program with defined governance, a Register of Information covering every ICT vendor arrangement through specified data fields, portfolio-level concentration risk assessment, and mandatory contractual provisions. These requirements reach beyond the individual assessment. A completed questionnaire cannot substitute for a portfolio view or establish rights missing from a contract.
Legacy agreements make the gap concrete. Firms with critical or important function vendors on ICT contracts that predate January 2025, and still lack Article 30’s mandatory provisions, face direct enforcement risk at their next supervisory interaction. The assessment may be complete while the contractual control remains absent. That is precisely the weakness an activity-based score can obscure, because the existence of a reviewed document says little about whether its provisions meet the required standard.
DORA thus makes higher maturity observable through specific obligations. It tests whether the program governs arrangements, understands concentration, and has controls it can enforce, all of which go beyond how much paperwork teams have done. For organizations outside its scope, NIST CSF 2.0’s GV.SC category offers the widely referenced non-regulated C-SCRM anchor. NIST SP 800-161 Rev 1 gives guidance on how to put that into practice.
Non-human identities and agentic connections as the maturity dimension no current framework scores
The major frameworks were built for vendor relationships managed by people, and none has an explicit score for the non-human identity surface described here. Enterprises have vastly more service accounts, API keys, OAuth tokens, certificates, and bot credentials than human identities. The vast majority of legacy IAM tools cannot manage AI and non-human identity risks, so a growing exposure falls outside the traditional assessment model.
The Salesloft-Drift incident shows how that exposure becomes a third-party breach. Salesloft disclosed that the threat actor accessed Drift’s Amazon Web Services environment and obtained OAuth tokens for customers’ technology integrations. Google’s GTIG stated that the compromise was not exclusive to the Salesforce integration and affected other integrations. Cloudflare disclosed that 104 of its API tokens were exposed and required rotation. The relevant control boundary was the integration’s access.
Agentic connections widen that governance gap. OAuth lets AI agents and MCP servers act on SaaS and cloud accounts, and an employee may connect them through a consent screen without going through controlled provisioning. Organizations already struggle to see all the vendors connected through OAuth apps alone. Individually created agent connections make that visibility problem harder. The incident points toward scoped OAuth token issuance rather than broad API key grants, contractual security standards, and continuous monitoring for anomalous integration access, but the frameworks have not caught up with this as a distinct maturity dimension.
How continuous monitoring changes what maturity means in practice
In a point-in-time program, the assessment captures risk, that view remains stable until the next scheduled review, and remediation is tracked separately from the score. Continuous monitoring changes that relationship. Vendor behavior, external signals, and control evidence update the risk picture, while findings automatically trigger reassessment, contract review flags, or escalation without waiting for an analyst to initiate the process.
The distinction is operational. A program can have strong due diligence and still be at an early stage in monitoring, leaving a window in which changing risk goes undetected. Healthcare makes the consequence clear because organizations may manage hundreds or thousands of vendors with PHI exposure. Calendar-based assessments provide no real-time insight into changes in those vendors’ security posture. A well-run review cycle cannot supply evidence from the interval it does not observe.
Monitoring only advances maturity when its findings re-enter the program. As the evidence changes, it must feed into onboarding decisions, contract obligations, risk scores, and incident response. A separate monitoring module that analysts check periodically preserves much of the old operating pattern. It adds signals without necessarily changing decisions. By contrast, an integrated process connects a new finding to the lifecycle stage responsible for acting on it.
That connection also changes the purpose of assessment work. When continuous evidence establishes that a vendor remains stable and low risk, zero-touch assessment allows analyst time to move toward relationships that need human judgment. Maturity then becomes visible in how the program responds to evidence, including when it decides that another manual review would add little value.
What higher-maturity programs do differently with contracts, AI, and analyst time
Contracts become active controls when their obligations are compared with real performance. DORA’s Article 30 requires security, monitoring, audit, and exit provisions, which supervisors check against the required list. Higher-maturity programs connect obligations to continuous vendor performance data. A deviation triggers review.
The leading GRC uses in 2025 included risk monitoring and reporting, compliance workflow automation, threat detection and incident response, predictive risk identification, and third-party risk management. Their common contribution is removing routine data handling from analyst queues. Speed alone is not the maturity advance. AI that fails to adapt to an organization’s control frameworks simply accelerates existing work, while systems that learn from analyst decisions can apply that learning to subsequent assessments.
Analyst time reveals whether that shift has occurred. At Level 2, analysts spend most of their time chasing questionnaire responses, re-entering data, and routing paperwork. At Level 4 and above, zero-touch assessment handles low-risk vendors, while AI-assisted analysis supports work on complex relationships. Human judgment concentrates on escalation decisions, novel risk scenarios, and regulatory interaction, where automation cannot produce the same outcomes. The decisive question is not whether the program uses AI, but whether its use has changed what analysts spend their time on.
