How to Make Sure You're SOC 2 Compliant

Building a SaaS product? Your next enterprise customer is going to ask for your SOC 2 report. Here's what SOC 2 actually requires, what it costs, and how to not lose six months and a quarter-million dollars figuring it out the hard way.

If you're building a SaaS product — or really any application that stores customer data — you're going to hear three words that will haunt your product roadmap: "Do you have SOC 2?"

It usually comes from your biggest prospective customer's security team. It arrives in the form of a vendor security questionnaire that's 400 questions long and asks things like "describe your change management process" while you're still deploying to production by SSHing into a server and running git pull. Good times.

SOC 2 (Service Organization Control 2) is a compliance framework developed by the AICPA that evaluates how well your organization protects customer data. It's not a certification — it's an audit report. A very expensive, very thorough audit report that enterprise buyers treat as table stakes for doing business.

And here's the part nobody tells you upfront: about 40% of enterprise deals stall or die when the vendor can't produce a SOC 2 report. That's not a compliance statistic — that's a revenue problem. Your SOC 2 report isn't a security artifact. It's a sales asset.

So let's talk about how to actually get one without losing your mind, your engineering velocity, or a small fortune.

01The Five Trust Service Criteria

SOC 2 is built around five Trust Service Criteria. Think of them as the five questions the auditor is trying to answer about your organization. Security is always required. The other four are optional — but "optional" in the way that wearing pants to a job interview is optional. You can skip them, but your prospects will notice.

Security (Always Required)

This is the foundation. Every SOC 2 audit includes the Security criterion, also called the Common Criteria. It covers whether your systems are protected against unauthorized access — both logical (who can log into what) and physical (who can walk into the server room, assuming you still have one of those).

In practice, this means access controls, encryption, monitoring, incident response, and change management. If your idea of "access control" is a shared 1Password vault with the master password in a Slack channel pinned message, we need to talk.

Availability

Can your customers count on your system being up? This covers uptime commitments, disaster recovery, failover, backups, and capacity planning. If you've ever promised "99.9% uptime" in a contract while your primary database runs on a single EC2 instance with no read replicas, this criterion is going to be an uncomfortable conversation.

Processing Integrity

Does your system do what it claims to do? This covers whether data is processed completely, accurately, and in a timely manner. It's particularly relevant for fintech, payment processing, and data pipeline companies — anywhere incorrect processing would cause real financial harm to your customers.

Confidentiality

Is sensitive information properly protected? This goes beyond just customer data — it includes intellectual property, business plans, financial data, and anything else classified as confidential. If you're a B2B company handling your customer's proprietary data, this criterion is effectively required by your market.

Privacy

This covers personal information specifically — how you collect it, use it, retain it, and dispose of it. It overlaps with regulations like GDPR and CCPA. If you process consumer data, particularly in healthcare, fintech, or consumer SaaS, include this one.

The most common combo for B2B SaaS: Security + Availability + Confidentiality. That covers about 80% of what enterprise buyers ask for. If you're in healthcare or handle consumer PII, add Privacy. If you're in fintech or do data processing, add Processing Integrity.

02Type I vs Type II: Choose Your Adventure

This is where most first-timers get confused, and where bad advice costs real money. There are two types of SOC 2 reports, and they're not just "easy mode" and "hard mode."

Type I says: "We looked at your controls on a specific date, and they were properly designed." It's a snapshot. A selfie of your compliance posture on one particular Tuesday.

Type II says: "We watched your controls operate over a period of 3–12 months, and they actually work." It's a documentary. Cameras rolling for months, watching you actually do the things your policies claim you do.

Here's the thing: enterprise buyers overwhelmingly want Type II. A Type I report tells them you could be compliant. A Type II report tells them you are compliant. The difference matters when they're trusting you with their customers' data.

Our recommendation: If you're under pressure from a specific deal, get Type I first — it takes 2–4 months and unblocks the immediate sales conversation. Then immediately start your Type II observation window. If you have 6+ months of runway before the compliance question becomes urgent, skip Type I entirely and go straight to Type II.

The worst thing you can do is get Type I and think you're done. Type I is a bridge, not a destination. Every quarter you delay Type II is another quarter where a sophisticated buyer's security team is side-eyeing your compliance program.

03The Actual Roadmap

Getting SOC 2 compliant follows a predictable path. The timeline varies based on your starting point, but the phases are always the same.

Phase 1: Scope and Gap Analysis (Weeks 1–2)

Before you build anything, figure out what needs to be in scope. This means:

• Map your systems. Every application, database, cloud account, and SaaS tool that touches customer data is in scope. Yes, even that internal tool Dave built with a free Heroku dyno. Especially that one.
• Choose your trust service criteria. Security is mandatory. Pick the optional criteria based on your market and customers.
• Identify gaps. Compare your current state against what SOC 2 actually requires. This is where reality meets the "we're pretty secure, right?" optimism that every startup has.

The output of this phase is a gap assessment that tells you exactly what you need to build, fix, or document before you're audit-ready. Most companies find 20–40 gaps. If you find fewer than 10, you either have a very mature security program or a very incomplete gap analysis.

Phase 2: Build Controls (Weeks 3–8)

This is where the real work happens. You're implementing the controls identified in your gap analysis — and this is where most companies either get it right or burn through six figures learning what "right" means.

Technical controls — the stuff your engineering team builds:

• MFA everywhere (no exceptions, even for the CEO who "doesn't like extra steps")
• Centralized logging with proper retention (90 days minimum, 1 year recommended)
• Automated vulnerability scanning
• Encryption at rest and in transit
• Endpoint detection and response (EDR) on all employee devices
• Infrastructure as code — because auditors love being able to see your infrastructure configuration in version control

Administrative controls — the stuff that lives in documents:

• Information security policy
• Acceptable use policy
• Incident response plan
• Business continuity / disaster recovery plan
• Vendor management policy
• Data classification policy

A word on policies: they need to be real. Not copy-pasted templates from Google with your company name find-and-replaced in. Auditors can smell a template policy from three paragraphs in, and they will ask your team questions about it. If your incident response plan says you'll "convene the Security Incident Response Team" but nobody on your team has heard of that committee, you have a problem. Write policies that describe what you actually do.

Phase 3: Readiness Assessment (Weeks 9–12)

Before the auditor shows up, do a dry run. Test every control. Collect the evidence. Interview your team. Find the gaps you missed before paying $20K–$60K for an auditor to find them for you.

This is also when you start collecting evidence. Screenshots of MFA enabled. Exports of access reviews. Pull request histories showing code review requirements. If a control exists but you can't prove it, it doesn't exist.

Phase 4: The Formal Audit

The auditor will:

• Review your policies and procedures
• Test a sample of your controls (they won't test everything — they sample)
• Interview team members about their security responsibilities
• Review evidence of controls operating over time (for Type II)
• Issue a report with their opinion and any exceptions

Exceptions are findings where a control didn't work as intended. A few minor exceptions are normal and won't torpedo your report. A material exception — like "the company has no access controls and the intern has root access to production" — will result in a qualified opinion, which is roughly the SOC 2 equivalent of failing.

04The Controls That Actually Matter

Let's get specific about what auditors look at most closely:

Access Controls (The #1 Finding Area)

• Unique user IDs — no shared accounts, anywhere, ever. The "deploy" user that three people share? Kill it. Create individual service accounts.
• MFA on everything — production systems, cloud consoles, version control, email. If it has a login, it needs MFA.
• Least privilege — developers shouldn't have write access to production databases. If they need it to debug, implement a just-in-time access system with approval workflows and time limits.
• Quarterly access reviews — every quarter, someone needs to look at who has access to what and confirm it's still appropriate. When was the last time you checked if that contractor from 18 months ago still has GitHub access? Yeah. Do that.
• 24-hour offboarding — when someone leaves the company, all access is revoked within 24 hours. Not "eventually." Not "when IT gets around to it." Twenty-four hours. Automate this with SCIM provisioning through your identity provider.

Change Management

• All changes through pull requests — no more SSHing into production and editing files. Every change goes through version control with a documented review process.
• Code review required — at least one reviewer who is not the author. Enforce this with branch protection rules. No exceptions for "urgent fixes" at 2 AM — especially for urgent fixes at 2 AM.
• Automated testing in CI — your pipeline should catch regressions before they reach production. Auditors love seeing a CI/CD pipeline that proves every deploy was tested.
• Separated environments — development, staging, and production should be isolated. Production data should never exist in development environments. If your dev environment has real customer data "for testing," that's a finding.

Monitoring and Incident Response

• Centralized logging — all systems push logs to a centralized platform (Datadog, Splunk, CloudWatch, ELK). Logs sitting on individual servers that no one checks are useless.
• Alerting that someone actually responds to — having 500 unread PagerDuty alerts is the same as having no alerting. If your team has alert fatigue, fix the alert thresholds.
• Incident response plan — not just a document, but a practiced process. Your team should know who to call, what to do, and how to communicate during an incident. Run a tabletop exercise at least annually.
• Post-incident reviews — every significant incident should have a blameless postmortem. Auditors want to see that you learn from failures.

05What It Actually Costs

Let's talk money, because this is where the sticker shock hits. SOC 2 compliance costs fall into three buckets:

Audit fees:

• Type I: $15,000–$40,000
• Type II: $30,000–$80,000
• Annual renewal: $25,000–$60,000

Compliance platform (strongly recommended):

• Vanta, Drata, Secureframe, or similar: $10,000–$50,000/year
• These platforms automate evidence collection, provide policy templates, continuous monitoring, and integrate with your existing tools. They cut preparation time by 40–60%. If your annual revenue is above $1M, the ROI is obvious.

Internal engineering time:

• First-time implementation: 200–500 engineering hours (roughly 2–4 months of one engineer's time)
• Ongoing maintenance: 5–10 hours/month

Total first-year cost for a Series A SaaS company: $60,000–$150,000 all-in, including the platform, audit, and engineering time.

Is it expensive? Yes. Is it cheaper than losing a $500K enterprise deal because you couldn't produce a SOC 2 report? Also yes.

06The Mistakes That Cost Real Money

After helping multiple companies through this process, here are the mistakes we see over and over:

1. "We'll deal with compliance later." This is the most expensive sentence in startup security. Retrofitting SOC 2 controls into an application that wasn't designed for them costs 3–5x more than building them in from the start. Logging is easy to add on day one. Retrofitting comprehensive audit logging into an 18-month-old codebase with 200 API endpoints is a project that will make your lead engineer cry.

1. Shared credentials everywhere. That one AWS root account everyone uses? The shared admin login for your monitoring tool? The API key hardcoded in a config file committed to Git in 2023? Each one is an audit finding. Fix it now. Your auditor will find it.

1. No evidence trail. SOC 2 isn't about being secure. It's about proving you're secure. Every control needs evidence. If you enabled MFA six months ago but can't show the auditor when it was enabled and for whom — did it really happen? Start collecting evidence from day one.

1. Copy-pasted policies. Auditors interview your team. If your incident response policy says "contact the CISO" and your company doesn't have a CISO, that's a finding. Write policies that match reality. Update them when reality changes.

1. Ignoring vendor risk. Your SOC 2 scope extends to every vendor that handles customer data. That includes your cloud provider, your analytics platform, your customer support tool, and your payment processor. Each one needs a security review. Each one should have SOC 2 or equivalent compliance themselves.

1. Treating it as one-and-done. SOC 2 is annual. Your controls need to work every day, not just during audit season. Continuous monitoring isn't optional — it's the difference between a smooth renewal and a scramble to fix months of accumulated drift.

07The Compliance Platform Decision

You can do SOC 2 without a compliance automation platform. You can also drive a nail with a rock instead of a hammer. Both technically work. One is dramatically more painful and time-consuming.

Compliance platforms like Vanta, Drata, and Secureframe connect to your existing infrastructure — AWS, GitHub, Okta, Jira — and continuously monitor your controls. They auto-collect evidence, flag when something drifts out of compliance, and give your auditor a clean package of evidence instead of a messy Google Drive folder of screenshots.

When to use a platform: If your company has more than 10 employees or more than $1M in revenue, just get one. The $15K–$30K annual cost pays for itself in the first audit cycle through reduced preparation time alone.

When you might skip it: If you're a 3-person startup and your only SOC 2 motivation is a single prospect, a manual approach with spreadsheets and screenshots might suffice for Type I. But you'll outgrow it fast.

08The Timeline That Actually Works

Here's what a realistic SOC 2 journey looks like for a startup that's starting from scratch:

Month 1: Scope definition + gap analysis. Choose your criteria, map your systems, identify what needs to change.

Months 2–3: Build controls. Implement technical controls, write policies, deploy monitoring, set up a compliance platform.

Month 4: Readiness assessment. Test everything. Collect evidence. Fix what's broken.

Months 4–5 (Type I path): Engage auditor for Type I. Receive report. Start Type II observation window immediately.

Months 5–12 (Type II path): Observation window. Your controls are operating and evidence is being collected continuously. Keep everything running.

Month 12–13: Type II audit. Auditor reviews the observation period. Report issued.

Month 13+: Annual renewal cycle. Continuous monitoring. Annual re-audit.

09The Bottom Line

SOC 2 compliance is a lot of work. But it's predictable work with a clear return. Every week you delay is another week of enterprise deals sitting in "pending security review" limbo. Every shortcut you take is a future audit finding that costs more to fix than it would have cost to do right.

The companies that do SOC 2 well treat it as an engineering project, not a paperwork exercise. They automate evidence collection from day one. They build controls into their CI/CD pipeline. They make compliance part of how they ship software, not a separate workstream that competes with product development.

The companies that struggle treat SOC 2 as a checkbox — something to fake their way through so they can get back to "real work." Those companies spend twice as much, take twice as long, and end up with a compliance program that crumbles between audits.

If you're building a SaaS product and compliance is on your roadmap, we do SOC 2 readiness assessments at Apptivity. We'll map your current state, identify gaps, and give you a concrete remediation plan with realistic timelines and costs. No fear-mongering — just engineering advice from a team that's been through the audit process and knows where the real landmines are. (The fear-mongering in this blog post, however, was entirely intentional.)