Establishing contractual obligations as part of a robust vendor risk management program requires setting key performance indicators and continuous monitoring.
Modern business models increasingly rely on interconnected vendor relationships to streamline operations. Companies migrating to the cloud add new vendor risks arising from Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS) vendors. Although many organizations set control requirements as part of their service level agreements (SLAs), a robust vendor risk management (VRM) program requires continuous monitoring to ensure that vendors meet the outlined contractual obligations.
The alphabet soup of cloud vendors often leaves organizations feeling overwhelmed. In fact, many companies may not realize how many vendors they use or what type of risk the vendor poses.
SaaS vendors represent the majority of vendors. These products offer web-based services that streamline end-user experiences. Examples of SaaS providers include Salesforce, Office 365, Google Business Suite, Box, and SAP.
IaaS services include public, private, and hybrid cloud environments where the company deploys its own operating system within the cloud. For example, a company may use Google Compute Engine or Amazon Web Services (AWS) EC2 for cloud-based servers and data storage. The IaaS model enables the company to reduce hardware costs while gaining greater flexibility.
A PaaS environment recreates the company’s entire infrastructure within the cloud. PaaS services include the operating systems and applications necessary for migrating to the cloud. For example, AWS Elastic Beanstalk, Microsoft Azure, Force.com, and Heroku are all PaaS ecosystems since they natively incorporate the software necessary to streamline business operations.
Evaluating vendor risk works the same way as evaluating your own risk, since many of your organization’s risks arise from vendor integrations. Evaluating vendor risk is the first step to creating appropriate contractual obligations for the SLA.
When identifying your vendors, you want to think on a broad scale. For example, vendors may include:
After identifying your vendors, you need to look at the types of information they access. This information includes Personally Identifiable Information (PII) such as:
Once you’ve identified all your vendors and the information assets they access, you can start to identify the risks. For example, a vendor who accesses a database that attaches names to emails poses a greater risk than a vendor who accesses a database that only has email addresses with no name attached to them.
As part of identifying vendor risk, you need to review:
Business critical vendors and vendors who access sensitive data are a higher risk than other vendors and require more monitoring.
Once you’ve identified and assessed risks, you need to analyze them. The analysis is separate from the assessment. While all of these steps overlap, they remain distinct. A risk analysis requires you to determine the likelihood of a vendor data breach, the potential impact to your organization if the vendor experiences a data breach, and the cost to your business if a vendor is breached.
Analyzing the risk enables you to determine whether you want to accept, transfer, refuse, or mitigate the risks associated with a vendor. For example, a business critical vendor such as a PaaS provider may be a high risk, but to migrate to the cloud, you need this service. Therefore, although the vendor may be a high risk, you are willing to accept the risk. With that said, your vendor risk management program needs to incorporate the necessary oversight for managing that accepted risk.
You can control your cybersecurity posture. However, companies struggle with vendor risk management because they cannot control their vendors’ activities. In some cases, the contractual obligations detailed in the SLA and monitoring vendor compliance with the SLA act as the primary way the organization manages vendor risk.
When working with vendors, you need to incorporate agreed-upon controls as part of your SLA. Since the SLA is the contract that governs the relationship, you need to ensure that the vendor meets your security risk tolerance. Larger vendors, such as IaaS/PaaS providers, will supply you with their standardized SLA. As part of your due diligence, you need to ensure that their risk tolerance aligns with yours. Contracting with smaller SaaS providers, however, may mean that you have to provide them your own SLA.
Some examples of controls to include in the contract include:
If your company has controls that govern its cybersecurity, incorporating these are requirements for vendors enables you to align your cybersecurity risk tolerance with your vendor risk management program.
Enforcing vendor contractual obligations can be tricky. You cannot control a vendor’s IT department, but you also need to protect your business and customers.
In order to prove governance over your vendor risk management program, you need key performance indicators (KPIs) that establish objective metrics. Some examples of KPIs are:
For example, the SLA may require the vendor to install patches for commonly known vulnerabilities within 30 days, but the vendor patches every 60 days. This would be a breach of contract. Within the contract, you should establish clear KPIs for cybersecurity performance.
Additionally, the contract should also establish enforcement strategies. A contract is only useful if it incorporates a way for you to enforce your cybersecurity requirements. To enforce your contract, you can either reward the vendor for protecting information or punish the vendor for cybersecurity weaknesses.
Rewards for continuously strong cybersecurity can either be bonus payments or promising to extend the contract. Punishments for cybersecurity weaknesses can either be fines or contract termination.
In some cases, you may want to incorporate both strategies. Punishment language may set an argumentative tone which can lead to a strained business relationship. However, not all vendors are motivated by rewards. Therefore, creating contractual language that blends the styles may be more effective.
After establishing your KPIs, you need to find a way to monitor your ecosystem to ensure compliance with the SLA. Many organizations struggle when trying to monitor their vendors since they lack visibility into how the vendor manages its cybersecurity responsibilities.
Traditional vendor audits, using once-a-year questionnaires, do not meet current cybersecurity needs. While many regulations still suggest an annual review, cybercriminals never stop evolving their threat methodologies. Thus, you need to continuously monitor your environment to ensure that your vendors continuously update their controls accordingly. Your vendors should be able to provide you with documentation proving that they continuously monitor, remediate, and document their cybersecurity strategies.
At Zeguro, we understand that protecting your company against a cyber breach can be overwhelming and expensive. This is why we created a holistic approach to help all organizations strengthen their cybersecurity programs. Starting with a security-first approach to cybersecurity, we help you identify risks, create policies, and monitor control effectiveness. If you are a vendor who needs to meet contractual obligations, our platform can enable you to prove your cybersecurity posture. However, we go further than other companies. We also provide the documentation necessary to meet increasingly strict industry standards and regulatory compliance requirements. As part of our Cybersecurity-as-a-Service (CSaaS), we also direct you towards an end-to-end cyber insurance policy that fits your needs. To get early access to our end-to-end cyber safety platform and find out first-hand what CSaaS is all about, sign up for early access here.