SOC 2 Compliance for Developers: What Engineers Implement

A prospect’s security questionnaire asks for your SOC 2 report, and suddenly an engineering team that has never thought about audits needs to understand one. The good news is that most of the engineering work is ordinary security hygiene. The harder parts are scoping it sensibly, producing evidence over time, and not getting sold something that isn’t a real SOC 2.

This guide is written for the engineers who end up owning the technical controls. It sticks to what the AICPA material and audit firms say, and labels vendor estimates as vendor estimates.

What is SOC 2, in plain terms?

SOC 2 is an attestation report from a licensed CPA firm on your controls for protecting customer data. A Type 1 report checks that controls are suitably designed at a point in time. A Type 2 also tests that they operated effectively over a period. It is not a certification, and the security criteria are always included.

Who sets the rules, and who can sign

SOC 2 is defined by the American Institute of Certified Public Accountants (AICPA). The examination is performed under the AICPA’s attestation standards, and the criteria are the 2017 Trust Services Criteria, with points of focus revised in 2022.

Only a licensed CPA can sign the report. On a Journal of Accountancy podcast in April 2026, the AICPA’s Amy Pawlicki called SOC 2 “not a certification” but “an examination-level attestation engagement signed off on by a licensed CPA.” That distinction matters when you shop around. Compliance automation platforms help you prepare and collect evidence, but most are not CPA firms. A February 2026 Journal of Accountancy article warns about offers of “compliance (a term never used in SOC 2 examinations)” delivered in weeks. If an offer bundles the audit, check who the CPA firm is.

Who can see the report

A SOC 2 report is restricted to specified parties who understand the system, according to the AICPA guide. In practice you share it with customers and prospects during their security reviews. If you want something you can post publicly, that’s a SOC 3, which the AICPA describes as a general use report that “can be freely distributed.”

Why teams get one

Enterprise buyers’ security reviews commonly ask for a SOC 2 report, and having one replaces a lot of custom questionnaires. That’s the business reason. The engineering reason is that the work forces you to make access, logging, change control and incident response consistent, which you’d want anyway. If you’re weighing the cost, compare it with what a security incident actually costs.

Type 1 vs Type 2

The AICPA guide defines both:

• A Type 1 report covers management’s description of the system and the suitability of the design of controls “as of a point in time.”
• A Type 2 report covers the same, plus whether the controls “operated effectively throughout the period of time”, with a detailed description of the auditor’s tests and results.

A Type 1 is like checking that smoke detectors are installed. A Type 2 checks that they were tested every month for the whole period and that someone acted on the failures.

How long the Type 2 period is

The AICPA doesn’t set a minimum. Management picks the period. A CPA writing for the Cloud Security Alliance puts it this way: “there are no requirements for the length”, and “in practice, you usually see periods of three to twelve months.” Schellman, a CPA firm, describes Type 2 periods as “typically six months or more.” Many companies start with a shorter first period and move to a rolling twelve months.

Which to get first

A common sequence is a Type 1 first, so you have something to show buyers quickly, then a Type 2 period starting soon after. Some teams skip straight to a Type 2 with a short first period if buyers in their market insist on it. Ask two or three of your target customers which they accept before you decide.

The Trust Services Criteria, for engineers

There are five categories: security, availability, processing integrity, confidentiality and privacy. Security, through the “common criteria”, is in every SOC 2. The AICPA guide says the common criteria “constitute the complete set of criteria for the security category”, and each optional category adds criteria on top of them. Schellman puts it simply: “the Common Criteria are required for all SOC 2 reports.”

What each category means for engineering:

Category	Question it answers	Engineering work it brings
Security (always included)	Is the system protected against unauthorized access?	Access control, MFA, network security, logging and monitoring, vulnerability management, change management, incident response
Availability	Is the system available as committed?	Uptime monitoring, capacity planning, backups, disaster recovery, tested restores
Processing integrity	Is processing complete, accurate and timely?	Input validation, error handling, reconciliation, job monitoring
Confidentiality	Is confidential information protected?	Data classification, encryption at rest, retention and disposal
Privacy	Is personal information handled as promised?	Privacy notice, consent, data subject requests, retention

Add a category only when it matches something you promise customers. Availability makes sense if you sell an uptime SLA. Confidentiality makes sense if customers trust you with source code, contracts or business data. Privacy overlaps heavily with GDPR work, so it’s cheaper to add if you’ve already done that. Every extra category means more controls to evidence and a bigger audit.

The controls engineering teams implement

The criteria describe outcomes, not tools. Your auditor decides what evidence satisfies them. The controls below are the ones engineering teams most often own; access control sits under the CC6 criteria and change management under CC8.

1. MFA on everything that matters

Enforce multi-factor authentication on:

• your Git host (org-wide enforcement on GitHub, GitLab or Bitbucket)
• cloud consoles (AWS, GCP, Azure), with the root account locked down
• your identity provider and email (Google Workspace, Microsoft 365)
• database, hosting and deployment platforms
• Slack or whatever chat holds incident and customer information
• your password manager

Prefer phishing-resistant methods such as hardware security keys or passkeys for admins, and avoid SMS codes. One admin account without MFA is an easy finding. The same discipline applies to machine credentials; see our guide to secrets management with Vault and Doppler.

2. Audit logging

You need to answer “who did what, when, and from where?” for:

• authentication events (logins, failures, MFA changes)
• permission and role changes
• access to sensitive data
• infrastructure and configuration changes
• admin actions such as user creation and deletion

{
  "timestamp": "2026-03-13T14:22:31Z",
  "actor": "alice@example.com",
  "action": "user.role_change",
  "target": "bob@example.com",
  "details": { "old_role": "viewer", "new_role": "editor", "project": "client-dashboard" },
  "ip": "203.0.113.42",
  "user_agent": "Mozilla/5.0..."
}

Most SaaS tools already produce audit logs. Your job is to centralize them (Datadog, Splunk, CloudWatch or similar), protect them from tampering by keeping them separate from production and limiting who can delete them, and retain them for a defined period that covers your audit window.

3. Backups and disaster recovery

Expect the question: “If your primary database disappeared now, how long until you’re back, and how much data would you lose?” You need:

• automated backups of databases and critical data
• encryption of backups at rest
• copies stored separately from production (another account or region)
• a documented recovery time objective (RTO) and recovery point objective (RPO)
• restore tests on a schedule, with the results written down

The restore test is the one teams skip. Having backups you’ve never restored is a common gap.

4. Vulnerability management

You need a way to find and fix vulnerabilities in code, dependencies and infrastructure:

• dependency updates with Dependabot or Renovate; our Renovate vs Dependabot comparison helps you pick
• dependency and code scanning (GitHub code scanning, Snyk, Socket or similar)
• cloud and container scanning
• a software bill of materials in CI if you ship containers, so “what’s in this build?” has a quick answer

Then write a patching policy with target times by severity and follow it. An example policy might say critical issues within a few days, high within a couple of weeks, medium within a month, and low within a quarter. The exact numbers are yours to choose. What the auditor checks is that your patching history matches what you wrote.

5. Code review and branch protection

Usually the easiest control, because most teams already do it:

• no direct pushes to the main or production branch
• at least one approving review that isn’t the author
• required CI checks (tests, lint, security scans) before merge
• the same rules for admins

# Example GitHub ruleset for main (document this for the auditor)
Branch: main
Rules:
  - Require a pull request before merging: 1 approval minimum
  - Dismiss stale approvals when new commits are pushed
  - Require review from code owners
  - Require status checks: [tests, lint, security-scan]
  - Block force pushes
  - Restrict deletions
  - Do not allow bypass, including administrators

6. Access reviews

On a regular schedule (quarterly is common), review who has access to what and remove anything no longer needed:

1. Export user lists from your Git host, cloud accounts, databases, identity provider and other key tools.
2. Compare them with the current team roster.
3. Remove access for anyone who has left. This should already happen at offboarding; the review catches misses.
4. Check permission levels, especially admin and production access.
5. Record the date, the reviewer and what changed.

It’s tedious, and it is one of the controls auditors test most carefully. Automate the exports where you can.

7. Incident response plan

You need a written plan, and evidence that you followed it. A short plan the team actually knows beats a long one nobody has read.

Phase	Action	Owner	Example target
Detection	Alert fires from monitoring	On-call engineer	Immediate
Triage	Assess severity	On-call engineer	Within 15 minutes
Containment	Isolate affected systems	Engineering lead	Within 1 hour for critical
Communication	Notify affected customers	Founder or exec	Per contract and law
Investigation	Find root cause	Engineering	Within 24 hours
Remediation	Fix the issue	Engineering	Depends on severity
Post-mortem	Write up lessons	Engineering lead	Within 1 week

The targets are examples; set ones you can meet. If there were no incidents during the period, expect to show a tabletop exercise instead. If incident ownership has outgrown one person, our guide to hiring a cybersecurity engineer covers what to look for.

8. Change management

Every production change should leave a trail: a ticket, a branch, an approved pull request, passing CI, an automated deploy, and post-deploy monitoring. You probably already do most of this. For SOC 2, the point is that you can show it for any change the auditor picks from the period.

What you can skip

SOC 2 asks for reasonable controls that are consistently followed. It doesn’t ask for perfection.

You don’t need a dedicated security team. A small company can have an engineering lead own the program, as long as ownership is clear and the work happens. If you do hire for it, our guide to hiring a DevSecOps engineer covers what that role should own.

You don’t need to build tools. SaaS monitoring, scanning and password management count as controls.

You don’t need perfect documentation on day one. A two-page policy people follow is better than fifty pages nobody reads.

You don’t need PCI DSS or HIPAA unless you handle card data or US health data. They are separate frameworks.

And you don’t need zero exceptions. Auditors report exceptions they find, and first reports often have a few. What matters to buyers is how many, how serious, and what you did about them.

Compliance automation platforms

Platforms like Vanta, Drata, Secureframe, Sprinto and Thoropass connect to your cloud, Git host, identity provider and HR system, monitor controls continuously, collect evidence, host policies and track training. They take most of the screenshot-gathering out of the process.

None of the major ones publish prices; their pricing pages ask you to contact sales. Two things to check when comparing them: which of your tools they integrate with, and whether they include the audit. Most are not CPA firms and partner with one. Thoropass states on its site that its assurance arm “is a licensed certified public accounting firm” (Thoropass).

Remember the Journal of Accountancy warning above. A platform can make you ready. Only an independent CPA can issue the report.

What it costs and how long it takes

There’s no official price list. The published figures come from vendors who sell SOC 2 tooling, so treat them as rough ranges:

• Vanta says the audit fee “usually runs between $10,000 and $50,000”, with first-year all-in costs between $10,000 and $80,000 or more, and preparation taking one to five months.
• Drata estimates a Type 1 audit at $7,500 to $15,000 and a Type 2 at $12,000 to $20,000 for smaller companies, with most startups spending $25,000 to $50,000 in the first year and $15,000 to $40,000 a year after that.
• Schellman doesn’t publish numbers and says the fee depends on scope.

On timing, Vanta calls its figures “rough estimates”: a Type 1 audit taking roughly five weeks to two months, and a Type 2 window of three to twelve months. Add your own preparation time before either.

Beyond fees, budget engineering time for closing gaps, writing policies and running reviews, plus a penetration test if your auditor or customers expect one.

A realistic sequence

1. Pick an owner and a compliance platform. Connect your tools and read the gap report.
2. Get quotes from two or three CPA firms. Ask about scope, period length and what evidence they expect.
3. Close the easy gaps first: MFA everywhere, branch protection, centralized logs.
4. Write the core policies: access control, change management, incident response, data classification, acceptable use.
5. Set up the recurring controls: access reviews, vulnerability scan reviews, backup restore tests, security training.
6. Run a tabletop incident exercise.
7. Do the Type 1 audit, or start the Type 2 period, and keep every control running and evidenced throughout.

Common first-audit findings

These come up often enough to check for before the auditor does:

1. One tool without enforced MFA.
2. A missed quarterly access review.
3. Admin access granted for a good reason that nobody documented.
4. Backups that were never test-restored.
5. A former contractor who still has access somewhere, often a staging environment.

None of these is hard to fix. All of them are easier to prevent than to explain.

Getting started this week

Day one: start a trial or demo of a compliance platform and connect your main tools. Day two: enforce MFA everywhere it’s missing, starting with admins. Day three: turn on branch protection for your main branches. Day four: write a first incident response plan, two pages is fine. Day five: list the CPA firms you’ll ask for quotes.

After that, the gap list tells you what’s next. Most of it is straightforward engineering work done consistently.