You shipped the SOC 2 badge. You built a security page. You even wrote a privacy policy a human can read without wincing.
And the deal still stalled in procurement.
Most founders treat trust like a single deliverable — get the certification, post the badge, move on. Procurement teams at serious companies treat trust like an audit. They have a scorecard, sometimes literally a spreadsheet, and every blank cell is a reason to slow down, ask more questions, or pick the vendor who filled in all the rows.
This post is about those rows.
Five years ago, "where does the data live?" was a question for regulated industries. Now it appears on evaluation forms from mid-market SaaS companies buying other SaaS companies.
Procurement wants to know which regions host customer data, whether data can be pinned to a specific jurisdiction, and what happens during failover. If your answer is vague — "we use a major cloud provider" — you have already lost points.
The table-stakes version: name the regions. State clearly whether data crosses borders. If it does, explain why and under what legal framework.
The differentiator version: give the customer control over residency at the contract level, and back it with architecture that enforces it.
Every vendor you share customer data with is a sub-processor. Procurement teams at companies subject to GDPR — and increasingly companies that just sell to those companies — want a published list. They want to know who the sub-processors are, what data they touch, and how you will notify the customer when the list changes.
Most startups do not maintain this list at all. Some maintain it but bury it in a PDF that requires a sales call to access. Both are friction.
Publish the list on your website. Include a mechanism for update notifications — even a simple email subscription. This is not a competitive secret. It is a trust signal, and its absence makes evaluators nervous about what else you haven't documented.
"We will notify you promptly" is not an SLA. Procurement wants a number. Seventy-two hours is table stakes in GDPR-land. Many enterprise buyers want shorter windows — twenty-four hours is common in financial services.
Beyond the timeline, they want to know: Who gets notified? Through what channel? What information will the initial notification contain? Is there a committed cadence for follow-up updates?
If you have never had a serious incident, it is tempting to treat this as theoretical. Procurement does not see it that way. They see a vendor who either has a plan or does not. The plan itself is the trust signal. Whether you ever execute it is secondary.
This one surprises founders. Yes, procurement teams ask about insurance. Cyber liability coverage, errors and omissions, sometimes general commercial liability.
They are not asking because they plan to sue you. They are asking because their risk team needs to check a box, and because a vendor with appropriate coverage is a vendor that an insurer has also evaluated. It is a proxy signal: someone else with money on the line looked at your operation and decided it was insurable.
If you do not carry cyber liability insurance yet, get quotes now. The cost for an early-stage company is often lower than founders expect, and the ability to answer "yes, here are our coverage limits" removes an objection you may never hear spoken aloud.
Procurement wants to know what happens when things break. Not your uptime percentage — your recovery plan. What is your recovery time objective? Recovery point objective? Have you tested the plan, and when?
A status page with historical uptime is good. A documented, tested recovery plan with stated objectives is better. The combination is what lands in the "strong" column on the scorecard.
Here is the hard part: procurement teams rarely tell you which row failed. The deal just slows down. Emails get shorter. The champion inside the account stops returning calls. You chalk it up to "timing" or "budget."
Sometimes it was timing. But often it was a blank cell. A missing sub-processor list. A vague answer about data residency. No insurance certificate. The champion could not get the deal past the review committee, and nobody sends a rejection letter that says "your trust documentation was incomplete."
No single artifact closes an enterprise deal. SOC 2 does not excuse a missing incident response plan. A great security page does not compensate for undocumented sub-processors. Insurance does not replace data residency commitments.
Trust is a portfolio. Each element covers a different concern for a different stakeholder — legal, security, risk, compliance, sometimes the CTO personally. The portfolio does not need to be perfect on day one, but you need to know what is in it, what is missing, and what to invest in next.
Start by getting the scorecard. Ask a friendly customer or prospect to share their vendor evaluation template. Read every row. Count how many you can answer today with a link or a document. The gap between that count and the total is the quiet risk sitting under every deal in your pipeline.
Be the first to comment.
0 comments
Loading comments...