Compliance Isn't a Feature, It's a Posture
A SOC 2 Type 2 attestation tells you what a vendor was doing for the twelve months ending on a specific date. It does not tell you what they're doing now. If you bought based on the badge, you bought yesterday's vendor, and yesterday's vendor is not the one operating your production environment.
Before Railway I was at Citrix, where I spent a meaningful chunk of my career on customer environments at Verizon and Lockheed Martin, the kinds of places where the procurement team treats a security questionnaire as a load-bearing artifact and where "compliance" is a department with a budget. I have watched the compliance industry from both sides of the table: the vendor side, watching engineers reshape their work to satisfy an auditor's checklist, and the customer side, watching procurement teams accept a PDF as a substitute for trust.
What I have learned, across both sides, is that compliance is not a feature. It is a posture. It is the difference between a vendor who can produce an attestation because their daily operating discipline happens to satisfy the controls, and a vendor who can produce an attestation because they spent the last quarter retrofitting evidence for a Type 2 window. Both vendors will hand you the same PDF. Only one of them is safe to buy from. This is about how to tell which is which, and why the question matters more every year that the auditing industry commoditizes the badge.
The compliance industry has, over the last decade, achieved something impressive: it has turned a discipline that used to require taste into a procurement artifact that can be ordered from a vendor portal. Vanta, Drata, Secureframe, and the long tail of GRC tooling have done for SOC 2 what Stripe did for payments. The friction is gone. The expertise is automated. The output is a PDF.
This is, on balance, a good thing. A startup with five engineers can now achieve a SOC 2 Type 2 in months, not years, and the controls it implements along the way are mostly the controls it should have implemented anyway. The floor has risen. The problem is what happened to the ceiling.
When a credential is cheap to acquire, it stops carrying information. SOC 2 used to mean "this vendor takes security seriously enough to spend a year and a quarter-million dollars on an audit." Now it means "this vendor spent eight weeks and forty grand on a guided GRC workflow." The badge is the same. The signal underneath it is not.
Buyers have not caught up. The procurement playbook still treats SOC 2 Type 2 as a meaningful filter. The questionnaire still asks the same questions it asked in 2018. The answers are still graded on a pass/fail basis, with no follow-up on whether the controls described in the attestation reflect how the vendor operates on a Tuesday afternoon when an engineer is on call and a customer is reporting a strange behavior. The result is that compliance has become a feature: a thing the vendor ships, the buyer consumes, and neither party thinks about again until renewal.
I wrote a piece last year called "The F in SOC2 Stands for Functional," which argued that the auditing industry has incentives to commoditize attestation. That piece was about the supply side. This one is about the demand side. Buyers are not powerless. The compliance industry has shaped itself to what buyers ask for. If buyers ask for badges, vendors will ship badges. If buyers ask for posture, vendors will have to demonstrate posture, and the ones who cannot will reveal themselves.
Posture is the set of operational disciplines a vendor practices when no auditor is watching. It is the default behavior of the system and the default behavior of the people running it. It is, by definition, the thing that an annual attestation cannot measure, because the attestation is a snapshot and posture is a continuous quality.
There are four disciplines I look for, and they generalize across nearly every vendor category.
The first is continuous monitoring. A SOC 2 Type 2 audit measures controls over a twelve-month window. A vendor with good posture measures their controls every minute. They have alerting on access patterns, on configuration drift, on dependency vulnerabilities. They do not wait for an auditor to ask "how do you know your encryption-in-transit is still on?" They know because the system is checking, and because a human is paged when the answer changes.
The second is defensive defaults. The single highest-leverage security decision a platform makes is what behavior it ships with the checkbox already ticked. If encryption-in-transit requires an opt-in, most customers will not opt in. If audit logging on admin actions is a paid feature, most customers will not pay. A vendor with good posture treats the secure configuration as the default configuration, and treats every deviation from the default as an explicit, logged, reversible decision. The opposite vendor ships a permissive default, points to the documentation, and treats customer misconfiguration as a customer problem.
The third is incident response history. Every vendor has incidents. The difference between a vendor with posture and a vendor with marketing is what happens in the seventy-two hours after the incident resolves. Does the vendor publish a postmortem? Does the postmortem name the root cause, the contributing factors, the action items, and the people who own them? Or does the status page get a vague update and a "we apologize for the inconvenience"? Public postmortems are the most legible signal of operational seriousness, because they require the engineering team to commit, in writing, to a version of events they cannot quietly revise.
The fourth is engineer ownership. In organizations where compliance is a feature, security is a department. Engineers ship code, the security team reviews it at the end of the process, and the compliance team writes the evidence. In organizations where compliance is a posture, security is a shared concern. Engineers think about threat models when they design APIs. Code review includes a "what does an attacker do with this" question. The compliance team exists to coordinate, not to absolve. You can tell which kind of organization you are dealing with by asking an engineer at the vendor a security question and watching whether they answer it or redirect you.
At a glance:
Comparison of good versus weak vendor posture across postmortems, logging, encryption, who answers, and secrets scoping
The procurement questionnaire will not tell you any of this. The procurement questionnaire is a hashing function: it reduces the vendor's posture to a series of yes/no answers, and the vendor's GRC tooling has been optimized to produce yeses. You will need to ask different questions.
Ask where the most recent incidents are documented. Not "have you had incidents," because every vendor has. Ask for the URL of the most recent public postmortem. A vendor with good posture will send you a link in under a minute. A vendor with bad posture will route the question to legal.
Ask what the platform's defaults are. Are admin actions logged by default, or is audit logging a feature flag? Is encryption-in-transit on by default, or is it a configuration the customer applies? Are secrets scoped per-environment by default, or does the platform encourage a single shared bag of environment variables? Defaults are revealed preference. They tell you what the vendor believes the median customer should be doing.
Ask who answers your security questions during procurement. If your security questions are routed to a sales development representative reading from a knowledge base, the vendor has built a process to insulate engineers from buyer scrutiny. If your questions are routed to a security engineer, or to the CTO, the vendor has decided that buyer scrutiny is a thing engineers should participate in. Both are choices. Only one of them produces accurate answers.
Ask whether the platform publishes security-relevant release notes. A vendor with good posture will tell you, in a changelog entry, when they ship a control improvement: a new audit log field, a tightened default, a deprecated authentication mechanism. A vendor with bad posture will treat security changes as silent, on the theory that publicizing them implies prior weakness. The first vendor is operating from a position of confidence. The second is operating from a position of marketing.
If a vendor cannot answer these four questions in writing, in a single email thread, with concrete URLs and not vague gestures at "our security page," the SOC 2 PDF in your folder is decorative. It is not evidence of posture. It is evidence that the vendor knew how to hire a GRC consultant.
I work at Railway, so I will be brief and honest. The point of this section is not to pitch the platform. The point is to show what posture looks like when you describe it concretely, so that you can apply the same lens to any vendor.
Railway scopes secrets per-environment by default. Production, staging, and ephemeral PR environments each have their own isolated variable store, and promoting a service across environments requires an explicit action, not an accidental copy. Encryption in transit is on by default for every service, both for ingress and for private networking between services in the same project. Admin actions, including environment variable changes, service deletions, and permission grants, are recorded in an audit log that workspace owners can review. We publish postmortems on our public status page when incidents have customer impact, and we describe the root cause in enough detail that a reader can form their own opinion about whether we have done the work. Security-relevant changes are called out in our changelog when we ship them.
None of this is exotic. All of it is the kind of thing a vendor with good posture should be able to describe in five sentences. If your current vendor cannot, that is the signal.
The compliance industry will not change. The incentives are too aligned: auditors want repeat engagements, GRC vendors want recurring revenue, and the vendors who buy GRC tooling want the smallest possible distance between "we exist" and "we have a SOC 2." The badge will continue to get cheaper. The signal underneath it will continue to weaken. None of this is going to be reformed by a regulator or a standards body.
What can change is how buyers evaluate. The next time a vendor sends you a SOC 2 Type 2 report, read the date on it, then ask them what they have shipped since. Ask for the most recent postmortem. Ask what the defaults are. Ask whether an engineer or a salesperson is answering you. The vendors who treat compliance as a posture will recognize the questions, because their daily work is the answer. The vendors who treat compliance as a feature will hand you the PDF a second time and hope you stop asking.
Buy from the first kind. The badge is the floor. Posture is the building.
Happy shipping.
Angelo
Angelo Saraceno is a Solutions Engineer at Railway. Before Railway he was at Citrix, working inside Verizon and Lockheed environments, so he has seen what "enterprise IaaS" looks like after the slides come down. He writes about infrastructure, deployment, and the gap between how cloud is sold and how it runs in practice.