From Risk Reality to Readiness: Practical Preparation for TPRM in 2026

In TPRA’s December blog, “TPRM State of the Industry: The 2026 Risk Reality Check,” Heather Kadavy laid out what many practitioners are dealing with heading into 2026, deeper dependency chains, more AI use by third parties, higher expectations for ongoing oversight, and external pressures that land through suppliers. 

This blog will discuss what to do with that reality in practice. The sections below focus on preparation and actions that can be put in place early and reused throughout the year, so programs are not rebuilding workflows every time a third party issue surfaces. 

What follows is practical guidance, not a maturity model or a checklist. The goal is usable steps that support consistent execution as issues surface. 

1) Third Party visibility that supports decisions 

Third Party issues often become harder to manage once the same questions circulate across functions. Questions such as who is involved, what systems or data are affected, and which dependencies sit behind the third party. When that information is fragmented, early coordination slows. 

• Consolidate third party inventories across Procurement, IT, Cyber, Privacy, Finance, and Compliance. 

• Tag third parties with service, data they can access, criticality, connectivity, primary hosting region, and key sub-service providers. 

• Track unknowns, such as unclear data exposure or missing sub-service provider detail, and reduce them over time. 

Visibility supports alignment when decisions are needed. 

2) Tiering for effective and efficient risk management 

As third party populations grow, tiering becomes essential to keep program requirements proportional to inherent risk. The point is not only due diligence depth. Tiering and criticality help structure how the program addresses the most common risks and the biggest threats in a consistent way. 

• Define your risk tiers (high, moderate, and low) using inherent risk factors such as data sensitivity, access level, operational criticality, concentration risk, regulatory compliance and geography. 

• Identify third parties that are essential to operations, interact directly with customers, or could reasonably drive regulatory scrutiny if they fail or experience an incident, and flag them as critical. 

• Assign every third party both a risk tier and a critical or not critical designation, so the program can clearly identify which vendors require the most scrutiny, due diligence, monitoring, and oversight. 

• Use the risk tier to set baseline program requirements, such as due diligence scope, evidence expectations, monitoring cadence, issue management timelines, and escalation triggers. 

• For critical third parties, set heightened requirements across contracts, business continuity and disaster recovery expectations, scenario testing, performance monitoring, and incident coordination. 

The intent is to structure program effort around where risk and impact concentrate. 

3) Practical Nth-party accountability 

Sub-service provider exposure often becomes visible after an issue has already arisen. At that point, teams are working to understand who else is involved and what leverage exists. 

• Require disclosure of material sub-service providers, hosting locations, and changes that affect data or service delivery. 

• Request sub-service provider data maps for critical third parties only, focused on dependencies that carry real impact. 

• Start with a small group of critical third parties and expand once the process is repeatable. 

Sub-service provider work tends to be most useful when it starts with the dependencies that affect service delivery or data exposure, then broadens over time. 

4) Monitoring with clear ownership, including performance 

Many organizations receive more third party risk information than they can act on. Without thresholds and ownership, monitoring loses operational value. Monitoring also needs to cover performance, not just risk events, because service degradation and missed deliverables often surface before a formal incident. 

• Define a short list of conditions that require attention, such as breach disclosures, ransomware activity, sanctions exposure, financial distress, critical vulnerability exposure, major control changes, or sustained service issues. 

• TPRM sets the cadence and requirements for monitoring based on risk tier and criticality, including what must be reviewed, how it is documented, and when escalation is required. 

• The business owner manages third party performance and is accountable for driving timely, complete remediation with the third party, including Service Level Agreement (SLA) review, corrective actions, and escalation when customer or operational impact is at stake. 

Ownership and accountability drive follow-through and better outcomes. 

5) Third party incident readiness and continuity coordination 

Third Party incidents rarely affect just one function. They can raise legal questions, trigger privacy assessments, affect operations, or require triage from Information Security teams. When a critical provider is degraded or offline, business continuity and recovery planning becomes part of the same conversation. 

• Develop a third party incident and continuity playbook with cyber, legal, privacy, procurement, business owners, and business continuity and recovery stakeholders. Include notification and evidence requests, impact assessment, escalation paths, communications, recovery time and recovery point expectations, workaround options, and decision points for failover or alternate sourcing. 

• Run tabletop exercises that include both incident handling and service disruption scenarios, using at least one critical third party as the case study. 

• Confirm 24/7 contacts, notification SLAs, and continuity-related commitments for critical third parties, including recovery objectives and support expectations during disruptions. 

Preparedness here reduces confusion during incidents and shortens the path from impact to recovery. 

6) AI governance in intake and contracts 

AI use by third parties can affect data handling, security controls, and compliance obligations. Addressing expectations early helps reduce rework later. 

• Ask where AI is used, what data it touches, if data is used to train models, retention practices, access controls, and incident handling. 

• Include contract language on data use, transparency, and notification when AI-related practices change. 

• Require third parties to identify material changes to AI-enabled features, underlying model providers, or data processing workflows that could affect confidentiality, integrity, availability, privacy, or regulatory obligations. 

The goal is oversight and defensible governance, not blocking adoption. 

7) Regional and geopolitical disruption 

External pressures often reach organizations through suppliers. Preparation means thinking through how disruption would affect service delivery and contractual obligations. 

• Identify single points of failure by region, facility, cloud zone, or logistics route. 

• Document substitution options and what can be paused if disruption occurs. 

• Run scenario exercises tied to regional or geopolitical disruption and update continuity assumptions. 

Scenario work surfaces dependencies that are otherwise easy to miss. 

8) Cross-functional integration 

Third party issues tend to escalate when relationship ownership, escalation paths, and decision authority are not clearly defined. 

• Name a business owner for each third party to own the relationship and drive risk remediation. Document risk acceptance authority and escalation paths, typically an executive owner or committee.  

• Hold regular decision meetings for exceptions, remediation approvals, renewals, access changes, and exits. 

• Maintain an exceptions register with clear expiration dates. 

Regular coordination keeps decisions moving and reduces friction when issues span multiple functions. 

9) Develop a scorecard leadership will use 

A small, consistent scorecard helps leadership see where risk is concentrated and where follow-up is lagging. 

Track a limited set of measures: 

• Percent of critical third parties with current evidence-based validation 

• Percent with known material sub-service providers 

• Time to triage third party incidents 

• High-risk issues past agreed timelines 

• Concentration risk across core functions 

Metrics are most useful when they inform decisions and drive action. 

Closing thought 

None of these actions require rebuilding a TPRM program. They require clarity on roles, a disciplined way to separate critical third parties from the broader population, and monitoring and escalation approaches that connect risk signals to real follow-up. The programs that hold up best tend to be steady on the fundamentals, especially when third party issues arrive alongside procurement deadlines, operational pressure, and leadership questions. 

---

Author Bio

Hilary Jewhurst

Sr. Membership & Education Coordinator at TPRA

Hilary Jewhurst is a seasoned expert in third party risk and risk operations, with nearly two decades of experience across financial services, fintech, and the nonprofit sector. She has built and scaled third party risk programs from the ground up, designed enterprise-wide training initiatives, and developed widely respected content that helps organizations navigate regulatory complexity with clarity and confidence.

Known for turning insight into action, Hilary’s thought leadership and educational work have become go-to resources for professionals looking to mature their TPRM programs. She regularly publishes articles, frameworks, and practical guides that break down complicated risk topics into meaningful, accessible strategies.

Hilary recently joined the Third Party Risk Association (TPRA) as a staff member, supporting industry-wide education, peer learning, and advancing best practices. She is also the founder of TPRM Success, a boutique consultancy that helps organizations strengthen their third party risk management capabilities through targeted training, tools, and strategic guidance.