Skip to main content
Guide

SOC 2 doesn't have to be overwhelming.

Your first enterprise customer just asked for your SOC 2 report. Here is what that means, what you actually need to do, and how to get there without losing your mind.

→ Get your readiness score + timeline estimate with the free SOC 2 calculator (no email required)

What is SOC 2, actually?

SOC 2 (Service Organization Control 2) is an auditing standard developed by the American Institute of CPAs (AICPA). It evaluates how a service organization manages customer data based on five categories called Trust Services Criteria. A licensed CPA firm performs the audit and issues a report that your customers use to evaluate your security posture.

SOC 2 is not a certification you earn once and keep forever. It is an audit report that covers a specific period, and it needs to be renewed regularly. There are two types:

Type I

Evaluates the design of your controls at a single point in time. It answers the question: do you have the right controls in place? This is faster to achieve (typically 1-3 months of preparation) and is often the starting point for companies pursuing SOC 2 for the first time.

Type II

Evaluates the design and operating effectiveness of your controls over a period of time (usually 6-12 months). It answers the question: do your controls actually work consistently? This is what most enterprise customers ultimately want to see.

Most companies start with Type I to prove they have controls in place, then move to Type II for the next audit cycle. Some companies skip Type I entirely and go straight to Type II if they already have strong controls and can demonstrate consistent operation over the audit period.

The report itself is not public. You share it selectively with customers and prospects under NDA. This is different from ISO 27001, where the certificate itself is public but the detailed audit findings are not.

The five Trust Services Criteria.

SOC 2 is organized around five categories. You do not have to include all five in your audit. Security (also called Common Criteria) is always required. The other four are optional and depend on what your service does and what your customers care about.

Security (Required)
Protection against unauthorized access. Covers firewalls, access controls, intrusion detection, multi-factor authentication, encryption, and incident response. This is the foundation of every SOC 2 report and the only mandatory criterion.
Availability
The system is available for operation and use as agreed upon. Relevant if you have SLAs with customers. Covers disaster recovery, backup procedures, incident response, and capacity monitoring. Include this if uptime is a key part of your customer promise.
Processing Integrity
System processing is complete, valid, accurate, timely, and authorized. Relevant if you process transactions, calculations, or data transformations on behalf of customers. Less commonly included unless your service involves financial processing or data pipelines.
Confidentiality
Information designated as confidential is protected as agreed. Covers data classification, encryption at rest and in transit, access restrictions, and secure disposal. Include this if you handle trade secrets, business plans, or other non-public customer data beyond PII.
Privacy
Personal information is collected, used, retained, disclosed, and disposed of properly. Relevant if you handle consumer PII. Covers consent mechanisms, data subject rights, retention policies, and breach notification. Different from confidentiality, which covers any non-public data.

For most B2B SaaS companies, starting with Security alone or Security plus Availability is the right approach. Adding more criteria increases the audit scope and cost. You can always add criteria in future audits as your customers require them. See our frameworks overview for a detailed breakdown of how SOC 2 maps to other standards.

What you actually need to prepare.

SOC 2 readiness comes down to three things: policies that document your commitments, controls that enforce them, and evidence that proves they work.

Policies you will need:

  • Information Security Policy — Overarching security commitments and governance structure
  • Access Control Policy — How access is granted, reviewed, and revoked. MFA requirements, password standards, role-based access
  • Change Management Policy — How code and infrastructure changes are requested, reviewed, approved, and deployed
  • Incident Response Plan — Steps for detecting, responding to, and recovering from security incidents
  • Risk Assessment Policy — How you identify, evaluate, and treat risks to customer data
  • Vendor Management Policy — How you evaluate third-party vendors who access customer data
  • Data Retention and Disposal Policy — How long you keep data and how you securely delete it
  • Business Continuity Plan — How you maintain operations during disruptions. SOC 2 Common Criterion CC9.1 (risk mitigation) and the Availability TSC both expect documented continuity planning. LukaGRC's BC/DR module covers BIAs, recovery plans with RTO/RPO targets, tabletop exercises, dependencies, crisis communications, and succession plans — with auditor-ready exports. Open the BC/DR module ›

Controls you need to implement:

  • Multi-factor authentication on all production systems and administrative accounts
  • Encryption at rest and in transit for customer data
  • Code review and approval process before production deployments
  • Background checks for employees with access to customer data
  • Quarterly user access reviews with documented evidence
  • Vulnerability scanning and patch management on a defined schedule
  • Security awareness training for all employees, at least annually
  • Monitoring and alerting for security events

Evidence you need to collect:

For every control, you need proof it is working. Screenshots of MFA configurations, logs showing access reviews were completed, training completion records, vulnerability scan reports, change approval tickets. The audit period for Type II is typically 6-12 months, so you need evidence from across that entire period, not just a snapshot from last week.

Organizing all of this in spreadsheets and shared drives gets painful fast. A purpose-built GRC platform maps evidence to specific controls and frameworks, so when your auditor asks for evidence of control CC6.1 you are not searching through 200 files in a Google Drive folder.

Common mistakes that slow you down.

After watching companies go through the SOC 2 process, certain patterns emerge. These are the mistakes that add months to your timeline and thousands to your costs.

  • Trying to include all five criteria on your first audit. Security is required. Everything else is optional. Start narrow. Your auditor, your team, and your budget will thank you. You can add Availability or Confidentiality in the next cycle once you have the basics running smoothly.
  • Not scoping properly. SOC 2 applies to a specific system or service, not your entire company. If you have three products and only one handles customer data, scope the audit to that one product. A tighter scope means fewer controls, less evidence, lower cost, and faster completion.
  • Writing policies you do not follow. Auditors do not just read your policies. They test whether you actually follow them. If your access control policy says you do quarterly access reviews but you have never done one, that is a finding. Write policies that reflect reality, then improve reality over time.
  • Starting evidence collection too late. For a Type II audit, you need evidence covering the entire observation period. If your audit window is January through June, and you start collecting evidence in May, you have five months of gaps. Start collecting evidence the day you decide to pursue SOC 2.
  • Choosing an auditor at the last minute. Good SOC 2 auditors book up months in advance. Start talking to audit firms 3-4 months before you want to begin the audit. Ask for references from companies your size. And get pricing in writing. SOC 2 audit costs vary widely, from $15,000 to over $100,000 depending on scope and complexity.
  • Treating it as a one-time project. SOC 2 is not a project with a finish line. Your first report expires, and customers will ask for the latest one. Build sustainable processes that you can maintain year after year, not a heroic one-time effort that burns out your team.
Common pitfall

Do not hire a consultant to build your program and then hand it off to your team to maintain. If your team does not understand the controls, they will not follow them. Invest in internal understanding from day one. Consultants are useful for guidance, but your team needs to own the program.

Building a realistic timeline.

How long SOC 2 takes depends on where you are starting from. If you already have strong security practices and just need to document them, you can move fast. If you are building from scratch, plan for more time. Here is a realistic timeline for a startup going from nothing to a Type II report.

Month 1-2
Foundation. Define your scope and choose which Trust Services Criteria to include. Write your core policies (information security, access control, incident response, change management). Implement basic controls: MFA everywhere, encryption at rest and in transit, code review process. Start collecting evidence immediately.
Month 3-4
Build out. Complete remaining policies (vendor management, risk assessment, business continuity). Conduct your first formal risk assessment. Perform a gap assessment against SOC 2 requirements. Select your auditor and schedule the engagement. Run your first quarterly access review and vulnerability scan.
Month 5-6
Readiness. Close gaps identified in your assessment. Complete security awareness training for all employees. Conduct a readiness assessment (many audit firms offer this as a separate, cheaper engagement). Begin your Type I audit if going that route, or continue operating controls for Type II observation period.
Month 7-12
Observation period (Type II). Operate your controls consistently for 6 months minimum. Continue collecting evidence every month. Conduct quarterly access reviews, ongoing vulnerability scans, and incident tracking. Maintain your risk register. This is where discipline matters.
Month 12-14
Audit. Your auditor examines your controls and evidence over the observation period. Expect 2-4 weeks of active engagement, including document requests, walkthroughs, and testing. Address any findings or exceptions. Receive your SOC 2 Type II report.

The Type I path is faster: roughly 3-5 months from decision to report. But most enterprise customers want Type II, so factor in the full 12-14 month timeline when setting expectations with your sales team.

The key to staying on track is not heroics. It is consistency. Monthly evidence collection, quarterly reviews, and a clear owner for each control. A platform that tracks deadlines, organizes evidence by control, and shows your compliance status in real time makes the difference between a smooth audit and a scramble. See how LukaGRC works for the full workflow, or check our own security practices to see how we approach this internally.

Start your SOC 2 journey today.

Organize policies, track controls, collect evidence, and stay audit-ready. All in one platform built for growing teams.