How to get SOC 2 compliance: A developer’s guide

SOC 2 compliance will help your company grow and land larger deals, but it takes some work. This guide covers:

• What SOC 2 compliance is
• How to get SOC 2 compliance 
• Best practices for achieving compliance

What is SOC 2 compliance?

SOC 2 is a set of compliance requirements and an auditing process designed to ensure data security. It was developed by the AICPA, one of the major governing bodies of accountants in the U.S.

An auditor evaluates your company’s security and trustworthiness, identifies and addresses any gaps, and certifies 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 require more advanced security measures before engaging with vendors. As we’ll see in a bit, most of what you’ll need to work on to be SOC 2 compliant overlaps with engineering best practices.

If you’re wondering about the relationship between SOC 1 and SOC 2, the key difference is that SOC 1 focuses on financial reporting, while SOC 2 emphasizes compliance and operational security.

There’s also SOC 3, which is similar to SOC 2 but designed for a general audience. It offers a simplified and less technical summary of the same information.

SOC 2 compliant criteria

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 create a plan. Generally, they’re looking for a few things:

• There’s quality oversight of the company (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.)

The good news about SOC 2 is that its engineering-related requirements are typically straightforward. Most modern software engineering teams already have systems like issue tracking, code review pipelines, vulnerability scanning, and other processes that align with auditors' expectations.

How to get SOC 2 compliance

The first step to becoming SOC 2 compliant is conducting a gap analysis. This is where you determine your current standing and what needs fixing before the audit. Essentially, you’ll want to examine your systems, policies, and procedures to identify any areas that don’t meet SOC 2 standards.

The analysis will focus on access controls, encryption, monitoring, and vulnerability management. It’s also the perfect time to make sure your documentation is solid. Auditors love detailed policies and evidence of your processes, so the more prepared you are in advance, the smoother the audit will go. 

Once you know what’s missing, it’s time to implement the key security controls that SOC 2 requires. Auditors are going to be laser-focused on a few critical areas:

Access controls

Auditors expect strict access controls: Only relevant team members should have access to customer data and applications, and access must be revoked when employees leave. Here’s what auditors check:

• Core infrastructure access‍: Auditors look for strong IAM controls in AWS (or your cloud provider) with clear distinctions between admins and non-admins. You'll need a review process for adding users and may be asked to provide proof, like a screenshot of access requests.

• De-provisioning users‍: When an employee leaves, access to all company accounts (infrastructure, SaaS, etc.) must be revoked within one business day. 
• MFA‍: Any method for accessing customer data must be protected by (at least) two-factor authentication.
• Remote device management‍: Company computers should be secured in case of loss or theft. Tools like Fleetsmith can remotely wipe data when an employee leaves.

Data encryption

You should encrypt customer data at rest and ensure that sensitive requests (especially related to auth or customer data) are encrypted in transit. Ideally, your site and app have SSL enforced, and your certificate is valid.

Some auditors will also require an encryption policy describing your company’s encryption approach.

APM / monitoring

To achieve SOC 2 compliance, you’ll need an application performance monitoring (APM) system, either built in-house or provided by a vendor like Datadog. Auditors will want to know how you handle incidents: how often downtime occurs, how quickly it’s resolved, and what actions you take. 

You may need to share screenshots of outage metrics from your APM tool and provide evidence of resolution through your issue-tracking software.

Logging and backups‍

Auditors will expect centralized logging for your application, stored securely in a solution like flat files, Elasticsearch, or an out-of-the-box option like Heroku (for PaaS environments). 

They may also require daily backups, focusing more on your app’s data than the app itself. If you’re using a service like RDS, you can leverage its built-in backup to S3 functionality to meet this requirement.

Vulnerability management

This is a major focus of the audit process. Auditors look for 3 things here:

1. There’s a safe way for someone to notify your company of vulnerabilities
2. Your team is proactively checking for vulnerabilities via review meetings and software
3. When a vulnerability is discovered, 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 expect proactive vulnerability scanning. If you’re using managed infrastructure like Heroku, much of this is handled for you. Additionally, GitHub provides alerts for dependencies with known vulnerabilities.

How long does it take to get SOC 2 compliance?

Getting SOC 2 compliant is not a quick process. A typical timeline generally looks like this:

1. Preparation phase (2-6 months): This phase includes assessing your security practices, implementing necessary controls, and gathering the required documentation. 
2. Monitoring and collecting evidence (3-12 months): After implementing controls, you'll need to operate those controls for a specific period, typically 3 to 12 months, to gather evidence for the audit. The length of this period depends on whether you're going for a SOC 2 Type I (a point-in-time audit) or a SOC 2 Type II (which covers a period, typically 6 or 12 months).
3. Audit and reporting (1-2 months): The actual SOC 2 audit process, conducted by an independent auditor, can take between 4 to 8 weeks, depending on the scope and the complexity of the audit. Once the audit is complete, you’ll receive the SOC 2 report, which can take another 2 to 4 weeks to finalize.

SOC 2 audit process

Pre-audit preparation

First, you’ve got to define the scope. Figure out which systems and processes will be under review — SOC 2 has five key Trust Service Criteria: 

• Security
• Availability
• Processing integrity
• Confidentiality
• Privacy

Next, you'll need to hire an auditor. Auditors are usually CPAs who specialize in SOC 2 compliance. Many companies start with a gap assessment, which is basically a readiness check. 

After that, you’ll want to ensure your security controls are dialed in — like encryption, access control, and monitoring. These are the bones of what the auditor will be looking at.

Decide whether you need a Type 1 or Type 2

SOC 2 Type 1 audit evaluates the effectiveness of the design of your systems and controls at a specific time, ensuring they are suitably designed to meet the SOC 2 criteria.

SOC 2 Type 2 audit, which digs deeper. It looks at how well your controls have worked over several months — usually 3 to 12 months. It’s more intensive but carries more weight, especially when trying to win over enterprise clients.

SOC 2 audit steps

Documentation review

The auditor will start by reviewing all your security documentation, including policies for incident response, access control, encryption, and so on. This is your chance to show that you’re organized and on top of things.

Control testing

Then comes the hands-on part. The auditor will test whether your controls are actually doing what they should. For a Type 2 audit, this happens over a set period (e.g., 6 months) to make sure your security processes are consistent and reliable. Key areas of focus include:

• Issue tracking and bug fixes
• Change management processes
• Data encryption (both at rest and in transit)
• Backup procedures
• Monitoring and logging
• User access control and de-provisioning processes
• Disaster recovery plans

Evidence gathering

Be prepared to hand over logs, screenshots, and records of security actions. The more organized your evidence, the smoother this will go. Auditors love proof that you’ve been resolving issues on time, encrypting data, and following your processes.

Interviews and walkthroughs

Don’t be surprised if the auditor wants to chat with your engineers, DevOps team, and security folks to see how things work in practice. These walkthroughs help them verify that what’s on paper actually happens in real life.

Audit findings & remediation

• Audit Report: Once the audit is done, the auditor will create a report outlining where you’re compliant and where you’ve got gaps. If there are problems, don’t panic — you’ll get a chance to fix them.
• Remediation: Think of this as your chance to correct any weak spots. Whether missing encryption or not having the right access controls, most companies have a remediation period to address these issues.
• Final report: After you’ve made the necessary fixes, the auditor will issue the final report. This is your official SOC 2 badge of honor, showing potential customers you’ve met all the requirements.

If your company passes the audit, you can use the SOC 2 compliance certification to signal customers that you meet the highest security standards. You can display the SOC 2 logo on your site.

SOC 2 compliance requires ongoing monitoring. To maintain your SOC 2 Type 2 compliance status, you’ll need to undergo the audit regularly, typically annually.

Best practices for achieving SOC 2 compliance

Below are some key best practices to help follow on your SOC 2 journey:

• Collaboration: The process will require collaboration across multiple teams, including IT, security, development, and operations. Regular communication with your auditor is also important to ensure the process stays on track.
• Documentation is key: Ensure that you have detailed documentation for all security controls, incident response policies, and access management practices. Auditors will expect thorough records as proof of compliance.
• Have clear policies in place: Auditors want to see documented guidelines on how your company handles customer data and your core product. You can always write these policies from scratch or find templates online, but plug-and-play tools like Vanta take care of this for you, and we highly recommend looking at them.

How WorkOS helps with SOC 2 compliance

WorkOS simplifies the path to SOC 2 compliance by offering built-in features that address key security and operational requirements. Here's how WorkOS can help your organization achieve and maintain SOC 2 compliance:

• Ready-to-use audit logs: WorkOS offers customizable, strongly typed, exportable audit logs that you can stream to your customers' existing SIEM providers.
• Directory sync: Integrate your app with any SCIM-compliant identity provider your customers use. Whenever an employee leaves or their access changes, you'll automatically receive a request to update their permissions — they’ll never have more access than necessary.
• Downstream compliance: WorkOS is SOC 2 compliant. You don’t jeopardize your compliance by integrating WorkOS products.
• Simplified access control: WorkOS’s Single Sign-On (SSO) and FGA provide enterprise-grade access control, which helps meet the stringent requirements for user authentication and access management in SOC 2 compliance.
• Multi-Factor Authentication (MFA): WorkOS simplifies the implementation of MFA, an important security measure required for SOC 2 compliance. 

Sign up for WorkOS today, and start selling to enterprise customers tomorrow.