Search Results

Third party risk management (TPRM) looks very different now than it did 20 years ago. Back then, teams mainly checked procurement and contracts and conducted basic due diligence. Rules were simpler, and oversight was mostly manual. Today, TPRM covers just about every part of the business, including cybersecurity, privacy, resilience, business continuity, AI, fourth-party and supply chain risks, compliance, Environmental, Social, Governance (ESG), and even geopolitics. The field has become more specialized, with dedicated professionals, certifications, technology tools, and standardized industry practices. As TPRM evolves, practitioners must continuously learn to ensure their skills remain current. This article covers key TPRM skills to consider in today’s environment and shares practical ways to build them through your daily work and ongoing learning. Practical Technical Skills and Understanding Everyone working in TPRM should have a solid grasp of the basics: lifecycle stages, core risk domains, risk tiering, critical third party identification, ongoing monitoring and reassessment, performance oversight, and offboarding. Comfort with these fundamentals is essential for TPRM professionals. The next sections outline technical skills and experience that are increasingly vital for both new and seasoned practitioners. Understanding AI in a TPRM Context By now, most professionals have heard that anyone who does not learn AI will be left behind. For TPRM practitioners, the bar is higher than just knowing how to use a tool. The key capability is understanding how AI is actually being used across your organization and your third party ecosystem, as well as how that use affects existing risk domains such as cybersecurity, privacy, operational resilience, reputation, and governance. Organizations vary in AI maturity. Some have formal governance and oversight; while others are still finding out where AI is used across their business and third party services. Even when governance structures are still developing, effective third party risk practitioners prioritize understanding AI well enough to ask informed questions, recognize its presence in workflows and products, and identify potential operational, cybersecurity, or compliance concerns before formal processes are established. Ways to build capability include: Learn the basics of how AI systems function, including concepts such as large language models, training data, automation, model drift, and generative AI. Focusing on your higher-risk third parties, pick one that markets “AI-powered” capabilities and review its documentation, privacy notice, or security whitepaper. Note where data use, governance, and controls are clearly explained and where information is vague or missing. Ask internal Security, Data, Architecture, or Technology teams to walk through one existing AI use case and its risk review. Identify which of those questions you should also be asking during third party due diligence. Review a current questionnaire, contract template, or assessment process and identify where AI-related questions, disclosures, or governance language should be added or strengthened. Spending time on these activities helps you see how AI really works in your company and with third parties. This hands-on experience shows that AI is more than just an abstract idea. Seeing Risk Beyond the Questionnaire Many third party risks don’t show up in questionnaires or security checks. Instead, they appear as outages, repeated failures, missed promises, poor escalation, unhappy teams, or customer complaints. It’s important to spot risks beyond checklists and understand how vendors work every day. Strong TPRM links third party oversight to real operations. This requires knowing where the business relies most on a provider, where workarounds exist, where support issues recur, and where failures cause disruption. These insights often come from conversations, incident reviews, and observing relationships over time. Ways to build capability include: Ask a business owner to walk through how they use a key third party during a normal workday, including where they experience the most dependency, delays, or operational pain points. After a third party-related incident or outage, review the event summary and identify where stronger TPRM visibility or earlier questioning may have helped surface concerns sooner. Sit in during operational, service review, or escalation meetings involving key third parties to see how issues are handled in practice versus how they appear in contracts or assessment responses. Review recurring support tickets, performance metrics, or complaint trends tied to critical third parties and look for patterns that may indicate broader operational or governance concerns. Strengthening this area helps you spot operational risks early, establish credibility with business stakeholders, and expose hidden gaps that questionnaires may miss. The key is proactively identifying risks and gaps before they impact operations or stakeholder trust. Turning Data into Something People Can Use Most TPRM teams collect plenty of data, but much of it is hard to use or doesn’t support decision-making. Reports can be overwhelming, dashboards confusing, and important issues can get lost. A key skill is making information clear so the business can focus on what matters. You don’t need to be a reporting pro or data-visualization expert, but you do need to organize info so people can see the real risks, know what matters, and focus. The best reports make things clear quickly, not just dump out all the data. Ways to build capability include: Review a dashboard or report your team regularly produces and identify what people actually reference during meetings versus what is largely ignored. Take a large third party spreadsheet and reduce it to a short summary focused only on critical third parties, overdue remediation items, or unresolved high-risk issues, then see whether the simpler version improves the discussion. Ask a business stakeholder which third party metrics or reports they actually find useful versus which ones feel confusing or too complicated. Practice summarizing a complicated third party issue in a few plain-language sentences without leaning on acronyms, scoring formulas, or framework terms. When you make data easier to understand, people can make better decisions. Clarity helps drive action with confidence. Building Contract and Performance Awareness No one expects you to be a lawyer, but you do need to know contracts and performance standards well enough to spot when something is missing, unclear, or doesn’t line up. Big risk calls often hinge on service levels, security promises, escalation rules, audit rights, or how you can end a contract, even if you’re not the one negotiating the details. Good TPRM means spotting the gap between stakeholder assumptions and contract terms. If you understand service level agreements (SLAs), reporting, and accountability, you give better advice and catch problems before they become disputes. Ways to build capability include: Select one important third party agreement and review only the sections tied to SLAs, security obligations, audit rights, incident notification requirements, and termination language, then summarize the key commitments in plain business language. When a third party repeatedly underperforms, compare the operational issues being reported to the contractual requirements and identify where expectations and obligations do not line up. Sit with Procurement, Legal, Vendor Management, or Business teams during a contract review discussion to see which provisions tend to create the most negotiation friction or operational risk. Review a recent third party’s escalation or dispute and identify whether the issue stemmed from poor performance, unclear expectations, weak governance, or contract language that lacked specificity. Improved contract and performance awareness empowers you to address gaps early and drive realistic risk conversations. Takeaway: Understand contracts to manage operational outcomes. Soft skills deserve equal attention Technical expertise helps you identify problems and assess risk, but your influence on outcomes hinges equally on how you communicate, negotiate, and collaborate. These interpersonal skills are least likely to be automated, making them necessary for long-term career endurance in this field. Telling the Risk Story So People Listen Risk management matters only when people understand it clearly enough to make decisions or act. Many TPRM teams provide detailed, accurate assessments, yet leaders leave discussions uncertain about priorities. The ability to explain risk in practical, relevant terms tied to business impact is priceless. Effective communication in TPRM is not about sounding technical. It is about making information usable. Stakeholders need to understand the issue, how it could affect the business, the trade-offs, and the action you recommend. That often means simplifying language, cutting unnecessary detail, and focusing on consequences and decisions rather than framework terminology. Ways to strengthen this area include: Take a recent assessment or finding and rewrite the summary for a business leader in five short sentences, focusing on impact, exposure, and available options. Before a meeting or escalation discussion, identify the specific decision, approval, or action you need and shape your talking points around that outcome. Review an older risk report or assessment summary and spot where acronyms, scoring language, or technical detail may have made the message harder to understand. Ask a non-TPRM stakeholder to review one of your summaries or presentations and explain back what they believe the risk or concern is, then notice where misunderstandings occur. Clear communication makes it much easier to build stakeholder trust, gain support for remediation efforts, and help the business make well-informed decisions. Handling Stakeholders, Negotiation, and Conflict TPRM is often caught between different pressures. Business teams want speed and flexibility. Security wants stronger controls. Legal cares about liability. Procurement focuses on cost and timing, and third parties want quick agreements. Handling these tensions is a normal part of the job. The goal isn’t to win every argument or block progress. Good TPRM work means raising concerns clearly, explaining trade-offs, and helping others make reasonable decisions without causing extra friction or damaging relationships. Ways to strengthen this area include: During a difficult conversation or escalation, start by clearly summarizing the other party’s priorities or concerns before presenting your own risk perspective or recommendations. When documenting disagreements or unresolved concerns, frame the situation around available options, tradeoffs, and potential impacts rather than reducing it to a simple approval-versus-rejection decision. Observe how experienced leaders in your organization handle difficult stakeholder conversations, especially where business pressure and risk concerns collide. After a challenging meeting, reflect on which communication approaches helped move the discussion forward and which ones created defensiveness or blocked progress. Getting better at this builds your credibility and helps others see TPRM as a collaborative partner who solves problems, not just a gatekeeper. Growing Yourself and Your Team If you lead a TPRM function, these same capabilities apply at the team level. The work is changing, and so are expectations. It is not enough to build processes and buy tools. Teams need chances to practice, learn from mistakes, and grow in both technical and soft skills. To ensure ongoing development is effective, consider tracking team growth through regular skills assessments, structured feedback sessions, and peer reviews. These approaches help you spot where the team is making progress and where more support is needed. You don’t need a formal rotation program. Small, intentional opportunities within your current work can help people grow. In practice, that can look like: Giving analysts chances to present their own work instead of always presenting for them, then debriefing afterward on what landed well and what could be clearer next time. Inviting team members to observe a contract negotiation, a difficult third party call, or a high-stakes risk discussion, and then talking through why certain points were pushed, where tradeoffs were made, and how tone influenced the outcome. Using real assessments, incidents, or escalations as teaching moments, walking through not just what decision was made, but how you weighed business pressure, control gaps, and relationship impact. Pairing less experienced staff with more senior colleagues on complex third parties so they can see how judgment is applied, not just how checklists are completed. These practices help move TPRM from just following steps to building real judgment, which is more important than ever. Conclusion Third party risk management will continue to evolve as long as organizations rely on external products, services, platforms, and partners. There is no way to predict exactly what the next few years will bring, whether that is new regulatory pressure, different operating models, more embedded AI, or risks that are not getting enough attention today. What tends to set the most effective people in this field apart is a strong grasp of the foundations, paired with communication, judgment, stakeholder management, and a willingness to keep learning as the environment changes. For people already doing this work, that means keeping your eyes open, staying curious, and treating the job itself as part of your ongoing development. With so many skills to develop, it helps to prioritize based on both organizational needs and your personal areas for improvement. Start by talking with your manager or stakeholders about which risks or capabilities are most urgent for your business right now. Consider where you feel least confident or where you have received feedback, and target skill-building there first. Reviewing recent incidents, business objectives, or audit findings can also help you choose the most relevant areas to focus on. By identifying a few high-impact skills to work on at a time, you can make continuous progress without becoming overwhelmed. For those leading teams, it also means building the bench, creating opportunities for people to grow, and helping strong practitioners expand into the more extensive range the field now demands. 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.

Executive Summary Third-Party failures rarely begin as legal disputes. They being as performance weaknesses, control breakdowns, or operational gaps that contracts failed to anticipate, define or enforce. Most organizations treat contracts as legal protection and service level agreements (SLAs) as operational metrics. But in reality, contracts and SLAs are among the most powerful risk management tools an organization has – if they are designed to reflect the priorities of all stakeholders and monitored through a risk lens. This paper introduces the concept of Contractual Fitness: the degree to which a vendor agreement translates enterprise risk, regulatory expectations, and resilience requirements into enforceable obligations and measurable performance indicators. It also outlines how SLA performance monitoring, when aligned to risk impact rather than technical convenience, becomes an early warning system for vendor instability, compliance exposure, and operational disruption. The Core Problem: Why Contracts Often Fail the Business Across industries, contracts are negotiated in silos Function What They Focus On What Often Gets Missed Legal Liability, indemnification, dispute terms Operational enforceability of resilience & security IT Technical SLAs Business impact of service degradation Compliance Regulatory clauses Monitoring mechanisms to validate compliance DR/Resilience Recovery capabilities Contractual testing and proof requirements Procurement Commercial Terms Risk-based performance accountability TPRM Risk identification Ensuring mitigations become binding obligations Results: risks are identified during due diligence but never fully embedded into contractual language or measurable SLAs. Contracts describe services – they don't always control risks. Defining Contractual Fitness Contractual Fitness is the alignment between: Risk Exposure – What could go wrong Contractual Obligation – What the vendor is legally required to do Performance Metrics (SLAs) - How ongoing effectiveness is measured Governance & Enforcement – What happens when performance degrades A contract is “fit” when risk expectations are: Clearly Defined Measurable Auditable Enforceable Stakeholder Priorities and How They Translate into Contract SLAs Vendor risk is multi-dimensional. A contract that works only for Legal or for IT is incomplete. Below is a cross-functional view of what each stakeholder needs from vendor agreements. Stakeholder Primary Concern Critical Contractual Clauses Key SLA / Monitoring Metric Common Gap Information Security Protection of systems and data Security control requirements, vulnerability management, audit rights, incident notification timeliness Patch remediation timeliness, vulnerability remediation cycle time, incident response time Security language is vague (“reasonable security”) and not measurable Privacy Lawful data processing & subject rights Data Processing Addendum, sub processor approval, cross border transfer terms, deletion or return of data DSAR support response time, deletion certification timelines, sub processor change notifications Privacy obligations exist but are not operationalized or tracked DR / Resiliency Service recovery within tolerance Defined RTO/RPO, mandatory testing, geographic redundancy, dependency transparency DR test success rates, actual recovery time vs. Contracted RTO, backup validation results RTO/RPO written in contract but no tested or reported IT / Engineering Reliable technical performance Availability SLAs, incident response SLAs, change management notice, maintenance windows Uptime % latency, MTTR (mean time to restore), change notification timeliness SLAs measure performance but not business disruption Legal Liability containment & enforceability Indemnification, limitation of liability carve-outs, termination rights, cooperation clauses Tracking repeated breaches of contractual obligations Operational failures not escalated as contractual risk triggers Compliance / Regulatory Ability to demonstrate oversight Right to audit, regulatory cooperation, control evidence requirements Timeliness of evidence delivery, audit finding remediation timeliness Contract allows audit, but evidence collection is not structured Finance / Procurement Financial exposures & value Service credits, benchmarking, billing audit rights, termination for convenience SLA credit trends, billing accuracy rates, overcharge recovery Credits are claimed but not analyzed as risk signals TPRM Holistic risk oversight Risk-based obligations, subcontractor flow-down performance reporting requirement SLA degradation rends, control testing results, unresolved issue aging Risk findings don’t always translate into enforceable contract terms. From Clause to Control: What “Good” Language Looks Like A major element of contractual fitness is moving from vague commitments to measurable obligations. Risk Area Weak Clause Contractually Fit Clause DR “Vendor will maintain disaster recovery capabilities” “Vendor shall maintain DR capabilities sufficient to restore services within an RTO of 8 hours and an RPO of 15 minutes. Vendor will conduct at least annual failover testing and provide documented results and remediation plans.” InfoSec “Vendor will use reasonable security measures” “Vendor shall maintain security controls aligned to ISO 27001 or NIST CSF and remediate critical vulnerabilities within 14 days and high vulnerabilities within 30 days.” Incident Notification “Vendor will notify customer of breeches promptly” “Vendor shall notify Customer within 24 hours of becoming aware of a confirmed or suspected security incident affecting Customer Data and provide status updates every 48 hours until containment.” Sub processors “Vendor may use subcontractors” “Vendor must provide 30 days prior notice of new sub processors, flow down equivalent security and privacy obligations, and remain fully liable for their performance.” SLA Reporting “Vendor will provide performance reports.” “Vendor shall provide monthly SLA performance reports including uptime, incident metrics, and root cause analysis for any SLA breach.” SLA Performance Monitoring as a Risk Discipline SLAs are often treated as operational scorecards. But they are more powerful when viewed as risk indicators. SLA Metric Traditional Interpretation Risk-Based Interpretation Uptime % Service quality Operational continuity and customer impact risk Incident Response Time Help desk efficiency Cyber containment and business disruption risk DR Test Results Technical exercise Organizational survival dependency Patch Timelines IT hygiene Exposure window for cyber exploitation Change Notification Process formality Risk of unassessed system or data impact When TPRM tracks these metrics over time, patterns emerge that may include: Control fatigue Under-investment by the vendor Operational instability Elevated breach or outage likelihood Trending & Early Warning Indicators Isolated SLA failures happen. Trends tell the real story. Trend Patterns Potential Risk Signals Gradual increase in SLA credits over multiple quarters Declining service quality or capacity strain Missed DR testing deadlines Weak recovery preparedness Slower vulnerability remediation times Security control deterioration Increasing incident response times Staffing or Operational stress at vendor Delays in providing audit evidence Compliance maturity issues These trends allow organizations to act before a regulatory breach, data compromise, or major outage occurs. Governance: What Happens When Performance Degrades Measurements without action creates - “risk tolerance” by default. A contractually “fit” governance model includes: Operational Review – immediate discussion of SLA breach Formal Notice of Performance Concerns – Triggered by repeated failures Executive Governance Escalation – senior-level accountability Documented Remediation Plan – with deadlines and reporting Termination Readiness – exercising exit rights if risk remains unacceptable. These steps must be supported by contract clause allowing: Formal notice of breach Mandatory remediation Service credits Termination for chronic failure The Integrating Role of TPRM TPRM is uniquely positioned to connect: Phase TPRM Role Pre-Contract Identify risk and required control expectations Contracting Ensure risk requirements translate into clauses & SLAs Ongoing Monitoring Analyze SLA trends and control performance Escalation Elevate chronic issues as enterprise risk concerns Renewal / Exit Use performance history to inform decisions TPRM transforms contracts from static documents into dynamic risk management tools. Actionable Take-Aways For TPRM Map risk tiers to mandatory clauses and SLA expectations Trend SLA performance as part of ongoing monitoring Treat repeated SLA failures as risk events, not vendor nuisances For Legal Replace “reasonable efforts” with measurable, auditable standards Preserve audit, termination, and step-in rights Ensure operational clause are enforceable, not just aspirational For IT, Security, Resilience Team Define SLAs based on business impact tolerance, not vendor defaults Require testing and documented evidence for recovery and security claims For Procurement & Finance Analyze SLA credits and billing issues as indicators of operational risk Tie commercial leverage to performance accountability For Executives View chronic vendor underperformance as an enterprise risk signal Support cross functional governance when SLA show sustained decline Contracts should not simply describe services; they should operationalize trust. When risk expectations are translated into enforceable obligations and monitored through meaningful SLAs, vendor agreements become what they were always meant to be. A front-line control for protecting the organization's operations, data, customers, and reputation. Authors Heather Kadavy Director of Membership Success at TPRA Ryan Hesser VP Third Party Risk Mgmt & Legal Counsel at VyStar CU

In this episode of the TPRM Exchange Podcast, host Hilary Jewhurst sits down with Tracy Keeping, Founder of Steel Harbor Consulting and former risk executive at State Street, JPMorgan Chase, and Deutsche Bank, to explore one of the most pressing challenges facing third party risk programs today: geopolitical uncertainty. “Geopolitical uncertainty becomes a third party problem the moment it impacts operational decisions.” The conversation explores why traditional geopolitical risk assessments often fail to capture the speed and interconnectedness of these changes, and how organizations can move from passive visibility to active decision-making. Rather than treating geopolitical risk as a standalone category, Tracy explains how emerging conditions are exposing vulnerabilities hidden deep within vendor ecosystems, supply chains, cloud infrastructure, and subcontractor dependencies. “Geopolitical risk isn’t creating entirely new problems — it’s accelerating the risks organizations already have.” This episode is especially valuable for practitioners navigating: Rapidly changing supplier and jurisdictional exposure Escalating concentration and fourth-party risk Executive pressure to make faster decisions with incomplete information The growing gap between assessment cycles and real-world events Governance and accountability challenges during periods of uncertainty Key Takeaway Geopolitical risk is no longer a static checkbox within a risk framework — it is a dynamic force accelerating existing vulnerabilities across third-party ecosystems. Organizations that succeed will be the ones that connect external events to operational decision-making in real time. About the Guest Tracey Keeping Founder and CEO Steel Harbor Consulting Tracy Keeping is the Founder of Steel Harbor Consulting and a former risk executive at State Street, JPMorgan Chase, and Deutsche Bank. 📩 Have a topic idea? Email: pod@tprassociation.org

I was pleased to be invited by Third Party Risk Association to attend April’s session on Emerging Risks and Geopolitical Uncertainty. The discussion reinforced how quickly the third party risk landscape is shifting and how interconnected these risks have become. AI, data sovereignty, supply chain realignment, cyber activity, financial stability, and operational resilience are no longer separate topics. They are converging. Across all of it, one message came through clearly: Organizations need a more integrated and leadership-led response. AI is changing the landscape of third party risk AI is no longer a niche technology issue. It is reshaping how organizations approach vendor oversight, data governance, and cross-border exposure. A vendor that appears straightforward on paper often relies on multiple layers beneath the surface. A SaaS provider may depend on an AI engine, which in turn relies on foundation models and sub-processors across multiple jurisdictions. That means data is moving across countries and entities, often without full visibility. The implication is clear... Organizations need to move beyond generic policy references. AI-specific due diligence, stronger contractual controls, and a clear understanding of data flows must now be foundational. Data sovereignty is now a live, operating issue Data sovereignty is becoming more complex, not less. It is no longer sufficient to know where a provider is headquartered. Organizations need to understand where data is stored, processed, accessed, and transferred across the full ecosystem of providers and infrastructure. The leadership question has shifted. It is no longer “Is the data protected?” It is “Can we clearly explain where our data is going and why?” Geopolitical fragmentation is reshaping supply chain risk Geopolitical tension is actively reshaping supply chains. Regional conflict, sanctions, trade tension, energy disruption, and concentration risk in sectors such as semiconductors and infrastructure are directly affecting resilience, pricing, and service continuity. Many organizations believe they have diversified. In reality, they have often redistributed risk. Third- and fourth-party dependencies remain a significant blind spot. Cyber activity is part of the operating environment Cyber risk continues to evolve in both scale and intent. The TPRA discussion highlighted activity targeting critical infrastructure, telecom providers, and software supply chains. This shift is important to note. This is no longer just about data loss. In some cases, threat actors are positioning themselves inside infrastructure to enable future disruption. This raises a critical question. How much visibility do you really have, not just into your vendors, but into the infrastructure they depend on? Financial stability still matters Financial stability remains a core risk factor, particularly in uncertain markets. Tariffs, energy pricing, and geopolitical instability are directly impacting vendor viability. This is especially relevant for smaller or newer providers where financial transparency may be limited. The practical question is straightforward... If a critical vendor failed tomorrow, could you transition? For many organizations, the answer is still no. Operational resilience is where this all comes together Operational resilience is no longer a standalone activity. It cannot be reduced to documentation or periodic assessments. It is shaped by: Geographic concentration of vendors Supply chain dependencies Location of talent and engineering teams Strength of contracts and communication protocols The ability to respond effectively under pressure The session emphasized the importance of testing real-world scenarios, including third party failure and geopolitical disruption. This is where the leadership challenge becomes visible because these issues do not sit in one function. They cut across legal, procurement, risk, cyber, compliance, operations, and executive decision making. What this means in practice If you are leading third party risk management today, focus on this: Move beyond visibility to decision readiness It is not enough to map vendors and dependencies. You need to understand how decisions will be made when something fails or is disrupted. Define ownership across functions before pressure hits Legal, procurement, risk, and the business often operate independently until there is an issue. Clarity on ownership and escalation paths need to be established in advance. Strengthen how you evidence decisions Regulators and boards are increasingly focused on how decisions are made, not just the outcome. Document rationale, trade-offs, and accepted risk clearly. Test your operating model under stress Tabletop exercises should reflect real scenarios such as geopolitical disruption, vendor failure, or cyber events. Many frameworks work in a steady state but fail under pressure. Reframe third party risk as an organization-wide issue This is no longer a compliance exercise. It requires executive engagement, cross-functional coordination, and board-level visibility. Final reflection The environment is no longer stable enough for siloed responses. AI, geopolitical tension, supply chain concentration, cyber disruption, and vendor viability are intersecting in ways that increase pressure on decision making. Organizations do not need more frameworks. They need to be able to make and defend decisions under pressure. This is where leadership becomes the differentiator. My thanks again to Third Party Risk Association for the invitation and for convening such a timely discussion. Author Bio Tracy Keeping Founder, Steel Harbor Consulting Tracy Keeping is the Founder of Steel Harbor Consulting, providing fractional executive leadership to organizations navigating governance, risk, and operational complexity. She works directly with CEOs and boards to drive decisions, execution, and defensible outcomes.

When the CFO asks "How many active suppliers do we have?", and you get three different answers from Procurement, Accounts Payable, and Legal, you don't have a TPRM problem - you have a data architecture problem. This scenario plays out more often than most organizations care to admit. Third-party risk management programs invest heavily in assessment tools, monitoring platforms, and automation workflows. But underneath all that technology sits a foundation that's often fractured: the supplier data itself. Multiple systems. Duplicate records. Conflicting information. Outdated details. No single source of truth. The result? TPRM teams spend enormous effort not managing risk, but managing data chaos. And that chaos creates real exposure that no amount of sophisticated tooling can fix. The Symptom Everyone Recognizes Ask any TPRM practitioner what consumes their time, and you'll hear familiar complaints: "We discovered during an audit that the same supplier had three different risk tiers across our systems." "IT says a vendor has admin access to our environment, but Procurement has no contract on file for them." "Legal approved a supplier based on one set of financials, but Finance is seeing completely different numbers in their system." "We can't tell auditors when we last assessed a critical supplier because the records are scattered across email, SharePoint, and two legacy platforms." These aren't edge cases. They're symptoms of a structural issue that undermines every TPRM initiative: fragmented supplier information. Why Data Quality Breaks Down TPRM data quality problems don't happen because teams are careless. They happen because of how organizations evolve: Mergers and acquisitions bring together disparate systems, each with its own supplier database. Integration gets deprioritized, and suddenly the organization is operating with three "master" supplier lists. Departmental silos mean Procurement tracks suppliers in an ERP, Compliance uses a GRC platform, IT maintains a separate vendor access registry, and Finance works from Accounts Payable records. Each system becomes authoritative for its domain, but none owns the complete picture. Tool proliferation compounds the problem. Organizations add point solutions for vendor risk scoring, contract management, security assessments, and ESG tracking. Each creates its own data repository. Each requires manual updates. None integrate cleanly. Spreadsheet workarounds emerge when systems don't talk to each other. Teams build Excel-based "integration layers" to bridge gaps. These spreadsheets become critical infrastructure, despite being fragile, error-prone, and impossible to audit. The result is predictable: data decays. Supplier information becomes stale the moment it's entered, because there's no mechanism to keep it current across all the places it lives. The Hidden Costs of Bad Data Poor data quality isn't just an operational annoyance. It creates genuine risk and measurable cost: Failed audits and regulatory findings. When auditors ask for evidence of due diligence on critical suppliers, teams scramble to piece together documentation from multiple sources. Gaps appear. Inconsistencies raise questions. What should be a routine control verification becomes a finding. Duplicate assessments and supplier fatigue. Without a unified view, different teams send overlapping questionnaires to the same supplier. The supplier receives three security assessments, two financial reviews, and four ESG questionnaires in the same quarter - all asking similar questions. Response rates drop. Relationships deteriorate and generate supplier fatigue. Slow incident response. When a supplier experiences a security incident or operational disruption, response speed matters. But if the first 30 minutes are spent identifying who owns the relationship, what data they access, and which business functions they support, the window for effective action closes. Inaccurate risk aggregation. Executive dashboards show supplier risk metrics, but those metrics are only as good as the underlying data. If 40% of supplier records are incomplete or conflicting, leadership is making decisions based on fiction. Blocked business velocity. Sales teams wait for supplier approvals. Procurement can't onboard vendors quickly because compliance workflows are stuck gathering basic information that should already exist. The TPRM program becomes a bottleneck, not because processes are broken, but because data is. How to Diagnose Your Data Quality Problem? The MDM (Master Data Management) appears as the solution. Before fixing data quality, you need to measure it. Here's a practical framework for auditing your current state: Step 1: Map Where Supplier Data Lives List every system that stores supplier information. Don't limit this to "official" systems—include spreadsheets, Accounting, SharePoint sites, and departmental databases. For each system, document: Who maintains it What data fields it contains How often it's updated Who relies on it for decisions Most organizations discover they have 6-10 systems touching supplier data, with no clear owner for ensuring consistency. Step 2: Test for Basic Accuracy Pick 20 critical suppliers at random. For each one, answer these questions: How many records exist for this supplier across all systems? Do the records show the same legal entity name? Do they reflect the same address and contact information? Is the risk tier or classification consistent? Can you identify a single business owner? If you find significant discrepancies in more than 30% of your sample, you have a material data quality problem. Step 3: Measure "Time to Basic Information" Run this exercise: Ask someone outside the TPRM team to answer basic questions about a supplier: Is this supplier currently active? What services do they provide? When was their last risk assessment? Who is the business owner? Are they compliant with our requirements? Time how long it takes to get definitive answers. If it requires more than 5 minutes and multiple system lookups, your data architecture is creating friction. Step 4: Identify the "Data Conflict Rate" Pull supplier records from your three most-used systems. Compare key fields like risk tier, contract status, and last assessment date. Calculate the percentage of records where these fields conflict. A well-governed TPRM program should see conflict rates below 10%. Rates above 25% indicate systemic issues that automation alone won't fix. Building a Data Quality Remediation Roadmap Once you've diagnosed the problem, remediation follows a structured path: Phase 1: Establish a Single Source of Truth The first step is philosophical, not technical: decide where authoritative supplier data will live. This doesn't mean consolidating all systems into one platform immediately. It means designating one system as the "system of record" where the definitive version of core supplier information exists. Core fields typically include: legal entity name, primary contact, business owner, risk tier, criticality designation, contract status, and last assessment date. Other systems can maintain specialized data, but they should reference—not duplicate—the core record. Phase 2: Deduplicate and Consolidate Assign a team, or a subcontractor, to systematically merge duplicate supplier records. This is unglamorous work, but it's foundational. Start with critical and high-risk suppliers, then work down the tier list. Use a consistent methodology: Identify the authoritative record (usually the most recent or most complete) Merge data from other records, preserving any unique information Document the consolidation in an audit log Deprecate old records with clear redirects to the current one Use a common token as the Duns Number Phase 3: Implement Data Governance Data quality doesn't maintain itself. Establish clear ownership and processes: Assign a Data Steward role responsible for supplier data integrity Define update workflows: who can modify core fields, and with what approval Build quality checks into onboarding: new suppliers can't be activated with incomplete records Schedule periodic reviews: quarterly audits of high-risk suppliers, annual reviews of the full population Phase 4: Automate Validation and Monitoring Once foundational data is clean, use technology to keep it that way: Implement validation rules that prevent invalid or incomplete data entry Set up alerts for data conflicts (e.g., if a supplier's risk tier changes in one system, flag for review) Use APIs to synchronize core data fields across systems rather than manual updates Build dashboards that surface data quality metrics: completeness rates, staleness, conflict rates Why Technology Alone Won't Fix This It's tempting to believe that buying a new TPRM platform will solve data quality problems. It won't—at least not by itself. A new platform can provide better structure, more robust validation, and cleaner workflows. But if you migrate messy data into that new platform, you just have expensive, messy data. The organizations that succeed treat data quality as an organizational discipline, not a technology project. They invest in governance, assign clear ownership, and build data hygiene into their operational culture. Technology enables good data management. It doesn't create it. The Strategic Advantage of Clean Data When TPRM teams solve their data quality problem, something remarkable happens: the program shifts from reactive to strategic. Instead of spending hours reconstructing basic supplier information during incidents, teams respond in minutes using reliable, current data. Instead of duplicating assessments across departments, cross-functional teams collaborate from a shared view of supplier risk. Instead of building executive reports manually, leadership gets real-time visibility into third-party exposure. Clean data doesn't just reduce friction—it becomes a competitive advantage. Organizations can onboard suppliers faster, make risk decisions with confidence, and demonstrate control to auditors and regulators without scrambling. Moving from Chaos to Clarity The TPRM data quality problem is solvable, but it requires acknowledging that it exists. Too many organizations layer sophisticated risk analytics and automation workflows on top of fragmented, unreliable supplier information—and then wonder why their programs underperform. The path forward starts with measurement: understand where your data lives, how accurate it is, and where conflicts arise. Then commit to remediation: consolidate, deduplicate, govern, and maintain. The work isn't glamorous, but it's foundational. Because every TPRM capability—risk assessment, continuous monitoring, incident response, regulatory reporting—depends on one fundamental requirement: knowing the truth about your third parties. Author Bio Emmanuel Poidevin CEO and co-founder of Aprovall Emmanuel Poidevin is the CEO and co-founder of Aprovall, a TPRM platform serving 1,800+ organizations. Emmanuel leads Aprovall's vision to centralize supplier information, automate compliance workflows, and enable cross-functional risk management from a single system of record. Connect with Emmanuel on LinkedIn or learn more at www.aprovall.com. Aprovall provides a centralized TPRM platform designed to serve as a single system of record for third-party information, eliminating data fragmentation across procurement, compliance, legal, and risk teams. Organizations use Aprovall to establish data governance, automate validation, and maintain accuracy across the supplier lifecycle. To learn more about building a unified approach to third-party data management, visit www.aprovall.com.

Many third-party risk management (TPRM) programs today have reached a level of operational maturity. They have defined processes, lifecycle coverage, and established workflows for intake, due diligence, and monitoring. But a critical question remains: Is your program actually improving—or just maintaining the status quo? In this episode of the TPRM Exchange Podcast , Hilary , Senior Membership & Education Coordinator at TPRA, speaks with Keith Frantz, Director of Vendor Management at Prosper Marketplace, to explore the difference between maturity and true progress, emphasizing that strong programs continuously evolve alongside changing risks, technologies, and business needs. “If it’s a check-the-box exercise, you have room for improvement.” From identifying signs of stagnation to adapting for emerging risks like AI, this conversation highlights practical ways practitioners can refine assessments, strengthen monitoring, and deliver more meaningful insights to the business. What You’ll Learn Why maturity doesn’t equal improvement Signs your TPRM program may be stagnant How to modernize risk assessments and evidence standards The growing impact of AI and emerging risk domains How better reporting and monitoring drive stronger decisions Why collaboration across procurement, legal, and the business is critical Key Takeaway “Collaboration, communication, and education—that’s what makes a program successful.” About the Guest Keith Frantz, Prosper Marketplace Graduate of Baylor University, worked in Financial Industry for over 20 years under numerous umbrellas. While in the mortgage industry, I worked primarily in default and risk management providing oversight for mortgage servicers. After moving to risk and vendor management, I have built and matured several programs at different companies and now oversee Procurement, Third Party Risk, and Internal Controls for Prosper Marketplace. Have a question or topic idea? Send us your suggestions at: pod@tprassociation.org

It's impossible to ignore what's happening in the world these days. Headlines are nonstop, commentary is everywhere, and every update appears urgent. Many news stories are meant to grab attention or push an agenda, but not all deserve equal focus. For third party risk management (TPRM) teams, the main challenge isn't just keeping up with the news. It's figuring out what actually matters. With so much information available, the important part is connecting outside events to your key third parties, suppliers, and services, and then deciding if you need to take action. Geopolitical issues do not always arrive as dramatic, obvious events, although sometimes they do. War breaks out. Military tensions escalate. Governments impose sudden restrictions. Just as often, the impact shows up through day-to-day operations. A third party can look perfectly fine in a due diligence review and still carry real exposure because of where it operates, what it relies on, and how those dependencies are structured Geography as a Starting Point, Not the Full Picture In many TPRM programs, geography is treated as a separate risk factor. Teams look at where a third party is based, where it operates, and which laws apply. Geography sets the foundation and shapes the legal, regulatory, and business environment for that third party .  Geopolitical risk changes how we think about geography . A place that once seemed stable can quickly become difficult to operate in if sanctions shift, governments add new rules, or broader instability starts to impact business. When Stability Shifts Without Warning  A region that seemed stable can change quickly. Conflict, political decisions, or new regulations can alter operating conditions with little notice. Third parties and key suppliers that looked safe yesterday might need attention today, even if the third party itself hasn't changed.  That's the challenge so many TPRM teams face right now.  The issue isn’t just that instability happens. It’s how fast it can impact critical third parties and their sub-servicers, even when you have strong due diligence and monitoring in place.  A third party in a country that has been stable in the past can still face problems because of its dependencies. Subcontractors, infrastructure providers, logistics networks, and supply chains can all bring risk. Changes in regulations and cross-border rules can also affect how services are delivered.  The impact doesn’t have to be local to be real . It often shows up as disruptions, delays, or changes in how services operate.  Programs that solely depend on periodic reassessment will feel those impacts first. By the time the next review comes around, the situation might already be affecting operations.  The Impacts of Geopolitical Events  When things change, the impact rarely stays in just one area. It usually affects several risk areas at once.  Operational disruption as service delivery slows or degrades  Compliance pressure as sanctions, restrictions, or regulatory expectations change  Dependency exposure as subcontractors and providers are affected  Concentration risk when multiple services rely on the same region or provider  Geography is only the starting point. The real impact comes from how it influences the rest of your third party ecosystem.  What Deserves your Attention  This is where context and nuance matter. The event that gets the most attention isn’t always the one with the biggest impact on your operations. A major event somewhere in the world might not affect your third parties, but a quieter regulatory or policy change could have immediate effects on your operations, data, supply chain, or service delivery.  The practical question is simple: Does this event connect to a specific third party, supplier, service, location, dependency, or requirement that matters right now? If you’re not sure, that’s where you should start looking.  Where the Real Exposure Sits  Organizations will often gather information about dependencies during due diligence, but that’s not the same as thoroughly assessing those dependencies. It also doesn’t mean the third party has examined its own third parties, providers, or sub-servicers as closely.  The question is not always whether the third party itself is in an unstable region. Sometimes the third party looks fine, its geography looks fine, and the real issue sits deeper in the chain. Sub-servicers, supply chains, and infrastructure can be affected long before the direct third party shows visible signs of strain.  Where Monitoring May Fall Short Many people use headline alerts, news aggregators, and general monitoring tools. These might help you stay informed, but more often create a lot of noise without much guidance.  They tell you what’s happening, but not whether it matters for your third party environment.  Where Risk Intelligence and Alert Services Add Value  Risk intelligence services are more effective because they are designed to connect outside events to your third party group.  Different services offer different capabilities. Some focus on company-level monitoring and alert you when a specific third party is affected. Others track geopolitical and regulatory developments across regions. Some provide visibility into supply chains and downstream dependencies, including subcontractors and infrastructure providers. Others focus on cyber or operational disruption tied to external events.  Most programs depend on a combination of these capabilities.  The real value comes from how well alerts are linked to your actual risks.   A useful alert doesn’t just report that something happened in a region. It shows how that event connects to specific third parties, services, or dependencies.  What This Looks Like in Practice  A geopolitical alert might show up as:  A sanctions update affecting a region where a critical supplier operates  A regulatory change affecting data transfer requirements where a third party processes data  A conflict disrupting a logistics route tied to a supplier  A government restriction affecting infrastructure used by a subcontractor  These alerts don’t need to be escalated right away on their own. They need context.  The first step is to check if the alert connects to a third party, service, or dependency that is important to your business.  If it does, the response can stay focused:  confirm whether the third party is directly affected  assess service continuity and contingency plans  check downstream providers and subcontractors  validate whether regulatory obligations have changed  document whether escalation or monitoring is needed  The goal isn’t to react to every alert. It’s to quickly figure out what matters and what steps to take next.  Making it Operational  Managing geopolitical risk in TPRM comes down to three things: knowing which events are relevant to your specific third parties and dependencies, monitoring with tools that connect external developments to your actual environment, and having a program that can move from information to action. These elements reinforce each other, and all three need to be in place.  Taking these actions can help.  Map exposure clearly.  Know where your critical third parties operate, what they depend on, and which services are most important  Be able to report quickly.  When something changes, you should be able to quickly identify affected third parties, including downstream dependencies.  Define triggers for action.  Decide what kinds of changes require outreach, reassessment, or escalation  Assign ownership.  Assign someone to review developments and decide on next steps  Keep responses proportionate.  Not every development needs action, but the next steps should be clear when action is required.  Conclusion   Geopolitical risk is not going away, and the amount of information around it will only continue to grow. Most of that information will be noise. The difference for TPRM teams is whether they can filter it quickly and focus on what actually affects their third party ecosystem.  That is the real work. Not tracking everything, but knowing what matters, when it matters, and what to do about it. When a TPRM program is built that way, it does not need to predict every disruption. It is already positioned to respond when it counts.  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.

In today’s third party risk landscape, the most significant incidents often don’t originate within your organization; they come from vendors, suppliers, and partners you depend on. When that happens, your team is left responding to an event you don’t control, with limited visibility and increasing pressure from leadership and regulators. In this episode of the TPRM Exchange Podcast , host Hilary Jewhurst sits down with Sagar Sudhir Behere , Enterprise (ERM) & Third Party Risk (TPRM) Oversight Senior Manager, to explore what effective incident response looks like in a third party context. Drawing from deep experience in resilience planning and complex outsourced environments, Sagar shares practical insights on how organizations can better coordinate, communicate, and respond when vendor incidents occur. “Early response is about decision-making under uncertainty—not perfect information.” Together, they discuss the key differences between internal and third party incidents, common misconceptions around vendor visibility, and why contractual protections alone aren’t enough. The conversation also dives into how to balance speed with accuracy, manage internal stakeholder tension, and build stronger recovery and resilience practices after an incident. “Move fast with awareness. Slow down with conclusions.” Whether you’re building or maturing your TPRM program, this episode offers actionable guidance to help you improve incident response coordination and strengthen your organization’s readiness. What You’ll Learn How third-party incidents differ from internal incidents—and why that matters What information is critical in the first hours of an incident Common blind spots, including fourth-party dependencies Why contracts don’t guarantee effective incident response How to balance speed, uncertainty, and communication What defines a truly successful recovery A practical exercise to improve vendor incident readiness “You’ll learn more in one hour of a vendor scenario than months of questionnaires.” About the Guest Sagar Sudhir Behere is a recognized thought leader in Third Party Risk Management (TPRM) and Enterprise Risk Management (ERM), with decades-long years of experience implementing innovative risk frameworks across Fortune 100s, Tech, FinTech, and FAANG organizations. As Head of TPRM at Circle Internet Financial, he has built Circle’s TPRM program from the ground up, achieving industry-leading efficiency and automation, including reducing vendor risk assessment processes by over 90%. His work integrates blockchain, AI, and automation to optimize compliance, risk oversight, and operational resilience. Sagar is an active contributor to industry standards and best practices, mentoring emerging leaders in risk management. He regularly shares his expertise at global conferences and the customer advisory board, influencing how organizations worldwide approach AI, automation, and blockchain integration in risk programs. His contributions are recognized for driving original, impactful solutions that redefine efficiency, governance, and innovation in global risk management. Have a question or topic idea? Send us your suggestions at: pod@tprassociation.org

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.

Most third party risk management (TPRM) programs stall not from a lack of effort, but because teams get stuck in routine: assessments proceed, documents are exchanged, and dashboards look fine. It all appears effective until someone asks a tougher question.  Is the program really getting better, or is it just running as usual?   Practitioners often recognize when nothing is broken, but the process feels stuck. The same issues repeat, third parties ask familiar questions, and teams rely on old workarounds to avoid disrupting the routine.  At this point, the program may seem mature from the outside, but inside it has settled into maintenance mode. The team is focused on keeping things running rather than questioning whether the process still fits. This gradual shift is when continuous improvement matters most.  The Risk of Operational Comfort  Repetition in TPRM programs can signal maturity or simply routine. Templates have passed audits, questionnaires seem complete, and the team knows where manual fixes are needed because they’ve seen these problems before.  Meanwhile, the organization is changing. Third parties may offer more products or assume larger roles. Cloud use grows, and data sharing is more complicated than when the program started. A third party that once handled a small task might now be responsible for a critical function.  If the program runs as originally designed, it can lose touch with the environment and rely on outdated assumptions, even as risks change.  Actions to Take: Once a year, bring together Security, Procurement, Legal, and business stakeholders for a practical discussion on how the program reflects the risks of current operations. Ask which third parties are more critical today than they were a few years ago, which parts of the process cause the most friction, and which risks feel harder to evaluate than they used to. Those answers usually reveal where the program has fallen out of alignment.  Continuous Improvement Is Not a Program Overhaul “Continuous improvement” can sound daunting, like a massive redesign or endless meetings. But small, steady steps are more practical and effective than big overhauls. Simple changes can help without overwhelming the team.  In reality, improvement is often much simpler. It’s about noticing what the program is already showing you and using that to make changes.  Most stalled programs don’t lack effort. They lack a way to learn from results. Lessons are recorded but rarely drive change. Onboarding problems persist, and third party incidents are treated as isolated incidents rather than as prompts for process improvement.  Pro tip: Review last year's most common third party findings. Clearly identify whether they led to changes in the program, such as revised questionnaires, clarified evidence requirements, enhancements to contracts, or altered monitoring priorities. If you identify no resulting changes, the takeaway is that the program needs a stronger improvement loop, not more automation.  The Feedback Loop Many Programs Overlook  TPRM programs naturally generate assessments, test results, follow up on incidents, and alerts that reveal how well the process works.  But most teams focus on completing tasks, rarely pausing to spot patterns.  Continuous improvement begins when practitioners see this data as feedback. Some controls get vague answers from third parties. Or maybe certain requirements tend to lead to frequent exceptions. Monitoring sometimes finds problems that assessments missed. These are not just third party actions; they show where the program needs to change.  Programs that adapt to these patterns become more effective over time. Updating the process with new insights is key.  Actions to Take: Once a quarter, review several completed assessments and ask a simple question... What did these reviews teach us about our process? Not only about the third parties, but about the program itself. To make these quarterly reflections easier, consider using questions like:  Which requirements caused the most confusion or pushback from third parties?  Did any part of our process slow down unnecessarily, and why?  Are there risks we failed to catch until after the assessment, and what signals did we overlook?   These questions highlight where the program needs to change and encourage real discussion.  Where Improvement Usually Starts  Improvement usually begins in three areas: assessments, governance, and risk communication.  Assessment questionnaires often grow over time as new questions are added but rarely removed. Eventually, they become hard to complete and review , without adding value. Mature programs review assessments, remove redundancies, clarify evidence needs, and focus on meaningful risk controls.  Pro tip: Identify the questions third parties struggle to answer most often. If responses are vague or copied from policy templates, the issue may not be the third parties. The question itself may need revision or a different validation approach.  Governance models need regular review. Current third party tiering may be outdated, and review schedules can become unbalanced. Regular checks help restore focus where it matters most.   Actions to Take: Review the third party inventory and ask a simple operational question. If this third party failed tomorrow, what would actually happen to the business? If the answer does not match the third party’s current risk tier or oversight level, the governance model likely needs adjustment.  Risk communication often requires improvement. Detailed reports may obscure key decisions. Sometimes, making reports clearer and simpler is the most valuable change.  Pro tip: In the next leadership report, replace one status slide with a single prompt: what third party risk decision requires attention this quarter? If that question is difficult to answer, the reporting model may need refinement.  Identifying When Your Program Has Plateaued Teams rarely admit that a program has stalled, even when clear patterns appear: repeated findings, recurring exceptions, and reviews that have become routine.  This plateau doesn’t mean failure. It just means it’s time to rethink improvement.  Instead of just checking whether the process is followed, the team should ask whether it still aligns with reality. The key is that moving from just maintaining to reflecting helps the program grow.  Actions to Take: Choose one program component each year and deliberately revisit its design. It might be third party tiering, assessment scope, monitoring strategy, or reporting. Improvement rarely appears on its own. Someone has to decide that it is time to look again.  Continuous Improvement as a Habit  The best TPRM programs aren’t always the ones with the longest questionnaires or the most detailed governance charts. They are the ones where people stay curious about how their process works and work to make it better.   They review their assumptions before they become outdated, learn from third party incidents instead of treating them as isolated events, and adjust oversight when business needs change.  Continuous improvement is a habit, not a project . Regular reflection is essential to maintaining the value of third party risk management as a practice.  When this habit becomes routine, maturity usually follows. It’s not because the framework is perfect, but because the program keeps learning.  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.

Most third party incidents come to light before the third party officially reports them. Usually, the first sign is indirect; a service slows down, a business owner notices access problems, a customer-facing team spots a disruption, or an alert goes off with little detail. By the time the third party confirms the issue, internal teams are already asking key questions: what is affected, what data is involved, who manages the relationship, what does the third party need to do under contract, and what options are available if service is not restored quickly.  Here, the extended enterprise means all the outside organizations that help the business run , including both third parties and the fourth parties they depend on. This matters during incident response because the i mpact and the root cause are often in different places. For example, a fourth party might cause a disruption, but the response still goes through the third party covering contracts, communication, evidence requests, and recovery promises. Third Party Risk Management (TPRM) teams need to make this chain clear and actionable during an incident.  Incident response and recovery in the extended enterprise are just as much coordination issues as technical ones. Security teams focus on containment and investigation. Privacy and Legal teams assess notification and contractual obligations. Business owners need to keep operations running and manage third party accountability. Continuity teams need recovery assumptions and workaround options. Procurement needs contract visibility and leverage. TPRM sits in the middle, translating third party relationships into a decision-ready context, so the response does not stall while teams reconstruct basic information.   This blog shares practical ways TPRM practitioners can help with incident response and recovery when third party incidents happen across the extended enterprise. The focus is on tools and processes that work during real incidents, not just on perfect documentation. The aim is to cut down the time spent on getting oriented, escalating issues, and tracking down information, so teams can act faster on impact, third party accountability, and recovery.  Maintain third party records for use during an incident.  When a third party problem comes up, the first challenge is getting oriented. Teams need to know who manages the third party, what the third party does, and how much disruption the business can handle.  TPRM programs should ensure third party records include:  A clearly identified business owner with authority to engage the third party.  The services provided and systems involved.  The types of data accessed or processed.  Whether the service supports customer-facing, revenue-generating, or regulated activity.  If teams have to gather this information after an incident begins, the response slows down and coordination suffers.  Practitioner takeaway: Ensure third party inventories are immediately usable during real incidents, not just for onboarding or annual reviews, so teams can quickly access orienting information.  Use risk tiering and operational criticality to define response expectations.  Risk tiering sets the basic level of oversight. Operational criticality shows if a problem with this third party would have an immediate effect on the business.  Each third party should have:  An inherent risk tier  An operational criticality designation, critical or not critical  Together, these factors should guide:  Notification and response timelines  Evidence and information requests during incidents  Leadership escalation and continuity involvement  For third parties that are critical to operations, these expectations should be agreed on and documented ahead of time. This includes clear escalation paths and recovery plans the business depends on.  Practitioner takeaway: Use risk tiering to set oversight expectations. Use operational criticality to determine how quickly a third party issue becomes a business-impact decision.  Treat fourth-party involvement as a normal part of the response.  Many third party incidents involve a fourth party, like a hosting provider, cloud platform, or specialized subcontractor. During a response, teams need to know if a fourth party is part of the delivery chain and if that changes recovery options.  Programs tend to be more effective when they:  Require third parties to disclose material fourth parties that affect service delivery or data exposure.  Apply this requirement primarily to operationally critical third parties.  Require notification when material fourth parties change.  This helps teams quickly assess impact and recovery limits, avoiding the slow process of rebuilding the supply chain during an active incident.  Practitioner takeaway: Focus fourth party visibility on the most important dependencies related to service delivery and data exposure for effective response.  Monitor for service disruptions and security events.  Third party incidents often start as performance issues. Service instability, missed Service Level Agreements (SLAs), or delayed results usually show up before there is a formal incident notice.  Monitoring practices should clearly define:  Which conditions require review.  Who is responsible for follow-up.  What triggers incident escalation.  A practical way to divide responsibilities is:  Business owners monitor performance, manage day-to-day third party relationships, and escalate when a disruption appears credible.  TPRM checks the third party’s risk tier and criticality, confirms escalation paths and contacts, and sends the issue to the right internal teams based on the third party’s profile.  Security, Privacy, Legal, and Continuity teams get involved once the situation is considered an incident, either because the third party declares it or internal teams confirm a possible security, data, or continuity impact.  Practitioner takeaway: Set a defined point for when an issue escalates to a formal incident, ensuring clear responsibility transfer.  Align incident response with recovery and continuity planning.  For third parties that are critical to operations, incident response and recovery planning often overlap. A security problem can quickly turn into an availability or customer-impact issue with little warning.   Organizations are better prepared when they have a shared approach for third party response and recovery. This should include:   Notification requirements and evidence expectations.  Impact assessment inputs.  Decision authority and escalation paths.  Recovery time and recovery point assumptions.  Workaround and alternate sourcing options.  Talking through scenarios that include third party outages helps teams understand limits before a real disruption happens.  Practitioner takeaway: Integrate recovery planning into incident response so that recovery steps are considered as part of overall incident handling, not left until later.  Address AI-related incident considerations during intake and contracting  When third parties use AI, it affects data handling, control processes, and regulatory risks during incidents. These issues are hard to solve in the middle of a response.  Practical preparation includes:  Identifying where AI is used and what data it touches.  Requiring notice of material changes to AI-enabled workflows.  Aligning incident notification and investigation expectations contractually.  This helps reduce uncertainty when incidents happen.  Practitioner takeaway: Define incident response expectations for AI usage and data handling with third parties before incidents happen to avoid delays.  Consider regional and geopolitical disruption in third party recovery planning.  Regional outages, sanctions, and infrastructure failures often hit third parties before they affect your own operations.  Preparation should include:  Identifying regional concentration across operationally critical third parties.  Understanding which services can pause and which cannot.  Discussing realistic disruption scenarios with continuity stakeholders.  These talks often reveal single points of failure that might otherwise go unnoticed.  Define ownership and decision authority in advance.  Third party incidents take longer to resolve when it is unclear who is responsible. TPRM can help speed things up by making the structure clear.  Programs should ensure:  Every third party has a named business owner.  Escalation and risk acceptance authority are documented.  There is a defined forum for remediation decisions, exceptions, renewals, and exits.  Exceptions have owners and review dates.  Clear authority helps resolve incidents faster.  Practitioner takeaway: Address structural issues, like unclear ownership and escalation paths, to reduce delays during third party incidents.  Track incident-relevant measures, not activity volume.  Leadership oversight gets better when reports focus on risk exposure and follow-up, not just on program activity.  Measures that tend to support decision-making include:  Coverage of current validation for operationally critical third parties.  Known material fourth-party exposure for operationally critical third parties.  Time to initiate triage for third party incidents.  High-risk issues that exceed agreed remediation timelines.  Concentration risk across essential services.  These measures help teams focus on what matters most and escalate issues as needed.  Practitioner takeaway: Ensure reporting enables clear decision-making by emphasizing risk exposure and remediation status.  Summary   Effective incident response and recovery in the extended enterprise rely on preparation that supports coordination, clear ownership, and predictable escalation. TPRM teams add the most value when third party records are ready to use during incidents, response expectations are based on risk and criticality, and recovery planning is part of the response process. Fourth-party involvement should be seen as a normal part of third party delivery, with clear visibility into key dependencies for the most important third parties.  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.

Navigating Ownership, Oversight, and Expertise in the Age of Artificial Intelligence  As artificial intelligence (AI) adoption accelerates across industries, organizations are grappling with a new challenge: where should AI risk management, and specifically AI-related Third Party Risk Management (TPRM), live within the enterprise?  While some organizations assign ownership to existing structures like IT, model risk management, or cybersecurity, others manage AI/TPRM through risk committees or distributed governance models.  However, as AI becomes embedded in everything from third party software to operational decision making, defining accountability and expertise is more critical than ever.  This blog explores the current state of organizational ownership of AI/TPRM, the challenges of fragmented accountability, and the evolving landscape of AI risk governance.  The Current Reality: Distributed Ownership, Fragmented Accountability  Most organizations are still in the early stages of formalizing how AI and third party risk intersect. The result is a patchwork of ownership that reflects historical structures rather than emerging needs.  Common Models of AI/TPRM Ownership:  Model Typical Owner Strengths Challenges IT Ownership CIO or Head of IT Deep technical knowledge; integration visibility Focused on enablement over risk; limited governance scope Cybersecurity Ownership CISO or Security Team Expertise in data protection, privacy and threat management May overlook model bias, ethics and performance risk Model Risk Management (MRM) CRO, Enterprise Risk or Finance Familiar with validation frameworks and model governance Not all AI tools qualify as “models”; hard to scale across third parties. Enterprise Risk Management Chief Risk Officer Holistic view of risk across functions May lack the technical fluency needed to assess AI-specific risks Governance Committee or AI Council Cross Functional Groups Encourages shared accountability Decision-making can be slow; unclear escalation or ownership paths In practice, AI/TPRM often lives everywhere and nowhere at all.   This distributed reality makes it difficult to establish clear accountability, consistent controls, or effective monitoring.   The Expertise Dilemma: Interest, Enthusiasm, and Illusion  AI governance has quickly attracted attention across business functions.  Within most organizations, there are three groups emerging:  The Interested:  Professional who wants to understand AI’s risk and opportunities but lack hands-on experience.  The Aspiring Expert:  Individual who follows AI trends and participates in governance conversations but may not yet grasp the nuances of model architecture or data provenance.  The Actual Experts:  Technologist, data scientist, and risk professionals who understand both the technical and ethical implications of AI.  The challenge is not a shortage of passion, it's a shortage of true multidisciplinary expertise.  AI/TPRM sits at the intersection of technology, ethics, and compliance, few individuals or departments are fluent in all three.  To close this gap, organizations must create intentional learning pathways and collaborative governance structures that balance subject matter expertise with enterprise risk accountability. Governance in Practice: Moving Towards a Federated Model  A leading practice emerging across industries is a federated governance model for AI and TPRM. This structure combines distributed ownership with centralized oversight.  Key Features of a Federated Model  Central Oversight Body  – An AI Risk or Governance Committee that sets policy standards, and reporting expectations.   Functional Ownership – Each business or function (e.g., IT, Cyber, Risk, Legal, Procurement, etc.) owns execution of AI/TPRM controls relevant to their domain.  Integration with TPRM – Third party due diligence processes are expanded to include AI-specific assessment covering model transparency, ethical design, data sourcing, and bias testing.  Continuous Monitoring – Establish ongoing oversight for AI-enabled third party tools, especially for evolving and retraining models.  This model encourages shared responsibility while ensuring decisions align with enterprise-level risk appetite and ethical standards.   A Practical Path Forward  Organizations can begin clarifying AI/TPRM ownership with the following steps:  Map Current Ownership – Identify where AI activities and risk currently reside(within IT, Cyber, Risk or elsewhere).  Establish an AI Governance Charter – Define roles, responsibilities, and decision rights for all AI-related risk activities, including third party AI vendors.  Integration of AI Risk into TPRM Frameworks – Update third party due diligence questionnaires/assessments and monitoring processes to include AI use, transparency, and data ethics.  Create a Skills Development Roadmap – Offer training that bridges the technical, operational and ethical dimension of AI risk.  Promote Transparency and Communication – Encourage open dialogue between those who “build”, those who “buy”, and those who “govern” AI.  Where AI/TPRM “lives” is not a static question, it's a reflection of how mature an organization is in managing emerging risk. Ownership will likely evolve over time, shifting from isolated functions to integrated governance models.   Ultimately, the goal isn’t to decide whether IT, Cyber, or Risk “owns” AI. It's to ensure that someone is accountable,  that the process is transparent, and decisions are made responsibly.  AI will continue to reshape third party risk management. Those who establish clarity of ownership today will be better equipped to manage the risks and seize the opportunities of tomorrow.  Author Bio Heather Kadavy Senior Membership Success Coordinator Heather Kadavy  joined the Third Party Risk Association (TPRA) in 2023 as the Senior Membership Success Coordinator. In recent year(s) Heather has been providing freelance TPRM consulting work to various organizations after retiring from a Nebraska financial institution after nearly 35 years where she oversaw and managed critical programs of the organization including Third Party Risk Management, Information Security, Physical Security, Safety, Business Recovery, Financial Crimes, Model Risk Management, and Enterprise Risk Management.  In her TPRM role she had oversight of over a thousand third party relationships, systems, due diligence reviews and contract management activities.  She developed, facilitated, and implemented training programs for thousands of employees over the years. Heather is a natural born connector of people and values relationship building at the cornerstone of her career.  She encourages you to connect with TPRA and herself via LinkedIn to join in the "TPRM Global Conversation".