A great deal can be gleaned from asking some basic questions about the vendor business. Is it well capitalized and what are its revenues in the last three years? Take a look at the cap table and ask how it is funded. Private equity-backed firms are quite likely to be acquired within a five-year horizon, which can disturb relationships with customers. Does it have a strong management team that is there for the long haul? How many employees are there, and across which service areas and departments? Do they have a qualified lawyer working on their contracts, SLAs, T&Cs?
All of these answers will help to establish a picture of whether the vendor is a fit for your requirements, budget and risk appetite.
Industry analysts can be a good starting point to devise a list of vendors to approach, but you generally need to dig deeper and check that it is the right fit for an individual business.
Customer references can be extremely valuable, especially if it is a peer of your choice that you can relate to. Pairing like with like will validate if the reference is equivalent in scale, especially for an enterprise customer.
Internal process
There is huge value in building an internal process for evaluating vendors that combines interaction from colleagues in Finance, Tech, Security and Legal. They should all have some input to this, and how any vendor gets evaluated.
It is also insightful to hear the representative teams at a vendor educating others on why their service is ideal and compliant in a way that is intelligible to any function at the prospective customer.
Beware of using a one-dimensional checklist as this can create too narrow a view that does not encourage the assessor(s) to really think about what they need, and why that vendor has the best solution. A checklist approach is unlikely to fit all vendors. Be more dynamic and holistic. Think hard about finance, security, resilience, reputation and subject matter expertise.
Assessments of a vendor can be independently verified to some extent. As an example, some vendors offer a SOC2 Audit report but these can vary in substance and value.
SOC2s are designed to provide assurance to management and user entities around the suitability and effectiveness of the vendor’s controls for security, availability, processing integrity, confidentiality and/or privacy.
A checklist approach is unlikely to fit all vendors. Be more dynamic and holistic. Think hard about finance, security, resilience, reputation and subject matter expertise.
But a vendor can cut corners here and veil the truth. It makes sense to ask if the SOC2 also covers services, as well as data centers. How many controls does it cover? Most vendors will point their SOC2 at perhaps 60 controls, but the most thorough will cover up to 160 controls. Was the audit on the actual data center where your data will be kept? Or on a sample? It is worth considering who completed the SOC2, and if this auditor is independent or conflicted.
KYV should not be just the once before the knot gets tied – it needs to be a continuous part of the relationship with a vendor. Evaluate to what extent a vendor has its own program that will ensure up-to-date information is pushed to the customer on security, audits, performance and development.
It is key to establish if customer data will be involved and could potentially be exposed. Due diligence takes on a whole new complexion if your core assets are involved, and your reputation is at stake for any failures.
Privacy is such a big issue now, especially where personal data is involved. Subprocessing is an additional risk that needs to be considered. Ask to see a data processing addendum and evidence of controls, as well as proof that the vendor under- stands the regulatory obligations around subprocessing.
It pays to be specific when interrogating the vendor’s approach to DR. Vendors can state they will not lose your data, but pointed questions about their ability for failover can be revealing. Multiple data center backup is what should be verified, and vendors should understand that you expect systems access, ideally in minutes and not hours or days, if there is an outage.
A golden rule in the regulated financial world is that you can not contract out your compliance and legal responsibility. Obligations cannot be outsourced, period.
Where is the data?
Subcontractors and subprocessors can again be a thorny issue here – ask if the vendor is providing the service or outsourcing it. Do you know the subvendor that they are outsourcing to? Make sure the contract states that the vendor is responsible for what its subcontractor does, so you are not just white-labelling something and ultimately on the hook for it.
A topical question that is growing in importance by the day is the vendor’s approach to ESG issues and regulation. The response that any business gives to this request can reveal a great deal about the maturity and business capability of its management team.
The current fashion as the corporate world hurtles into the cloud is to go public. The perhaps misguided perception seems to be that there is strength and security in being part of the crowd, housed like the rest of the corporate market with Google, Amazon and Microsoft.
Often overlooked is that there is some advantage in being housed in a country other than the US, that is treated as a third country by key regions like the EU for GDPR compliance.
Many corporates like their data to be stored in their own country. Vendors are prone to saying they can accommodate customer requests in order to win the business – the reality is that “quickly spinning up a data center in a new location” can cost more than people think, and this does not happen overnight.
The reality is that ‘quickly spinning up a data center in a new location’ can cost more than people think, and this does not happen overnight.
Another worthy consideration, especially for a customer who is operating in a highly regulated market such as financial services, is whether the vendor is sophisticated enough to be able to handle a data request from a regulator or government, so they can best serve and protect the customer’s interests. Evidence of how a vendor might approach this sort of request can be telling for a prospect.
This has the utmost relevance to data vendors. Quality in, means quality out. Can vendors reconcile this and show that this is business as usual for them? Can they really deliver here?
Sometimes the stakes are high enough to justify running a Proof of Concept (PoC). This way you get to test that the service actually works, and in your environment. It also lends transparency to the service itself, and how you will get charged. Considerations for a PoC are the cost, its scale, and what happens when it ends.
Service must be a primary concern. Ensure that they will provide continuous live support (can they evidence that irrespective of whether they guarantee it in the SLA?) and training. If it is software, how frequent will security updates or patches be?
Do not forget to build in contingency if there is a risk of the product or service being discontinued. How will data be preserved and returned? Is an alternative provider available? What is the likelihood of this happening?
The scale, scope and risk of the engagement and relationship needs to be considered carefully, and must be reflected in a proportionate way in terms of the depth and rigor of your vendor due diligence.