Search Results

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

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

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

In TPRA’s December blog, “TPRM State of the Industry: The 2026 Risk Reality Check,” Heather Kadavy laid out what many practitioners are dealing with heading into 2026, deeper dependency chains, more AI use by third parties, higher expectations for ongoing oversight, and external pressures that land through suppliers.    This blog will discuss what to do with that reality in practice. The sections below focus on preparation and actions that can be put in place early and reused throughout the year, so programs are not rebuilding workflows every time a third party issue surfaces.    What follows is practical guidance, not a maturity model or a checklist. The goal is usable steps that support consistent execution as issues surface.     1) Third Party visibility that supports decisions  Third Party issues often become harder to manage once the same questions circulate across functions. Questions such as who is involved, what systems or data are affected, and which dependencies sit behind the third party. When that information is fragmented, early coordination slows.  Consolidate third party inventories across Procurement, IT, Cyber, Privacy, Finance, and Compliance.  Tag third parties with service, data they can access, criticality, connectivity, primary hosting region, and key sub-service providers.  Track unknowns, such as unclear data exposure or missing sub-service provider detail, and reduce them over time.  Visibility supports alignment when decisions are needed.  2) Tiering for effective and efficient risk management  As third party populations grow, tiering becomes essential to keep program requirements proportional to inherent risk. The point is not only due diligence depth. Tiering and criticality help structure how the program addresses the most common risks and the biggest threats in a consistent way.  Define your risk tiers ( high, moderate, and low) using inherent risk factors such as data sensitivity, access level, operational criticality, concentration risk, regulatory compliance and geography.  Identify third parties that are essential to operations , interact directly with customers , or could reasonably drive regulatory scrutiny if they fail or experience an incident, and flag them as critical .  Assign every third party both a risk tier and a critical or not critical designation, so the program can clearly identify which vendors require the most scrutiny, due diligence, monitoring, and oversight.  Use the risk tier to set baseline program requirements, such as due diligence scope, evidence expectations, monitoring cadence, issue management timelines, and escalation triggers.  For critical third parties , set heightened requirements across contracts, business continuity and disaster recovery expectations, scenario testing, performance monitoring, and incident coordination.  The intent is to structure program effort around where risk and impact concentrate.  3) Practical Nth-party accountability  Sub-service provider exposure often becomes visible after an issue has already arisen. At that point, teams are working to understand who else is involved and what leverage exists.  Require disclosure of material sub-service providers, hosting locations, and changes that affect data or service delivery.  Request sub-service provider data maps for critical third parties only, focused on dependencies that carry real impact.  Start with a small group of critical third parties and expand once the process is repeatable.  Sub-service provider work tends to be most useful when it starts with the dependencies that affect service delivery or data exposure, then broadens over time.  4) Monitoring with clear ownership, including performance  Many organizations receive more third party risk information than they can act on. Without thresholds and ownership, monitoring loses operational value. Monitoring also needs to cover performance, not just risk events, because service degradation and missed deliverables often surface before a formal incident.  Define a short list of conditions that require attention, such as breach disclosures, ransomware activity, sanctions exposure, financial distress, critical vulnerability exposure, major control changes, or sustained service issues.  TPRM sets the cadence and requirements for monitoring based on risk tier and criticality, including what must be reviewed, how it is documented, and when escalation is required.  The business owner manages third party performance and is accountable for driving timely, complete remediation with the third party, including Service Level Agreement (SLA) review, corrective actions, and escalation when customer or operational impact is at stake.  Ownership and accountability drive follow-through and better outcomes.  5) Third party incident readiness and continuity coordination  Third Party incidents rarely affect just one function. They can raise legal questions, trigger privacy assessments, affect operations, or require triage from Information Security teams. When a critical provider is degraded or offline, business continuity and recovery planning becomes part of the same conversation.  Develop a third party incident and continuity playbook with cyber, legal, privacy, procurement, business owners, and business continuity and recovery stakeholders. Include notification and evidence requests, impact assessment, escalation paths, communications, recovery time and recovery point expectations, workaround options, and decision points for failover or alternate sourcing.  Run tabletop exercises that include both incident handling and service disruption scenarios, using at least one critical third party as the case study.  Confirm 24/7 contacts, notification SLAs, and continuity-related commitments for critical third parties, including recovery objectives and support expectations during disruptions.  Preparedness here reduces confusion during incidents and shortens the path from impact to recovery.  6) AI governance in intake and contracts  AI use by third parties can affect data handling, security controls, and compliance obligations. Addressing expectations early helps reduce rework later.  Ask where AI is used, what data it touches, if data is used to train models, retention practices, access controls, and incident handling.  Include contract language on data use, transparency, and notification when AI-related practices change.  Require third parties to identify material changes to AI-enabled features, underlying model providers, or data processing workflows that could affect confidentiality, integrity, availability, privacy, or regulatory obligations.  The goal is oversight and defensible governance, not blocking adoption.  7) Regional and geopolitical disruption  External pressures often reach organizations through suppliers. Preparation means thinking through how disruption would affect service delivery and contractual obligations.  Identify single points of failure by region, facility, cloud zone, or logistics route.  Document substitution options and what can be paused if disruption occurs.  Run scenario exercises tied to regional or geopolitical disruption and update continuity assumptions.  Scenario work surfaces dependencies that are otherwise easy to miss.  8) Cross-functional integration  Third party issues tend to escalate when relationship ownership, escalation paths, and decision authority are not clearly defined.  Name a business owner for each third party to own the relationship and drive risk remediation. Document risk acceptance authority and escalation paths, typically an executive owner or committee.   Hold regular decision meetings for exceptions, remediation approvals, renewals, access changes, and exits.  Maintain an exceptions register with clear expiration dates.  Regular coordination keeps decisions moving and reduces friction when issues span multiple functions.  9) Develop a scorecard leadership will use  A small, consistent scorecard helps leadership see where risk is concentrated and where follow-up is lagging.  Track a limited set of measures:  Percent of critical third parties with current evidence-based validation  Percent with known material sub-service providers  Time to triage third party incidents  High-risk issues past agreed timelines  Concentration risk across core functions  Metrics are most useful when they inform decisions and drive action.  Closing thought  None of these actions require rebuilding a TPRM program. They require clarity on roles, a disciplined way to separate critical third parties from the broader population, and monitoring and escalation approaches that connect risk signals to real follow-up. The programs that hold up best tend to be steady on the fundamentals, especially when third party issues arrive alongside procurement deadlines, operational pressure, and leadership questions.  Author Bio Hilary Jewhurst Sr. Membership & Education Coordinator at TPRA Hilary Jewhurst  is a seasoned expert in third party risk and risk operations, with nearly two decades of experience across financial services, fintech, and the nonprofit sector. She has built and scaled third party risk programs from the ground up, designed enterprise-wide training initiatives, and developed widely respected content that helps organizations navigate regulatory complexity with clarity and confidence. Known for turning insight into action, Hilary’s thought leadership and educational work have become go-to resources for professionals looking to mature their TPRM programs. She regularly publishes articles, frameworks, and practical guides that break down complicated risk topics into meaningful, accessible strategies. Hilary recently joined the  Third Party Risk Association (TPRA)  as a staff member, supporting industry-wide education, peer learning, and advancing best practices. She is also the founder of  TPRM Success , a boutique consultancy that helps organizations strengthen their third party risk management capabilities through targeted training, tools, and strategic guidance.

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

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

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

In many Third Party Risk Management (TPRM) programs, contracts and service-level agreements (SLAs) are signed, filed, and then forgotten. That is, until a renewal deadline sneaks up, or a vendor fails to meet a critical performance standard, whereby no one can prove whether the vendor was or wasn’t held accountable.  If that sounds familiar, you’re not alone.  Contract and SLA management are two of the most underrated yet high-impact areas for TPRM automation. And the good news? You don’t need a massive system overhaul to start reaping the benefits.  Why Contract & SLA Monitoring Matters in TPRM  Contracts contain the DNA of your third party relationships. They note:  What services are being delivered  What controls are expected  When the agreement expires or renews  What happens if something goes wrong  If this information lives in static PDFs or folders, and relies on someone to remember key dates or terms, you’re exposing your organization to real risk. Such risks include, but are not limited to:  Missed renewals that may auto-renew unfavorable terms  SLA violations that go undetected and un-remediated  Unenforced obligations that weaken your risk posture  Automation can help solve this problem. And it doesn’t have to be complex.  What You Can Automate  Here are several key elements of contract and SLA management you can automate today:    1. Key Date Reminders  Renewal and termination notice deadlines  Compliance documentation expiry (e.g., updated SOC 2 required every 12 months)  Review cycles (e.g., quarterly performance check-ins)  Automation example:  Auto-alerts at 90/60/30 days before renewal, with owner assignment and status tracking.     2. Obligation Tracking  Ensure third parties deliver required evidence (e.g., updated pen test results)  Auto-track performance standards (e.g., response times, uptime, ticket resolution)  Flag when obligations aren’t met  Automation example:  Use automated tools to extract obligations from contracts and load them into a tracker that flags upcoming deliverables.     3. SLA Monitoring Integration  Link with operational data (e.g., help desk platforms, uptime monitors) to auto-validate whether SLA commitments are being met.  Set automated thresholds for escalation if a third party exceeds a defined limit (e.g., >3 late response tickets in a month).  Automation example:  When help desk tickets tied to a third party cross a certain age threshold, an alert is triggered to the TPRM team.  Real-World Example: Automating Renewal Notifications in a Mid-Sized Bank  A regional U.S. bank had thousands of third parties with contracts stored across multiple departments. Renewal dates were tracked in spreadsheets, and deadlines were frequently missed, resulting in automatic renewals that locked the organization into poor terms.  “We didn’t realize how often we were defaulting to auto-renewal until we missed our shot at renegotiating a major payment vendor,” the TPRM manager shared.   The team implemented a contract tracker tied to their TPRM tool that extracted and logged:  Contract expiration dates  Required notice periods  Assigned contract owners  Automated alerts were triggered on 90, 60, and 30 days before key dates, with color-coded status dashboards.  Impact:   100% of critical third party renewals reviewed on time  Saved ~$300K through renegotiated terms in Year 1  Improved coordination with Legal and Procurement  Getting Started: Tools You Can Use  You don’t need a custom platform to get going. Some automation options include:  GRC/TPRM platforms  with contract modules   Contract lifecycle tools  (e.g., Ironclad, LinkSquares, DocuSign CLM)  Workflows in MS365 or Google Workspace  using reminders and task lists  Low-code platforms like Airtable or Monday.com for custom trackers    Key Takeaways:  Contracts are a goldmine of risk and performance data. Don't let them sit untouched.  Automating reminders and tracking obligations keep your third parties accountable and your TPRM program compliant.  Start small: even a shared tracker with auto-reminders can reduce missed deadlines and drive savings.  Author Bio Heather Kadavy Senior Membership Success Coordinator Heather Kadavy  joined the Third Party Risk Association (TPRA) in 2023 as the Senior Membership Success Coordinator. In recent year(s) Heather has been providing freelance TPRM consulting work to various organizations after retiring from a Nebraska financial institution after nearly 35 years where she oversaw and managed critical programs of the organization including Third Party Risk Management, Information Security, Physical Security, Safety, Business Recovery, Financial Crimes, Model Risk Management, and Enterprise Risk Management.  In her TPRM role she had oversight of over a thousand third party relationships, systems, due diligence reviews and contract management activities.  She developed, facilitated, and implemented training programs for thousands of employees over the years. Heather is a natural born connector of people and values relationship building at the cornerstone of her career.  She encourages you to connect with TPRA and herself via LinkedIn to join in the "TPRM Global Conversation".

In the early morning of October 20, 2025, Amazon Web Services, the backbone of much of the modern internet, experienced a widespread outage in its Northern Virginia region. Within hours, popular apps, business platforms, and government services began to slow or fail. By evening, AWS reported that services were operating normally, with some backlogs clearing after that. This was not some minor hiccup. It took much of the day to resolve, and by the time systems steadied, the outage had already reminded everyone how deeply daily life depends on the same shared foundations.  The Impact  The outage originated in AWS’s US-EAST-1 region, which supports a significant portion of global cloud activity. That single region underpins countless tools and services used every day by businesses, governments, and consumers alike. Well-known platforms such as Zoom, Venmo, and Alexa saw interruptions, but the effects reached much farther than that.  For many organizations, the disruption was one step removed. Their own systems appeared stable, yet vendors or downstream providers that relied on AWS began to falter. Even companies with no direct contract felt the slowdown through partners and service integrations that quietly depend on the same infrastructure.  The Cause  AWS said the incident stemmed from DNS resolution issues that affected DynamoDB service endpoints in US-EAST-1, and they began mitigation after identifying the problem ( AWS update ). In parallel, traffic health checks did not behave as expected, which complicated rerouting and recovery. The combination created a chain of disruptions that took most of the day to unwind.  In short, one lookup broke, one database stalled, and everything built on top of them learned what “shared dependency” really means.   The Response  AWS posted regular updates, isolated the DNS issue, and restored service, with some queues taking longer to clear. By evening, operations were mostly normal.  AWS confirmed that the outage was not the result of a cyberattack  and said a detailed incident analysis would be released. The company’s updates through its status page and social channels provided transparency but were highly technical, which made it difficult for non-technical teams to interpret and share meaningful updates inside their organizations .   What This Illustrates About Concentration Risk  This was concentration risk in practice, too much dependency in one place. The AWS US-EAST-1 region is popular because it is large, efficient, and cost-effective. That popularity concentrates demand, which can magnify impact during an incident.  When multiple organizations and their vendors depend on the same region, a single problem can become a multi-industry event. Many companies that felt diversified discovered their vendors were sitting on the same underlying infrastructure.  What It Reveals About Fourth- and Nth-Party Risk  Even companies far removed from AWS saw disruptions. That is extended vendor risk, where your vendor’s vendor, or their vendor’s vendor, fails and causes impact for you.  A payment platform might use AWS directly, while your billing software depends on that platform. Your HR system’s analytics add-on might sit on AWS even if the core platform does not. The farther down the chain the issue occurs, the harder it is to see, yet the business effect is the same.  The Broader Lesson: Shared Infrastructure Means Shared Consequences  Cloud services and computing have made business faster and more connected. It has also made it interdependent. When one provider falters, entire industries can feel the shock.  Technical events become business events quickly. Disruptions affect customer access, transactions, revenue, and regulatory expectations. For TPRM programs, resilience is not about predicting every outage. It is about understanding dependency risk and being ready to respond calmly when it appears.  What TPRM Practitioners Should Be Doing Now  The AWS outage was a free stress test. Even if your organization stayed upright, it showed how much depends on a handful of cloud providers. Now it’s time to turn awareness into action.  1. Revisit your dependency map   Trace your direct, fourth-party, and nth-party exposure. You do not need to document every sub-vendor, but you should know where critical systems live and who connects them.  Review your direct vendors and note hosting provider and region.  Identify shared dependencies across your portfolio.  Flag any service that leans on a single region.  Share this with cybersecurity and IT partners to align contingency plans.    2. Strengthen collaboration between TPRM and Cybersecurity/Information Technology  When an outage hits, both perspectives are essential.  Cyber professionals (which may include the incident response team) focus on the how, root cause, technical exposure, and data integrity.  TPRM focuses on the so what, business impact, vendor accountability, and continuity of services.  Confirm with IT which systems can run from more than one location. Confirm with TPRM which vendors must maintain uptime and notify you. If this partnership is informal, formalize a simple workflow that defines who watches vendor status, how alerts move to business leaders, and who decides when to communicate with executives or customers.  3. Update due diligence and contracting  Bake resilience into every step of the vendor lifecycle.  During due diligence   Ask where systems are hosted, including backup regions.  Require disclosure of key sub-vendors such as cloud hosts and data processors.  Confirm that failover is tested and recent.  Check that downtime tolerance matches your business needs.  In contracts   Add notification timelines for incidents that affect your data or operations.  Require vendors to maintain and test continuity and disaster recovery plans on a regular basis (at least annually).  Define how credits or remedies apply during regional incidents.  Include data portability and exit terms so you can migrate if reliability declines.  For existing contracts, capture this through an addendum or vendor questionnaire. The goal is alignment between your expectations and actual capabilities.  4. Treat vendor resilience as an ongoing metric  Do not let resilience live in a one-time questionnaire.  Track uptime and incident response quarterly.  Watch how vendors communicate during industry-wide disruptions.  Follow up with any vendor that takes more than a business day to confirm whether they were affected.  Transparency and communication matter as much as uptime.  5. Bring the lesson to leadership  Executives and boards care about continuity, not DNS details. Use this event as a case study.  Keep it in business terms.  How long could you operate if your main region failed?  Which vendors share that region?  How long does recovery actually take in hours, not in theory?  Boards and regulators should already be asking about cloud concentration and systemic risk. Showing mapped dependencies and credible plans signals maturity and foresight.  Not Ready for All That Yet? Try This Instead  If your program is not ready for the full list above, start smaller. A one-hour tabletop can surface the most important gaps before you redesign your program.  A One-Hour Tabletop: “When the Cloud Falters”  Scenario:  Your most important customer-facing service is degraded for six hours because your cloud provider’s main region is down.  Prompts:   What fails first, and who notices?  Who owns communication with leadership and customers?  What do you tell executives in the first 30 minutes?  What data confirms whether the issue is internal or supplier-related?  If the outage lasts more than four hours, how do you continue operations?  When and how do you tell customers you are stable again?  What good looks like:   Clear ownership of communication and impact analysis.  Named roles for executive updates and recovery coordination.  A realistic recovery time, not a guess.  Two improvement items assigned for follow-up within 30 days.  Start here. Capture where confusion happens and what slows decisions. The results will show you where to strengthen communication, contracts, and coordination next.  Conclusion   The AWS outage was not just about downtime. It was about concentration risk and dependency, and how quietly it grows until something forces everyone to see it. What looked like one point of failure was really a network of shared reliance across vendors, industries, and geographies.  For TPRM professionals, the lesson is to stop treating concentration as abstract and start treating it as operational reality. Every vendor, every contract, and every dependency tells part of that story. The work ahead is not to eliminate risk, it is to ensure that when one link breaks, which it inevitably will, the rest of the chain holds.  Additional Resource Explore our certificate, Securing SaaS Applications: A Comprehensive Approach to Cloud Risk Management , which provides an in-depth look at evaluating and managing risks associated with cloud-based SaaS solutions. 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.

When a vendor relationship ends, the risk doesn’t.  Too often, vendor offboarding is treated as an afterthought, left to chance, split between departments, or buried in a never-used checklist. The problem? An incomplete or inconsistent termination process exposes your organization to some of the highest risks in the TPRM lifecycle.   These risks include, but are not limited to, access that was never revoked, assets that were never returned, and/or data that was never deleted.  The good news: these risks are avoidable, and automation can help.  Why Offboarding Matters More Than You Think  In many organizations, onboarding gets all the attention, due diligence, approvals, kickoff meetings, and security reviews.  But what about the end of the relationship?  "You wouldn’t let an employee walk out the door without collecting their badge and shutting off system access. Why do we do it with vendors?"   Poor offboarding can lead to:  Lingering system access and potential unauthorized activity  Unreturned data or devices , especially in hybrid/cloud environments  No formal record of what actions were completed or by whom  Compliance gaps if data disposal or security controls were contractual  The Automation Opportunity  Here’s where automation can drastically improve vendor offboarding, making it faster, repeatable, and auditable.  1. Triggering the Offboarding Workflow Automatically  When a contract is marked as terminated or not renewed, the system will kick off automated offboarding activities.  It can route these activities to IT, InfoSec, Procurement, and TPRM automatically.  Tool tip: Use a trigger from your TPRM tool, GRC system, or contract lifecycle platform to launch this sequence.    2. Auto-Assigning Offboarding Tasks  Such offboarding tasks can include, but are not limited to:  Revoking system access and credentials  Collecting physical or virtual assets  Confirming data destruction or secure transfer  Archiving vendor risk files and workpapers  Tool tip:  Use tools like ServiceNow, Jira, or Monday.com to assign tasks and track completion status in real time.    3. Generating & Storing Offboarding Evidence  The system can require documentation uploads or confirmations (e.g., screenshot of deprovisioned access, destruction certificates) of completed offboarding tasks  It can also store all evidence in the third party profile for audit purposes  Tool tip:  Attach offboarding steps to a third party profile in your TPRM platform or centralize storage in a secure SharePoint folder.    4. Post-Termination Reviews  Set up a short internal review form to capture any final third party risks or lessons learned.  Optionally trigger a survey to business owners to assess third party performance.  Update the third party’s profile to note if the third party can be used again or if it is recommended to not do business with the third party.  Tool tip: Use Microsoft Forms or Google Forms and auto-send based on the third party status change.  Real-World Example: Offboarding Automation at a Global Fintech  A fintech company with over 1,200 third parties discovered that more than 30% of “inactive” third parties still had some form of residual access, including access to shared cloud folders and legacy single sign-on (SSO) profiles.  The organization then implemented a third party offboarding checklist built into their TPRM platform, which auto-triggered when a contract end date was reached or when a business owner marked a third party as "no longer in use."  Each task, such as deprovisioning access, collecting assets, confirming data deletion, was auto-assigned to pertinent stakeholders with deadlines and owner accountability.  Results in the first 6 months:   Reduced open-access risk by 78%  100% of offboarding steps documented and accessible for audits  Gained stronger alignment between TPRM, InfoSec, and Procurement  Getting Started: Questions to Ask  Do we have a standard offboarding checklist for third parties?  Who owns each task, and how do we know the tasks were completed?  Can we identify all third parties with system access that may still be active post-contract?  Do we store evidence of data destruction or handover?    Quick Win to Try  Start by creating a centralized third party offboarding checklist with due dates and owner fields. Even if you use Excel or a Google Form at first, link this to third party termination triggers and build consistency from there.  Then, explore how your existing tools (TPRM platform, ticketing system, workflow automation) can formalize and automate the process.    For additional information on the third party Termination process, view TPRA’s TPRM 101 Guidebook.   Author Bio Heather Kadavy Senior Membership Success Coordinator Heather Kadavy  joined the Third Party Risk Association (TPRA) in 2023 as the Senior Membership Success Coordinator. In recent year(s) Heather has been providing freelance TPRM consulting work to various organizations after retiring from a Nebraska financial institution after nearly 35 years where she oversaw and managed critical programs of the organization including Third Party Risk Management, Information Security, Physical Security, Safety, Business Recovery, Financial Crimes, Model Risk Management, and Enterprise Risk Management.  In her TPRM role she had oversight of over a thousand third party relationships, systems, due diligence reviews and contract management activities.  She developed, facilitated, and implemented training programs for thousands of employees over the years. Heather is a natural born connector of people and values relationship building at the cornerstone of her career.  She encourages you to connect with TPRA and herself via LinkedIn to join in the "TPRM Global Conversation".

In today’s increasingly interconnected enterprise landscape, third-party vendors are no longer just peripheral—they are central to how organizations operate, deliver value, and respond to change. Despite their critical role, many companies lack a clear understanding of how these external relationships align with strategic goals, operational dependencies, and risk tolerance. This lack of visibility can leave organizations vulnerable to disruption, inefficiency, and unmanaged risks. One of the most effective tools for closing this gap is the business capability map—a structured representation of what the business does to create value. When enriched with vendor, contract, and procurement data, this map shifts from a planning artifact into a strategic framework for enterprise resilience.  A business capability map outlines the core functions of an organization independently of its structure, technology, or processes. It offers a stable view of what the business can do—such as “Customer Onboarding,” “Revenue Management,” or “Supply Chain Visibility”—regardless of how those capabilities are currently implemented. This abstraction is powerful because it enables leaders to focus on what the business needs to accomplish, rather than how it does it. When third-party vendors are mapped to the capabilities they support, the organization gains a clear, contextual understanding of external dependencies. This mapping shows which vendors are connected to specific business functions, identifies redundancies or gaps, and illustrates how vendor relationships affect operational resilience.  The value of this approach becomes especially clear when viewed through the lens of risk awareness and resilience analysis. For example, if a single vendor supports a mission-critical capability like “Data Protection,” the organization may face a concentration risk. Conversely, if multiple vendors support the same capability without a strategic reason, it could indicate vendor sprawl—an inefficiency that can weaken accountability and add complexity. By visualizing these relationships, organizations can identify where intentional redundancy is necessary for resilience and where consolidation could lower risk and cost.  This capability-vendor mapping also supports more strategic decision-making. Leaders can pose targeted questions such as: Are high-risk vendors supporting high-value or mission-critical functions? Are there capabilities without vendor support, indicating over-reliance on internal resources or potential single points of failure? Do current contracts and procurement strategies align with the organization’s future capability roadmap and resilience objectives? These questions help shift the focus from reactive vendor management to proactive resilience planning.  The advantages of this approach are clear. For example, during a vendor outage or cybersecurity incident, the capability map helps teams quickly determine which business functions are affected and prioritize response efforts. During periods of organizational change—such as mergers, acquisitions, or digital transformation—the map offers a stable reference point for evaluating vendor dependencies and maintaining continuity. Procurement teams can use the map to negotiate contracts that include resilience clauses, like service-level guarantees, disaster recovery provisions, and data portability. Business owners gain clarity on which capabilities are externally supported and can plan accordingly for performance, continuity, and scalability.  Building and maintaining this resilience-focused capability map requires collaboration among several key roles. Third-party risk managers contribute insights into vendor criticality, exposure, and compliance. Business owners provide operational context and performance expectations. Procurement teams align sourcing strategies with business priorities and resilience objectives. And business architects ensure the capability framework remains accurate, relevant, and adaptable to future needs. Together, these stakeholders create a shared understanding of how external relationships support the business—and how those relationships can be optimized for resilience.  Ultimately, mapping third-party vendors to business capabilities is more than just a technical task—it’s a strategic necessity. It enables organizations to manage complexity confidently, reduce risk, and build a more resilient enterprise. By defining ownership, dependencies, and risks across the capability landscape, businesses can make better decisions, respond more effectively to disruptions, and ensure that external partnerships support long-term strategic objectives.  Author Bio Keith Stouder VP, Data Privacy and Protection Keith Stouder is an experienced executive with over 30 years of experience in enterprise architecture, data privacy, and security. He began his career in state procurement, where he handled complex technical RFPs, and has established a notable record in third-party risk management (TPRM), successfully launching two TPRM programs and developing two others. Keith consistently takes a strategic and practical approach to balancing risk with business value. He currently serves as Vice President of Data Privacy and Protection at ACT, Inc. , where he leads a cross-functional, innovative team focused on using automation and AI to enhance third-party due diligence and streamline the vendor approval process. Keith ensures that vendor value is delivered throughout the contract lifecycle—managing vendors both individually and as part of the broader enterprise portfolio. Through strategic oversight of vendors and applications, he aligns portfolio management with business goals to maximize operational and financial impact.

Most TPRM programs start risk management after the contract is signed, or worse, after the third party is already active.  But by that point, you're already behind.  The best TPRM teams are shifting left, embedding automation into the intake and triage process to capture the right information, assign the right risk level, and route the right review at the very start.   Done right, intake automation helps you:  Stop sending redundant questions to the third party  Avoid missed high-risk third parties  Improve turnaround time  Make procurement and business units your partners, not your adversaries  The Intake Problem   Manual third party intake often looks like this:  Business user of the third party product/service emails TPRM team: “Can we use this third party?”  TPRM team asks for a basic description of products/services that will be offered  A general questionnaire is sent (regardless of third party type or data sensitivity)  Multiple follow-ups and clarifications are performed  Everyone’s frustrated  This is inefficient and does not take into account a risk-based approach. Low-risk third parties get over-scrutinized, and high-risk third parties may slip through the cracks.  What You Can Automate   Let’s look at how automation can transform intake into a structured, repeatable process that gathers key risk insights and triggers the right next steps, without creating bottlenecks.   1. Smart Intake Forms  Use an online form (e.g., in your GRC, TPRM platform, or tool like Microsoft Forms) that business users fill out   before  engaging with a third party.  Questions to include:  What services will the third party provide?  Will they access customer data or company systems?  What types of data will be accessed (PII, PHI, PCI, IP)?  Where will the services be delivered from?  What’s the contract value or term length?  Is this third party replacing an existing one?  Tool Tip : Conditional logic can adjust questions based on prior answers, keeping the form short and relevant.    2. Automated Risk Triage  Based on responses, route the request into the appropriate track:  No Risk Identified → auto-approved or documented as "informational only"  Low Risk → minimal questionnaire or policy acknowledgment  Moderate Risk → standard due diligence questionnaire sent  High Risk  → full risk review, possibly including legal, compliance, and InfoSec reviews  Tool Tip:  Some TPRM Tools allow auto-routing of intake requests based on logic trees.  3. Trackable Intake Queue   Turn intake into a visible, trackable pipeline, not a buried inbox.  You should be able to see:  How many new third parties are awaiting review  What tier each has been assigned  What due diligence is pending or complete  Who “owns” the next step  Tool Tip: Use Trello, Jira, Monday.com , or a built-in TPRM dashboard to manage this visually if your TPRM system doesn't already.    4. Integration with Procurement or Legal Workflows   Make intake the bridge between procurement, legal, and risk, not a roadblock.  Connect your intake system to:  Contract review tools  E-signature platforms (e.g., DocuSign)  Purchase request systems  Procurement tools (e.g., Coupa, SAP Ariba)  Bonus : Add a “TPRM clearance” checkbox in your procurement tool so teams can’t finalize deals without routing through risk mitigation activities.    Real-World Example: Intake Transformation at a Healthcare Provider   A large healthcare company implemented a smart intake form tied to its procurement request portal. The form automatically tiered third parties and launched tailored workflows based on services, data access, and regulatory flags.  Results:  3x faster intake processing time  100% of high-risk third parties flagged before a contract was signed  70% reduction in unnecessary reviews for low-risk third parties  Business stakeholders started submitting requests earlier in the process  Getting Started  Here’s how you can start automating intake and triage:  Map what you want to know up front (data access, geography, system access, business impact)  Build a simple intake form, even in Google Forms or Microsoft Forms if you do not have a TPRM platform  Create decision logic to assign a risk tier based on responses  Route the third party to the appropriate review workflow  Track the intake queue so nothing falls through the cracks    Pro Tip: Make Intake the Gateway, Not the Gatekeeper  Your intake process should empower business stakeholders with clarity and speed, not add layers of friction. Automation allows you to deliver fast “yes/no/how” answers, making it easier to get the right third parties in the door and ensure risky ones are on your radar.    Key Takeaway  Automating intake and triage ensures that TPRM starts at the right moment, with the right information, and the right level of scrutiny is provided. It protects your organization while speeding up business decisions.    Author Bio Heather Kadavy Senior Membership Success Coordinator Heather Kadavy  joined the Third Party Risk Association (TPRA) in 2023 as the Senior Membership Success Coordinator. In recent year(s) Heather has been providing freelance TPRM consulting work to various organizations after retiring from a Nebraska financial institution after nearly 35 years where she oversaw and managed critical programs of the organization including Third Party Risk Management, Information Security, Physical Security, Safety, Business Recovery, Financial Crimes, Model Risk Management, and Enterprise Risk Management.  In her TPRM role she had oversight of over a thousand third party relationships, systems, due diligence reviews and contract management activities.  She developed, facilitated, and implemented training programs for thousands of employees over the years. Heather is a natural born connector of people and values relationship building at the cornerstone of her career.  She encourages you to connect with TPRA and herself via LinkedIn to join in the "TPRM Global Conversation".