What it is, why you need it, and how to use it.
You might be thinking something like:
“Meh!We don’t need another policy that nobody will read! Policies are a waste oftime, especially a Vendor Risk Management Policy!”
I get it. People aren’t thrilled by policies. They’re not exciting.They’re not fun either. For some, policies can even be painful.
Policies get a bad rap. Not because they’re evil or anything, but because people rarely use them well. The fact is, information security policies play a very important role in supporting all information security efforts, and a vendor risk management policy plays a very important role in supporting our vendor risk management efforts.
I don’t like wasting people’s time, so I’ll get right to the point. Most policy problems are founded in the confusion about what a policy is, why they need one, and how they should be used. So, let’s address this as simply as possible. After all, complexity is the enemy of good information security (remember this always).
NOTE: Insome organizations, vendor risk management and third-party information securityrisk management have slightly different meanings. Third-party informationsecurity risk management is part of a greater vendor risk management effort.For the purposes of this article, we’re using vendor risk management andthird-party information security risk management synonymously.
What a Vendor Risk Management Policy is
The “what” for any policy are the rules. Think of this interms of a game. A policy defines the rules for the game. A vendor riskmanagement policy defines the rules for the vendor risk management game.Simple.
If you’ve never played the vendor risk management gamebefore, this could be a difficult policy for you to define. If this is you, asksomeone you trust for help. Here are two options for you right now:
- You can download our template. Change the rules to fit the game that you’re willing to play and make it yours.
- Contact SecurityStudio - The experts at SecurityStudio will make sure you get all the answers you need.
There are some typical structural things that should foundin every policy, including this one. Policies should contain a purposestatement, note the audience for the policy, the policy status (draft,approved, adopted, etc.), version, date, the policy itself (the rules),references (to standards and/or other documentation), enforcement intentions,and version history.
Your game, your policy. Don’t expect someone else’s policyto fit as-is, and don’t include rules that you don’t intend to play by.
Why you need a Vendor Risk Management Policy
If the “what” for policy are the rules, the “why” for policyis communication. Policies are used to communicate the rules to others. You don’tneed a policy if you don’t have anyone to communicate the rules to. Good news,right?
Before you rejoice, it’s very unlikely that you have no oneelse to communicate the rules to. There’s almost certainly someone else whoneeds (or wants) to know the rules.
Think about who needs to know the rules for your vendor riskmanagement game. The list could include:
- Anyone else within your organization thatparticipates in vendor risk management activities.
- Anyone who’s interested in your organization’svendor risk management activities (examiners, regulators, partners, etc.)
- Anyone who’s ultimately responsible for yourorganization’s vendor risk management activities, including executive managementand the board of directors (if one exists).
The more people who need to know about your rules, the moreimportant the policy becomes. In a small organization where there is a singleperson who does all the vendor risk management activities, there’s lessimportance. Not “no” importance, just less importance.
How to use a Vendor Risk Management Policy
Once you’ve written a policy, it’s time to figure out how touse it. Every policy, including this one, must be approved, communicated,adopted, and adjusted (or revised). This is a policy lifecycle that is wellunderstood by most.
- Draft – The policy is drafted (as v1 in new policies, as incremented version in subsequent cycles).
- Approve – The policy must be approved by someone with authority (executive management, BoD, etc.).
- Communicate – The policy must be communicated to all personnel who are affected by it.
- Adopt – Gap analysis (or audit) coupled with plans and projects to ensure compliance.
- Review/Revise – Periodic (and regular) review of policy, suggested edits move forward.
Policies are reference documents and should be written thisway. Let’s go back to our game comparison.
When you sit down with friends to play a new board game, howmany people read the rules? Just one, and this is the de-facto person whooversees the game. How many people should read your policies (rules)? Just theperson (or group) who oversees the game. As the game is played, the rules arereferenced whenever a question comes up. Same goes for policies.
That’s it. Simple. Define the rules for vendor riskmanagement, communicate the rules, and manage the rules. Vendor risk managementpolicy in a nutshell.
Having a policy in place is great, but also having a workflow that evaluates all third-party vendors and brings your weakest links to the surface is even better. Schedule a demo with us today to get your easy-to-use vendor risk management program.
Estimate your score or book free demo today
Estimator | Get a Demo
