9 Design Questions Every Vendor Management Program Needs to Answer

I get asked this more than almost anything: how do you shape and right-size a third-party risk management program to work effectively within the business? Less theory, here’s what we actually see in the field.

Why bad design creates friction

A few weeks ago I was in Denver at the Third Party Risk Association conference. At our booth, we used a heat map visual to highlight where friction can live within vendor management. It was a great conversation starter, as folks walked up, pointed, and said, “that’s us.”

Nothing on the heatmap showed a process or software or even a specific pain point. It showed hotspots where friction lives in the foundation. Strategy. Infrastructure. Governance.

These are the root causes of friction. Not software. Not processes. But design.

Most organizations respond to program pain by looking for a better tool, a new process, or more headcount. Those things help at the margins. They don’t fix a function that was never properly designed in the first place.

The strategic blueprint

That’s where a strategic blueprint comes in. When we help clients create a strategic blueprint for their vendor management program, there are 9 design questions we walk through. The principles are the same for every organization. The answers are not. They have to be tailored to how your organization actually operates. And all 9 have to be present.

Here they are.

1. What is the scope of your operations?

Scope defines the boundaries of your program. It answers two foundational questions: which types of third parties are governed by the function, and which functional workstreams are included.

On the third-party side, this starts with defining what a vendor or third party actually means to your organization. If that sounds basic, it isn’t. For example, an insurance client we work with includes brokers and agents in their third-party management scope. Another doesn’t, as they are managed through a different function. The boundary isn’t obvious. It has to be drawn.

On the workstream side, some programs are narrower by design. Third-party risk management functions focus specifically on risk-related workstreams. More comprehensive vendor management programs connect the full lifecycle, from initial sourcing through final offboarding, including contracts, performance management and everything in between. Neither is wrong. But the choice has to be deliberate.

Get scope wrong and you either overreach in ways the organization can’t sustain, or you leave material gaps that come back to create problems later.

2. What operating model fits how your organization actually works?

Your operating model defines the structure of your operations, accountability, and how cross-functional teams will work together. The three models we recommend choosing from are:

• Centralized. A central vendor management office owns and executes all practices. One team, one set of standards, one place where the work gets done.
• Hybrid. Some practices are owned and executed centrally. Others are distributed across the business, with the VMO setting standards and contract owners in the business retaining day-to-day responsibility for their relationships.
• Center of Excellence. The VMO sets standards, provides tools and guidance, and serves as an internal advisor. The business owns execution. The CoE enables and monitors but doesn’t do the work itself.

The right operating model is the one that fits how your organization actually works and can be sustained with the resources you have. And we have clients that have successfully adopted all three.

West Bend Insurance, a $2B P&C insurer we’ve worked with, is a good example.

When Amy Palm took over as vendor manager, contracts and vendor relationships were distributed across the business. Different functions owned different agreements, with wildly different levels of experience managing them. Pulling all of that into a central function wasn’t realistic. So we recommended a hybrid model where the VMO owned certain competencies centrally and set the standards, while contract owners across the business kept day-to-day responsibility for their relationships. That model fit how West Bend actually operated, and it gave Amy the foundation to mature into a seven-person team with a quarterly steering committee that includes executives from IT, Legal, HR, and Underwriting.

There’s no universally right answer. The right model is the one that reflects how your organization actually operates and can be sustained with the resources you have.

3. Where should the function report?

Reporting structure simply means where the vendor management function sits within the organization. Comprehensive vendor management programs commonly sit within Procurement or Finance. Narrower programs often sit under risk (for third-party risk) or IT (for IT-only vendor risk).

The right answer depends on two things.

First, it should align to your scope of operations. A program built around full lifecycle vendor management belongs somewhere with the authority and reach to influence sourcing, contracting, and performance. A narrower risk-focused program may fit naturally under a risk or compliance function.

Second, and just as important, it should sit where it will have the strongest executive sponsorship and the best chance of being taken seriously. The right reporting line with the wrong sponsor will stall a program faster than almost anything else.

4. Which functions own which roles?

Vendor management is naturally a cross-functional effort. While Business Owners generally own contracts and performance, procurement, risk, compliance, legal, cybersecurity, IT and finance all touch vendors at one or more points in the relationship.

Part of your strategy is identifying which functions play a role, defining what those roles are, and establishing how they’re going to work together. Not defining these clearly is one of the most common sources of friction we see. Work falls into the gaps between functions. Accountability gets murky. And when something goes wrong, fingers get pointed instead of problems getting solved.

5. What do your regulators actually expect?

A growing list of regulations governs how organizations manage their third parties and supply chains. Banking, healthcare, life sciences, energy. They all have third-party management and supply chain regulatory requirements for those in the industry, and the list keeps expanding.

Knowing what your regulators expect is critical to ensuring your program is designed to meet those expectations, not retrofitted afterward.

Take NYDFS Part 500 (and related supply chain guidance) as an example. It requires Covered Entities operating under NYDFS jurisdiction to implement a third-party service provider security policy covering identification and risk assessment of providers, minimum cybersecurity standards those providers must meet, due diligence on their cybersecurity practices, and ongoing monitoring.

When that regulation first came out, our client Legal & General America needed to stand up a third party management program to meet requirements. What we built wasn’t a narrow compliance exercise. It was a best-practice vendor management program for all vendors, with NYDFS expectations woven into the design from the start. One program that handled both operational needs and regulatory requirements. We went from concept to operational in six months, giving Legal & General the foundation they needed to certify compliance with Part 500 and continue maturing the program from there.

6. Which frameworks and standards do you align to?

Beyond regulatory requirements, many organizations align to one or more industry frameworks. Risk frameworks like ISO 31000. Cyber and supply chain frameworks like NIST SP 800-161 and the NIST Cybersecurity Framework.

These need to be integrated into your design, not bolted on afterward. They shape how you assess risk, what controls you look for, and how you demonstrate program maturity over time.

7. Which risk domains matter, and how much risk are you willing to accept?

Risk is a central component of every vendor management program because third parties introduce a wide range of risks to the organization. Leading standards make this explicit. The IIA’s Third Party Topical Requirements, for example, expect programs to address 11 key risk domains: strategic, reputational, ethical, operational, financial, compliance, cybersecurity, IT, legal, sustainability, and geopolitical.

That’s a broad list. So your strategy needs to narrow things down to what matters to you, focusing on two key questions:

1. Which risk domains is your organization focused on managing with third parties?
2. What’s your appetite for accepting risk in each of those domains when a third party presents them?

The answers drive everything downstream: how you structure your inherent risk assessments, the level of due diligence you apply, and how much risk you’re willing to accept before requiring mitigation or walking away from a vendor relationship.

8. Who qualifies as a critical service provider?

A big part of risk mitigation is knowing which third parties support your critical services.

A critical service is a business function or process that, if disrupted or degraded, would have a material impact on your ability to operate, serve customers, meet regulatory obligations, or manage risk. Claims processing for an insurer. Settlement systems for an asset manager. Patient records for a hospital. The things that, if they go down, you have a real problem.

Your strategy needs to define the criteria you use to identify which third parties support those critical services. For most organizations, that criteria should align to what’s already defined in your business continuity plan. If a vendor failure would trigger your BCP, that vendor is supporting a critical service and deserves a higher level of oversight and scrutiny than others in your portfolio.

9. What does success actually look like?

This is the ninth component. It’s also the one that gives the other eight their direction.

Before you design anything, you need to know what you’re designing toward. What is the program actually supposed to deliver? Speed and efficiency in working with vendors? Regulatory compliance? Risk mitigation to acceptable levels? Vendor performance against SLAs? All of the above?

Your success measures provide the guardrails around the size and scope of your program. They keep you from building something technically comprehensive but operationally disconnected from what the organization actually needs. And they give you a basis for measuring whether the program is delivering value over time, not just activity.

Why all 9 strategic questions need to be answered

These 9 components aren’t a checklist you can pick from. They’re interdependent. Skipping or defaulting on any one of them creates blind spots, misalignment, or gaps that surface later as friction.

Scope drives operating model. Operating model shapes cross-functional alignment. Risk appetite informs diligence and risk acceptance. Critical services drive oversight intensity. Success measures keep everything focused on the right outcomes, not just activity.

And strategy isn’t a one-time exercise. As your organization evolves, so do the answers. M&A changes your vendor portfolio overnight. New regulations reset compliance expectations. AI vendor proliferation is adding complexity most programs weren’t designed to handle. The questions stay the same. The answers have to adjust to changing realities.

Where to start

The programs we see struggling the most aren’t doing so because of old technology or inefficient processes. It’s because the strategies were never deliberately designed in the first place.

So if you’re feeling friction, start by auditing your own program against these nine components. Not as a compliance exercise, but as an honest diagnostic. Where have you been intentional? Where did you default, skip, or inherit something that was never really designed at all? The gaps you find will always be contributing to the friction.

If you’re standing up a new program, use these as your blueprint from day one. If you’re inheriting or improving an existing one, use them to find where the design broke down. Either way, the goal is the same: a program that was built deliberately, fits how your organization actually operates, and can be sustained and matured over time.

Frequently asked questions