Let's build a Third-Party Risk Program that Works - Part 1

Part 1 of 6: Foundation - Understanding Your TPRM Requirements | 8 min read

You've been tasked with building or rejuvenating a Third-Party Risk Management (TPRM) program. Maybe it's new regulation, or old regulation with regulators circling. Maybe a customer sent a pointed security questionnaire. Maybe your board suddenly cares about "vendor risk" after reading about another supply-chain breach. Or maybe it's time to fix a program that's burning money without building confidence.

Here's the uncomfortable truth: TPRM programs cost real money and political capital—in a risk area that may have never cost your organization a single dollar.

So how do you build—or improve—a program that actually works without turning into expensive tool sprawl? Let's start by re-thinking the business case itself.

The Real Business Case (It's Not What You Think)

"Do we need a formal TPRM program?" I hear this constantly: "We've worked with vendors for 20 years and never had an issue." And to be honest, you might go another 20 years without incident—or you might be dealing with one tomorrow.

Many organizations confuse luck with control. Building a program that reflects real risk means striking the right balance of investment, visibility, and resilience to match your risk appetite.

Think of it like car insurance. Everyone needs to buy it—even if they've never crashed. But, the deductible and coverage depend on what you're protecting. TPRM works the same way. Every organization needs one, but the level of investment for due diligence depends on potential fallout concern: exposing customer data, a critical supplier outage, or a compliance violation from a partner's mistake. Any one of these can cost more than a decade of prevention.

The "One Size Fits All" Trap: Rachel Wilson, Head of Data Security and Infrastructure Risk at Morgan Stanley, said at a 2023 conference: "TPRM is a complicated domain. It is one size fits no one." In many cases where the foundation is not clear, she might be right. Organizations that treat every vendor the same—forcing the janitorial service through the same scrutiny as the cloud provider—end up with programs that serve no one well. High-risk vendors slip through. Low-risk vendors stall procurement. The fix: consistent process, scaled intensity.

However, with the right approach, we can get beyond that.

What TPRM Actually Does:

• Identifies and inventories who you're working with—and the impact they can have on your business, far beyond just cyber access.
• Creates visibility into which partners could reach your crown jewels.
• Enables informed risk decisions—not the illusion of eliminating risk.
• Builds defensible documentation when regulators, auditors, or customers come knocking.
• Reveals "single-point-of-failure" vendors hiding in your ecosystem.

What TPRM Doesn't Do:

• Guarantee vendor performance or prevent all incidents.
• Replace contracts, insurance, or basic vendor-management fundamentals.
• Magically solve every compliance problem—TPRM is one piece of a broader risk strategy.

The key: Calibrate to your actual risk appetite. Get a true picture of your vendor roster and assess each relationship based on inherent risk—not on a "check every box" fantasy or an excuse to buy software that becomes another abandoned initiative.

Don't Overthink the Team (But Don't Wing It Either)

Most TPRM programs lose their effectiveness in one of two ways:

Death by Committee: You create a governance board that meets too often or obsesses over vendor taxonomy instead of sharing real risk status and decisions.

Death by Ambiguity: Everyone owns it, so no one owns it. Decisions stall, and the program drifts without purpose.

The Sweet Spot: Someone must own it. Dedicated resource, shared role, hybrid approach—it doesn't matter. What matters is that one person can articulate successes, identify gaps, and drive strategy forward.

Who Actually Needs to Be Engaged:

• Senior Business Stakeholders – They face the customers and headlines when vendors fail.
• Legal – Contract language determines your real recourse when things go sideways.
• Finance – They know where the money goes and which "vendors" are truly critical.
• IT/Security – Technical risk assessments; not all access is created equal.
• Procurement – Your gateway; if they don't enforce policy, the program is optional.

The Engagement Philosophy: Quarterly check-ins for business-as-usual. Ad-hoc meetings for decisions. One annual strategic review. That's it.

If senior leadership meets monthly, include a brief KPI update—informational only. Save policy debates for quarterly TPRM meetings.

Get explicit commitment on roles—but don't over-engineer it. Over-define and people disengage; under-define and the program drifts into irrelevance.

Real-World Example: A mid-sized financial-services firm launched a monthly TPRM committee with nine members. Attendance dropped to 30 percent within three months. They pivoted to quarterly email updates with escalation triggers for critical issues—and engagement shot up when it mattered.

Define "Risk Appetite" Like You Mean It

Once roles are set, it's time to define risk appetite. When I ask leaders, "What's your organization's risk appetite?" I usually hear: "Very risk-averse." That doesn't help.

"We have a moderate risk appetite" is equally meaningless.

Try This Instead—Be Concrete:

• System downtime: Can we operate if critical systems are down for 24 hours?
• Manufacturing interruption: Can we survive 48 hours without production?
• Financial loss: What's acceptable—$20,000? $200,000?
• Service outage: Can we tolerate two days of customer-facing disruption?
• Data exposure: Could we accept employee data being leaked?

This type of clarity drives action. You now know the RPO/RTO (Recovery Point/Time Objectives) and the risk valuation that truly matter. Those define your inherent-risk algorithm and guide which vendors need deeper due diligence. From there, you can shape controls to reach your residual-risk targets.

Why This Matters—A Real Example:

Risk Appetite: "We can not tolerate ANYunauthorized access or breach of customer PII—to protect against reputational and financial risk."

Inherent Risk Decision: "This vendor connects to systems with 50,000 customer records. Inherent Risk = Critical. Potential reputational damage + $500,000 exposure for credit-monitoring alone."

Control Requirement: "Vendor must adhere to semi-annual questionnaires, allow on-site visit of their data center, and maintain SOC 2 Type II certification to proceed."

*ERI Direct estimates the average cost of credit monitoring at $10 per affected customer. Source

The Measuring Stick: What Does a Good Foundation Look Like?

The First Meeting/Re-alignment Meeting Agenda

1. Present the mission of the TPRM program to stakeholders.
2. Assign ownership and clarify roles.
3. Define risk appetite with concrete, defensible statements.
4. Agree on what TPRM will—and won't—do.
5. Set goals for the next meeting.
6. Establish communication cadence and escalation protocols.

Document It: The Charter

Create/update your 2-4 page Charter Document (binder or intranet page) that includes:

• Program Mission & Purpose – Why this exists and what problems it solves
• Executive Sponsorship – Who cares about it at the leadership level
• Governance Structure – Committee members, ownership, and decision rights
• Risk Appetite Statements – Concrete, defensible thresholds (not vague principles)
• Scope & Boundaries – What's in, what's out (initially)
• Phased Roadmap – General milestones with realistic timelines
• Communication Strategy – Cadence, methods, escalation protocols
• Success Metrics – How you'll measure progress (beyond "assessments completed")
• First Meeting Minutes – Documented decisions and commitments

Get signatures. This becomes your North Star when scope creeps or priorities shift.

Real-World Example: A healthcare company spent six months debating its TPRM framework and toolset. When a new CISO arrived, we helped her design a clear strategy. She called her first meeting and documented the inherent-risk appetite with input from the CFO and CEO. She then advised that the program would develop an inherent-risk algorithm to evaluate all vendors and identify controls to meet residual-risk thresholds. In three pages she defined the structure, secured executive sign-off in two weeks, and had a working foundation within 30 days.

Start with small victories—bite-sized goals that build longevity. Perfection is the enemy of progress.

The Bottom Line

Building TPRM isn't about perfection. It's about creating a useful program your organization will sustain.

Foundation first: Know why you're doing this. Get the right people on board (without over-committing them). Define risk appetite in language real humans use. Document it. Move forward.

What's Next: Building Your Vendor Universe

In our next post, we'll tackle the messy reality of Program Planning—discovering your actual third-party landscape (not the aspirational one).

• Technology vendors – SaaS sprawl, cloud providers, APIs, and infrastructure
• Operational vendors – facilities, logistics, janitorial, food service
• Contractors & consultants – the forgotten workforce hiding in HR systems
• Professional services – legal, accounting, auditors, marketing agencies
• Financial services partners – payment processors, banks, investment advisors
• Data processors & custodians – anyone touching customer or employee data
• Acquisition & merger targets – due diligence before they become your problem
• Fourth parties – your vendors' critical subcontractors

You can't manage risk you can't see. Part 2 will show how to uncover it all—without drowning in spreadsheets.

Does this resonate? Join the conversation - we would love to hear about the TPRM challenges you're facing—or the anti-patterns that make programs fail.

Ready to build a TPRM program that delivers results—without blind investments in Cyber Ratings or Questionnairing platforms that don't deliver? Let's talk about moving from "wandering program" to "defensible framework" in weeks, not months.

Don't miss Part 2: Subscribe to our newsletter below to get the next post in this series delivered straight to your inbox.

This is Part 1 of the Practical TPRM Series: Let's Build a TPRM Program that Works.