You already know a little about vendor risk management. For example – which street vendor would you rather buy a hot dog from? The left, or the right?
If you’re thinking about intestinal risk, the left sure looks like the better choice, but it’s not always this obvious when evaluating other types of vendor risk.
Unfortunately, most companies don’t put a lot of focus on managing the cybersecurity risks that come out of their relationships with external service providers and other vendors.
It often comes as a surprise then to those same companies when they prepare for their first SOC 2 or ISO 27001 compliance audit to see how much attention the auditors put on having a formal vendor risk management program.
A close look at some of the most spectacular cybersecurity breaches reveals that many incidents have occurred by criminals first compromising a company’s vendor, and then exploiting the vendor’s relationship with the target company to steal their data.
But using any vendor may also introduce all sorts of other more subtle internal risks – for example, are you sure you’re remembering to remove old employee accounts from your cloud document sharing service when someone leaves the company?
It’s not hard now to see why it is important to start evaluating vendor risk – both external and internal – so that you can make informed decisions and take action to protect your organization.
Don’t know where to start? Don’t worry, this 10-step guide will walk you through everything you need to know to easily get a vendor management program up and running.
But first, what is a Vendor Risk Management program?
In its most fundamental form, a vendor risk management program is any process you follow – even a simple one – that is designed to protect the data your company shares with third parties.
Pause and think about that for a second. Far too often, companies quickly lose sight of that basic point, and instead plow ahead and put in place complicated approval workflows and force vendors to fill out 300 question security assessments, without any clear understanding of how it actually protects their data.
But what does it mean to “protect your data”? Taken to an extreme, it would mean that you should lock up your data and keep it away from all vendors, but it’s awfully hard to run a business that way. You will likely have to share your data with somebody – but don’t forget that you still have control over who that is, how much of it’s shared, and on what terms. That protective oversight, when administered in a centralized and consistent way, is vendor risk management.
How to start a Vendor Risk Management program.
1. Start Small, Start Simple
Anything is better than nothing. Starting with even a simple vendor risk management process is far better than having no process at all.
The goal of your new vendor risk management program should be modest, but concrete: to help the organization make better risk-informed decisions .
“Better” does not mean “perfect” though! Any process you develop that helps you collect and measure your vendor risk in some capacity is an improvement, even if it has some gaps. That’s OK!
Also note that the goal is not to be an “approver” or “denier” – not for now at least. Initially, the vendor risk process should only aim to inform the larger business decision, and not be the final arbiter on vendor approval.
For example, let’s say you’re using this process and you identify some moderate security risks with a vendor, but does that mean it’s now “too risky” to proceed? That may be hard for you to say, because the risk still needs to be weighed by the business leaders against the perceived value of the new vendor’s services, and you may not even know anything about that side of the equation.
Your job then is to arm these people with enough information about a vendor’s security risk so they can compare that to the value of the service. You may also make recommendations on options to protect the company from some of the vendor’s shortcomings. In the end it’s their decision to make, but even a basic risk/benefit analysis would never have happened if it wasn’t for the vendor risk process informing the decision.
But where to start? The idea of reigning in what is probably a messy and uncontrolled process at your company can seem daunting, but it doesn’t have to be. Focus on getting a simple process in place as soon as possible, and don’t get bogged down with too much complexity. Think of it as laying a foundation, and you can build a more robust process as you grow.
2. Partner with Accounts Payable
You’ll need some friends on this journey. Partner up with whomever writes the checks. They know who all your current vendors are and when new ones are added.
One of the first things you need to do is get a list of your current vendors, but that can be difficult if different departments all manage their own vendors. Maybe Cloud Ops owns the AWS relationship, Marketing owns Salesforce, and nobody seems to know who owns the Zoom and Dropbox ones!
In most organizations though, there is usually one person or department that pays all the bills, perhaps Accounts Payable or even the CFO. Go out of your way to make friends with those people! (hint: Tina in Accounting really likes mocha lattes). You need them to supply you with a list of all the vendors your organization currently pays each month, along with the name of the relationship owner within your company, if possible.
They do not need to supply any information about payments, but any details they have about the length of the relationship may be useful.
More importantly, since they control payments, they will end up being the primary enforcers of the vendor risk management workflow. With senior leadership’s blessing, work with these gatekeepers to establish a routine where any request they receive to pay a new vendor must first undergo a risk review. Integrating directly into the existing invoice payment process is usually the easiest way to encourage quick, universal adoption across the organization.
3. Categorize your company’s data.
It’s all about the data. To understand your exposure, create simple categories for the data you share with vendors.
Think about this for a moment – which vendor poses a greater danger?
Vendor A has incredibly sloppy security practices but doesn’t have access to any of your important data.
Vendor B has excellent security practices but also processes your customers’ most sensitive financial transactions.
The greater danger is most likely with Vendor B, because it probably doesn’t matter if Vendor A has a catastrophic security incident. If there’s nothing important at stake, there’s no potential loss to you (beside the trouble of finding a new vendor!). If Vendor B has even a minor security incident, it could lead to very significant trouble for your company, including lawsuits and very uncomfortable investigations.
Measuring risk first requires an understanding of what is “at risk” in the first place. This can quickly get tricky, so remember the “keep it simple” approach. Try to come up with only a few labels to broadly categorize the data that you share with vendors. You’ll use this later to help track the importance of the vendor relationship.
Consider using these categories, but adjust as needed for your business:
None – no data shared with the vendor. For example, a subscription to a stock image library service your marketing team uses for newsletter and website content.
Public – information that is publicly shared and is of little concern if exposed. For example, publicly available data about competitors you’ve collected that you’re now sharing with a market research firm.
Confidential – information that is widely available to employees and other trusted parties but not to the public. Company policy documents, employee handbooks, or a list of employee email addresses are all “confidential”.
Sensitive – information that is protected internally on a “need to know” basis. Financial reports, sales forecasts, bank routing details, product source code, database passwords, and employee home addresses should all be considered “sensitive”.
Protected – This highest level is reserved for Sensitive information that may additionally be subject to regulatory, compliance, or contractual protections. Examples include Protected Healthcare Information (PHI), certain types of financial transactions, and credit card numbers (for PCI-DSS). If you are a SaaS company, you may decide to put your client’s production data in this category too. You often have specific obligations on how you protect this category of data, so it is very important to identify when it is shared outside your organization.
Added bonus: you can re-use these definitions in your first Data Classification policy! (often necessary for a SOC 2 or ISO 27001 audit)
4. Create a Vendor Risk Management Register
Fill-in-the Blanks. Create a very simple vendor risk register for your existing vendors.
Starting with either our free template or a blank spreadsheet, list all your vendors in the first column (thanks, Tina in Accounting!), and then add column headers for:
Service – short description of the service being provided by the vendor. For some large vendors, you may have a separate row for each service they provide, like Microsoft Azure and Microsoft 365.
Owner – person in your company responsible for the vendor relationship and/or the person with the highest-level administrative access. For example, you may have a VP who manages the commercial relationship with your cloud provider and a senior technical lead who manages the root account.
Onboarded – date the commercial relationship with the vendor began (if known).
Data – level of data shared, using the categories defined in Step 3.
Reviewed – date of the last risk review for this vendor (Step 5)
Compliance – to indicate if the vendor has an external compliance report, like a SOC 2 or ISO 27001. Note which ones and when issued. (Step 5)
Controls – a link to a document that describes the internal controls and other guidelines you’ve developed to reduce the risk of this vendor (Step 6)
Critical? – label “yes” if the risk review determines this is a critical vendor (Step 7)
As best you can, fill in the details for the first four attributes. If you have a long list of vendors, this can take some time, so just do what you can for now or enlist someone to help. The most important part for now is identifying the category of data shared with the vendor.
It’s almost guaranteed that there will be gaps, but don’t let that bother you. Your objective is just to gain some experience with this format before evaluating new vendors.
You may decide as you work through this that you need to add an additional attribute or two, or accommodate something special about how your business operates. There are no hard rules here, but still try to keep it as simple as possible.
The last four attributes (Reviewed, Compliance, Controls, Critical) will be filled in later when you do retroactive security reviews on these legacy vendors.
5. Bootstrap your review process.
Develop and practice your review process using your current vendors.
Chances are that your current vendors weren’t evaluated all that carefully for cybersecurity risks when they were first selected. Now’s your chance to make up for lost time!
Prioritizing by data sensitivity, try to research each vendor and see if they have any public information about their security practices. Most companies that invest heavily in their own security view it as a competitive advantage and often are willing to share details. If they have one, see if they can provide you with a copy of their SOC 2 report or ISO 27001 certificate – it’s OK to ask for it! (they may only provide it to active customers and/or require an NDA).
Having a SOC 2 report or ISO 27001 certificate doesn’t necessarily guarantee anything, but if they don’t have one you should definitely start asking some probing questions about their commitment to security.
If you’re still left with unanswered questions, most small and medium sized vendors will be happy to arrange for a talk with their security architects or other qualified personnel. Your mileage may vary once you get up to the AWS and Microsofts of the world though.
You may be thinking that this all sounds like a lot of work, and maybe it would be better to just send the vendor a long standardized security questionnaire you found somewhere?
Probably not! Long questionnaires usually miss the point and end up just being a waste of time for all involved. It would be far better to send a short, well crafted questionnaire asking them to describe the ongoing commitments they’ve made to information security management and governance. This will let you quickly get a good sense of how serious they are about managing their own security, and it’s a great way to frame a live discussion with them.
For some SaaS vendors, they may have configuration options that you can activate to enhance the security of your integration with them. For example, they may offer multi-factor authentication for your employee logins to their service. It’s worth checking if anybody ever turned that on!
Other SaaS integrations require access to your data, like a code vulnerability scanning service accessing your source code repositories. Review this extremely carefully – many vendors get greedy and say they “require” full read/write/delete, where just read access would clearly work just as well.
In the end, you’ll have some information about each vendor’s security practices. Just understand that it’s almost guaranteed to be imperfect, incomplete, and inconclusive … but that’s OK! You now have some information to inform your decisions where before you probably had none . That’s a huge improvement!
But wait … does it really make sense to spend so much time reviewing existing vendors? If their services are already integrated into your company, is anyone going to bother to switch to another vendor if you find anything concerning about their security practices?
6. Go on the Defense
Protect yourself! Put guardrails on how your company uses each vendor’s services.
This is arguably the most important but unfortunately the most overlooked part of vendor risk management!
So far, you’ve evaluated the vendor’s security, and you now have a rough feeling of how inherently risky it may be to use their services. It’s also unlikely anything you say or do will make them change how they operate. So, are you just stuck with it and simply must decide on your recommendation to accept or reject this vendor?
Nope!
You still have a great influence on how risky this relationship will be to your company.
Consider this scenario: you’re helping your teenage son or daughter buy their first car. The best car you can find that they can afford is a junker. Only one headlight works, the tires have low pressure, and the door lock is broken. Sounds like a risky purchase!
Ah, but not so quick … you can lower these risks by helping your teenager understand how to manage them: fix the headlight, inflate the tires and check them regularly, and don’t leave anything valuable in the car. You may still not be comfortable with them driving, but you gotta let them grow up sometime.
Similarly, your job is to now design a set of rules (or “controls”) to follow that will help to reduce (or “mitigate”) a vendor’s inherent risks. This may end up being very vendor-specific, depending on how you use their services and what data you share, but there are a few common things to consider:
Authentication : if your employees will need to log into a vendor’s service portal, what can you do to protect their credentials? Passwords are notoriously difficult to secure, so can you enforce multi-factor authentication, or integrate with your existing authentication systems (“Sign in with Google”, etc.)?
Audit : for self-service arrangements, establish a plan for your company’s administrator to do periodic audits to check for any expired users, fix or enable security configurations, and confirm that only allowed data is present on the platform.
Data : establish very clear rules-of-the-road for your employees that spell out what data is allowed on the platform. For example, you may be comfortable letting employees put Public or Confidential data on a service, but since this vendor’s security practices are slightly questionable, you never want them to put Sensitive or Protected data on it.
Employee offboarding : If you are provisioning employee user accounts on the vendor’s platform, then you should update your employee offboarding process to make sure those accounts are promptly removed and all company data associated with their account is scrubbed or moved elsewhere.
Whatever you come up with, be absolutely sure to document your list of mitigating controls for each vendor. Make sure everyone involved with implementing and enforcing it understands the details, and plan on reviewing it’s effectiveness over time. It may be difficult to put all the details in the vendor spreadsheet, so instead just add a link to your document repository.
Retrofitting these controls across all of your vendors may turn out to be a long term project, so focus first on cleaning up where data may already be exposed. Start with a quick audit of all your services and just see what data and legacy accounts should be cleaned up. You’ll be surprised what you find!
7. Identify Critical Vendors
Some vendors need special attention. Be extra careful with them!
By now, you have an understanding of each vendor’s security practices, you’ve designed your mitigating controls, and you’ve identified the data you’re sharing with them. You can now make a determination if they are a “critical” vendor. This will help you maintain a close eye on the potential troublemakers!
There’s no magic formula for this. At some point, you should create a formalized definition for a “critical vendor”, but it may first take some trial and error to help understand what that means for your company. For now, it’s fine to mostly go with your gut.
Are you sharing Sensitive or Protected data with a vendor, or do they have access to your networks and systems? Then by default they’re probably a critical vendor.
Would you be unable to operate your business if this vendor had a major outage? That also sounds like a critical vendor.
Are their security practices really dicey, but there’s no way to avoid doing business with them? Then you better believe that’s a critical vendor!
Go back to your spreadsheet and mark all of the critical vendors. You’ll be checking in on them periodically once you get this process fully up and running.
8. Share your findings.
Show how potential losses increase when exposing more sensitive data, but decrease with better vendor security and your mitigating controls.
Just as you’re filling in the last critical vendor on your spreadsheet, you get an email from Tina in Accounting – there’s a new vendor to review!
You may need to talk to the requestor to understand some background details about this vendor, but by this point you’re confident you can do a risk review. All of your practice so far with existing vendors to classify data, assess security, and design ways to protect your company is finally paying off. The difference is that you’re not working on your own, just cleaning up the legacy vendor list – you now need to inform a decision before it’s made. What will be the best way to present your research on this new vendor to the business approvers?
Don’t forget – your goal is not to just evaluate a vendor’s security practices and give a thumbs up or thumbs down assessment.
Your goal is to help the organization make better risk-informed decisions, and that’s more than just saying this vendor is a “high” or “low” risk choice. You need to explain what’s at stake, and you also need to help the reader understand how the risk can be managed by implementing the mitigating controls you’ve identified.
And just as with the car example, you may not still be uneasy with the risks you couldn’t address (residual risk), but in the end you need to let your leadership team decide if accepting that risk is outweighed by the value of the service to the business.
Your job then is to present this information in a way that informs their decision but doesn’t try to make it for them. Remember, while you may have the best view on the danger this vendor may pose (and some ways to control it), you may not have a great view on the value this vendor may bring to the company.
When providing a vendor risk assessment, lay out the facts as best you can. You’ll likely need to fill in some gaps and color it a bit using your own professional judgement, so just be clear when you cross that line:
“The vendor provided a SOC 2 report with satisfactory assertion from their auditor. However, there were several noted exceptions in their report. Their written responses to the exceptions included in the report did not seem acceptable to me, so I reached out directly to them to see if they could explain further. While they were able to show how they’ve addressed some of the exceptions, there were still several unresolved and seemingly easily corrected flaws with their employee offboarding process and security awareness training that are troubling to see.”
After explaining what you can about the vendor’s security, lay out the ways you plan to address some of their shortcomings. Some of these mitigating controls may require an investment or ongoing commitment, so make that clear as well. Just as importantly, be sure to mention any vendor shortcomings you were not able to address.
The last component to explain is what company data will be shared with this vendor (and what limits you’re suggesting be placed on it). They ultimately need to make the decision if risking that data to potential loss due to a deficiency in the vendor’s security is worth the benefit.
Finally, summarize with a statement about the potential for losses over time. Try your best to put a dollar value on it; it is guaranteed to be better understood by business leaders. If you can’t take it that far, then try to at least use a rough relative scale:
“For these reasons, I rate this vendor’s security as 5 or 6 out of 10, but if we implement all the suggested mitigating controls the net result would be a score of 8 or possibly 9. This means that it is highly unlikely they will have a security incident that impacts us, but it’s not out of the question. While this may not be secure enough for our Sensitive data, we can limit our data breach exposure to only minor reputational losses if we only allow data classified as Confidential (or lower) data to be uploaded to this service.”
In the end, it’s not perfect, but it’s something the recipient can now use to inform their decisions. And anything is better than nothing!
9. Codify your Vendor Risk Management Program.
Smooth out the bumps. Time to make vendor risk management part of the company culture.
Once you complete a few vendor risk reviews, the value of the program should become readily apparent to senior leadership and other decision makers. You’ll need their voice now to make sure the rest of the organization understands that vendor risk reviews are an important way the business manages risk and that the process needs to be respected and followed. It’s also important that they communicate that this process isn’t just getting in the way and slowing things down – in many situations it can be a business enabler.
How so? Perhaps there’s a vendor that appears at first to be too risky to partner with – imagine a startup with incredible cutting edge services, but their security practices are woefully immature. Well, the vendor review process may be able to pinpoint specific concerns and identify appropriate controls to reduce the risk to your company. If this is done well enough, it may mean that it ends up being possible to do business with them and to take advantage of their innovative offerings, which you use to attract more customers.
Hand in hand with that, the vendor review process should be codified in company policy and procedures so that everyone understands the process and their role in it. Other policies should be updated to also help control vendor risk, like updating your Incident Response plan with details on how to respond to different types of vendor data breaches.
Requesters should also do some of the legwork. For example, they likely already have some relationship with the vendor, so it’s probably easier for them to ask for the SOC 2 or ISO 27001 report instead of you. Partnering with them in the process will increase their awareness of the vendor’s security practices, which should result in a more cooperative discussion on how to address the vendor’s shortcomings.
10. Establish a periodic review process.
Keep your eye on the ball. Vendor security may change over time. Establish a review process to check in on them.
Now that you have a long list of approved vendors, it’s important to keep watch over them to make sure that they’re maintaining their security practices, and to make sure that you’re still following your mitigating controls.
For critical vendors, do a full review once a year as if they were a new vendor. Most SOC 2 reports are issued annually, so be sure to request an updated report from them. Compare it to the previous report – they don’t always improve year over year! And don’t forget to review your controls – are they still adequate for this engagement?
This should be easier than the first time around, but be careful not to treat it as a cursory review. Stay vigilant!
You should also review all non-critical vendors, but it doesn’t need to be quite as frequent. A review every three years or at contract renewal time is a reasonable approach.
Wrapping up
Congratulations! You now have a respectable vendor risk management process that’s likely to pass muster with your SOC 2 or ISO 27001 auditor! Awesome job!
As you can now see, a vendor risk management program doesn’t have to be a burden. If designed properly, it should add value and enable the business. It’s clear that paying more attention to the security of your vendors will make you more secure in turn.
And finally, don’t forget to thank Tina in Accounting – you couldn’t have done this without her!
Want to get great cybersecurity content delivered to your inbox? Click here
