Third-Party Risk Management Frameworks: The Guide

No single approach is ideal for every organization, but some commonly used frameworks serve as a solid starting point. Here’s what you need to know.

TPRM Frameworks

Third-party risk management frameworks address a problem that keeps getting bigger.

According to the World Economic Forum’s Global Cybersecurity Outlook, 54% of large organizations identify supply chain vulnerabilities as their greatest barrier to cyber resilience — ranking above budget constraints, staffing gaps, and technical complexity.

A third-party data breach or vendor failure can expose an organization to regulatory penalties, customer notification obligations, and reputational damage that no internal control can fully prevent. A third-party risk management framework gives that challenge structure.

The frameworks available vary significantly in scope, regulatory alignment, and readiness for emerging risk categories. Most organizations need more than one.

What's Inside
  1. What Is a Third-Party Risk Management Framework?
  2. Why You Need More Than One TPRM Framework
  3. How to Choose a TPRM Framework
  4. Core TPRM and Supply Chain Risk Frameworks
  5. How Regulatory Requirements Map to TPRM Frameworks
  6. AI Vendor Risk as an Emerging Priority in TPRM Frameworks
  7. Build One Program, Not Five
  8. Frequently Asked Questions

What Is a Third-Party Risk Management Framework?

A third-party risk management framework is a structured set of controls, processes, and governance requirements organizations use to identify, assess, and manage risk across their vendor and supplier relationships. Frameworks define what to assess, how to conduct that assessment, and how to organize findings into an actionable risk management process. They serve as the foundation on which a TPRM program is built.

TPRM frameworks fall into three categories:

  1. Dedicated TPRM and supply chain risk management (SCRM) frameworks, such as the Shared Assessments TPRM Framework and NIST SP 800-161, purpose-built for managing third-party relationships at the program level.
  2. Ancillary information security frameworks, including NIST CSF 2.0, ISO 27001, and NIST SP 800-53, which provide control libraries organizations use to design vendor risk assessment questionnaires and measure vendor security posture.
  3. Non-IT and ESG frameworks, including CSRD and GRI, which address sustainability reporting and supply chain due diligence obligations outside the traditional cybersecurity perimeter

A TPRM framework is not the same as a TPRM program. The framework provides the standards and controls. The program is the organizational infrastructure: the people, processes, and technology that put those standards into practice.

Why You Need More Than One TPRM Framework

No single framework covers every dimension of third-party risk. An organization managing financial services vendors in the EU needs DORA-aligned ICT third-party controls, ISO 27001 for vendor information security assessments, and CSRD reporting obligations for supply chain sustainability.

Each framework addresses a different regulatory obligation or risk type. The practical approach is framework stacking: most mature TPRM programs draw from multiple frameworks simultaneously, using each where it delivers the most value.

An organization might anchor its program on the Shared Assessments TPRM Framework for lifecycle governance, but use NIST 800-161 to design controls for high-risk technology vendors, and apply ISO 27001 requirements to vendor assessment questionnaires. Regulatory mandates layer on top.

Organizations operating across multiple jurisdictions face compounding complexity. The same third-party vendor may trigger ICT oversight requirements under DORA, data processing obligations under GDPR, and supply chain reporting requirements under CSRD, each carrying distinct assessment, documentation, and ongoing monitoring obligations. A framework stack designed with that multi-jurisdictional picture in mind produces a materially more defensible compliance posture than one built to satisfy a single standard.

How to Choose a TPRM Framework

Before selecting a framework, organizations need a clear view of their risk. The types of risk that third-party relationships create will shape which frameworks address the most material exposures: cybersecurity and data privacy, financial, operational, legal and regulatory, reputational, and ESG.

Several practical factors should drive the selection process:

  • Regulatory requirements: Which frameworks does your regulatory environment mandate or reference? Financial entities covered by DORA, healthcare organizations subject to HIPAA, and payment processors complying with PCI DSS v4.0 each face specific framework expectations.
  • Alignment with existing risk management infrastructure: A framework that cannot integrate with your enterprise risk management processes creates parallel workstreams rather than a unified risk function.
  • Update cadence: Frameworks that fail to keep pace with regulatory change become liabilities. Check when each was last revised, particularly in cybersecurity and ESG.
  • Risk tiering: Does the framework support differentiating between high-risk, medium-risk, and low-risk vendors? Applying the same assessment depth to all third parties is operationally unsustainable.
  • Customer and counterparty expectations: Which frameworks do your customers or business partners reference in their own vendor due diligence processes? Organizations that send and receive assessment requests benefit from framework alignment on both sides of the relationship. Adoption breadth is part of this: widely used frameworks generate more pre-mapped vendor responses and reduce the time to complete assessments at scale.

Core TPRM and Supply Chain Risk Framework

The frameworks break into four categories: supply chain risk, vendor assessment, AI governance, and ESG reporting.

Shared Assessments TPRM Framework and SIG

The Shared Assessments TPRM Framework is one of the few frameworks designed specifically for third-party risk rather than broader information security or supply chain management. It covers the full vendor risk management lifecycle, from outsourcing analysis and due diligence through ongoing monitoring and exit management. The framework organizes into fundamentals covering governance and program buy-in, and eight process families.

The Shared Assessments Standardized Information Gathering questionnaire (SIG) is the assessment instrument that operationalizes the framework. It maps directly to ISO, HIPAA, NIST, GDPR, and PCI DSS, making it particularly useful for organizations running consistent risk assessments across vendors operating under different regulatory regimes. Organizations building a TPRM program from scratch will find the SIG’s pre-built control mappings significantly reduce time to operational capability.

NIST SP 800-161

NIST SP 800-161 provides supply chain risk management guidance developed for U.S. federal entities. It integrates C-SCRM controls across the NIST Risk Management Framework, giving organizations a systematic approach to supply chain risk that extends beyond cybersecurity into operational continuity, supplier financial health, and geopolitical exposure.

Private sector organizations with complex, multi-tier supply chains consistently find NIST 800-161 useful as a program foundation, even without a federal compliance obligation. Its depth on concentration risk and fourth-party exposure addresses gaps that narrower cybersecurity frameworks leave open.

NIST CSF 2.0, NIST SP 800-53, and NIST RMF 800-37

For vendor risk assessment questionnaires, NIST CSF 2.0 remains the reference standard. Its six functions — Govern, Identify, Protect, Detect, Respond, and Recover — provide a consistent framework for evaluating a vendor’s cybersecurity posture and maturity. Organizations with strong data privacy and regulatory compliance requirements find that NIST CSF-based questionnaires generate more actionable risk findings than generic alternatives.

NIST SP 800-53 and the NIST Risk Management Framework (NIST RMF 800-37) extend the assessment toolkit for organizations needing control specificity beyond what CSF provides. Many organizations combine all three: 800-161 for supply chain program governance, CSF for vendor assessment design, and 800-53 or RMF for control-level detail on high-risk third parties.

ISO 27001/27002 and ISO 27036-2

ISO 27001 and 27002 set requirements for an information security management system, with significant supplier risk provisions built in. They are particularly useful for organizations with international third-party vendor portfolios, where ISO certification creates a common language for information security expectations across jurisdictions.

ISO 27036-2 addresses information security requirements for supplier relationships across the full lifecycle, from procurement through exit.

AI Risk Frameworks: NIST AI RMF and ISO 42001

As AI vendors become a material category within third-party ecosystems, TPRM teams need evaluation frameworks that go beyond standard cybersecurity questionnaires. The NIST AI Risk Management Framework (AI RMF) provides a structured approach to identifying, assessing, and managing AI-specific risks across the AI lifecycle; its “Map” and “Govern” functions have the most direct TPRM applicability.

ISO 42001, the international standard for AI management systems, aligns with ISO 27001 and establishes governance requirements for organizations developing or deploying AI, making it the relevant benchmark when an AI vendor claims structured AI governance. Together, they give TPRM teams a defensible basis for AI vendor assessment.

Environmental, Social, and Governance Frameworks

Third-party risk management has traditionally focused on cybersecurity, operational continuity, and regulatory compliance. ESG frameworks are expanding that scope: supply chain due diligence legislation creates legal obligations to identify, assess, and remediate human rights and environmental risks in supplier relationships, and Scope 3 emissions reporting cannot be met without structured data collection from vendors. Both obligations make ESG performance a direct TPRM input rather than a separate sustainability function.

  • CSRD: The CSRD requires large EU organisations to report on sustainability matters using a double materiality lens, assessing both the financial impact of sustainability risks on the business and the organisation’s own impact on people and the environment. Following the Omnibus I Directive, which entered into force on 18 March 2026, the CSRD now applies to organisations with more than 1,000 employees and net annual turnover above 450 million euros. For TPRM teams, the most direct obligation is Scope 3 emissions reporting, which requires structured ESG data collection from suppliers. Supply chain human rights and environmental due diligence is governed separately under the CSDDD (both obligations are covered in the regulatory mapping section below).
  • Global Reporting Initiative (GRI): The GRI is one of the most widely used voluntary ESG frameworks. It provides comprehensive standards for reporting on economic, environmental, and social issues. The GRI’s modular structure allows organizations to choose the standards most relevant to their material topics, making it a flexible and widely applicable framework.
  • Carbon Disclosure Project (CDP): The CDP is a disclosure platform focusing on environmental governance and policy, risks and opportunity management, and environmental targets. It offers detailed questionnaires on climate change, water, and forests, evaluated against CDP’s own scoring methodology. The CDP is particularly valuable for organizations looking to improve transparency and accountability in their environmental practices.

How Regulatory Requirements Map to TPRM Frameworks

Regulatory mandates specify what organizations must achieve, not which framework to use. Organizations must determine which framework or combination of frameworks satisfies each requirement.

  • DORA (EU Regulation 2022/2554, in force January 17, 2025) imposes ICT third-party risk requirements on financial entities under Article 28. Financial entities must adopt a documented strategy on ICT third-party risk, maintain a register of all ICT third-party contractual arrangements, conduct pre-contract due diligence on prospective providers, and maintain exit strategies for critical functions.
  • HIPAA requires covered entities and business associates to implement safeguards governing how third-party partners handle protected health information. The Shared Assessments SIG includes HIPAA-mapped controls, making it a practical starting point for healthcare organizations designing their vendor risk assessment questionnaire.
  • PCI DSS v4.0 places explicit third-party service provider obligations on organizations that process, store, or transmit cardholder data. Requirement 12.8 mandates documented policies for managing third-party providers, including regular risk assessments and a current list of active providers.
  • FFIEC guidance requires financial institutions to conduct thorough due diligence and ongoing monitoring for third-party relationships that could affect safety, soundness, or consumer compliance. NIST SP 800-161 and the Shared Assessments TPRM Framework both align closely with FFIEC expectations.
  • GDPR imposes data processing agreement requirements on organizations that engage third parties to process personal data. Vendor risk assessments under GDPR must address data transfer mechanisms, subprocessor chains, and data breach notification capabilities.
  • CSRD and CSDDD operate on distinct tracks that are easy to conflate. CSRD’s ESRS S2 standard requires disclosure of material impacts on workers in the value chain: a reporting obligation. CSDDD Article 8 requires active due diligence on human rights and environmental impacts across the supply chain: an operational obligation.
    Note: Following the Omnibus I Directive (Directive (EU) 2026/470, in force 18 March 2026), CSDDD active due diligence requirements now apply to a single, narrower scope of organisations: those with more than 5,000 employees and EUR 1.5 billion in net worldwide turnover (for EU companies), or EUR 1.5 billion generated in the EU (for non-EU companies). All in-scope companies must comply by a single unified deadline of 26 July 2029. The Member State transposition deadline is 26 July 2028.

AI Vendor Risk as an Emerging Priority in TPRM Frameworks

 

There is an AI gap in TPRM frameworks

Standard TPRM frameworks have long addressed AI-adjacent requirements — ISO 27001, for example, provided the foundation for ISO 42001, which maps established information security controls to AI management systems specifically. What’s shifting is the directness and specificity with which frameworks now treat AI vendors as a distinct assessment category. The 2026 SIG adds AI-specific questions covering deployment practices and data governance. Less developed is program-level guidance on how to govern AI vendors differently from traditional ICT vendors, given the distinct risk characteristics AI systems introduce: model drift, training data provenance, algorithmic transparency, and the liability implications of AI-generated outputs.

McKinsey’s State of AI 2025 finds that 88% of companies now use AI regularly in at least one business function. Most TPRM programs are not keeping pace: EY’s 2025 Global Third-Party Risk Management Survey found that only 13% of companies have optimized technology and automation maturity in their TPRM programs. IBM’s 2025 Cost of a Data Breach Report shows what that gap costs — 97% of organisations that experienced AI breaches lacked proper access controls, and 63% had no established governance policies in place .

Organizations should treat AI vendor risk as a distinct assessment category within their TPRM framework, not a subset of standard ICT vendor risk. At minimum, vendor assessment questionnaires should address model governance practices, data sovereignty, the use of customer data in model training, AI system explainability, and compliance with the EU AI Act’s high-risk AI requirements, which take effect for most high-risk AI systems in August 2026.

Build One Program, Not Five

No single framework covers everything. NIST SP 800-161 and ISO 27036-2 anchor supply chain risk controls. NIST CSF and ISO 27001 shape vendor assessment design. The SIG provides a standardized questionnaire baseline, now updated for AI and geopolitical risk. ESG frameworks connect supplier data to your own reporting obligations. NIST AI RMF and ISO 42001 are becoming relevant as AI vendors enter your third-party ecosystem.

Most programs struggle not with framework selection but with operationalization. With every new obligation, the team finds itself rebuilding workflows and questionnaires from scratch. Program managers who get this right run one assessment program across all of them.

Mitratech Prevalent maps pre-built workflows and questionnaires to the frameworks covered in this post, so teams spend less time on program design and more time on risk decisions.
See how it works.

One Program. Multiple Risk Frameworks.

See It In Action

Frequently Asked Questions

Do all third-party vendors require the same level of risk assessment?
No. Most established TPRM frameworks, including Shared Assessments and NIST 800-161, build risk tiering into their structure. High-risk vendors — defined by the sensitivity of data they access, the criticality of functions they support, or the degree of system integration involved — require more rigorous initial due diligence and more frequent ongoing reassessment. Low-risk vendors can operate on longer cycles. Applying the same assessment depth to all third-party relationships is operationally unsustainable and misallocates limited assessment resources.

Which TPRM framework is required for DORA compliance?
DORA (EU Regulation 2022/2554, in force January 17, 2025) does not mandate a specific named framework. Article 28 specifies required outcomes: a documented ICT third-party risk strategy, a comprehensive vendor register, pre-contract due diligence, and exit strategies for critical functions. In practice, most financial entities use ISO 27001/27036 or NIST 800-161 to build the structural backbone that satisfies Article 28, supplemented by DORA’s own regulatory technical standards on subcontracting and ICT concentration risk.

Is NIST SP 800-161 only for federal agencies, or can private sector organizations use it?
NIST SP 800-161 was developed as guidance for U.S. federal information systems, but its supply chain risk management controls apply to any organization managing complex vendor relationships. Private sector organizations in critical infrastructure, financial services, and manufacturing regularly use NIST 800-161 as a program framework. No licensing requirement or federal affiliation is required to adopt it.

Does CSRD require a TPRM framework, or does it overlap with supply chain due diligence under CSDDD?
They address different obligations. CSRD’s ESRS S2 standard requires disclosure of material impacts on workers in the value chain: a reporting requirement. CSDDD Article 8 requires active identification and assessment of adverse human rights and environmental impacts across the supply chain: an operational due diligence requirement.

Following the Omnibus I Directive (in force 18 March 2026), the phased implementation structure has been replaced by a single compliance deadline of 26 July 2029. The Member State transposition deadline is 26 July 2028. Scope has been narrowed: CSDDD now applies to organisations with more than 5,000 employees and EUR 1.5 billion net worldwide turnover.

How often should third-party vendors be reassessed within a TPRM framework?
Reassessment frequency should follow risk tier, not a fixed calendar. High-risk vendors with access to sensitive data, critical operational dependencies, or rapidly changing regulatory exposure warrant at minimum annual reassessment, supplemented by real-time continuous monitoring for changes in security posture, financial health, or regulatory status. Medium- and low-risk vendors can operate on 18- to 24-month cycles. DORA Article 28(3) requires financial entities to report annually to regulators on the number of new ICT third-party arrangements entered into during the year. This does not mandate annual reassessment of all vendors — reassessment frequency remains risk-based — but it creates a regular reporting rhythm that supports an annual review of the vendor register.

Editor’s Note: This post was originally published on Prevalent.net. In October 2024, Mitratech acquired Prevalent, an AI-enabled third-party risk management platform. The content has been updated to reflect Mitratech’s product offerings, current regulatory developments, and compliance changes.