Cloud vendors are a critical part of any organization’s operational ecosystem today. Assessing vendor risk is a necessary part of your security team’s due diligence before you agree to onboard a vendor. That assessment, though, can take on so many different forms - questionnaires, scorecards, various vendor management systems, Google searches, reviewing vendor security artifacts, and even incorporating security terms into legal obligations within a contract (like Dropbox).

Often, before a formal vendor review kicks off, teams are asked to figure out a baseline risk assessment of said vendor to figure out what follow-up review of the vendor’s security posture needs to be done. This can be a frustrating process and includes hours of culling through public security information found on the vendors’ marketing websites, third-party security review sites, and/or Google search results.

At Conveyor, we’re making the trust-building process between customers and vendors run as smoothly and efficiently as possible; so today, we’re tackling the topic of how best to do an initial evaluation of your vendor or to put it another way, the “who-the-heck-is-this-vendor-and-how-can-I-figure-out-a-quick-overview-of-their-security-posture” part of the vendor review process (i.e. typically step one). 

To do this, we’ve put together a list of the top trust indicators you should evaluate when starting a vendor security review. 

So, what are trust indicators? 

Trust indicators are a reflection of how mature a companies’ security practices are, and how much they prioritize security as an organization. Getting a good understanding of these indicators will give you a solid basis for assessing risk, and help you quickly understand how their security posture matches up with your business requirements. 

Each of the 18 trust indicators listed below should be accessible via public information. The weight you put behind each of these will depend on what’s most important to your business. To see an example of how we scored some of the top B2B SaaS vendors on these criteria, you can check out our new Vendor Security Reports on popular SaaS vendors. 


Key Trust Indicators & How to Assess Them

Trust Indicator Iffy or Unknown Baseline Good Great
Do they have a current SOC 2 Type 2 Report? There’s no reference to SOC 2 or other comparable frameworks on their website. For more mature organizations operating in regulated industries, lack of any documentation, reference, or justification for their security decisions could land them here. They have a SOC 2 Report. For companies formed in the past few years, commitment to move towards SOC 2 compliance is reasonable.

Companies operating with lower sensitivity data may also justify why they do not need to align with SOC 2 or similar frameworks. A SOC 2 Type 1 is an acceptable approach, but it should ultimately progress to a Type 2.
They have a SOC 2 Type 2 report that covers a recent period greater than 3 months. Good SOC 2 Type 2 reports often include the "triple crown" of SOC 2: Security, Confidentiality, and Availability. They have a SOC 2 Type 2 report that covers a recent period greater than 12 months. They could also have additional assurance reports such as ISO 27001, HITRUST, FedRAMP, and/or PCI DSS.
Do they offer customers and prospects self-serve access to up-to-date documentation and questionnaire answers? There’s no security contact made available or instructions on how to access security documentation. They provide a security point of contact or instructions on how to gain limited access to documentation. They provide continuous access to a self-service trust portal that includes up-to-date documentation. They provide continuous access to a searchable, self-service trust portal that includes up-to-date documentation and questionnaire answers.
Do they have a public security policy? There’s none available, or it’s entirely boilerplate. They have a security policy available that covers basic topics. Some boilerplate is acceptable here. They have a company specific security policy that goes into detail on specific practices, limitations, and assumptions. They have all aspects of "Good" plus they provide cohesive links out to supplementary policies and documentation.
Do they have a public privacy policy? There’s none available, or it’s entirely boilerplate. They have a privacy policy available that covers basic topics. Some boilerplate is acceptable here. They have a company specific privacy policy that goes into detail on specific processing, practices, limitations, and assumptions. They have all aspects of "Good" plus they provide cohesive links out to supplementary policies and documentation.
Does their product support SSO/MFA? It does not support MFA, or the supported MFA is weak. It supports strong MFA. It supports SAML 2.0, but it may cost extra. It supports SAML 2.0 and/or OAuth. It supports SAML 2.0 and SCIM.
How do they encrypt data in transit? At rest? They use weak or outdated protocols, including serving mixed content and data over http. They use TLS 1.2 with exceptions to allow some legacy clients to connect. They use TLS 1.2, and provide data about standard encryption practices, like AES-256 at rest. They provide a system diagram that goes into detail on each data store/transfer and supported encryption.
Do they disclose their product’s hosting location? They provide generic data or don’t disclose their hosting location. They use a SOC 2 and/or ISO 27001 certified data center. They use standard cloud hosting like AWS, GCP, or Azure.

If private cloud, they provide substantial documentation surrounding the shared responsibility model and security considerations.
They have all aspects of “Good” plus provide options for hosting within different judicial boundaries and cloud providers.
Do they have a public subprocessor list?

Can you opt-in to receive updates?
They don’t have a list, or don’t reference its existence. They have a basic list of subprocessors. They have a subprocessor list that was recently updated and reflects the nature of subprocessing and legal means for transfer. They have all aspects of "Good" plus the ability to subscribe to updates.
Will the vendor enter into a DPA? They don’t enter into DPAs. They discuss GDPR/privacy obligations on website They enter into a DPA, but potentially gate it behind a subscription level. They don’t share a copy of the DPA publicly. They enter into a DPA and have shared a copy publicly. They potentially include the DPA wrapped into all commercial terms.
Do they have a live status page for the product with reassuring historical reliability data? They don’t have a status page. They have a basic status page. They have a status page that includes historical data and the ability to subscribe to updates. They have all aspects of “Good” plus a contractual SLA.
Do they publish a system diagram/definition? They have a basic text definition. They have a basic visual. They have a detailed visual with integrations and data flow. They have detailed visual(s) with integration, data flow, and network information.
Do they have a list of available integrations and good integration documentation? They don’t have one, or it’s made up of marketing smoke/mirrors. They have a basic summary. They have an integration overview with supporting documentation. They have detailed documentation including API documentation. There’s "signs of life" that they update regularly.
Do they have a public designated security contact or contact form? They have no way to contact security. They have a generic security contact, potentially commingled with a general support contact. They have a dedicated security contact. They have a detailed security contact form that collects specifics about security inquiries.
Do they complete regular penetration testing? They do not complete penetration tests. They complete periodic penetration testing, but don’t share specifics or summaries. They complete annual penetration testing and disclose summary data including scope. They complete annual penetration testing and discloses summary data including scope. They provide additional assurances such as remediation and mitigation status.
Do they have a bug bounty or responsible disclosure program? They have no page related to bug bounties or responsible disclosure. They have a weak page related to bug bounties or responsible disclosure. They have a strong page related to bug bounties or responsible disclosure. They use a dedicated bug bounty program like BugCrowd.
Do they have a dedicated security team? They don’t have a dedicated team. Security is a shared responsibility with another team, often engineering. They have a dedicated security team. They have multiple dedicated security teams (ex. Corporate security and Application security)


More on Trust Indicators

Joe V. and Tania K. are on the Trust and Security Team at Conveyor, and with their powers combined, came up with these trust indicators. 

Joe has been a part of hundreds of implementations of GRC programs. Through those experiences, he has learned about a variety of techniques to assess vendor risk and maturity. Tania has supported numerous clients on privacy and vendor management initiatives, including many of the Fortune 500. Collectively, the two of them have over 15 years of experience building trust & security programs internally and in a consulting capacity. 

Our Trust & Security Team has also spent hours scouring the internet for the security postures of several popular SaaS vendors so you can get a head start on your next security review (aka - you don’t have to pull these trust indicators yourself!). Check out our SaaS Vendor Security Reports here

Go forth and build trust

Using these trust indicators can help your team quickly create a baseline for assessment across vendors and get a high-level picture of how trustworthy a vendor might be based on the transparency of information they provide upfront. These are just a starting point on assessing vendor risk, but hopefully can help you simplify evaluation from the beginning.