Speedrunning SOC 2 Type 2

Photo by Mathias Reding

Introduction

Given you are here, you already know that SOC 2 Type 2 is a common compliance standard for organizational security that applies to many B2B software technology startups. As you grow, you'll soon be asked by customers to adhere to this standard or at the very least provide a concrete timeline for when you plan to comply. I should also be honest here and admit that a part of the reason why we delayed getting a SOC 2 audit was that deep down we thought something was slightly distasteful about what we had assumed to be the security theater of using paperwork and a policy driven approach to solve for security. After all, we were engineers trying to solve for information security through the use of cryptography and open source software.

After having opted to finally get a SOC 2 audit, in retrospect, this was somewhat short-sighted, because that may align with a certain type of stakeholder (typically an engineer) inside of a customer organization but not a compliance officer or a CISO. I'm happy to say that the formal process of documenting and proving compliance has been very much complementary to the "security by design" approach. Especially if it's done in a way that doesn't add hurdles to engineering and development. I was wrong to assume it was contradictory.

This guide will serve as a rough outline for any early-stage technical founder or team of a software company to get SOC 2 Type 2 compliance as quickly as possible on a reasonable budget. If you are trying to close a deal with a customer who is asking for SOC 2 Type 2 compliance, this guide will help you get a sense of the cost, timeline, and processes. I'll also make sure to provide details that may not be publicly available that I wish I had when we were getting started.

Cost

Assuming you are:

• Early stage company - bootstrapped or seed stage
• Headcount ≤5 employees
• Standard corporate structure - Delaware C Corp, Singapore Pte Ltd. Topco
• Fully remote company - no office / WeWork space
• Using standard tools & services - AWS, Cloudflare, GitHub, Slack, Stripe, etc.

To honor confidentiality, I won't share the specifics of the quotations that we received from any of the partners we engaged. Expect it to be in the range of $10k-15k, annually recurring.

You should budget for your existing cloud / engineering spend to increase by 5-25% depending on the tools and services you are using.

Finding a compliance partner

We recommend you work with a compliance partner, a company that offers a compliance platform with integrations for all your tools and services and has a team that can handle everything on your behalf with the auditor (typically a CPA firm). This will save you a lot of time and effort. Things to look for in a compliance partner:

• Your level of involvement - can they handle everything on your behalf?
• Integration support - well designed SaaS platform with integrations for all your tools and services
• Price - given that this will be a recurring cost

We researched a few options and here are the ones we reached out to:

• Vanta - More established, larger company. Communication delays and pushy sales staff.
• Oneleet - Offers compliance automation + pentest bundle, moves faster -- from first call, to quotation, to private Slack channel was ~5 days.
• Probo - Newer player, open source, claims to provide SOC 2 Type 1 within a week. Requires you to meet the auditor at least once.

We went with Oneleet as we were also looking for someone that can handle everything on our behalf and we also wanted to get a pentest done. A pentest for an application of our size and scope can cost between $4-10k. Perhaps one limitation of the Oneleet all-in-one package is that they only offer 20 hours of pentest. You will either have to reduce the scope or discuss an additional add-on that can accommodate your full scope.

Timeline

The timeline for the entire process mainly depends on your current state of readiness and how much progress you can make to comply with all the controls in what amount of time. There is going to be a mandatory minimum 90 day observation period that you cannot avoid, during which you will be evaluated against the controls that you have set up during the preparation stage. A ballpark estimate for the entire program, start to finish, would be about 4-5 months.

1. Preparation: This is where you will be setting up the policies and processes to satisfy various controls that will be used during the observation period. This is also where you will be collecting the evidence that will be used to satisfy the controls, and automating their validation. If you already have taken your operational security and engineering practices seriously, this will be significantly easier.
2. Internal audit: Should be thought of as a dry run of the final audit. This will be handled by your compliance partner's team to gauge overall readiness before the observation period, as you comply with each control and submit the evidence to your compliance partner for their review and feedback. We were able to do this in parallel to the preparation stage.
3. Observation period: A minimum 90 day period where you will be evaluated against the policies and processes that you have set up during the preparation stage.
4. Audit: The final audit conducted by an independent third party auditor. Your level of involvement in this stage will depend on the compliance partner you choose. Ideally go with someone who can handle everything on your behalf.
5. Report: The report will be compiled by the auditor and will be made available to you and your customers.

Preparation

Controls and evidence collection

In this phase, you will be assessing your current state of readiness against each of the control categories of your SOC 2 Type 2 compliance program. If you have taken security seriously thus far and followed best practices, this will make things a lot easier. Get a letter of engagement from your compliance partner when getting started. Find out if they offer a hosted trust center page (most do) where you can document your progress as you comply with each control. These two will be your public-facing evidence of your compliance program.

If you are doing the following, you are already in good shape:

• GitHub PRs require at least one reviewer's approval before merging to main
• Using a company-wide password manager like Bitwarden
• Using an application secrets manager to centralize secrets and configurations across dev, staging, and production environments
• Using a company wide VPN or a managed service like Tailscale or Netbird
• All data is encrypted in transit and at rest between client, application server, and database.
• Database backups enabled and tested (in the last 90 days), snapshots and point-in-time recovery enabled.
• Automated system status monitoring and alerts - CloudWatch, Datadog, Sentry, etc. Even dedicated Slack channels with alerting bots are a good start.
• Full disk encryption enabled on your desktops and laptops used for work
• Your S3 buckets are encrypted and not publicly accessible (when they don't need to be)

If you are using standard tools for work like Slack, Linear, GitHub, Google Workspace etc. and host your application on a popular cloud provider like AWS, you are in even better shape. Your compliance partner's platform should be able to integrate with these tools and automate the collection of evidence. If something is out of compliance, they will offer detailed instructions on how to remediate it. This will greatly reduce the burden on you to manually collect evidence in the form of screenshots and exports. Keep in mind SOC 2 Type 2 is about staying in compliance with all the controls through a period of time; this is in contrast to SOC 2 Type 1 which should be thought of as a point-in-time assessment. As you go through each control, think very carefully about how you will prove compliance over time. Automate where possible.

In our case, what came as a pleasant surprise was that, given our product is open source, we were able to provide evidence of public code repositories as evidence to satisfy a decent portion of the controls. This was a big win for us and it should be for you as well if your core product is open source. Transparency makes compliance easier.

Ideally you want all evidence collection to be automated. Going with a compliance partner with the widest possible integrations will help you automate the collection of evidence. When you need to manually collect evidence, make sure to include timestamps in the screenshots and exports. When taking screenshots, it's best to take a snap of your entire screen that will show the desktop time and date. You may censor sensitive data from the screenshots. I strongly suggest reading Oneleet's guide on what makes good evidence.

Hope this gives you a better idea of how you can hack the process by using more of your existing toolchain. The only thing I'll add to this is - keep an eye on the costs very carefully. Things like monitoring VPC flows, excessive monitoring with infinite retention, KMS API calls, etc. can add up quickly.

Policies and processes

Moving on, you will soon hit some paperwork. This is the least fun part of the process if you ask me. Your compliance partner and their platform should help you with drafting policies and processes. You'll need to draft, publish, sign (by all relevant personnel) and comply with these policies. If you ever feel confused about a policy, ask your compliance partner for clarification. It's totally fine to push back if you feel like a control is not relevant to your company or prohibitively expensive to comply with operationally. You want to avoid getting into a pattern of overcommitment and undercompliance.

Here are some pitfalls to avoid:

• Overcommitments: Avoid including requirements that aren't actually followed or operationalized. Policies should reflect real practices (e.g., using GitHub PRs for approvals) rather than idealized processes.
• Vague Language: Be specific enough that the intent is clear and auditable. Replace phrases like "changes will be reviewed" with how they are reviewed (e.g., "changes are reviewed via GitHub pull requests by the security team").
• Unclear Ownership: Ensure it's clear who is responsible for implementing and maintaining the process. e.g. "The security team is responsible for reviewing and approving changes to the infrastructure and application code."
• Stale Content: Review this policy at least annually or when workflows or tools change to ensure it remains accurate and aligned with current practices.
• Policy-Evidence Gaps: Make sure that what's described here can be demonstrated through actual artifacts that can be audited.

Observation period

At this stage you have satisfied all controls and entered into the 90-day observation period to stay in compliance. Get into a habit of maintaining your asset inventory, tracking changes, patching vulnerabilities under the SLA, monitoring system status and alerts, etc. Your compliance partner will ask you for supplementary evidence for ~26% of the total controls of your entire program.

You will see two types of evidence requests:

• Active requests: This would involve providing updated screenshots, inventory lists and documentation. The sooner you can complete these requests, the better, as this often blocks the auditor from being onboarded by your compliance partner. Lowering the risks of exceptions that could get triggered during the audit.
• Upcoming requests: A second set of requests that would be due on the last day of your 90 day observation period. Please make sure to mark your calendar and set reminders. Your compliance partner will ask you how certain events were managed (e.g. approvals, tickets, or documentation). Example: If you had 1,000 access requests, you'll upload the full list. Note: If no events happened (e.g. no onboarding), that's fine - just show that the control was in place and ready.

Think of these two sets of requests as checkpoints that confirm that you are still in compliance with the controls. You can use your compliance partner's platform to track the status of these requests and ensure you are on top of them.

Audit

At this stage your compliance partner will handle everything on your behalf. They will engage an external accredited CPA firm to conduct the audit. You will receive a mutual NDA (MNDA) and engagement letter from them to sign. They will conduct the audit and review your evidence. Any request for further evidence will be communicated to your compliance partner by the auditor, who will first evaluate the request to determine whether it can be addressed through the integrations you already have or the evidence you've already provided and, if needed, request further documentation. Your compliance partner will share a draft of the System Description document, more specifically Section III, for your review. This is the core, customer-facing part of your SOC 2 report that describes your company and security program. Please review it carefully and make adjustments as needed to reflect your company and product. Once ready, this will be shared with the auditor and be part of the final audit report.

I would strongly recommend that you take this time to prepare for the next year's audit while the entire process is still fresh in your mind. Make notes. Automate where possible.

Report

The report will be compiled by the auditor and will be made available to you and your customers. You will have two sets of reports, one with a high-level executive summary and the other with the detailed exhaustive report.

Closing

Thanks for reading! I hope this was helpful. I used the word speedrun a bit tongue-in-cheek to describe how to best and most effectively execute on the entire process, given time is the ultimate constraint for any startup. This is not a guide on hastening your security to gain a badge. To the security hawks among you, the technical controls listed in SOC 2 Type 2 may not seem exhaustive. There is plenty of room to really lock things down. I hope those of you who have made it this far can use the process as a starting point to a never ending journey to secure and protect your users' data.