A critical service is down, the third party has missed its recovery target, and someone finally opens the contract looking for answers. Instead, they find phrases such as “commercially reasonable efforts” and “prompt notification.” This is the moment when third party accountability is tested. If the contract does not define the obligation, the evidence required, or the response to failure, the organization may know that performance was unacceptable without having a clear way to compel action. This blog looks at how practitioners can turn risk terms into usable accountability tools, with practical steps for defining expectations, assigning responsibility, verifying performance, and responding when a third party falls short. Write Risk Terms That Can Be Leveraged Accountability starts with language that works under pressure. A term that cannot be measured, verified, or enforced may help complete a negotiation, but it provides little leverage when the service fails. For each material obligation, the contract should answer: What is the third party required to do? When must it be completed? How will performance be measured? What evidence must the third party provide? What happens if the requirement is not met? The final question is often the weakest. A contract may require a business continuity plan without requiring test results or correction of identified gaps. It may establish an incident-notification deadline without addressing repeated late notices. A missed obligation should lead to an appropriate response. Depending on the severity, that may include increased reporting, a corrective-action plan, executive review, formal notice, contractual remedies, or transition planning. The purpose is not to make every issue punitive. It is to remove uncertainty before a problem occurs. Focus on the Obligations That Matter Most Trying to monitor every contract provision with the same intensity creates plenty of activity but not necessarily better oversight. Accountability should focus on the obligations that protect critical services and support meaningful risk decisions. For higher-risk relationships, these may include: Availability and performance thresholds Incident notification requirements Business continuity and disaster recovery testing Recovery time and recovery point objectives Security and data protection controls Remediation deadlines Material subcontractor changes Transition assistance and data return Termination rights for repeated failures The right priorities will vary by service. A cloud provider, payment processor, call center, and records-storage company should not have identical oversight requirements. Monitoring should reflect how the service could fail and what that failure would mean for the organization. Require Evidence, Not Reassurance Accountability depends on evidence. A third party may state that a control is effective or that an issue has been resolved, but the organization needs enough information to evaluate that claim. The contract should identify the evidence required for material obligations. This may include performance reports, incident notices, recovery test results, remediation records, assurance reports, subcontractor notifications, or documentation of data return and deletion. Receiving evidence is not the same as reviewing it. Someone must determine whether the information is complete and whether it addresses the contractual requirement. Practitioners should also compare third party reports with internal operational information. A dashboard may remain green while internal support tickets increase or transaction backlogs take longer to clear. The third party’s report is an important source, but it should not be the organization’s only view of performance. Accountability Also Runs Inward An organization cannot hold a third party accountable if its own responsibilities are unclear. Strong contractual rights have limited value when no one monitors them or when identified problems have nowhere to go. For each material obligation, the organization should identify: The business owner accountable for the service The third party risk function responsible for oversight and challenge The specialist responsible for evaluating the evidence The review frequency The escalation threshold The governance body authorized to require action Third party risk management has an essential role, but accountability cannot sit with that function alone. Business owners understand service performance. Technology, Cybersecurity, Privacy, Compliance, and Business Continuity teams evaluate specialized evidence. Procurement supports commercial escalation, while Legal advises on notices, remedies, amendments, and termination. Operational resilience or enterprise risk may be positioned to connect third party performance with internal dependencies, customer impact, and the organization’s tolerance for disruption. The structure may differ among organizations. What matters is that responsibility for the complete view is assigned rather than assumed. Act Before a Formal Breach A formal contract breach should not be the first sign that intervention is needed. Repeated near misses, late reports, missed remediation dates, and worsening service trends can justify action before a critical threshold is crossed. Useful escalation triggers may include: Repeated failure or near failure of a critical Service Level Agreement (SLA) Late or incomplete incident notification Failure to meet recovery objectives during testing Overdue high-severity remediation Repeatedly late root-cause reports Material subcontractor changes without required notice Rising backlogs, outages, or customer complaints Each trigger should lead to a defined response. Otherwise, escalation depends on who notices the issue and how persistent that person is. That is not a reliable control. Practitioner Action Items The following actions can move accountability from contract language into daily oversight: Start with critical services. Select a manageable group of third parties that support essential operations. This directs limited resources toward relationships where weak accountability could cause the greatest harm. Identify the obligations that matter most. Focus on commitments that affect continuity, regulatory duties, customer impact, security, or recovery. This prevents important requirements from being buried among routine commercial terms. Test whether each obligation is usable. Confirm that it includes a timeframe, measurement method, evidence requirement, and response to failure. If the organization cannot determine whether the obligation was met, it will struggle to enforce it. Assign an owner and reviewer. The person managing the relationship may not be qualified to evaluate security evidence or recovery testing. Match the reviewer to the obligation and document who has final accountability. Compare external and internal evidence. Reconcile third party reports with incident records, complaints, ticket volumes, backlogs, and performance data. Differences may reveal deterioration before an SLA is missed. Define escalation in advance. Establish when the organization will require enhanced monitoring, remediation, formal notice, or transition planning. Predefined triggers reduce delay and inconsistent treatment. Track corrective action through closure. An accepted remediation plan is not a resolved issue. Confirm that promised actions are completed and supported by evidence. Use failures to improve future contracts. Feed incidents, failed tests, and recurring exceptions back into contract templates and negotiation guidance. Otherwise, the same weakness may return at renewal. Practitioner Takeaways Third party accountability is not about creating a combative relationship. It is about making expectations usable and ensuring that both parties understand what follows when those expectations are not met. The practical test is straightforward: Can the organization identify the obligation, evaluate the evidence, assign responsibility, and act when performance falls short? If not, the contract may contain strong language without creating meaningful accountability. 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.

The Third Party Risk Association (TPRA), in partnership with ten leading third party risk management service providers, is pleased to provide TPRM professionals with the Standard Trust Portal Guidance for Third Party Risk Management (TPRM). Definition A Trust Portal is a centralized hub that provides transparent, self-service access to security, compliance, privacy, and governance information. It enables collaborative due diligence activities by helping customers and other stakeholders quickly validate the effectiveness and maturity of your third-party risk program. Designed to unify how organizations demonstrate security, compliance, privacy, and governance maturity, the Trust Portal Guidance provides a standardized framework for building and managing trust portals, which are centralized hubs for evidence sharing and transparency between organizations and their third parties. The guidance aims to empower practitioners, vendors, regulators, and platform providers to align around a single, trusted model that reflects industry expectations and best practices for transparency, efficiency, and responsible evidence sharing. It also supports AI-driven TPRM technologies by standardizing evidence formats for automated review and analysis. Trust Portal Pillars TRANSPARENCY Open, accessible trust data for responsible risk decisions. EFFICIENCY Automated, reusable evidence. TRUST Verified information driving stronger partnerships. INNOVATION Enabling AI-ready, proactive due diligence. What It Can Do For You For Practitioners: Reduces questionnaire fatigue, improves review quality, and saves time through standardized, AI-friendly evidence formats. For Vendors/Third Parties: Demonstrates maturity and transparency; less time answering one-off questionnaires. For Regulators: Encourages uniformity and accountability in demonstrating control effectiveness. For Service Providers (Platforms): Provides a shared framework to enable AI and automation in TPRM workflows. Download Now This document is available for FREE download. How It Was Created Our TPRM Service Provider Advisory Council spent months working quietly behind the scenes, researching and collaborating to create a cohesive and comprehensive resource to be freely shared with all members of the TPRM community. Acknowledgements & Contributors Thank you to the following organizations, which contributed perspectives and subject matter expertise to help shape this guidance (displayed in alphabetical order): Their collective insights reflect practical experience across third-party risk management, compliance automation, trust assurance, and practitioner due diligence.

Every few years a profession gets a moment where the ground shifts and the people who read it early pull away from the people who wait. Third party risk management is in one of those moments right now. The pressure is easy to feel and hard to name, so let me name it plainly: the part of your job that is easiest to automate is the part most programs still spend most of their time on. This is not a threat to fear. It is a map. It tells you exactly where to stop investing your career, and exactly where to start. The rest of this blog will discuss that map. Not the technology for its own sake, but what it means for how you should be building yourself and your program over the next two years. The skill that is quietly losing its value For most of our careers, questionnaire throughput was a real skill. Knowing the frameworks very well, moving assessments through the pipeline, keeping the register current, chasing third parties for responses. People built reputations on being fast and thorough at this, and they deserved to. That skill is depreciating, and the reason is simple. A third party can now generate a flawless questionnaire response in twenty minutes with an AI model. You can review it in twenty seconds with another one. When both sides automate the exchange of claims, the exchange stops carrying information. The output is fast, polished, confident, and empty. If your professional value is anchored to moving that exchange efficiently, your value is anchored to the one thing the technology just commoditized. This is uncomfortable to say out loud, and I say it because the practitioners who hear it early have time to move, and the ones who hear it late do not. The good news is that the skills replacing questionnaire throughput are more interesting, more durable, and far harder to automate. Where the value is moving Think of the modern TPRM skill set in three horizons. What you should acquire now, what you should build in parallel, and what you should aim to own over the next two to three years. This is as true for how you develop yourself as it is for how you develop your program. Acquire now: evidence literacy and AI judgment. The single highest-leverage move available to you is learning to read for evidence instead of attestation. That means reading a SOC 2 for the findings that hide outside the exceptions table, the complementary user entity controls that are quietly your obligations, and the subservice carve-outs that are a fourth-party map printed inside the report. It means telling the difference between a control that is enforced and one that is merely available, a distinction that lives in configuration exports, not questionnaires. And it means knowing where AI genuinely helps in your workflow and where it fails, so you can use it without being fooled by it. None of this requires a technical background. All of it requires unlearning the habit of treating a filled-in form as an answer. Build in parallel: governance and monitoring design. As volume rises and headcount stays flat, the analyst's job shifts from doing assessments to governing how they get done. That means designing which controls receive human review and which can be AI-accepted with spot-checks, documenting overrides in a way that survives an examiner, and building monitoring that fires on real signals instead of the calendar. Your assessment cycle takes weeks; public breach disclosure now averages well over a hundred days. Annual reassessment was never going to close that gap. The practitioners who can design event-driven monitoring, and defend it, become indispensable. Own long-term: program architecture and business translation. The most durable skills are the ones furthest from automation: designing an AI-augmented program from the ground up, and translating technical findings into the language a Chief Financial Officer (CFO) or a board risk committee will act on. These are the capabilities that turn a senior practitioner into a program leader, and they compound every year you hold them. Building the program, not just the résumé Everything above is also a blueprint for the program you are responsible for, because your career and your program advance through the same moves. Start by asking the question most programs never ask out loud: why does our program actually exist? Is it funded by regulatory mandate, by customer and market pressure, or by genuine conviction that the program prevents real losses? The honest answer shapes everything. A program that can only demonstrate documentation is now competing against infinitely cheap documentation and losing. A program that can demonstrate prevented loss has no such competition. If you cannot point to a single incident your program caught that would have cost the business real money, then the value of your program is reduced. This is the most important thing on your roadmap, not another questionnaire integration. Then, you will want to point your technology investments at evidence rather than attestations. The wave of automation has currently meant "faster questionnaires", which points current investments to the least informative part of the process. The programs that will matter most are shifting the object of automation from what a third party says to what can be observed: from documents to query-able data, from attestation to configuration, from annual cycles to continuous signals. And when you evaluate any AI-assisted tool, hold it to a standard of auditability. When an examiner asks you to reconstruct one decision, can the tool show the inputs, the model version, the citations, and the human who signed off? Most cannot. That question is the best filter you have for separating serious platforms from confident demos. Why this is bigger than our function The reason this deserves real attention, from you and from your leadership, is that delegated trust has become the largest attack surface most enterprises have. Companies outsource more of what they do every year. Every third party relationship, every integration, every AI agent granted standing access is a delegation of trust and an extension of the attack surface. The incidents that defined recent years were not perimeter failures; they were trust failures, a compromised build pipeline, a stolen integration token, a socially engineered supplier help desk. Enterprise resilience now rests on third party risk in a way it simply did not a decade ago. That is the opportunity hiding inside the disruption. A function that was often treated as a compliance cost center is becoming central to whether an organization can withstand the failure of the many parties it depends on. The practitioners who build the evidence-first skills, and the programs built on them, are the ones who will be in the room when it matters. Where to start this quarter Preparation does not require permission or budget. Pick your three most critical third parties and write down, honestly, what you actually know about their security posture versus what they attested. That gap is your starting point. Read the scope section of your next SOC 2 yourself, not the AI summary. Run one assessment you did manually through an AI tool and study where it agreed, missed, and surprised you. Build the habit of collecting one piece of observable evidence per critical third party per quarter. Small, unglamorous, and compounding. This conviction is why we built the "TPRM in the Age of AI" series with TPRA. Module 1, AI and the Future of Third-Party Risk, lays out what is changing and why, from first principles, and closes with concrete actions you can take this week and this quarter. Module 2, The Practitioner's Skill Stack, is the hands-on training for the evidence-first skills above: reading the artifacts, running AI with discipline, and designing monitoring that works. Both are CPE-eligible through the TPRA training platform. They exist to help you make exactly the moves this article describes. The questionnaire era is ending, and that is good news for anyone willing to build. The work ahead is not to fill out the form faster. It is to become the practitioner, and to build the program, that can tell whether the form was ever true. Start now, while it is still early. Being early is the whole advantage. Author Bio Clarence Chio Cofounder and CEO of Coverbase Clarence Chio is cofounder and CEO of Coverbase and has taught AI and security at UC Berkeley since 2019. He is the instructor for the "TPRM in the Age of AI" professional development series, available through TPRA. Coverbase is one platform for third-party risk and security, with AI that tailors to your program and controls and continuously evaluates every surface of exposure.

A New Requirement Takes Effect September 15, 2026 On September 15, 2026, the Institute of Internal Auditors’ (IIA) new Third-Party Topical Requirement goes into effect, establishing a consistent, mandatory framework for internal auditors conducting assurance engagements that involve third party management (TPRM). For TPRM practitioners, the requirement provides greater clarity into what internal audit may examine and the types of practices, controls, and evidence organizations should be prepared to demonstrate. The IIA has published two core documents: Third-Party Topical Requirement – Provides the mandatory baseline of requirements internal auditors must follow when performing assurance engagements on third party management. Third-Party Topical Requirement User Guide – Provides guidance for implementing the requirement, including examples of evidence and controls internal auditors may consider. Additional information is available on the IIA Third-Party Topical Requirement resource page. Unlike a regulatory or industry-specific standard, the requirement establishes principles that can be applied across organizations and industries. Many align with existing regulatory guidance and established TPRM practices, while others extend beyond traditional TPRM activities into areas such as sourcing decisions and contract performance monitoring. Why This Matters: A Professional Perspective I’ve worked in third party and vendor risk management for more than 20 years, working with more than 100 organizations across financial services, healthcare, pharmaceuticals, energy, and other highly regulated industries. That experience has given me the opportunity to see TPRM programs at very different stages of maturity, as well as how the audits evaluating those programs have changed over time. Audits that once focused more narrowly on vendor due diligence and basic controls have expanded to examine how organizations govern third party relationships, manage risk across the lifecycle, and demonstrate that their processes are working as intended. The IIA’s new Third-Party Topical Requirement reflects much of that evolution. It also brings greater attention to several challenges I’ve encountered across organizations and industries over the years. With that perspective, here’s what TPRM practitioners should know about the new requirement, along with five areas that I believe deserve particular attention as organizations prepare. What the Topical Requirement Is The Third-Party Topical Requirement is a mandatory component of the IIA’s International Professional Practices Framework. When internal auditors perform an assurance engagement that addresses third party management, whether as part of a planned engagement or because third party risk becomes relevant during an audit, they are required to use the Topical Requirement as their framework. Each audit will still reflect the professional judgment, scope, and priorities of the team conducting it, but the requirement provides a consistent foundation from which to work. What Auditors Will Be Looking For The Topical Requirement contains 17 requirements organized into three categories: governance, risk management, and controls. Each category has defined criteria, supported by the User Guide with examples of evidence auditors may consider. Third Party Governance, 4 Requirements Governance focuses on whether the organization has a formalized approach to third party management. This includes documented policies and procedures covering the full lifecycle of the relationship, clearly defined roles and responsibilities, and communication protocols that keep appropriate stakeholders informed. Third Party Risk Management, 4 Requirements Risk management focuses on whether risk practices are standardized and comprehensive throughout the lifecycle. This includes how the organization identifies, assesses, prioritizes, and responds to third party risks, how issues are escalated and managed when they arise, and how risk information flows to leadership and oversight bodies. Third Party Controls, 9 Requirements Controls focus on operational execution throughout the lifecycle, including sourcing, due diligence, contracting, onboarding, monitoring, corrective action protocols, and offboarding. The requirements also address maintaining a complete, accurate, and current inventory of third party relationships, an area that can present practical challenges when third parties enter an organization through multiple channels. Five Areas That Deserve a Closer Look Based on my experience with TPRM programs across industries and at different stages of maturity, there are five areas I would pay particular attention to when preparing for the new requirement. 1. Lifecycle-Based Framework Across organizations, third party management frequently spans multiple business functions, each with its own policies, processes, systems, and responsibilities. That can make it difficult to create a cohesive view of third party management across the enterprise. The requirement calls for a formalized, documented approach that spans the full third party lifecycle. Organizations should consider whether activities across functions are sufficiently coordinated and whether policies, procedures, and responsibilities support a consistent enterprise approach. 2. Accurate, Documented Procedures Policies and procedures don’t always mature at the same pace. In many programs I’ve worked with, policies benefit from formal approval and regular review cycles, while the procedures supporting them may receive less attention over time. Procedures should clearly define roles, accountability, and documentation requirements and accurately reflect how the organization operates today. That review is particularly important as processes and technologies change, including the adoption of AI-enabled solutions. 3. Communications and Reporting Reporting can remain difficult even for well-established TPRM programs. Often, what appears to be a reporting problem begins further upstream with the quality and consistency of the underlying data. When third party data is captured by different functions without consistent fields, definitions, ownership, or collection practices, maintaining accurate and complete reporting becomes more difficult. Practitioners should consider both their reporting capabilities and the quality of the data supporting those reports. 4. Risk Domains Beyond Cyber Another pattern that has emerged over the years is the significant attention given to cybersecurity within third party risk programs. Regulatory requirements and established information security ownership have helped make cyber a well-defined component of TPRM in many organizations. The Topical Requirement, however, addresses a much broader set of risks, including strategic, reputational, financial, legal, operational, and geopolitical risks. Organizations should consider whether these additional risk domains have appropriate ownership, assessment processes, and oversight within the broader third party management framework. 5. Accurate Third Party Inventory Maintaining an accurate third party inventory continues to be a practical challenge for many organizations. One reason is structural: third parties may enter through procurement, accounts payable, corporate cards, or direct relationships established by individual business units. When those channels are not connected to a consistent process or system of record, gaps in the inventory can result. Organizations should evaluate whether they have clearly defined ownership, consistent processes for identifying and recording third parties, and a reliable system of record for third party relationships. What TPRM Practitioners Can Do Now The IIA has provided internal auditors with a clear framework to work from. For TPRM practitioners, preparation can focus on three things: Understand what's expected. Read the Topical Requirement and User Guide to understand the policies, practices and evidence auditors will look for. Evaluate your scope of operations. Focus on things you are responsible for within the third party management lifecycle and be honest about where you stand today. Coordinate with cross-functional peers. For those things outside your scope but within the Topical Requirement, work with your peers who own those activities to ensure responsibilities are clear, documented, and coordinated. Auditors will want to see a unified approach, not disconnected functions operating independently. The new requirement does not mean every element of third party management needs to sit within the TPRM function. It does mean organizations should be able to demonstrate how responsibilities and activities work together across the lifecycle. Starting that review now gives practitioners an opportunity to understand their current state, identify areas that may need attention, and coordinate with the other functions responsible for third party management before the requirement takes effect. Author Bio Tom Rogers Founder and CEO of Vendor Centric Tom Rogers is the Founder and CEO of Vendor Centric, a professional services firm that works exclusively with third-party and vendor management leaders to build, improve, mature and run their programs. With over 20 years in the field, Tom has worked with over 100 clients across financial services, healthcare, pharma, energy, and other highly regulated industries. He brings a practical, real-world perspective to helping leaders build operations that don't just hold up under scrutiny but actually deliver value. Tom and his team built a free self-assessment tool that maps to all 17 standards within the IIA’s Third-Party Topical Requirement. It takes about 15-20 minutes to complete and gives you an interactive gap analysis as soon as you’re done, along with a downloadable report you can share with the colleagues you’ll need to work with to close the gaps. You can access the tool here. You can connect with Tom on LinkedIn or reach him at trogers@vendorcentric.com.

If you've worked in third party risk management (TPRM) for any length of time, you know budget season rarely gets easier. Third party populations continue to grow. Business units expect reviews to move faster. Regulations continue to evolve, and AI has introduced new considerations into third party due diligence. Regulators have also made something else clear. Effective TPRM requires appropriate staffing, expertise, governance, and ongoing oversight. Leadership is responsible for ensuring those resources are available. The challenge, of course, is that leadership can't fund what it doesn't understand. It's up to TPRM leaders to demonstrate where the program stands today, where the gaps exist, and what resources are needed to support the business. That's where a well-built budget becomes one of the most important tools in your program. Start with Actual Spending Before building next year's budget, understand where this year's money actually went. Last year's approved budget is only part of the picture. Actual spending often tells a different story. Software renewals increase. A hiring freeze leaves a key position vacant longer than expected. An unplanned third party event requires outside expertise. Break spending into broad categories such as: Technology and software Outsourced assessments Staffing Training and certifications Consulting and audit support Some of these costs may be buried inside shared enterprise budgets, so partnering with finance early can save hours of reconstruction. Once you've organized the numbers, identify the largest variances. Those differences often reveal where the program is changing and provide the strongest justification for next year's request. Pro Tip: Compare at least two years of actual spending. Trends usually tell a stronger story than a single year's variance. Measure the Gaps The next question is whether your program is keeping pace with demand. Has your third party population grown? Are reassessments staying on schedule? Has your backlog increased? Are business units waiting longer for reviews? Are the risk domains you are assessing covering the right risks? If you aren't tracking these metrics yet, start now, even if it's only in a spreadsheet. Whenever possible, convert the problem into numbers. If third party growth resulted in forty additional assessments this year, estimate the effort required to support that increase. Finance can evaluate measurable impacts much more easily than general statements about workload. Quick Check How many third parties were added this year? What's your average assessment turnaround time? Where is your largest backlog? Which bottleneck would disappear first if your budget were approved tomorrow? How Does Your Program Compare? Every organization has different priorities, but it helps to understand where other TPRM programs are investing. According to KPMG's 2026 Global Third Party Risk Management Survey of 851 organizations, the top investment areas are risk assessments and due diligence (52%), TPRM technology (51%), cybersecurity and data protection (49%), and regulatory audits (45%). More than 80% of organizations outsource at least part of their TPRM activities, while only 17% reported having fully reliable TPRM data. These findings aren't a blueprint for your budget, but they provide a useful benchmark. Pro Tip: If your investment priorities look very different from your peers, be prepared to explain why. Sometimes there's a good reason and being able to articulate it to leadership is essential. Think about it this way... What level of third party risk does the organization need to manage, and what people, technology, intelligence, and assurance capabilities are required to manage it effectively? AI Is Expanding the Scope of TPRM AI is becoming part of more third party products every month, including products many organizations already use. As a result, existing third party relationships now require additional scrutiny. Questions about training data, model governance, customer information, and contractual protections have become routine parts of due diligence. Many organizations also expect AI to reduce costs and staffing needs. That expectation has largely outpaced reality. According to KPMG's survey, only 22% of organizations rated their AI initiatives as very effective. Finance may expect efficiency gains that haven't materialized, while TPRM teams face additional review work. Budget for the resources needed to support that growth. Budget Checklist Update AI due diligence questionnaires. Review AI-specific contract language. Invest in team training. Consider managed services or specialized expertise. Evaluate tools that improve assessment efficiency. Headcount May Not Be the Only Answer When workloads increase, it's easy to assume another team member is the answer. Sometimes that's true. Sometimes the real issue is an inefficient process, a technology gap, or the need for specialized skills. Before requesting another position, step back and identify what's actually slowing the program down. You can also ask which TPRM activities are consuming human capacity without requiring human judgement. Then consider all of the available options. Improve or redesign an existing workflow. Use capabilities already available in your technology stack. Automate repetitive administrative tasks. Outsource TPRM processes such as due diligence document collection or reviews Bring in part-time contractors during peak periods. Share platforms or subscriptions with Procurement, Information Security, or Compliance to reduce total cost of ownership. If another employee is still the right solution, you'll have a much stronger business case because you've already evaluated the alternatives. Pro Tip: Before requesting another FTE, ask whether the problem is capacity, process, technology, skills, or temporary workload. The answer will help you determine which investment will drive the improvement you need. Don't Overlook the Small Line Items Some of the easiest budget items to miss are also the ones most likely to create problems later. Recurring costs often increase over time, and one-time projects have a way of becoming recurring if they aren't clearly identified. Spending a little extra time reviewing your assumptions now can prevent mid-year surprises. Commonly Forgotten Budget Items Platform renewals and licensing increases Team training and certifications AI-specific assessment tools or questionnaire updates Fourth-party risk initiatives One-time consulting or implementation projects Pro Tip: Separate one-time investments from recurring operating expenses. It makes future budgeting easier and helps finance understand your long-term costs. Separate Needs from Nice-to-Haves Few organizations receive everything they request. Before budget discussions begin, decide which investments are essential and which would simply improve the program. Those decisions are much easier to make before you're sitting across the table from finance. A simple prioritization exercise can save time later. Must Have Regulatory or contractual obligations Minimum staffing requirements Critical platform renewals Required operational activities Reasonable Due Diligence capacity to support the business Nice to Have Additional reporting capabilities New dashboards Premium platform features Nice efficiency improvements that can wait another budget cycle Pro Tip: Ask yourself one question: If finance approved only half of this request tomorrow, what would stay? If you know that answer before the meeting, you're already ahead of the conversation. Build a Business Case, Not Just a Budget Budgets are approved because they support business objectives, not because a department needs more money. Rather than focusing on workload, explain what the investment enables the business to accomplish. Support your request with measurable outcomes whenever possible. For example: Improve supplier onboarding. If assessments currently take 90 days and your goal is 60, estimate how many projects or contracts could move forward 30 days sooner. Reduce operational risk. Estimate the potential impact of a supplier disruption, delayed implementation, or security incident, then compare it to the cost of earlier detection through stronger due diligence and monitoring. Strengthen regulatory readiness. If audit findings or manual processes require recurring remediation, estimate the effort required to address those issues today versus preventing them in the future. Support business growth. If the organization expects significant third party growth, estimate the additional assessment workload and show how your request will help maintain service levels and avoid backlogs. The stronger your data, the stronger your business case. Third party growth, assessment volumes, turnaround times, backlog trends, and remediation effort all provide objective evidence that leadership can evaluate. Pro Tip: Don't ask for more money. Ask for the ability to deliver a measurable business outcome. Keep Tracking Throughout the Year Budget season shouldn't be the only time you look at your numbers. Review spending throughout the year and compare actual expenses against your budget. Track trends such as assessment volume, cost per assessment, outsourced versus internal work, and unexpected costs resulting from third party incidents. Those metrics become the starting point for next year's budget instead of forcing you to rebuild the story from memory. Track These Metrics Quarterly Budget versus actual spending Third party growth Assessment turnaround time Assessment backlog Cost per assessment Outsourced versus internal work Final Thoughts No organization gets every budget request approved. The goal isn't to win every budget discussion. The goal is to build a request that's grounded in data, tied to business priorities, and realistic about where the program needs to grow. Organizations that consistently track workload, spending, and performance throughout the year rarely start from scratch when budget season arrives. They already have the data to explain where resources are needed and how those investments support the business. Budgeting is never just about the numbers. It's about demonstrating that your program understands its risks, knows where it needs to improve, and has a practical plan for getting there. 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.

Sanctions compliance may traditionally sit with legal, trade compliance, or another specialized function, but it has direct implications for third party risk management. A prohibited relationship can expose an organization to blocked transactions, frozen payments, regulatory enforcement, financial penalties, operational disruption, and reputational damage. In this episode of the TPRM Exchange, host Hilary Jewhurst speaks with Michael Volkov of The Volkov Law Group about how sanctions apply to third parties, where sanctions risk appears throughout the lifecycle, and what practitioners can do to build a practical and defensible process. Sanctions Risk Does Not Stop at the Border One of the most common—and potentially costly—misunderstandings is that U.S. sanctions no longer apply when a transaction is routed through an entity outside the United States. As Volkov explains, a U.S. company cannot avoid its sanctions obligations simply by working through a third party in another country. “The risk continues from wherever you’re located. If you’re a U.S. person or a U.S. company, it continues through your third parties, no matter where they are located.” — Michael Volkov Sanctions may target particular activities, individuals, entities, industries, or entire countries. Regardless of the specific program, the practical question for an organization is whether it is permitted to conduct business or complete a financial transaction with the party involved. Screening Should Begin During Onboarding Sanctions issues can emerge at several points in the third party lifecycle, but onboarding is the most important place to establish a control. Before a vendor, supplier, customer, distributor, or other third party is entered into an organization’s master database or approved for payment, the party should be screened. Building screening into the existing approval workflow allows the organization to identify potential issues before a contract is signed, goods are shipped, or money changes hands. Waiting until a bank blocks a payment puts the organization in a much more difficult position. By that point, goods may already have been delivered, contractual commitments may have been made, and funds may be frozen while the parties investigate. The Entity Name Is Only the Beginning Screening the contracting entity is an essential first step, but it may not reveal the full risk. Organizations may also need to examine the company’s beneficial owners, officers, directors, or other principals. Under certain sanctions rules, an entity can be treated as blocked when one or more sanctioned persons own 50% or more of it—even if the entity itself does not appear by name on a sanctions list. Ownership structures can also obscure the individuals who ultimately control or benefit from a company. When an initial screen produces a red flag, practitioners may need to gather additional ownership information and work with legal or compliance specialists to determine whether the relationship is permissible. Sanctions Exposure Extends to Nth Parties The conversation also highlights the importance of looking beyond direct contractual relationships. Sanctioned goods, materials, entities, or individuals may appear several levels down a supply chain or later in a distribution channel. Volkov uses supply chain and transshipment examples to illustrate how an organization can face liability even when it does not directly contract with the sanctioned party. Risk may arise when prohibited materials enter the supply chain through a subcontractor or when a distributor redirects a product to a sanctioned destination. Managing that exposure may require: Risk-based supply chain due diligence Appropriate sanctions and trade-compliance clauses End-use and end-user controls Supplier representations and certifications Supply chain audits Escalation procedures for geographic or ownership concerns The appropriate level of diligence will depend on the organization’s products, markets, geographic reach, distribution model, and overall exposure. Build Forward Instead of Trying to Fix Everything at Once Organizations implementing formal sanctions screening may discover that hundreds or thousands of existing third parties have never been screened. That does not mean the program must resolve the entire backlog before introducing an effective control. “You’re not going to boil the ocean over this. We don’t have time for that, nor the resources.” — Michael Volkov A more manageable approach is to establish a clear implementation date and screen every new third party from that point forward. The organization can then address its existing population using a risk-based plan. Higher-priority reviews may include third parties with: Operations in higher-risk countries or regions Significant organizational spend or revenue Exposure to known transshipment locations Complex or unclear ownership structures Access to regulated products, technology, or services Roles deeper within critical supply or distribution chains This approach allows the organization to establish a consistent control immediately while addressing historical exposure in a deliberate, defensible order. Screening Is Not a One-Time Activity A third party that passes screening today may be added to a sanctions list tomorrow. Sanctions designations can change quickly in response to geopolitical events, national security concerns, criminal activity, or changes in government policy. Automated screening platforms can help by retaining screened parties and issuing alerts when a party’s status changes. Organizations without an automated tool may begin with available government screening resources or seek assistance from qualified legal or compliance professionals, but manual screening becomes harder to sustain as international activity grows. Regardless of the technology used, the process should define: Who is screened When screening occurs Which lists and data sources are used How potential matches are reviewed Who can clear or reject a match How decisions are documented How active relationships are monitored When issues must be escalated The tool supports the control, but it does not replace a clear workflow and accountable decision-making. TPRM Does Not Have to Own the Process—but It Must Understand It Sanctions screening may be performed by compliance, legal, procurement, trade compliance, sustainability, or another team. Organizational structures vary, and there is no single operating model that works for every company. However, TPRM practitioners should understand how the process works even when another function owns it. They should know who makes sanctions decisions, what tools or information that team uses, what evidence confirms that screening occurred, and how an issue is escalated. That knowledge is necessary to explain the organization’s controls to business stakeholders, auditors, examiners, and leadership. It also prevents gaps between functions—particularly when onboarding involves several teams with different approval responsibilities. Compliance Must Be Positioned as a Business Partner Business stakeholders may view sanctions screening as another obstacle standing between them and a time-sensitive transaction. Volkov recommends approaching those conversations as a partner focused on helping the business proceed safely. The message should be straightforward: involve the appropriate risk and compliance teams early, and they can identify concerns, explore permissible options, and help prevent transactions from being blocked later. TPRM and compliance teams should also establish reasonable turnaround expectations. A well-designed screening process should support timely decision-making while ensuring that unresolved red flags do not pass unnoticed into the vendor master or payment process. When an Existing Supplier Triggers an Alert If a long-term supplier appears on a sanctions notice, the organization must act promptly. The immediate response should generally include pausing business and financial activity, notifying the appropriate internal stakeholders, and investigating the alert. The organization should contact the third party for an explanation while legal or trade-compliance personnel determine whether the notice is accurate and whether the relationship can lawfully continue. Contracts and purchase orders should contain sanctions-compliance language that supports the organization’s ability to suspend or terminate prohibited activity. These protections are particularly important when a designation occurs in the middle of a transaction or during a multiyear agreement. Practitioners should not assume that every alert establishes a confirmed violation. False positives and explainable matches occur. Nevertheless, activity should not resume until qualified personnel have reviewed the issue and documented a defensible decision. Two Practical Priorities Volkov closes with two primary actions for practitioners: Implement a sanctions-screening capability that supports onboarding and continued monitoring. Provide annual sanctions training to employees whose responsibilities may bring them into contact with sanctions-related issues. Training does more than communicate rules. It creates an opportunity for employees to raise questions, describe emerging business activities, and identify transactions or relationships that might otherwise remain outside the risk team’s view. Ultimately, effective sanctions compliance depends on visibility, defined ownership, appropriate technology, and cooperation across the organization. By embedding screening into onboarding, monitoring active relationships, accounting for beneficial ownership and nth parties, and responding quickly to alerts, TPRM practitioners can help protect the organization while still enabling the business to move forward.

If you spend enough time in third party risk, you’ll notice something unfair. Your third parties have their own third parties, and when those downstream providers fail, your organization still feels the impact, even though you never signed a contract with them. This leads to a common question: “How are we supposed to manage those third parties?” The short answer is that you don’t manage them directly. Instead, you focus on reducing the risks that come with these extended relationships. Fourth- and nth-party risk means knowing where these downstream dependencies are, how their failures could disrupt your services or affect your customers, and making sure your TPRM program identifies, analyzes, and reduces those risks where it matters most. Who is a 4th or nth party? In third party risk management (TPRM), “third party” usually means any external organization or supplier under contract to deliver a product, service, or process. That is the part everyone is used to tracking. A “fourth party” is any provider your third party relies on. These can be cloud platforms, sub‑processors, subcontractors, and upstream suppliers that sit behind the scenes but can still disturb your operations, affect your customers, or negatively impact your compliance posture when something goes wrong. “Nth‑party risk” is the more general term for the additional layers beyond that, including the third parties supporting those fourth parties and further out in the chain. Taken together, this extended chain of third, fourth, and nth parties is part of what many practitioners now refer to as extended enterprise risk, the risks that arise across the wider network of external relationships that support your organization’s products and services. Why fourth- and nth-party risks are getting attention Fourth- and nth-party relationships are getting more attention because shared dependencies are now easier to see. For example, one cloud platform, KYC provider, or infrastructure service can affect several third parties at once, turning a single incident into a disruption across multiple services. Regulators and boards are also asking more specific questions about sub‑processors, concentration risk, and resilience. Once you accept that fourth and nth‑party relationships can materially affect your organization, the next question is what to do about it in practice. You cannot manage every downstream provider directly, but you can absolutely design a TPRM program that properly addresses fourth‑ and nth‑party risk. Here are eight practical actions you can take to help your organization more effectively identify, analyze, and mitigate those extended‑ecosystem risks. 1: Determine How Far You Will Go If you try to map your whole supply chain, you’ll end up with too much information and little value. It’s usually better to set clear criteria for what’s in scope, like access to customer data, critical services, or when the same downstream provider is used by several third parties. Start by deciding how deep you are willing to go. A reasonable standard for many programs is your direct third parties, plus their critical sub‑processors and major shared platforms that would materially affect your business if disrupted. Make sure your final decision is reviewed and documented. If someone asks why a certain downstream provider is included or not, you should be able to explain it easily. 2: Know How to Identify Your 4th And Nth Parties After you decide how deep to look, the next step is finding those downstream entities. Some third parties will give you a clear list of sub-processors, but many will not. A practical way to do this is to gather information from several sources: SOC 2 Type II reports, especially the system description and subservice organization sections. External risk intelligence tools that map hosting providers, DNS, IP ranges, and technology stacks. Public trust centers and compliance pages that list sub‑processors or infrastructure partners. Regulatory or industry disclosures that reference key providers. Internal insight from Architecture, Security, and Operations teams that already know which shared platforms sit underneath important services. You are not trying to build an exhaustive inventory. You are trying to identify the downstream relationships that can materially impact your operations, customers, compliance, or reputation. 3: Think In Terms of Fourth‑Party Failure and Concentration When you look past your direct third parties, it helps to break fourth-party risk into two simple questions. Fourth‑party failure risk Start with a single third party and ask, “What if one of their critical fourth parties fails?” For that third party: Which fourth‑party providers are critical to the service they deliver to you? What parts of your operations stop working if one of those fourth parties has an outage or incident? How quickly would the third party detect and communicate that issue to you, and who owns the response on your side? What options exist if that fourth party is unavailable for an extended period (alternate providers, workarounds, manual processes)? This approach keeps the focus on a specific relationship: your third party, their key fourth party, and how it affects your organization. Fourth‑party concentration risk Then step back and ask, “How many of our third parties rely on the same fourth parties?” Across your third party portfolio: Which fourth‑party providers appear repeatedly in different third party relationships? How many critical services in your inventory ultimately depend on the same fourth‑party cloud, KYC, payments, or messaging provider? Are there specific fourth‑party entities that, if impaired, would create issues across multiple third parties at once? Here, you’re mapping shared fourth-party dependencies across your third parties . The result should be a short list of fourth-party providers and the services or third parties they support, so leadership can see where the biggest exposures are. By looking at fourth-party failure risk for each third party and concentration risk across your whole portfolio, you get a clearer view of where extended-ecosystem risk is acceptable and where you need to focus more attention. 4: Understand How Your Third Parties Manage Their Third Parties Since you can’t manage all your third parties’ third parties, one of your best controls is making sure your third parties have strong TPRM practices themselves. This means asking if your third parties identify and rank their own third parties, separate critical providers from less important ones, do proper due diligence, and monitor those relationships over time. Third parties with mature TPRM programs are more likely to spot their own dependencies, catch issues early, and alert you to important problems. If your third party does a weak job managing its own supply chain, you inherit that weakness. If they are disciplined about risk tiers, due diligence, and ongoing monitoring, you gain a layer of protection and visibility you could not create on your own. 5: Build Visibility into the TPRM Lifecycle It’s easier to manage downstream risk when you include it in your existing processes, instead of tracking it separately in a spreadsheet. This can be as simple as asking the right questions or gathering key information at each stage of the lifecycle: Risk Assessment: Identify your critical products and services and focus on their sub processors. Due Diligence: Ask third parties about material sub‑processors and critical upstream services during due diligence. Record those entities in your third party/supplier record so they can be tracked over time. Contracting: Ensure clauses cover disclosure of critical sub-processors and notifications when they change. Monitoring: Update the record when sub‑processors change, new dependencies appear, or incidents affect key downstream providers. Exit: Capture what you learned about the third party’s downstream footprint and use it in future assessments. By including fourth- and nth-party oversight in your regular processes, you create consistent risk checkpoints and collect data that helps you make better decisions. 6: Contract For Downstream Control You might not have contracts with fourth- or nth-party entities, but you do have contracts with your third parties who rely on them. That’s where you have leverage. Useful terms include the requirement to disclose material sub‑processors, notice before changes, flow‑down obligations for security and resilience, incident notification when a sub‑processor issue affects your service, and independent assurance where appropriate. You obviously can’t dictate how someone else’s third party or supplier program operates. You can hold your third parties accountable for managing their own downstream relationships in line with your risk expectations. 7: Use Risk Alerts and Threat Intelligence for Key Downstream Providers You don’t need a contract with a downstream provider to keep an eye on public risk information about them. Risk alert services, external monitoring platforms, and threat intelligence feeds use public and open-source data, making them helpful for key nth-party relationships. For higher-impact downstream entities, you can monitor domains, infrastructure, leaked credentials, breach chatter, major vulnerabilities, and other warning signs. This monitoring won’t replace good third party management, but it gives you another way to spot issues with important shared providers. This is especially useful when a downstream provider supports several third parties in your environment. In these cases, a single alert can tell you more than multiple questionnaires. 8: Embed Downstream Risk into Governance Fourth- and nth-party risk management works best when it’s included in the same governance channels as your other key risks. This could mean including shared dependencies in outsourcing discussions, resilience reports, third party portfolio reviews, and contract playbooks. When it’s part of regular reporting and oversight, it becomes a normal part of your program instead of a special topic. Conclusion Fourth- and nth-party risk falls somewhere between your third parties’ responsibilities and your own. You can’t control every downstream provider, but you also can’t ignore how those relationships might affect your organization and your customers. The eight actions in this blog are designed to give you a practical starting point. If you pick a few and add them to your program, you’ll get better visibility into the downstream relationships that matter most and a more consistent way to manage their risks. You don’t have to solve everything at once. Focus on bringing the right extended relationships into view and handling them with processes you can explain, repeat, and improve over time. That’s what real progress on fourth- and nth-party risk looks like in a TPRM program. 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.

Staying on top of third party risks doesn’t stop at onboarding. Ongoing monitoring is crucial for ensuring your third parties remain compliant and resilient over time. Review the infographic below for actionable tips to enhance your continuous monitoring strategy. Interested in learning more about Continuous Monitoring? Check out our Free TPRM 101 Guidebook: https://www.tprassociation.org/guidebook Download the infographic:

A decade ago, most third party risk programs followed a simple routine: assess the third party's risk level, perform adequate due diligence, review the contract, and check in once a year. While this approach is still used, it no longer meets today’s broader expectations for resilience, cybersecurity, privacy, supply chain oversight, and artificial intelligence, putting your business at risk of non-compliance or disruption. In 2026, TPRM is governed by a much broader mix of frameworks and regulations, including the Digital Operational Resilience Act (DORA), the Network and Information Systems Directive 2 (NIS2), the General Data Protection Regulation (GDPR), the Corporate Sustainability Due Diligence Directive (CSDDD), and the UK critical third parties regime. These requirements may highlight different risk concerns, but they often affect the same parts of a TPRM program: third party classification, due diligence, contract terms, monitoring, issue management, and exit planning. More Frameworks Now Affect TPRM The biggest change is not a single regulation, but the increase in frameworks that now apply to third party oversight. DORA requires financial firms to manage third party IT risk through governance, testing, concentration risk management, and record keeping. NIS2 broadens cybersecurity and supply chain requirements, making third party risk a key part of incident response and operational governance. Privacy and supply chain rules add complexity. GDPR continues to guide how organizations manage third parties handling personal data. CSDDD and Germany’s Supply Chain Due Diligence Act (LkSG) also drive organizations to examine risks, including human rights and environmental risks, beyond direct suppliers. Key takeaways Managing third party risk now means meeting broader standards for resilience, cybersecurity, privacy, and supply chain oversight. One process change may need to address multiple frameworks at once. Operational Resilience Has Raised the Standard Operational resilience rules continue to emphasize the importance and urgency of third party oversight. DORA requires firms to identify critical providers, manage concentration risk, include oversight and exit terms in contracts, and maintain detailed records. NIS2 also strengthens supply chain security and incident readiness, treating third party failures as broader issues. The UK’s critical third party regime adopts a similar approach for financial services, allowing direct oversight of providers whose disruption could affect many firms or the wider market. The bottom line: if a third party supports a critical service, regulators expect more than just a one-time review. Key takeaways Critical third parties require heightened scrutiny as new regulations and resilience rules emphasize operational dependencies and disruption risk. Third party classification, contracts, continuity, and documentation must adapt to resilience standards. Overlapping Rules from Different Jurisdictions Create Practical Challenges One challenge for TPRM teams is that third party oversight often goes beyond a single country’s rules. For example, a U.S. organization may begin with local requirements but find extra obligations if it serves customers in the EU or UK, supports regulated firms there, or uses third parties that do. This means the same third party might need different review steps based on location, customer type, or service model. To manage this complexity, organizations should prioritize requirements that carry the highest regulatory or business risk and look for opportunities to harmonize controls where possible. Establishing a baseline set of global controls, then layering on local or high-priority requirements, can help ensure compliance without duplicating effort. When faced with conflicting rules, consult with legal, compliance, or risk experts to determine which requirements should take precedence. Multiple regulatory requirements often create challenges as organizations grow. A TPRM program built for one country might struggle when the company expands to new markets or supports clients in other jurisdictions. DORA can even apply to non-EU providers serving EU financial firms; NIS2 covers organizations offering services in the EU, and the UK’s rules affect non-UK providers serving UK financial companies. Key takeaways Expanding your business across borders often brings overlapping regulatory requirements. TPRM needs adaptable due diligence and oversight for global third parties. Less Frequent Reviews Are Hard to Justify Annual assessments are useful, but less convincing when third party risk changes during the year. DORA and NIS2 both emphasize ongoing oversight and incident readiness. Not every organization needs to implement automated monitoring or redesign risk re-assessment schedules; however, critical third parties, major subcontractor changes, concentration points, and significant incidents should be addressed between formal reviews. Key takeaways Point-in-time reviews leave gaps when third party risk changes quickly, making it harder for your organization to respond to emerging threats. Higher-risk third parties require ongoing monitoring year-round. AI Highlights Weaknesses in Older TPRM Processes Artificial intelligence (AI) is now providing clear indicators of where older TPRM tools fall short. Standard questionnaires developed a few years ago might cover security and privacy but probably miss basic questions about AI use, data inputs, model governance, and how important changes are explained. This means organizations are trying to assess new risks with outdated templates. Regulations make this even more challenging. AI-related requirements can come from specific AI rules, privacy laws, model risk standards, or industry supervision, depending on the country and use case. As a result, the same third party may need different levels of review based on its services and where it operates. Key takeaways AI risks increasingly surface in third party relationships that older processes may overlook. Cross-border third parties need flexible, AI-specific due diligence and contracts. A Few Things Organizations Can Do Now Most organizations do not need to completely rebuild their TPRM programs. By strengthening the parts facing new regulatory pressures, you can meet evolving requirements and keep your business protected. Current frameworks all point toward better visibility into third parties and dependencies, stronger documentation, clearer governance, and more up-to-date oversight, delivering the assurance your organization needs. Here are a few practical steps that can help: Update your list of critical third parties and confirm which regulations apply based on service, location, customer type, and data exposure. Prioritize requirements that carry the highest regulatory or business risk and look for opportunities to harmonize controls where possible. Review your questionnaires and contract templates to ensure they cover resilience, subcontractor visibility, AI use, incident response, and exit support as needed. Set up monitoring triggers for Critical and high-risk third parties, such as major incidents, subcontractor changes, declining performance, sanctions updates, or concentration points affecting critical services. Ensure that changes or updates to your processes are documented, including the rationale for those changes. TPRM programs are always evolving, and recent changes mean many organizations must now align with overlapping expectations from DORA, NIS2, GDPR, CSDDD, and local rules for how third parties are chosen, contracted, monitored, and, if needed, exited. This is harder in multi-jurisdiction environments and with AI-enabled services, where the same third party can fall under several rule sets at once. Organizations that keep a clear view of critical third parties and jurisdictions, keep their questionnaires and contracts up to date on resilience and AI, and add reliable monitoring triggers, should be able to keep up without rebuilding their program every year. 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.

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