At Railway we believe that everyone should be able to deploy software, instantly.

No certs, no training. Code from laptop to live as quickly as you can commit code.

So naturally I tend to be the type of person that is skeptical of credentialing regimes.

Before anyone sends us hate mail saying that we hate security. Absolutely not, we spend a lot of our time fighting fraudulent workloads, dealing with spammers and abusers, and patching up our systems up to snuff. This is work that historically takes thousands of engineering hours that we’ve taken on behalf of our customers.

Some of the said work we can’t talk about.

I also hear you typing: “Well, you just don’t like compliance.”

Personally, I find the screenshots fun. Working at a startup is akin to founding a new country, and to me, there is nothing more exciting than contributing to the legitimacy of an organization like mature processes.

At my last employer, I spent a considerable amount of time working with FedRAMP auditors making sure that the last product I managed was fully compliant with the security standards, export controls, and documentation that one needs whenever you sell to the U.S. Federal Government. Before that, when I was a entrepreneur, I tried my hand at writing various SBIRs/STTRs and selling to government. I think the controls there for those organizations make sense. (I have also contributed to writing successful NSF grant proposals in a former life.)

There is no bureaucracy that I can’t navigate.

But for a company, that is just starting, that is very much likely to pivot, or to get their first design partner or proof of concept- SOC2 is a strangle hold of a tax.

Where in my opinion, adds undue stress for founders that otherwise would have been more logical to push the process until later. Those founders can’t complain about it because doing so would ruin their legitimacy.

With the way SOC2 is currently used, especially enforced by SOC2 software vendors has created a SOC2 pyramid scheme. Where in order to be (quickly) SOC2 compliant, it’s highly suggested that your vendors are also certified, forcing the entire stack to have the “certification” sticker- or be removed from an organization’s footprint.

To make matters worse, the now canonical way it’s implemented and audited flies in the face on how it was originally supposed to be implemented at these organizations.

We now require every startup to have screenshots and auditors before they have customers. We've added a $40,000 tax on any entrepreneur trying to sell to enterprises—another headwind founders don't need.

At Railway, we back entrepreneurs and host their applications. I, however, worry that building the next Zoom (2011), Slack (2013), or Superhuman (2014) wouldn't be possible today. Not impossible, but significantly harder.

We've created a credentialing cartel.

I hear the keyboard already! You must be typing out “No way this is true, the process can’t be that bad!”

And I agree, it’s not bad, for us, a VC funded company with experienced operations staff- but if you are a 2-3 person company, I think it’s fatal. Lemme explain to you how.

How SOC2 Works

Tiny sidebar on what SOC2 is:

SOC 2 is an independent audit (ran by a licensed CPA firm) that produces an attestation report, not a certification, about how a company’s security controls are designed and operate against the AICPA’s Trust Services Criteria (security, availability, confidentiality, processing integrity, and privacy).

What this looks like is a number of controls that are listed out on a matrix, and then a company spends their time writing documentation to show that they meet these controls.

A Type I opines on whether controls are designed and implemented correctly at a point in time.

A Type II checks that those controls actually operated over a observation window (commonly 6–12 months).

Note, that there is not a legal requirement for SOC2, although GDPR and California’s data privacy framework are law, this gave rise to a number of privacy and compliance management vendors who now occupy the space.

What we did in the times of yore

SOC2 has been around for quite sometime, since the 1970s in fact. However, it’s rise was in part due to a few factors.

As the demand from the public geared lawmakers in the U.S. and Europe to craft greater accountability to large tech companies, greater government regulation about data sovereignty arose. Example on how it applies to Railway. For any customer who decides to host their workload in the EU, we CANNOT move that workload to a different country and we have spent a good amount of effort to prove it via our EU representative that this is the case.

The increase in government oversight led to the rise of SOC2 security vendors that have compelled companies that they need SOC2 on top of the existing compliance frameworks.

In the past before this regime, you would sell to a business, and then at the mid-market level, they would send you to the IT where you would do a security review in the form for a questionnaire. It was long, but it was around 30 or so questions. Provided you had a sufficiently motivated buyer, it was not a major blocker after they signed an NDA.

However… enter screenshot mania

As the rise of these security vendors popped up, AICPA released SSAE 18 which updated the matrix and had a greater focus on cloud presence and data governance.

What security documentation vendors do then is take the list of controls, and then attempt to model a questionnaire off of the SSAE 18 standards that an auditor would expect when reviewing your packet.

When you look at the controls, they seem reasonable, take this one for instance.

The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.

—CC1.4, SOC2 SSAE 18

Let’s walk through the mindset of someone in operations should have when working with this document. Cool, I would provide proof of our hiring process, our recruiting process, and our code of conduct.

Usually, a security vendor would then prompt you to provide the following documentation and then you are good to go.

Except, there are 250 of these questions.

I will admit, most of them, are easy, and for a mature organization would have no problem spending the month or so going through the list at their own leisure as they beef up their organizational maturity addressing any gaps that the controls suggest.

But if you are a seed stage start up trying to account for this one:

The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.

—CC8.1, SOC2 SSAE 18

There is a David Graber-esque fake work PDF that you would have to spit out to satisfy the request of the control. Let’s assume that you are using a new upstart dev-tool, unless you feel strongly about it, you would just rip the tool out.

Since every prospect that you consider you as a vendor requires SOC2 to maintain their own SOC2 (or at least make it easier for their attestation report) we’re in a world where not companies are doing the questionnaire in bad faith, getting an attestation for a product that doesn’t exist, attesting for a process that doesn’t exist- watering down the attestation for everyone.

The Auditor is biased, and works for you.

You might be wondering, but they are accountants, that can’t happen. Can Duruk (good guy) who writes at Read Margins wrote about this part of the auditing process. But I am happy to add some color on how this may happen.

First off, I want to say that Railway, myself, and our operations team takes the attestation process seriously. We take our customer workloads seriously.

When we picked an auditor, we wanted the audit to be relatively adversarial. Meaning, we wanted to avoid a situation where the auditor is coaching us through the test. It’s common for an auditor to point out discrepancies in your reports and evidence, but we never wanted to pre-prep the packet and water down our footprint to make the firm happy.

However, with the rise of this belief that now everyone needs SOC2, auditing firms have started pre-screening the packets, even sometimes offering the attestation report that you fill out FOR THEM, that they just hand waive.

It’s an insult to the compliance process.

For some perspective, FedRAMP is a true adversarial auditing process where you hire two auditing firms. One that works with you to prep the packet to certify that you are at the FedRAMP level you attest to, and then one that you can’t have any communication with until after the interview. (I, for one, can’t wait when we begin this process.)

I don’t want the controls to get stricter, however, I don’t want what was previously a serious process to be taken less seriously all because three or four security vendors are making a business hoodwinking companies to hand over $12,000 a year plus a $12,000 for the audit, plus $20,000 for an external security review, on top of the amount of wasted engineering cycles spent taking screenshots and writing unread prose.

Protect Little Tech

Look, I understand I know that there isn’t great optics being someone at Infrastructure company complaining about the SOC2 process. Nonetheless, I am more passionate about the journey that our customers take when they decide to leave a familiar job and create something new that needs to be sold.

Many of those founders have enough to worry about, let alone the FUD that we have allowed this industry to push on them.

My fear is that BigCompliance will then convince a new generation of buyers that they will need FedRAMP Level 5 to be a good vendor and we will erect moats and choke out innovation like never before.

With that said, I do think we still should have a way to prove a software’s security and organizational footprint.

Keep the bar, change the ramp

The big challenge that I have with SOC2 is that it’s seen as a all or nothing gate. I strongly think that we need something between nothing and SOC2. If someone from the AICPA is listening- adopting a level system on SOC2 would be much appreciated where companies can start by building an attestation packet much sooner without the headache.

Most companies, those who use Railway, or using a traditional cloud provider are likely covered by a significant amount of controls that their cloud host offers. Example, Railway offers built in DB backups and one click restore, that massively helps with explaining a company’s disaster recovery story to an attestation report. I feel like we can do much better by having a sharable “Trust Kit” that has:

• System diagram & data flows
• Sub-processors & shared‑responsibility mapping to cloud attestations
• Access control inventory (who has access to what infrastructure, when)
• Backup/Disaster Recovery summary with reproduction and fire-drills and test logs
• Vulnerability management
• Incident response run book & on‑call policies

And- not that I can change the buyer I really wish that we move away from a world where we don’t require every sub‑vendor to be SOC 2 if their blast radius is small.

However, any advice, as the compliance environment shifts, be mindful about how your company presents it’s self and always think about how you can mature the organization you are building.

We’ll keep our own bar high (SOC 2 Type II done!; ISO 27001 on deck and FedRAMP… eventually), and we’ll champion the staged‑trust model with our vendors and customers.

Security should be earned and demonstrated continuously, not purchased as a one‑time sticker.

…and we’ll always have the back of the entrepreneur.