Third-Party Risk Management Framework: One Lifecycle, Twelve Regimes (2026 Guide)

A third-party risk management framework is the structure that turns a dozen separate regulatory obligations about suppliers, vendors, processors and outsourcing into one programme that can be run, evidenced and shown to whoever asks. The tempting mistake is to build the framework around the regime that examined you last. This guide sets out how a third-party risk management framework built on the lifecycle maps to twelve regimes at once, from the US Interagency Guidance and NIST CSF 2.0 to DORA, ISO/IEC 27001, SOC 2, PCI DSS, GDPR, HIPAA, NYDFS and the EBA guidelines, and what each regime actually adds.

What this guide covers

• Why one third-party risk management framework, not seven
• The spine: the lifecycle every regulator describes
• How each regime maps to the third-party risk management framework
• The governance layer of the third-party risk management framework
• The inventory and tiering layer
• Due diligence, contracting and monitoring across the regimes
• Regional regimes attach the same way
• What the framework’s document set contains
• Building the third-party risk management framework
• Frequently asked questions about a third-party risk management framework

Why one third-party risk management framework, not seven

Every regime that touches third parties says the same three things. The organisation keeps responsibility for what it contracts out. Effort must be proportionate to risk. And the relationship must be planned, checked, contracted, monitored and ended in a way that leaves a record. They differ in vocabulary, in which stage they detail most, and in the specific provisions they require. A third-party risk management framework built on the lifecycle absorbs those differences as a crosswalk rather than as separate programmes, which is why a bank can show the same documents to its prudential supervisor, its SOC 2 auditor and its data protection authority.

The alternative, a framework per regime, produces three inventories that disagree, questionnaires that ask the same provider the same questions three times, and a board that cannot see its concentration because no single register holds it. It also costs three times as much to keep current.

The spine: the lifecycle every regulator describes

The spine of the framework is the five-stage lifecycle: planning, due diligence and selection, contracting, ongoing monitoring and termination, with governance across all five. The 2023 Interagency Guidance sets it out in the most detail, with 90 enumerated considerations; our guides to the TPRM lifecycle and the Interagency Guidance cover the stages and the text. What follows is how the other eleven regimes attach to that spine.

How each regime maps to the third-party risk management framework

The governance layer of the third-party risk management framework

NIST CSF 2.0’s GV.SC-01 asks for a programme, strategy, objectives, policies and processes agreed by stakeholders; the Interagency Guidance places ultimate responsibility with the board and names what management must do; DORA Article 28(2) requires a strategy on ICT third-party risk reviewed by the management body; EBA/GL/2019/02 sections 5 and 7 require sound governance and a written outsourcing policy. In a third-party risk management framework those four requirements are one policy, one charter and one appetite statement, approved once. The CSF 2.0 informative references already map GV.SC to ISO/IEC 27001:2022 5.19 and 5.20, which is a useful check that the crosswalk is not invented.

The inventory and tiering layer

GV.SC-04 says suppliers are known and prioritised by criticality. PCI DSS 12.8.1 requires a list of providers with a description of each service. DORA Article 28(3) requires a register of information distinguishing arrangements that support critical or important functions. NYDFS 500.11(a)(1) requires identification and risk assessment of providers. EBA section 11 sets documentation requirements for the register. Five regimes, one inventory in the third-party risk management framework, provided it carries the fields all five need: tier, criticality, data classes, access, locations, subcontractors and contract dates. Tiering is the framework’s answer to the proportionality every regime demands: a fixed set of inherent-risk questions whose answers set the depth of every later stage.

Due diligence, contracting and monitoring across the regimes

Due diligence is required by GV.SC-06, SR-6, DORA Article 28(4)(d), EBA section 12.3, PCI DSS 12.8.3, NYDFS 500.11(a)(3) and GDPR Article 28(1), and the Interagency Guidance’s fourteen factors are the fullest statement of what it covers. A third-party risk management framework runs one tiered procedure, with three questionnaires of increasing depth, and cites all seven.

Contracting is where the regimes are most specific and most different. DORA Article 30 lists nine elements for every ICT arrangement and six more for critical functions; GDPR Article 28(3) lists eight processor obligations; HIPAA 164.504(e)(2) lists the business associate contract content; NYDFS 500.11(b) names representations and warranties. A single contract requirements checklist that maps every provision to its regime, with a clause reference column, is the instrument that makes this manageable. Monitoring is required by GV.SC-07, ISO/IEC 27001 control 5.22, EBA section 14, PCI DSS 12.8.4 and NYDFS 500.11(a)(4); the third-party risk management framework sets one cadence by tier and cites all five.

Regional regimes attach the same way

The mapping does not stop at the twelve. SAMA’s cyber security framework and its outsourcing rules, which our guide to SAMA outsourcing covers, attach to the same lifecycle at the same points; so do the UK’s PRA SS2/21 and the Critical Third Parties regime that went live on 13 July 2026. A third-party risk management framework built on the lifecycle gains a regime by adding a column to the crosswalk, not by adding a programme.

What the framework’s document set contains

A third-party risk management framework is only as real as the documents that operate it. The minimum set, whichever regimes apply: a policy, a charter and a risk appetite statement at the governance layer; an inventory with a tiering methodology and a critical-function register; a planning assessment used before selection; a tiered due diligence procedure with the questionnaires already written and a scoring guide; a contract requirements checklist with a clause library and a security schedule behind it; a monitoring procedure with a reassessment schedule, a findings register and an incident log.

Then the closing layers: exit plans for critical arrangements with a contingency plan and a test record; concentration and fourth-party registers; and the metric definitions and reporting pack that put the whole third-party risk management framework in front of the board. Each document names the requirement identifiers it answers, so the crosswalk is generated from the documents rather than maintained beside them.

Building the third-party risk management framework

The order of work matters more than the volume. Approve the policy and appetite; build the inventory from three sources until they agree; tier every relationship; bring the critical tier up to standard first, contract by contract; then set the monitoring cadence and write the exit plans. The TPRM Toolkit ships that framework as 86 templates, with a crosswalk workbook that maps every one of the 188 requirement identifiers across these twelve regimes to the document that answers it, and a gap tool to plan the first ninety days.

For the starting point, read what TPRM is; then the TPRM policy, the third-party risk assessment and fourth-party risk guides each build one layer of the framework.

Frequently asked questions about a third-party risk management framework

Which regime should a third-party risk management framework be built on?

The lifecycle, which all of them share, using the Interagency Guidance as the spine because it is the most granular. The regime that examines you most is then a column in the crosswalk, not the skeleton.

Do we need a third-party risk management framework if we are only ISO 27001 certified?

Annex A controls 5.19 to 5.23 require supplier policy, agreements, ICT supply chain management, monitoring and cloud controls. That is most of the framework already; building it on the lifecycle costs little more and prepares you for the next certification or regulation.

How does the framework handle a regime that changes?

By dating its sources and updating the crosswalk column. EBA/GL/2019/02 has a replacement in consultation and PRA SS2/21 has a new version applying from March 2027; a framework that cites editions can absorb both without restructuring.

Is a spreadsheet enough?

For the inventory and the crosswalk, a well-designed workbook is exactly right. For the policy, procedures, questionnaires, contract checklist and exit plans, it is not; those are documents an examiner reads.