We have dragged the wrong model of vendor assessments along with us for too long. Our evaluations of software and the risks we accept are too static for the modern world of software as a service (SaaS). Still, most organizations have simply adapted their legacy evaluation techniques for on-premise software to apply to SaaS providers. This not only creates massive bottlenecks, but also causes organizations to inadvertently accept far too much risk. Modern work requires a new model.

The simplicity of traditional assessments

Think about buying something that’s going to stick around with you for a while, like a car. It makes sense to go read reviews, see what Consumer Reports has to say, read about the crash test ratings. Then you might go drive it for a bit, brave the car dealership, and, when you’re ready, write a check. The car you’re buying is not going to change—the car you buy is going to be the same as the car you eventually sell, with the same parts and features. This model of evaluation was (rightly) adopted for on-premise software. You could evaluate the software, its composition, the company selling it, and come to a reasonable conclusion about what value you would receive compared to any risk related to its composition and runtime requirements.

‍

But…we no longer buy software

Our modern procurement process is not for software, but rather services. The benefits are immense: we get to remove any burden of running the software, and we get a service that is updated many times a year on our behalf. However, the services we assess no longer fit with the point-in-time assessment model we’ve dragged along with us from the car dealership. Two major issues emerge with a point in time assessment: first, we incur too much effort on the front end. The goal of integrating many of these services is an increase in productivity and speed of evolution. However, burdening the integration of these services with a weeks- or months-long assessment period will create a perverse incentive for working around the assessment process to avoid impeding productivity. The second issue is that a point-in-time assessment does not extend to the subsequent iterations of the service as it is updated during use—this approach fails to account for the evolutionary nature of the SaaS model. 

‍

A model for a modern vendor security assessment

To effectively adapt to this new reality, we need two major aspects to change: we need to shorten the timeline of initial assessment, and we need to increase iterative assessments over time. Within both of these objectives, we must evaluate the cost of incremental effort and the potential for inadvertent risk. 

‍

1. Establish a use-based policy for the initial assessment

The modern work environment leverages a vast array of services, each with a substantially different risk profile. Based on the nature of these services, organizations should establish an assessment policy that corresponds to the inherent risk. For example, a service used for employee data (such as Zenefits) will have distinct requirements from a service used in your production infrastructure (such as Teleport), which will have distinct requirements from a collaboration service (such as Slack). 

‍

The foundation of these policies should be easily established objective requirements, such as data locality, legal jurisdiction, and existing certifications. This simple foundation allows for efficient and effective disqualification or flagging of potential issues before a more involved assessment. Ideally, the initial assessment would be solely based on these objective requirements, and would align the legal obligations of your organization with the objectively measured qualifications of the potential provider. Additional considerations for evaluation are listed below.

‍

• Data Locality: What region is the data hosted by the service stored? How does this align with your legal obligations for the data hosted by the service?
• Legal Jurisdiction: Where is the company headquartered and what legal jurisdiction is specified in the terms of service? How does this align with your organization’s legal expertise and ability to represent themselves in that jurisdiction?
• Certifications & Attestations: What existing security certifications does the provider have? How do these align with your obligations for the data hosted by the service?
• Security Team: Does the provider have an established security contact? Is the team accessible for requests and clarifications?
• Breach History: Is there a public breach history for the provider? Is there an official response from the provider for the security incident?
• Bug Bounty Program: Has the provider established a bug bounty program?

‍

Here are sample sets of requirements for services types:

‍

Collaboration Service Requirements

Data Locality: USA

Legal Jurisdiction: USA

Certifications: GDPR, SOC2 Type II

Security Team: Present

Breach History: N/A

Bug Bounty: N/A

‍

IT & Infrastructure Requirements

Data Locality: USA

Legal Jurisdiction: USA

Certifications: GDPR, SOC2 Type II, ISO 27001

Security Team: Present

Breach History: Require Official Response

Bug Bounty: Present

‍

By making these initial assessments simple and objective, there is the potential for automation, simplification, and acceleration of the adoption process.

‍

2. Automate ongoing assessments

The next challenge is the iterative nature of the service being provided. Ultimately, as a service is updated, the underlying qualification of the service may evolve. Many organizations fall into the trap of a time-based reassessment. While this approach has the benefit of a predictable cycle and workload, it creates undue exposure for services that iterate faster than the period used for reassessment. 

‍

The ideal trigger for reassessment is an automated one. This could be the addition of another data processor to a SOC2 report, or a shift in hosting infrastructure, or an update to a privacy policy or terms of service. The challenge, of course, is finding opportunities to automate reassessments based on these signals. For updates to privacy policies or terms of service, you can easily use a service such as Distill.io to monitor for changes to hosted pages. This tool can also be used to identify updates to the security pages listing certifications and attestations. When requesting the initial SOC2 report, you can also establish a dedicated alias to receive any updates to the data processors used by the provider. Configuring these triggers will allow you to automate reassessment to ensure that as any given service evolves, it doesn’t evolve past your comfort zone.

‍

How Nudge Security can help

Nudge Security recognizes that vendor security assessments are a challenge for many organizations. The most pressing and consistent problem is identifying new providers, as so many employees adopt new SaaS services without waiting for a lengthy vendor assessment to be completed. Nudge Security continuously monitors for new cloud and SaaS accounts, so that when the first user in your organization adopts a new provider, you receive a notification to kick off a vendor security assessment. Additionally, all of the factors listed above (Data Locality, Legal Jurisdiction, Certifications, etc.,) are available for review in both the product interface and within the notification engine, which means that notifications can be configured specifically for vendors that do not meet your established requirements.

‍

Nudge Security also identifies the services and data processors that your SaaS providers use to run their businesses. This provides a near-real-time view of your supply chain risk without having to wait on your service providers’ annual SOC 2 report renewal.