An “ideal” vendor management program is unattainable, however, picking a focus and optimizing around that focus enables you to develop an improved program that works much better in comparison than most throughout the industry.
This piece explains six key focus areas to choose from when optimizing your vendor management program, how to measure maturity around each and key pitfalls to avoid.
Vendor Management Challenges
While the desire for an ideal vendor management program is understandable, real-world attempts to create such programs almost always fail. The reason for this is not only that every organization is different, but that each organization’s needs drive
different selections for different vendors. An organization that strategically outsources particular aspects of its business is different from an organization that strategically retains only particular aspects of its business while outsourcing all
the rest. Smaller organizations have different needs than larger organizations. Organizations differ in locality and by industry, with respectively different requirements in terms of vendor management. Instead of focusing on an ideal program, it is
usually better to focus on different ways to optimize your program.
Vendor Management Program Focus Areas
It’s possible to build a program that includes many different areas—such as governance, risk, vendor selection, vendor monitoring, vendor retention, etc. Most organizations typically will not want to focus on all areas equally and only consider
particular aspects to when it comes to optimization. There is growing emphasis on holistic evaluations in third-party risk management. NIST’s Cybersecurity-Supply Chain Risk Management (C-SCRM) regulations set a standard for organized and purposeful management of cybersecurity risks throughout the supply chain. C-SCRM requires enterprise recognition and awareness – critical for addressing cybersecurity risks throughout the supply chain.
1. Vendor Capabilities
When optimizing around vendor capabilities, it is important to identify, ahead of time, the vendor capabilities that matter. This may involve categorizing vendors by service provided (as opposed to high, medium and low risk), or it may involve identifying
vendors on a project-by-project basis. The key to this approach is recognizing the biggest risk from a vendor is often its failure to achieve the purpose for which it was hired.
Basing a program on vendor capabilities avoids the time sink of classic “vendor risk” assessment and, instead, requires a deep knowledge of how vendors are actually used in the organization. This approach will not work well in organizations
that are heavily siloed.
Maturity benchmarks: Maturity for this optimization would largely focus on building a library of internal needs and mapping that to a library of vendor capabilities. As the program matures, work would centralize around the categorization effort and attempts
would need to be made to constantly reduce vendors to avoid vendor bloat from becoming another core risk of vendor use.
2. Vendor Quality
Focusing on vendor quality is similar to capabilities, but instead of asking what a vendor can do for you, ask how well the vendor is working. This subtle difference is critical when it comes to the actual measurement of vendor performance. While initial
efforts may be contract-focused, building requirements directly into the agreements over time, it will be important to develop meaningful security metrics for each key deliverable and to
build a real-time reporting system that links to operations.
This approach allows for real-time measurement and is a good fit for a high-flow rapid delivery organization. It optimizes around vendor risks that mirror the organization’s ability to execute its mission and achieve its goals. This approach also
requires that vendors be selected with specific objectives in mind, so performance can be measured.
Maturity benchmarks: Maturity for this optimization would largely focus on building a library of vendor services and a set of tests to verify whether each capability is being met. Over time, this will require deep metrics around the services the vendor
is delivering, as well as deep understanding of what the vendor should be delivering.
DOWNLOAD: Vendor Vulnerability and Remediation Policy Template
3. Vendor Risk
The classic optimization is to focus on the nebulous term “vendor risk.” This is not helpful, however, nor is the classic approach to lump vendors into high-, medium- and low-risk vendors. What, after all, is a high-risk vendor? Is it a vendor
that has high inherent risk based on the nature of the work it does? Is it a vendor with a high level of risk because it has high turnover? Is it a vendor that has a high number of lawsuits against it? In any of these scenarios, if you have a vendor
that meets the requirement, why do you have them at all?
No, considering vendor risk in a modern vendor management program requires an understanding of what functions the vendor performs, what the risk indicators may be for each function, and then identifying whether any such “red flag” indicators
may be present.
Maturity benchmarks: Maturity in a modern vendor risk system requires orthogonality. In other words, as you mature the process used to categorize each vendor and identify the red flags, you want to minimize overlap between flags. When the program starts,
such overlap is inevitable, but as you iterate through the process of improvement, you will start to notice that every time one flag is raised, another is usually raised with it. This indicates overlap and is a point where the program must be revised
so each flag can and does stand alone.
READ: How to Build a Third-Party Risk Management Framework
4. By-the-Book Vendor Governance
A classic optimization would be around traditional vendor governance. This practice is based on the (flawed) notion that it is possible to change how a vendor does business based on a periodic assessment by a single one of its customers. While some organizations
may have the financial power over a vendor to force change, such events are rare and limited. Nonetheless, many organizations take this approach.
In this model, you develop a standard set of questions that you run all vendors through and have a set of recommended remediations for each question the vendor answers with what is predetermined as the wrong answer.
Maturity benchmarks: As such a program matures, you will find several questions keep coming back as “not applicable.” After digging, you will find the questions cluster around business type, and the program will splinter into different question
types for each type of vendor you work with. Taking maturity to the next level, you then look at all the questions that always come back with acceptable answers and start to wonder whether it even makes sense to ask those questions.
Over time, you may find that a by-the-book approach will converge on a more modern vendor risk optimization (see Focus Area 3), but with a much higher back-end cost due to higher rigor built into the vetting approaches.
READ: Third-Party Risk Management: Guidance for InfoSec Teams
5. Real-World Vendor Governance
A more real-world approach to vendor governance would involve identifying those vendors over which you may have real power to drive change. These may be partners or vendors with particularly detailed contracts. They may be vendors that agree to meet a
specific standard (e.g., PCI DSS) that undergoes public revision and, therefore, drives change. The key to this optimization is to split the vendors you can drive change with from the ones you cannot and develop two different programs.
The first program involves developing a practice around working with the vendors to implement ongoing permanent and monitored change in their practices. The second program would involve developing an internal resilience program to cover the risks from
vendors that cannot and will not change. The nature of each of these programs will vary drastically and should be based on a public standard, like the Center for Internet Security Critical Security Controls Version 8,
NIST SP 800-53 Rev. 5, PCI DSS, HITRUST
or FedRAMP/StateRAMP.
Maturity benchmarks: Maturity of a real-world governance program will show itself as variance from the standard you select to base your program on. You can measure each vendor’s variance in:
- A binary fashion, i.e., number of gaps vs. total requirements.
- Relativistic sense, i.e., percentage complete for each requirement, averaged across all requirements.
- High water mark sense, i.e., biggest risk of a gap wins overall.
Which model you use is up to you, but the key to maturity is to measure all vendors in the same class in the same way. It may, of course, be necessary to sub-class vendors to ensure you compare apples to apples.
READ: Understand the Changes to NIST's Supply Chain Security Guidance
6. Vendor Profiling and Throughput
Another common optimization is to attempt to cover all vendors in the vendor management program. This approach is difficult, because more vendors are being onboarded as you go through this process and, often, at a faster rate than you are able to profile
and assess the existing vendors. You can address this issue by developing a rapid profiling model where you identify classes of vendors and simply drop the vendors into “buckets” based on their attributes. You then assign a generalized
risk level to each bucket and have a very rough way to identify vendor risk across your overall vendor population.
This approach is flawed in that most vendors fit in multiple buckets. You can finetune the process by using a categorization approach as discussed earlier, i.e., assign a generalized risk score to each category, using averaging or high-watermark scoring
to get a sense of the overall risk.
Of course, profiling alone doesn’t improve your risk exposure, so any such program would need to be balanced by an internal resilience program as well.
Maturity benchmarks: As you mature a profiling system, you will find the profiling buckets or categories get better defined and more granular over time. Care would need to be taken, however, to avoid creating an array of categories, each of which only
holds a single vendor, because that would work against the throughput goal of getting full vendor coverage.
Common Failure Modes to Avoid
The most common failure modes when redeveloping a vendor management program include:
- Reinventing what you had before: Even if what you had included some good aspects, attempts to keep the good moving forward risks bringing along the bad. It is almost always better to go in a completely different direction and operate in that new
mode for six to 12 months before reviewing past plans and revising the new system to bring in what might be missing.
- Aiming for a comprehensive, mature program from Day 1: Start small and start with guidelines, instead of rules. Be ready to iterate through the program many times in the first few months, as you adjust big goals and, eventually, get to finetuning
the smaller pieces. Then let it run in that mode for an extended period of time—at least, six months—before doing a full-scale review and revamping the program to climb the maturity ladder.
- Focusing on what the program lacks instead of what it does well: There is no way to build a program that covers all risks and attempts to expand the program to cover everything optimizes human comfort over a functioning program. It is natural to
feel that more data produces better results, but this is objectively not true. By deliberately designing a program around what matters, you are leaving out what doesn’t matter—even if it feels like it should. However, aiming for coverage
slows velocity considerably. You will soon develop an insurmountable backlog and begin the discussion of how to revamp the program all over again.
Redeveloping a Vendor Management Program
When redeveloping a vendor management program, it’s important to:
- Start with a frank discussion of tradeoffs: Decide what the program should do at the cost of everything else and focus there. Pick one optimization and build around that, adding in elements from the other focuses when needed. But don’t stray
from the core focus area or you won’t make progress.
- Review existing vendors: Identify those that are performing poorly anecdotally and see what you can measure to predict that going forward.
- Consider new business projects: Ensure the program you are building will work as business practices transform.
- Look at past failure: Whether they are your failures or well-known industry failures, identify how your program will identify or respond to such events.
All vendor programs can be improved. All vendor programs can be reinvented. The hardest part is taking that first step, so decide what most important thing is and toss everything else to the side. Build a program that does that one aspect as well as you
possibly can. Then, and only then, see if there’s room to add anything else.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.