The Developer’s Guide to SOC 2 Compliance
SOC 2 compliance will help your company grow and land larger deals, but it takes some work to get there. This guide will walk through what you need to know as a developer.
Nobody wakes up in the morning excited to deal with a SOC 2 audit, but completing one will help your company grow and close larger deals faster.
SOC 2 covers a lot, and it’s not just an engineering checkmark - but if you’re a developer at a not-huge company going through SOC 2 compliance, chances are you’ll need to get involved.
This guide will cover everything you need to know from a technical perspective, from basic access controls to encrypting data at rest.
(Note: this guide is NOT a comprehensive assessment of what you’ll need to pass SOC 2 compliance, nor is it legal advice. The goal here is just to help developers understand what they’ll need to do to make sure that tech and infrastructure aren’t holding things up.)
What SOC 2 is and why it's important
SOC 2 is a certification – an objective third party checking your company out – developed by the AICPA, one of the big “governing bodies” of accountants in the U.S (riveting, I know).
The way it works is that you hire an auditor to investigate how secure and trustworthy your company is, fill in any holes they identify, and then they certify you as SOC 2 compliant.
Once you’ve passed an audit, you can display the SOC 2 logo on your site, tell your customers and leads that you’re compliant, and close those bigger deals.
The important thing about SOC 2 is that it’s not just a stamp for giant enterprises. Like SSO and Directory Sync, even fast growing startups are starting to require more advanced security measures before engaging with vendors. And as we’ll see in a bit, most of what you’ll need to work on to be SOC 2 compliant overlaps a lot with engineering best practices anyway.
So if you’re considering whether SOC 2 compliance is worth it for your company, it might be a realistic fit earlier than you think - and help you stand out to potential customers.
Now if you’re thinking that SOC 2 implies the existence of a SOC 1, you’d be right - but SOC 1 is a lot less popular among SaaS startups. It’s generally a lower lift certification and doesn’t meet the security requirements that those larger deals are looking for.
There’s also a SOC 3, but same story here - generally not the focus for the customers you’re trying to woo. SOC 2 is the big one.
So what exactly are these auditors looking for? What makes your company SOC 2 compliant? The answer, weirdly enough, is that criteria are subjective and company-specific - the auditor you work with will put together a plan. Generally, they’re looking for a few things:
- There’s quality oversight of the company as a whole (performance reviews, independent voices, background checks, etc.)
- The SDLC (software development lifecycle) is transparent, trackable, and controlled (issue tracking, unit testing, version control, etc.)
- Your application and underlying infrastructure are secure and monitored (encryption, logging, APM, vulnerability scans, etc.)
- You’ve implemented access controls for internal services and SaaS (de-provisioning accounts, 2FA, malware detection, etc.)
If a lot of these examples look familiar to you, it’s because you’ve probably already implemented them. The good news about SOC 2 is that, as it relates to engineering, the requirements are generally pretty agreeable and a lot of modern SWE orgs already have issue tracking, review pipelines, vulnerability checks, and a good amount of the remaining checks auditors will be looking for.
We’ll dive into the SDLC, app and infrastructure, access controls, and then take a look at how you can save time with pre-built software like Vanta that takes care of a lot of the annoying work you need to do for SOC 2, like policy generation.
The SDLC
Your auditor will put together a list of concrete checks that you’ll need to either (a) provide evidence that you’ve already done, or (b) get started on doing. Again - this is not a comprehensive list, but it should help you get started and think about what auditors will be looking for.
→ Issue Tracking
Any “issues” that relate to the core business - new features, products, bugs, vulnerabilities, etc. - should be tracked. There are a hundred ways to do this - if you’re at a bigger company you’re probably using JIRA, the cool kids are using Linear, and there’s also Clubhouse, GitHub Issues, and many many more.
The auditors are just looking to make sure known problems don’t slip through the cracks, and when a problem arises it’s dealt with effectively and in a timely manner.
.webp)
They might ask for a sample of your tracked issues over a given time period. You’ll save yourself a bunch of time down the road by finding a way to link commits and PRs to specific tickets, e.g. via a naming convention (BUG-453-fix-broken-dropdown).
→ Change Testing and Review Cycles
Auditors will be looking for documented policies that govern how you track, test, approve, and validate changes to your core application. Now ideally if you’re reading this, you’re not pushing directly to master - you’ve got a staging environment set up and a pull request process with required reviewers. Internal documentation might suffice here, but you’ll probably need to generate a policy (something Vanta can help with - more on that later).
If you’re working via a monorepo, building foolproof review cycles is pretty easy (it’s just a setting in GitHub). But if you’ve got a bunch of repositories all constantly changing, they should all ideally require reviews before merging in changes.
Even if there’s only one engineer pushing code, laptops can get lost or stolen, and auditors will want to see that extra security to bestow the SOC 2 stamp.
Application and infrastructure
Here, auditors are trying to verify that your app is generally reliable, trackable, and that you fix things quickly when they come up. Again - all things that you probably already care about.
→ Encryption
You’ll generally want to encrypt customer data at rest, and make sure that sensitive requests (especially if they’re auth or customer data related) are encrypted in transit/motion (e.g. HTTPS). Ideally your site and app have SSL enforced, your certificate isn’t expired (duh), and there aren’t any known issues.
Some auditors will also require an encryption policy that describes your company’s approach to encryption.
→ APM / Monitoring
To be SOC 2 compliant, you’ll need to set up a basic application monitoring system, either in house or via a vendor like Datadog. Auditors will also be interested in what you do with this information - how often is there downtime? How quickly does it get resolved? You might need to provide screenshots of outage statistics via your APM tool, and evidence that you resolved the issue via your issue tracking software.
These usually come in the form of a post mortem / analysis and remedy of the root cause.
It’s not a given, but some auditors will specifically require that you set up a Load Balancer to handle traffic, and monitor that Load Balancer as well as your core app.
→ Logging and Backups
Auditors will be looking for centralized logging from your app into a secure spot, via something custom like flat files, Elasticsearch, or an out of the box setup like Heroku (if you’re running on PaaS). You might be asked for daily backups - auditors are generally more concerned with your app’s data than your app itself, so if you’re using something like RDS, you can rely on their backup to S3 feature.
→ Vulnerabilities
Unsurprisingly, this is a major focus of the audit process, even if it’s not a common day-to-day occurrence. Auditors are basically looking for 3 major things here:
- There’s a safe way for anyone (literally, anyone) to notify your company of vulnerabilities
- Your team is proactively checking for vulnerabilities via review meetings and software
- When a vulnerability gets uncovered, your team fixes it
You’ll want to set up an email inbox for disclosing vulnerabilities (e.g. security@workos.com), put together a policy for how you handle incident response, and (if relevant) provide evidence that you’ve resolved any major vulnerabilities (i.e. a post-mortem). Auditors will also look for proactive vulnerability scanning. If you’re running on managed infrastructure like Heroku, they do a lot of that for you. GitHub will also notify you of any dependencies with known vulnerabilities.
Access controls / SaaS
This is where things get a bit tedious. In addition to your core infra (AWS or whatever cloud you’re using), chances are you’re using a bunch of SaaS like PagerDuty, Segment, GitHub, and the like, some cloud based and some (potentially) on prem.
Auditors are looking for rigid access controls: only relevant team members should have access to customer data and applications, and access needs to be revoked when employees leave the company.
→ Core Infrastructure Access
Auditors will be looking for even stricter controls when it comes to managing core infra. In practice, this means a robust IAM setup in AWS (or your cloud provider of choice) with clear lines between admins and non-admins, and a review process for adding new folks to the organization. You might need to prove that review via a screenshot of someone asking permission, or something along those lines.
As part of this review, you’ll probably end up needing to remove users from accounts that they previously had access to. Early on in the company lifecycle things are pretty free rein, but auditors will want to make sure that if you have no business querying the warehouse, you’re not on BigQuery.
→ De-provisioning Users
If an employee leaves the company or gets terminated, their access to all company accounts - infrastructure, SaaS, any anything else - needs to be revoked, and auditors will often look for this to happen within one business day of the employee’s last day with the company. You’ll probably need to do this manually for the first couple of years in the company lifecycle, but eventually you’ll want to set up Directory Sync so computers can do it for you.
→ MFA
Any method for accessing customer data needs to be protected by (at least) two-factor authentication. That means GSuite, GitHub, AWS and, if you’re using them, tools like Segment too. This can get kind of hairy depending on how you set up GitHub - especially if your team is committing from their personal accounts, you’ll need to require 2FA in your organization settings.
→ Remote Device Management
Company computers need to be protected in case they get lost or stolen. Tools like Fleetsmith help manage your “fleet” of company computers and wipe data remotely if an employee reports their’s gone.
Policies, Vanta, and Managed Services
One common thread among the SDLC, application and infrastructure, and access controls is this concept of a policy - auditors are looking for stated guidelines around how your company handles anything that relates to customer data and the core product. You can always write these from scratch or find templates online, but plug and play tools like Vanta take care of this for you, and we highly recommend taking a good look at them.
.webp)
Vanta also integrates with your cloud provider, GitHub, PagerDuty, and other related software to automatically pull the kinds of data that auditors are going to ask for. It can proactively let you know where you’re slacking and what you’ll need to do to fix it:
.webp)
Tools like Vanta won’t solve all your problems, though - you’ll still need to start running monthly or quarterly reviews of security, SDLC policies, and access controls. For example - as part of our SOC 2 certification at WorkOS, we now run a quarterly meeting to review who has access to which applications, and the attendees are (actually) documented.
It’s also worth noting that there are other solid options to choose from: SecureFrame and Tugboat Logic are a couple of the more popular ones. StrongDM’s Comply is an open source choice.
Another useful way to avoid tons of custom work for SOC 2 is using managed services for your infrastructure. Now, obviously, deciding how to deploy your app is a much more complex discussion than “making SOC 2 easier” - but it’s worth noting that using something like Heroku takes care of encrypting data at rest, load balancing, monitoring for vulnerabilities in infrastructure, and more.
Learning more about SOC 2 / resources
Hopefully this helped with a bit of perspective on what SOC 2 looks like from an engineering perspective. But like we mentioned, there’s a lot more to this - going through a SOC 2 audit is a company-wide initiative and takes a bunch of time (usually 3+ months, and you need to re-certify each year).
As a developer, the way you can be the most helpful is by getting ahead of the curve and implementing the measures above - which tend to align with engineering best practices anyway. A few more resources if you’re curious: