Vendor Risk Management for Startups
A guide to starting up your own Vendor Risk Management program
Background
If you are a company like Funding Societies | Modalku Group, then you are most likely engaging with various vendors / service providers to procure services from them. These engagements may require vendors to have access to your information technology (IT) systems and other information assets (that may include personal and financial details of your customers, employees, contractors, and/or other stakeholders). In view thereof, proper risk management processes and procedures must be in place to protect your business-critical information.
A quick search on the Internet for Vendor Risk Management (VRM) pulls up several results on the topic. However, none of them talk about how a VRM programme can be developed and implemented by startups with ease. This is the motivation for me to blog about this topic.
As per Gartner:
VRM is the process of ensuring that the use of service providers and IT suppliers does not create an unacceptable potential for business disruption or a negative impact on business performance. The VRM programme supports enterprises that must assess, monitor and manage their risk exposure from third-party suppliers that provide IT products and services, or that have access to enterprise information.
In our company, we have developed and put in place a VRM process that involves multiple stakeholders from the Business, Security, Compliance, Legal, and Finance teams across all of the countries that we operate in. Even if you may not have all these functions in your company, I hope that you may find this blog useful to kickstart your own customised VRM programme!
Our Approach
At the outset, we wanted to come up with a process that begins at the point that the business has a request to engage a new vendor (i.e., after the vendor is shortlisted) / renew an existing vendor; and ends with either Finance releasing the payment to the vendor, or the vendor being rejected from engagement with our company by any of the stakeholders of the process.
Inputs
The process will be triggered by the business raising a vendor assessment request on an Atlassian Jira board that we have set up to track the entire VRM flow.
Outputs
The outcome of the process could be either one of the vendor is:
- (Re-)Engaged by the company after passing the respective risk assessments by the Business, Security, and Compliance; followed by Legal checks on the agreement, and release of payment by Finance, or
- Rejected from being engaged by the company by any of the stakeholders of the process.
Vendor Assessment Request
A vendor assessment request form was created to collect the following information, among other things:
1. Vendor company name and contact details
2. Description of the engagement with the vendor
3. Importance of the vendor to the business:
- Mission Critical
- Very Important
- Moderately Important
- Slightly Important
- Nice to Have
4. Business and operational considerations in selecting the vendor
5. Internal systems or applications the vendor will access or integrate with
6. Type(s) of data the vendor will access — this could be broken down based on the data classification approach taken in your company.
As an example, if you classify data as Confidential / Internal / Public, the vendor assessment request form can list the following type(s) of data:
Confidential data:
- Customers’ Personally Identifiable Information (PII), such as NRIC, license number, bank account information, phone number, etc.
- Application source code, technical architecture documents, and product road maps
- Credentials (username and password) to access various systems
- Non-public security related bug information
- Financial data, like earnings before it is made public; or merger and acquisition details
- Legal agreements and its terms
- Employee- or employment-related information
- Trade secrets, such as business methods
- Business model
- Information pertaining to patent securement or drafting
- Any other data that is of high business impact in nature and of significant value to the company
Internal data:
- Internal wiki / knowledge base
- Internal company announcements
- Any other data that is of medium business impact in nature and of significant value to the company
Public data:
- Company website
- Launched marketing campaigns
- Public announcements
- Any other data that is public in nature, i.e., it is already available or can be disclosed in the public domain
Categorisation of Vendors
In order to optimise our VRM programme, we will not review every single vendor. Instead, we will risk assess any vendors that are providing products or services that may interface with customer or sensitive information, in addition to any vendors with whom we have a current or recurring formal contract or agreement.
Vendors will be categorised as Category 1 / Category 2 / Category 3 based on the business’ response to the vendor assessment request using the below table as a guideline:
For example:
- A vendor who is moderately important to the business but has access to confidential data will be categorised as Category 1.
- Similarly, a vendor who has access to only public data, but their availability is rated as medium will be categorised as Category 2.
Depending on how stringent (or not!) your VRM process needs to be, you could also categorise vendors in a different manner, such as the below:
Vendor Security Questionnaires
While a number of questionnaires for vendor risk assessments are available out there, we decided to use the free VSA-Full and VSA-Core questionnaires from Vendor Security Alliance (VSA) as our base questionnaires because they were created with the vendor in mind. The VSA questionnaire’s (VSAQ) focus is on eliminating irrelevant questions and unnecessary friction during the security review process, making for a much more streamlined questionnaire process that both the vendor and we will appreciate (and will be able to respond to in a faster manner). Since we operate in the regulated financial services space and in multiple countries, we have some custom questions in addition to the questions in the VSAQ to ask of our vendors and hence, we have customised the VSAQs to suit the needs of the different countries.
To keep things simple, you could look at using the VSA-Full questionnaire (more comprehensive) for Category 1 vendors and the VSA-Core questionnaire for Category 2 vendors (less comprehensive).
Having said that, if a vendor has already filled out another questionnaire, such as the Cloud Security Alliance — Consensus Assessments Initiative Questionnaire (CAIQ) or the Shared Assessments Group — Standardised Information Gathering Questionnaire (SIG / SIG-Lite), and would like to share that instead with us, we also accept the same and only ask the vendor any additional questions for which we need their responses.
Process Flow
Here is the process that we follow for vendor risk assessments among the different stakeholders involved:
As the process flow is pretty self-explanatory, I will not explain each step of it.
A couple of ways in which you could ensure that Finance does not release payment to a vendor, who has not been assessed and cleared appropriately, are:
- Getting the vendor assessment team added as an approver in the Finance new vendor on-boarding and purchase order processes.
- Building some automation that would update the Finance purchase order system when a vendor assessment has been completed and approved.
Another thing I would like to emphasise is that depending on how departments / teams are set up in your company, you could drop or add additional steps as required in the process.
It is also important to set up roles and responsibilities for stakeholders so that there is no ambiguity about who is responsible for what aspect of the VRM process:
It would also be useful to set up Service Level Agreements (SLAs) for each stakeholder involved in the process so that business teams know how long they would have to wait for each step of the process to get completed.
Summary
Here is a round-up of all that is involved in making the VRM programme possible:
- Identity the stakeholders to be involved in the process
- Define the roles and responsibilities for the stakeholders
- Identify the triggers and intended outcomes of the process
- Identify the information and the means to gather the same via the vendor assessment request form from the business
- Define how vendors will be categorised based on the information gathered via the vendor assessment request form
- Identify the vendor security questionnaire(s) to be used for carrying out the assessments
- Define the process together with all the stakeholders
- Agree on SLAs for each step of the process with the stakeholders
- Communicate the process to everyone in your company
Tada! You’re ready to kick off your own VRM programme.
Thank you for reading this post! I hope that this will help you in setting up your Vendor Risk Management programme with ease. Do let me know your thoughts / suggestions in the Responses section below.
Thanks to Stuart Hammar.
