Best practices: Vendor Risk Management

Vendor risk management is one of those areas you can go right down the rabbit hole and lose sight of why you’re doing it in the first place!

People often miss that the purpose of it is two part;

1. Manage the risks to your business from using third party services; and
2. Demonstrate how you manage the risks to your customers from your third party services.

That latter point is important. Your third parties are your customers fourth parties. As you sit in between, it keeps your customers at arms length from their own oversight and risk management practices over those vendors that they’re exposed to by extension.

Vendor risk management is one of the most intuitive control practices, and therefore often the least formally defined and operated. You choose reputable, secure, industry-leading third parties over alternatives because they are lower risk. In some cases you can even piggy back off their security and qualifications to satisfy your customers about the security of your own environment.

Every vendor risk management function should have a set of core components.

Vendor Risk Management Framework

The Vendor Risk Management Framework May be a separate document, incorporated into your vendor register, or your broader risk management framework (see Best Practices: Risk Management). Whatever form it takes it should cover the same components as any policy (see Best Practices: Policies); roles, responsibilities, and the key requirements of the function to meet your objectives.

Vendor Register

A vendor register tracks your material third party providers, often limited to those with information security implications and excluding the likes of Uber Eats or your logo design consultant. This register houses the rest of your vendor risk management function.

Vendor classification

The most pragmatic classification approach is for each vendor to determine;

• Sensitivity - security importance of data collected, processed or stored;
• Criticality - the business dependence on their systems or services;
• Risk rating - level of risk of each vendor;

The risk rating may consider a myriad of different factors like their reputation, past performance and uptime, security qualifications like SOC 2 and ISO 27001, and anything else that’s relevant. The combination of these three classification ratings determines your exposure. 

For example:

1. If AWS is High sensitivity holding all your customers data, High criticality based on your software being reliant on the AWS platform, but Low vendor risk due to their industry leading uptime and security practices, then it would be reasonable to conclude the risks are managed appropriately.
2. By contrast if you used an offshore development agency that had access to your production data, was the core team for managing your software development process, and had limited verification of their security and reliability, that may result in a high sensitivity, medium criticality and a high vendor risk. In that case you should consider a risk mitigation strategy or treatment plan.

Risk mitigation strategies

Risk mitigation strategies flow logically from a classification approach to identify which vendor risks are tolerable and which may need further actions. In the case of the offshore development agency you may determine that removing their production access reduces the sensitivity risk, and engaging a second agency or hiring local resources can provide a backup or continuity plan to reduce the criticality or business dependence. On that basis the risk may be tolerable, or you may go a step further to mitigate the vendor risk as well. That can include your own audits or questionnaires to assess their control practices, monitoring through SLA reporting, or as some of our customers have, sending over your own local resource to manage the offshore team directly.

Monitoring and managing the vendors

Hopefully by this point you’re realising a lot of this is quite logical and probably already things you’re doing in a less formal way. Going back to the purposes of vendor risk management; it’s both to effectively manage the risk but also be able to demonstrate how you do that to your customers (and auditors if you’re pursuing SOC 1, SOC 2, ISO 27001 or other standards and certifications). To round out the list, there's a few basic management activities for your third-party services.

• Assign a responsible owner to each vendor
• Track your vendor contracts or terms of service
• Review your vendor register at least annually
• Review your vendors third party reports and certifications like SOC 1, SOC 2, and ISO 27001

All of these above points are like the hygiene factors that keep your vendor risk management function working over time and being able to demonstrate it. Your customers want to review your SOC 2 or ISO 27001, and naturally expect you to review them from your own vendors (on their behalf if not for your own benefit). The ongoing ownership, tracking terms of service and an annual review process recognise that things change over time and it’s important to have those defined in order to identify and handle changes as needed.

Takeaway 

You can take it 10 steps further but the above has all the basic components of effective vendor risk management. Keep in mind that like broader risk management, it’s about supporting your objectives and should always be designed in a fit-for-purpose way in your business context. If you’re in the healthcare industry and privacy is a major focus and objective, you should expand your register to track PII and privacy risks and compliance associated with each vendor, for example.

The SOC 2 Perspective

Vendor Management is naturally relevant across all areas of the SOC 2 criteria; where you rely on third parties for your control practices. The criteria related to how you manage those third-parties features in the Risk Assessment, and the Risk Mitigation sections.

Common Criteria 3.2: The entity identifies risks to the achievement of its objectives across the entity and analyses risks as a basis for determining how the risks should be managed.

Common Criteria CC9.2: The entity assesses and manages risks associated with vendors and business partners.

AssuranceLab's Best Practices Series

AssuranceLab's best practices series, is about highlighting the "real operational benefits" that come from effective control practices. At best, they support your company culture, provide structure and clarity, and enable scalable growth. At worst, they tick the box of what your customers expect, reduce the reactive "firefighting" and time-wasting, and help you demonstrate your compliance with leading standards like SOC 1, SOC 2 and ISO 27001.