SOC 2 Compliance Checklist

What SOC 2 is

SOC 2 (System and Organization Controls 2) is a framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates how an organization manages customer data based on five trust service criteria. Unlike ISO 27001 (which certifies a management system) or PCI-DSS (which prescribes specific controls), SOC 2 evaluates whether an organization has controls in place that meet defined criteria — and whether those controls actually work over time.

A SOC 2 report is produced by an independent CPA firm after examining the organization's controls against the applicable trust service criteria. The report describes the system, the controls in place, the tests the auditor performed, and the results. It is not a pass/fail certification — it is an attestation with an auditor's opinion on the effectiveness of controls.

SOC 2 has become the de facto trust standard for SaaS companies, cloud service providers, and any technology organization that processes customer data. Enterprise buyers routinely require a SOC 2 Type II report before approving a vendor. Investors performing cybersecurity due diligence treat the absence of SOC 2 as a gap that will need to be funded post-close.

Type I vs Type II

SOC 2 reports come in two forms. The distinction matters because the two types answer fundamentally different questions — and customers know the difference.

Type I: design effectiveness at a point in time

A SOC 2 Type I report evaluates whether the organization's controls are suitably designed to meet the applicable trust service criteria as of a specific date. The auditor reviews policies, configurations, and control descriptions to determine whether the controls, if operating as described, would satisfy the criteria. Type I does not test whether the controls actually operated effectively over time — only that they exist and are designed correctly.

Type I is useful as a stepping stone. It validates that the control framework is sound before committing to the longer Type II observation period. For organizations pursuing SOC 2 for the first time, Type I provides early evidence to share with customers while the Type II observation period runs.

Type II: operating effectiveness over a period

A SOC 2 Type II report evaluates whether controls operated effectively throughout an observation period — typically 3 to 12 months. The auditor samples evidence from across the period: access review records, change management logs, incident tickets, monitoring alerts, and configuration snapshots. Type II demonstrates sustained discipline, not just good documentation.

Type II is what enterprise customers require. A Type I report shows you built the controls; a Type II report shows you ran them. Most security questionnaires and vendor assessment frameworks specifically ask for Type II, and many treat a Type I report as insufficient for ongoing vendor approval.

The five trust service criteria

AICPA's Trust Services Criteria (TSC) define what SOC 2 evaluates. Security is mandatory. The other four are selected based on business context and customer requirements.

Security (Common Criteria — CC)

Security is the foundation of every SOC 2 report and the only mandatory criterion. The Common Criteria cover nine categories:

CC1 — Control environment: governance, organizational structure, management oversight, accountability
CC2 — Communication and information: internal and external communication of security policies and obligations
CC3 — Risk assessment: identifying and analyzing risks to achieving system objectives (pairs with your security risk assessment)
CC4 — Monitoring activities: ongoing evaluation of controls and remediation of deficiencies
CC5 — Control activities: policies and procedures that mitigate identified risks
CC6 — Logical and physical access controls: authentication, authorization, access provisioning, physical security
CC7 — System operations: detection of anomalies, incident response, change management
CC8 — Change management: controlling changes to infrastructure, software, and configurations
CC9 — Risk mitigation: selecting and implementing risk response activities, including vendor management

Availability

Availability criteria evaluate whether the system is available for operation and use as committed or agreed. Controls include uptime monitoring, capacity planning, disaster recovery, backup procedures, and business continuity planning. Most SaaS companies include Availability because their customers rely on service uptime and have SLAs that make availability a contractual obligation.

Processing Integrity

Processing Integrity evaluates whether system processing is complete, valid, accurate, timely, and authorized. This criterion is relevant for organizations where data accuracy is a core service promise — financial calculations, analytics platforms, payment processing, and data transformation services. It is less commonly included by companies whose primary service is not data processing.

Confidentiality

Confidentiality criteria address the protection of information designated as confidential — customer data, intellectual property, business plans, and any data subject to contractual confidentiality obligations. Controls include encryption (at rest and in transit), data classification schemes, access restrictions based on classification, and secure disposal procedures. Organizations handling regulated data or operating under NDA-protected client relationships typically include this criterion.

Privacy

Privacy criteria evaluate how the organization collects, uses, retains, discloses, and disposes of personal information. The criteria align with generally accepted privacy principles: notice, choice and consent, collection, use and retention, access, disclosure and notification, quality, and monitoring and enforcement. Organizations that process personal data as a core function of their service — HR tech, healthcare platforms, consumer applications — should include Privacy. Organizations that only handle employee data or limited customer contact information often exclude it.

Pre-audit readiness checklist

The pre-audit phase determines whether the audit itself will run smoothly or surface expensive surprises. Organizations that invest in readiness before engaging an auditor avoid the most common failure pattern: an observation period that begins before controls are actually operational, producing exceptions that could have been prevented.

Policies and documentation

Information Security Policy — the overarching policy that establishes security objectives, management commitment, and the control framework

Acceptable Use Policy — defines what employees can and cannot do with company systems, data, and devices

Access Control Policy — documents how access is provisioned, reviewed, modified, and revoked across all systems

Change Management Policy — defines how changes to infrastructure, applications, and configurations are requested, reviewed, tested, approved, and deployed

Incident Response Plan — documented procedures for detecting, containing, and recovering from security incidents (template and guide)

Data Classification Policy — defines sensitivity levels (public, internal, confidential, restricted) and handling requirements for each

Vendor Management Policy — documents how third-party vendors are assessed, approved, monitored, and reviewed for security posture

Business Continuity and Disaster Recovery Plan — documented procedures for maintaining operations and recovering systems after disruption

Risk Assessment Policy — defines the methodology and cadence for conducting security risk assessments

Encryption Policy — documents encryption standards for data at rest and in transit, key management procedures, and approved algorithms

Access controls

Multi-factor authentication (MFA) is enforced on all production systems, cloud consoles, and identity providers

Least-privilege access is implemented — users have only the permissions required for their role

Access reviews are conducted quarterly (at minimum) with documented evidence of review and any changes made

Onboarding process provisions access based on role with documented approval

Offboarding process revokes access within 24 hours of termination with documented evidence

Service accounts and API keys are inventoried, assigned owners, and rotated on a defined schedule

Privileged access (admin, root, superuser) is restricted, monitored, and requires additional approval

Single sign-on (SSO) is implemented across business-critical applications where supported

Monitoring and logging

Centralized logging is configured for production systems, infrastructure, and security-relevant events

Log retention meets both audit requirements and your organization's policy (minimum 90 days; 12 months recommended)

Alerting is configured for security-relevant events: failed authentication attempts, privilege escalation, configuration changes, data exfiltration indicators

Logs are protected from tampering — stored in a separate system or immutable storage with restricted access

Endpoint detection and response (EDR) is deployed on all company endpoints (laptops, servers, workstations)

Cloud security posture monitoring (CSPM) is configured for all cloud accounts

Vendor management

Critical vendors are inventoried with documented business justification, data access scope, and risk classification

Security assessments are completed for all vendors that access, process, or store customer data

Vendor contracts include security requirements, data processing terms, breach notification obligations, and audit rights

Vendor SOC 2 reports (or equivalent attestations) are collected and reviewed annually

A process exists for monitoring vendor security posture between formal assessments

Change management

All changes to production infrastructure and applications follow a documented change management process

Changes require documented approval before deployment (peer review for code, manager approval for infrastructure)

Changes are tested in a non-production environment before production deployment

Emergency change procedures are documented with post-change review requirements

Change records are maintained with sufficient detail for audit evidence: who requested, who approved, what changed, when deployed

Separation of duties is enforced — the person who writes code does not approve and deploy it to production

Risk assessment

A formal risk assessment has been conducted within the past 12 months

The risk assessment covers all in-scope systems, data types, and third-party relationships

Identified risks are documented in a risk register with owners, ratings, and treatment plans

Risk treatment decisions (mitigate, transfer, accept, avoid) are documented with rationale

The risk assessment is reviewed and updated at least annually or after significant environment changes

The audit process

The SOC 2 audit follows a defined sequence. Understanding each phase prevents common missteps — particularly around scoping (which determines what the auditor examines), evidence collection (which consumes the most internal effort), and auditor selection (which affects report credibility).

1. Scoping

Scoping defines the boundaries of the audit: which systems, processes, and trust service criteria are included. The scope should cover the systems that process, store, or transmit customer data — the "system" described in the SOC 2 report. Scoping too broadly inflates cost and evidence requirements. Scoping too narrowly leaves important systems out of the report, which sophisticated customers will notice.

Define the system boundaries: production infrastructure, supporting systems (CI/CD, monitoring), and corporate IT
Select trust service criteria based on customer requirements and business context
Document system components: infrastructure, software, people, procedures, and data
Identify subservice organizations (cloud providers, data center operators) and determine whether to use the inclusive or carve-out method

2. Readiness assessment

A readiness assessment (sometimes called a gap assessment) evaluates current controls against SOC 2 requirements before the formal audit begins. This is optional but strongly recommended for first-time audits. The readiness assessment identifies gaps that can be remediated before the observation period starts — gaps found during the audit itself become exceptions in the report.

Many auditor firms offer readiness assessments as a separate engagement. GRC platforms also provide automated readiness checks that map your current controls to SOC 2 criteria and flag gaps. A fractional CISO experienced with SOC 2 can run the readiness assessment and prioritize remediation before engaging the auditor.

3. Evidence collection

Evidence collection is where internal effort concentrates. The auditor will request evidence that each control operated effectively during the observation period. Evidence types include:

Policies and procedures: documented, approved, and communicated to relevant personnel
Configuration screenshots: MFA settings, encryption configurations, access control lists, firewall rules
Process artifacts: access review records, change management tickets, incident response logs, vendor assessment records
System-generated evidence: audit logs, monitoring dashboards, alert records, vulnerability scan reports
People evidence: training completion records, background check confirmations, security awareness test results

GRC platforms automate much of this by integrating with cloud providers, identity providers, ticketing systems, and HR platforms to collect evidence continuously. Without automation, evidence collection for a Type II audit typically requires 100 to 200 hours of internal effort.

4. Auditor selection

SOC 2 reports must be issued by a licensed CPA firm. Not all CPA firms are equal in SOC 2 experience. Factors that matter:

SOC 2 volume: firms that issue hundreds of SOC 2 reports per year have more efficient processes and more consistent quality than firms that issue a handful
Industry experience: an auditor familiar with SaaS architecture will be more efficient than one whose primary practice is financial services SOX audits
Report credibility: Big Four and established mid-tier firms carry more weight with enterprise customers, but cost significantly more
Communication style: the auditor will interact with your team throughout the observation period — responsiveness and clear communication matter
Conflict check: if the same firm performed your readiness assessment, confirm that separate teams handle readiness and audit (independence requirements)

5. Audit timeline

A typical SOC 2 engagement follows this timeline:

Readiness assessment: 2 to 4 weeks (optional, recommended for first-time audits)
Gap remediation: 4 to 12 weeks depending on maturity
Type I audit: 4 to 8 weeks from engagement to report issuance
Type II observation period: 3 to 12 months (6 months is common for first reports)
Type II audit fieldwork: 4 to 8 weeks after the observation period closes
Report issuance: 2 to 4 weeks after fieldwork completes

Common findings and remediation

Certain control deficiencies appear in SOC 2 reports with disproportionate frequency. Addressing these during the readiness phase — before the observation period begins — prevents exceptions that could have been avoided.

Access control deficiencies

Access control exceptions are the most common SOC 2 finding. Typical deficiencies include:

Incomplete access reviews: quarterly access reviews were not conducted for all in-scope systems, or reviews were conducted but no evidence of remediation for inappropriate access was documented
Delayed offboarding: access was not revoked within the policy-defined timeframe after employee termination — the auditor checks termination dates against access revocation timestamps
Missing MFA: multi-factor authentication was not enforced on all production systems or cloud consoles, or exceptions existed without documented compensating controls
Overprivileged accounts: users had administrative access without business justification, or service accounts had broader permissions than required

Remediation: implement automated access reviews through your identity provider, integrate offboarding with HR systems to trigger immediate access revocation, enforce MFA at the identity-provider level (not application-by-application), and conduct a privileged access audit before the observation period begins.

Change management gaps

Change management exceptions typically involve:

Changes deployed to production without documented approval
Emergency changes without post-change review documentation
Developers with direct production access who can bypass the change management process
Configuration changes (infrastructure, firewall rules, IAM policies) not tracked through the same process as code changes

Remediation: enforce branch protection rules that require peer review before merge, implement infrastructure-as-code so infrastructure changes go through the same review process as application code, restrict direct production access, and configure audit trails for all configuration changes.

Monitoring and incident response gaps

Security monitoring exists but alerts are not investigated within defined SLAs
Incidents are resolved but not documented in a way that meets audit evidence requirements
The incident response plan exists on paper but has not been tested through tabletop exercises
Log retention is shorter than the observation period, leaving gaps in audit evidence

Remediation: define investigation SLAs for each alert severity, use a ticketing system for all incidents (even false positives — auditors want to see the triage process), test the IRP at least annually, and configure log retention to exceed the audit observation period.

Risk assessment deficiencies

No formal risk assessment has been conducted, or the most recent assessment is older than 12 months
The risk assessment exists but does not cover all in-scope systems
Risk treatment plans are documented but not tracked to completion
Risk acceptance decisions lack documented rationale and appropriate sign-off

Remediation: conduct a formal security risk assessment before the observation period begins, ensure it covers all systems in the SOC 2 scope, track treatment plans in a project management system with owner and deadline, and document risk acceptance decisions with executive sign-off.

Vendor management gaps

Critical vendors are not inventoried or classified by risk
Vendor security assessments have not been conducted or are outdated
Contracts with data-processing vendors lack security requirements and breach notification clauses
Vendor SOC 2 reports are not collected or reviewed

Remediation: build a vendor inventory with risk classification, conduct security assessments for all vendors that access customer data, update contracts to include security requirements and data processing addenda, and establish an annual vendor review cadence.

Cost and timeline expectations

SOC 2 costs vary significantly based on organizational maturity, scope, and whether the organization builds the program internally or engages external support. The following benchmarks reflect typical ranges for growth-stage technology companies.

Direct costs

GRC platform: $10,000 to $50,000 per year (Vanta, Drata, Secureframe, Sprinto — pricing varies by company size and feature tier)
Readiness assessment: $5,000 to $15,000 if performed by the CPA firm or an external consultant
Type I audit fees: $15,000 to $40,000
Type II audit fees: $25,000 to $80,000 (higher for multiple trust service criteria, complex systems, or Big Four firms)
Penetration testing: $10,000 to $30,000 (not required by SOC 2 but commonly included as supporting evidence and expected by customers)
External consulting: $150 to $350 per hour if engaging a fractional CISO or compliance consultant to build the program

Internal costs

Internal effort is the largest cost component and the most commonly underestimated. For a first SOC 2 engagement:

Policy development: 40 to 80 hours if starting from scratch; 10 to 20 hours if adapting templates
Control implementation: 80 to 200 hours depending on existing maturity (MFA deployment, access review processes, change management formalization)
Evidence collection and organization: 60 to 150 hours for Type II (ongoing throughout the observation period)
Audit coordination: 20 to 40 hours of engineering, security, and IT time responding to auditor requests

Total first-year investment

For a growth-stage SaaS company (50 to 300 employees) pursuing SOC 2 Type II with Security and Availability criteria:

Low end (mature controls, minimal gaps): $50,000 to $75,000 total (GRC platform + audit fees + internal time)
Mid range (some controls exist, moderate gaps): $75,000 to $120,000
High end (limited controls, significant build-out needed): $120,000 to $200,000+

Subsequent years are less expensive — the control framework is established, policies need only updating (not writing), and evidence collection is largely automated. Renewal-year costs typically run 40 to 60 percent of the first-year investment.

Maintaining compliance year-over-year

SOC 2 compliance is not a one-time project. The observation period for each Type II report must follow continuously from the previous one — any gap in coverage raises questions from customers and prospects. Maintaining compliance requires operational discipline across several dimensions.

Continuous monitoring

GRC platform monitors control effectiveness continuously and flags drift before it becomes an audit exception

Access reviews are conducted quarterly with documented evidence of review and remediation

Security awareness training is completed by all employees annually (and within 30 days of hire for new employees)

Vulnerability scans run on a defined cadence (monthly for infrastructure, weekly for critical systems) with remediation SLAs

Vendor security assessments are reviewed and updated annually

Incident response plan is tested through at least one tabletop exercise per year

Policy maintenance

All policies are reviewed and approved annually by the appropriate authority (CISO, CTO, or designated policy owner)

Policy updates reflect changes in the environment: new systems, new regulations, organizational changes

Policy acknowledgment records are maintained — employees confirm they have read and understood applicable policies

Policy exceptions are documented with compensating controls, expiration dates, and management approval

Audit preparation

Evidence collection is ongoing throughout the observation period, not concentrated in the final weeks

A quarterly internal review validates that controls are operating as designed — catching issues before the auditor does

The SOC 2 scope is reviewed annually and updated to reflect new systems, services, or organizational changes

Auditor engagement is renewed 2 to 3 months before the observation period ends to ensure continuous coverage

Previous audit exceptions are tracked to remediation and validated before the next observation period begins

Organizational integration

The most common reason SOC 2 compliance degrades is that it operates as a standalone compliance project rather than an integrated part of how the organization operates. Controls that are embedded in daily workflows — code review before merge, MFA on every login, automated access provisioning through HR systems — sustain themselves. Controls that require manual effort outside normal workflows — quarterly spreadsheet reviews, manual screenshot collection, after-the-fact documentation — degrade between audit cycles.

The long-term goal is compliance as a byproduct of good engineering and security practices, not compliance as a separate workstream. Organizations that achieve this spend less time on audit preparation, produce cleaner reports, and maintain continuous coverage with less internal friction.

Need help building your SOC 2 program?

vCSO.ai helps growth-stage companies build SOC 2 programs that pass audit and integrate with how engineering teams actually work — not compliance theater that falls apart between observation periods. Nick Shevelyov, former Chief Security Officer at Silicon Valley Bank, brings the same control framework discipline used at a $70B financial institution, scaled to fit the pace and resource constraints of growth-stage companies.

Request a consultation to scope your SOC 2 readiness, or explore our Strategic Oversight service — where SOC 2 preparation is one component of an ongoing cybersecurity governance program that includes risk assessment, compliance management, and board-level reporting.

Nick's book on cybersecurity strategy, Cyber War...and Peace, covers the operational security frameworks — including audit readiness, risk assessment, and governance structures — that turn compliance from a periodic project into a continuous organizational discipline.

Questions & answers

What is the difference between SOC 2 Type I and Type II?

SOC 2 Type I evaluates whether your controls are properly designed at a single point in time. Type II evaluates whether those controls operated effectively over a period — typically 3 to 12 months. Type I is faster and cheaper (a snapshot), but Type II is what most enterprise customers and investors require because it demonstrates sustained operational discipline, not just good documentation. Many organizations start with Type I to validate their control design, then move to Type II within 6 to 12 months.

How long does it take to get SOC 2 certified?

SOC 2 is not a certification — it is an attestation. An independent CPA firm issues a SOC 2 report based on their examination. Timeline depends on readiness: if controls are already in place, a Type I report can be completed in 4 to 8 weeks. Type II requires a minimum observation period (typically 3 to 6 months for a first report, 12 months for subsequent reports) plus 4 to 8 weeks for the auditor to complete their examination. Organizations starting from scratch should budget 6 to 12 months total for a Type II report.

How much does a SOC 2 audit cost?

Audit fees from CPA firms typically range from $20,000 to $80,000 depending on scope (number of trust service criteria), company size, system complexity, and whether it is Type I or Type II. GRC platform costs (Vanta, Drata, Secureframe, Sprinto) add $10,000 to $50,000 annually. Internal preparation costs — policy writing, control implementation, evidence collection — represent the largest variable and depend on existing maturity. Total first-year cost for a growth-stage SaaS company typically falls between $50,000 and $150,000.

Which SOC 2 trust service criteria should we include?

Security (the Common Criteria) is mandatory for every SOC 2 report. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and selected based on customer requirements and business context. Most SaaS companies include Security and Availability. Companies handling regulated data (financial, healthcare) typically add Confidentiality. Privacy is relevant if you process personal information as part of your service. Processing Integrity applies when data accuracy and completeness are contractually important (financial calculations, analytics platforms).

Do startups need SOC 2 compliance?

SOC 2 is not legally required, but it is increasingly a market requirement. Enterprise sales teams routinely encounter SOC 2 requests in security questionnaires and vendor assessments starting at Series A or B stage. Delaying SOC 2 does not save money — it defers the work and creates a backlog of control gaps that are more expensive to remediate later. The practical trigger is the first enterprise prospect that requires it, the first investor diligence process that asks for it, or the first customer contract that includes an audit-right clause.

What happens if you fail a SOC 2 audit?

You cannot technically "fail" a SOC 2 audit — the auditor issues a report with their opinion. A clean report has an unqualified opinion, meaning controls are suitably designed (Type I) or operating effectively (Type II). If the auditor identifies control deficiencies, the report includes exceptions — specific controls that were not operating as designed during the observation period. A qualified opinion means material deficiencies were found. The report still gets issued, but sharing a report with exceptions or qualifications with customers and prospects undermines the purpose of the exercise.

Can you do SOC 2 without a GRC platform?

Yes, but it is significantly more labor-intensive. GRC platforms (Vanta, Drata, Secureframe, Sprinto, Tugboat Logic) automate evidence collection, continuous monitoring, and policy management. Without one, you manage evidence manually — screenshots, spreadsheet trackers, manual access reviews — which works for Type I but becomes unsustainable during Type II observation periods where evidence must be collected continuously. Most organizations under 500 employees find that a GRC platform pays for itself in reduced audit preparation time.

How often do you need to renew SOC 2?

SOC 2 reports cover a specific period and do not automatically renew. Type II reports typically cover a 12-month observation period. To maintain continuous coverage, organizations start the next audit cycle before the current report expires — the new observation period begins immediately after the previous one ends. Most companies operate on an annual audit cycle. Gaps in coverage (months where no report exists) raise questions from customers and prospects during security reviews.

Ready to turn this into a working plan?

Nick's team helps growth-stage companies, PE/VC sponsors, and cybersecurity product teams translate security questions into board-ready decisions. First call is strategy, not vendor pitch.

Talk to Nick Explore services →