6 MIN READ
The people who actually run production systems, the ones who carry a pager, the ones who answer the 2 AM page, do not trust the vendors they buy software from. The trust gap is not new, but it has widened over the last three years, and the average enterprise security org now treats vendor announcements as marketing copy to be verified rather than facts to be acted on. Healthy instinct. Expensive, and not what the vendors want.
Why it exists is structural. Vendor incentives reward shipping the release on schedule, with the marketing claim that the release closes a particular vulnerability, supports a particular standard, or implements a particular feature. Operator incentives reward knowing whether the claim is true, on the version of the software they are actually running, with the configuration they are actually using, in the environment they are actually deploying to. Vendor side leans optimistic. Buyer side leans sceptical. The two incentives do not align, and the gap is permanent.
What operators do not trust
The specific things operators do not trust, ranked by how often the field reports them.
Security advisories that say “patch immediately” without specifying the exploit chain. A CVE number, a CVSS score, and a paragraph of marketing prose does not tell the operator whether the vulnerability is reachable in their environment. The buyer wants three things: the actual exploit, the prerequisites, and the detection signature. An advisory that skips those answers gets deprioritised, because the operator has a hundred of them and deprioritisation is the only way through the queue.
Compliance certifications that say “SOC 2 Type II” without specifying the scope, the period, or the auditor. A SOC 2 report that covers only the corporate IT environment for the corporate IT period is not a SOC 2 report for the production environment the operator runs. The buyer wants the basics. What was in scope, what was tested, what was the period, who was the auditor, what were the exceptions. A certification that hides those details does not move the needle on the vendor review.
SLA claims that say “99.9% uptime” without specifying the definition of uptime, the credits, and the carve outs. An SLA that credits the customer with a token fraction of the monthly fee for a downtime event the vendor gets to define is not the SLA the buyer thinks they are buying. The buyer wants the mechanics. How is uptime measured, what does the credit look like, what is excluded. An SLA that does not answer those questions does not survive the contract review.
Pricing models that say “per user per month” without specifying the user definition, the minimum commitment, and the overage. A per user per month price that bills on the active user in the last 30 days and counts the API integration as 50 users is not the per user per month price the buyer thinks they are buying. The buyer wants the rules. What counts as a user, what is the minimum, what is the overage. Pricing that hides those definitions gets renegotiated after the first quarterly bill.
Reference customers who turn out to be the marketing side, not the engineering side. A reference call that the vendor schedules is a reference call with the vendor’s chosen customer, talking to the vendor’s chosen stakeholder, about the vendor’s chosen topic. The buyer wants to talk to the on call engineer at a real customer, about what breaks at 2 AM, about what the support response looks like when the customer is not on the reference list. Vendors that refuse that call do not survive the reference check.
What operators do instead
Operators have learned, over years of being burned, to verify vendor claims in their own environment, on their own time, before trusting the claim. The verification looks like this.
The proof of concept, on the production stack. Not on the vendor’s reference architecture, not in the vendor’s free tier, not in the demo environment. On the production stack, with the production data, with the production configuration, for at least a month. Anything else is a PoC that does not tell the operator anything useful.
The incident test, before the incident. A controlled failure injected into the vendor’s software, at a time the on call engineer chooses, to see how the vendor’s stack handles the failure. Vendors that block the test have already told the operator everything they need to know.
The exit interview, before signing. A conversation with a customer who has stopped using the vendor. Most vendors will not facilitate it, and that refusal tells the operator whether the lock in is real and whether the support matches the marketing.
What the vendors should do about it
The vendors that are closing the trust gap have stopped treating operators as the audience for the marketing claim and started treating them as the audience for the engineering documentation. The vendors that are widening the gap are still putting the press release in the first paragraph of the security advisory.
Operators have voted with their feet. Vendors that earn the trust get the renewals, the case studies, the word of mouth. Vendors that do not earn it get churned out at the end of the contract, with a post mortem the vendor sales team will not want to read.
The trust gap is not going to close on its own. It will close because the operators, who are the ones who actually know whether the software works, are the ones who actually decide whether the contract gets signed.
The bottom line
Trust the engineering documentation, not the press release. Test on the production stack, break the vendor’s software on purpose, and talk to a customer who has already left. The operators who do that work get the vendors that earn the renewal. The ones who do not, pay for the gap at the next incident.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
