Falling short in establishing trust can cause significant business impacts. Additionally, since this process doesn't happen in a vacuum, you need to consider not just the impact to yourself but the impact to your partners, customers and vendors. Here are some common pitfalls to avoid.
A few "don'ts" when creating trust:
- Lack of Transparency - Your prospective customer wants to make the most risk informed decision when picking a vendor, and that decision will require some data analysis. Trust isn't built on blind faith and secret keeping. Refusing to provide even the most basic evidence requests will not help you solidify a sale. This is not to say that all types of requests for documents and internal company information should be shared, but as a vendor, your job is to make the customer feel at ease about your product or service. If you are finding that customer data requests are becoming too cumbersome to handle in both volume and uniqueness, consider implementing a customer self service portal and sharing your documents up front. This can put the prospective customer at ease and reduce the need for more back-and-forth.
- Delaying the security conversation - We've already discussed why customer security reviews are becoming a non-negotiable in so many sales cycles today. So if you are pretty certain there's going to come a point when your customer or prospect asks you to complete a vendor security assessment, there's little reason to delay this until the end of the sales cycle. Be upfront with documentation that proves your security posture: SOC 2 reports, penetration tests, security FAQs, and/or other standardized security questionnaires (like CAIQ, SIG, etc). By sharing security information with your prospects earlier on, you can shorten the security review process significantly — or avoid it altogether.
- Disjoined systems and tools - Even the most innovative, security-conscious companies out there today are not always the most advanced when it comes to responding to customer security questionnaires. Many organizations are using some combination of spreadsheets, email exchanges, shared drives, and maybe a 3rd part RFP tool. Each of these point solutions may solve one piece of the puzzle, but they are often not integrated, automated, or entirely secure. Look for a platform that all teams can work out of, and that allows for features like watermarking documents, managing access, and tracking activity. The more you can control the flow of information, the better for all parties.
- No justification for "No" - When you receive requests for compliance evidence or are answering questionnaires and you have to answer "no" to a request, not providing a justification can harm your chances at solidifying a new partnership. You can't be expected to meet 100% of all customers' requirements, but you should be prepared to have well-articulated, thoughtful responses for all requests. Suppose you receive a request that requires you to have a Dynamic Application Security Testing (DAST) tool in place. If you don't, don't fret, all may not be lost. Do you perform static code analysis? Do you contract with a third party to conduct periodic application penetration tests? Do you have a web application firewall installed? If so, explain these controls! There is no single recipe for achieving a secure or risk mitigated state and your customer should welcome these kinds of discussions. Always remember that trust is collaborative. We can't solve vendor trust problems if we only look at a single side of the equation.