SOC 2 for Engineering Teams and Founders

Explaining SOC 2 from an engineering mindset.

Compliance gets a bad rap. Most people roll their eyes with disdain when they hear “compliance.” Their first exposure to compliance is usually from some compliance nerd pushing overbearing, poorly thought-out security controls that strictly hurt productivity. This focus turns engineers off. It even upsets security engineers, as the time allocated for compliance often comes from the security team’s budget. If compliance isn’t driving forward the security team’s needs, there is bound to be bad blood. So let’s start fresh:

What is SOC 2

Let’s say I’m evaluating purchasing Spacelift on behalf of a $10 billion company. Spacelift is an infrastructure-as-code CI platform, meaning their product would have near-administrative credentials to my company’s infrastructure. That’s pretty risky, so how do I know if Spacelift has good security practices? When they fire employees, do they properly remove their access? Is the password to their main fileserver solarwinds123?

How can I evaluate a company’s security practices? I could email them an intense list of questions, but how would I know if what the claim in their responses is what they actually do? The best way would be to take the list of questions and then ask for live evidence proving that they are legit (i.e., an audit). And that’s what SOC 2 is.

The idea behind SOC 2 is that there are an agreed-upon set of best practices that cover security, availability, processing integrity, confidentiality, and privacy. Each company implements these controls differently, so each company hires an independent, third-party auditor to verify that the company has good controls that are adhered to. There are two main types of SOC 2 compliance reports:

• SOC 2 Type 1 → You’ve proven to an auditor all of your controls were properly adhered to for a single day.
• SOC 2 Type 2 → You’ve proven to an auditor that you’ve been able to maintain your security controls in perpetuity (all year).

Spacelift has its SOC 2, so I could ask for it (under NDA) as part of my purchasing plan. I could then read through what type of practices they implement and decide if Spacelift is worthy of my trust.

Compliance is about proving you can safely hold your customer’s data by being transparent about your business processes.

Your customers care that you follow good practices, not that you can fill out a form. When I think about trying to secure a software company, I think of it in the following three broad categories:

• Securing your code
• Securing your infrastructure
• Securing your company

On top of implementing controls for all three categories above, we should also review general guidance and policy management.

I don’t get paid to write: this is just my hobby. It feels great to know that you found this article helpful, so please 👏 , subscribe, follow me, or connect on LinkedIn to let me know!

General Guidance

If I had only three pieces of advice to give, it would be the following:

1. Avoid security theater,
2. Avoid bikeshedding,
3. Gather scope before taking action, and
4. Use a compliance platform.

1. Avoid security theater by focusing on risks, not solutions.

I’ve read through all of SOC 2, ISO 27001, and FedRAMP compliance controls, and I believe that almost all of these controls are reasonable and have good intentions. So why do people end up getting such a poor view of compliance?

Compliance is often a sales-driven business decision. Sales tell leadership they can’t sell without a compliance program, and leadership hires an expert to drive the process forward. These experts are tasked with achieving the certification, not necessarily improving security. Especially if the engineering team isn’t a good partner, compliance specialists can achieve their goal, regardless of whether the company has been made more secure.

If you can achieve compliance without improving security, you just perform theatrics.

Engineers can see this happening, and they get rightfully frustrated. At its core, it feels dishonest to implement a control you know doesn’t meaningfully make your company more secure. Most people I’ve worked with hate dishonesty in their work, which makes implementing weak compliance controls distasteful and demotivating.

2. Avoid bikeshedding.

Alright, software and infosec engineers, it’s also time for you to calm down too. My number one frustration when working with engineers on compliance is that they see things in black and white. They tend to argue that a given control is not infallible, and therefore we should prioritize either fully solving the problem or doing nothing. It’s like everything is either black or white.

My response: locking your front door doesn’t prevent all intruders, but it is also ridiculous to build a bank vault in your basement. Pick a middle ground.

Both sides need to find a balance between security theater and security bikeshedding.

3. Gather scope before taking action.

The desire to prototype and deliver quick wins is a winning strategy for most engineering projects, but compliance is not one of them. Compliance and security tend to impact productivity negatively, and a “quick win” for security can be highly disruptive. The winning strategy is to slow down, figure out the full scope, evaluate the situation collectively and empower others to act.

Note that gathering scope and evaluating risk has nothing to do with creating or proposing solutions. It’s about getting all the key stakeholders on the same page about the existence and severity of the current risks. If everyone agrees on these two points, the solutions will come easily.

4. Use a compliance platform.

I am not getting paid by any company to say this, but I highly recommend using one of the compliance platforms, such as Drata, Vanta, or Tugboat. These platforms provide a significant lift to the compliance process, especially if your company is smaller. In my opinion, Drata is the best platform for the following reasons:

• Live chat with audit advisors — There’s something incredibly comforting about asking questions like “If my company only sells a self-hosted product, do I need to draft up a data protection policy?” and getting responses from expert auditors. For this alone, I’d recommend Drata.
• Automated monitoring — Drata has a decent set of automatic monitoring for detecting misconfigurations in everything from GSuite to GitHub to AWS. My only feedback is that they need more monitors!
• Policy builders — Built-in policy editors that give you a sample policy, including references for which security controls each section of the document addresses. It’s a great jumping-off point for you to draft your own custom policy.
• Helpers — From risk analysis to security awareness training, they provide helpers that are an enormous lift for small startups.

Especially in a startup, you should try one of these platforms instead of trying to wing it. You can’t go wrong with any of the three, but Drata seems best in class.

Alright, enough with the general advice. Let’s jump into the three major sections:

• Securing your code
• Securing your infrastructure
• Securing your company.

Securing Your Code

TLDR: enforce code reviews and permissions across repositories, detect vulnerabilities in your code/containers, and release software to your customer in a safe fashion.

SOC 2 encapsulates these concerns as the Software Development Life Cycle (SLDC). While this might seem like a vague goal, it is a fairly concrete set of things you must do:

Securing Your Infrastructure

TLDR: control how changes are made and ensure everything is logged.

Like securing your code, there are many angles to securing your infrastructure, and it would be silly to write a quick summary of every best practice. Instead, I will focus on the bare minimum.

If you can say that you have a good story for each category above, you likely have enough to pass a SOC 2 audit. In theory, you could have a “good plan” for one of these categories that is so bad, it doesn’t meet the bar, but I doubt that’s the most common case. If you need advice on figuring out these gaps, contact me over LinkedIn.

Securing Your Company

TLDR: training, offboarding, onboarding, risk analysis, and business continuity is the majority of what you need.

By far, this is the most boring of all three sections, but that doesn’t make it less valuable. Securing your company is about the most fallible part of your system: the humans. Humans can’t be automated (yet), which means that this section is mostly about processes. While you can have many great technical controls, if clowns run your company, it doesn’t matter.

What does this have to do with security? Risk.

When I evaluate a vendor, I will ask myself: “What are the chances that this company will flop?”. If I spend years integrating a software vendor into my ecosystem, what happens if that vendor ceases to exist? How much would that damage my business? Sometimes a company is too small and unproven for me to consider taking a risk. Seeing that they have processes and documented policies gives me the confidence that they take their role seriously.

It has been mentioned several times in the post, but policies are an essential last step in your compliance process. I prefer to build excellent security practices first and then document them as formal policies later. It is helpful to read example policies early on, to get an idea of how comprehensive your security controls will need to be. Let’s talk more about these policies below.

SOC 2 Policies

I was fully expecting that I would find writing SOC 2 policies to be as invigorating as reading the dictionary from cover to cover. And while I wasn’t entirely wrong, I found that reading and writing SOC 2 policies helped me identify practices we needed to implement. While I knew the obvious practices by heart, there were some crucial but subtle ones I had missed. It was surprisingly rewarding.

Warning: tell no one that you enjoyed writing a compliance policy, or you will be immediately ostracized.

This blog post is too short to go in-depth into each policy, so I will limit the content to a summary of the policies and the basics of policy management.

Policy Summary

First thing you need to know is that it isn’t the title of the policy that matters, but the content contained within. You can combine policies, and some might not apply to your company. This list is primarily to help you understand the total possible scope.

Policy Management

Policies have an ongoing lifecycle. At first, you draft a policy and get it approved by the business decision-makers. Then you distribute that policy and track signatures/agreements to adhere to the policy. Over time, the business changes, and so must the policies, driving the cycle anew. Don’t forget the annual re-approvals!

There is no reason to do this outside of a purpose-built tool. Drata, Vanta, and Tugboat all have policy generators and trackers that make this process easy.

• Policy generators give you a starting foundation. While you will likely replace most of the content, it’s much easier to draft a policy when you know the approximate content it needs to cover.
• Policy tracking ensures that the right people have signed off on the correct version of the documentation. The process has to handle new employees, updated policies, notifications, and visualization.

Based on my experience, here is what I recommend:

1. Read the generated policy and get an understanding of what is required.
2. Gather information on what existing technology or practices are already used.
3. Determine the gaps between where you are and where you need to be.
4. Evaluate if the existing technology/practices can be modified to meet the compliance requirements.
5. Talk with the existing stakeholders and present them with the information
6. Determine a path forward that solves the compliance issues at the cheapest cost to the company.
7. Write the final draft of the policy and get it approved.

You easily remember this by remembering the acronym: RGDETDW. It’s that easy. /s

Wrap-Up

Alright, so if you made it this far into the article, I salute you! SOC 2 has a lot of components, but it is not a difficult compliance program to adhere to. My intent with this article was to present SOC 2 from an engineering-centric viewpoint that focuses on the security controls you should implement first, before any of the boring compliance paperwork.

I hope that the way you approach SOC2 is to focus the majority of your efforts on implementing great security controls and treat the policies as just documentation. Minimize all time spent on tasks that don’t improve security. If you do this correctly, people will feel proud of their work, instead of rolling their eyes at compliance.

Bottom line: don’t make SOC 2, suck too.