SOC 2 Guide

What is SOC 2, and what does a startup actually need to prove?

SOC 2 is less about checking a box and more about showing that your controls are designed well, operating consistently, and backed by evidence customers and auditors can trust.

Book an appointment Read the FAQ

Fast answer

SOC 2 is an audit framework for service organizations that need to show they handle customer data with the right controls.

For most software companies, SOC 2 becomes important when customers ask how access is managed, how systems are monitored, how incidents are handled, and whether the company can prove those controls operate in practice instead of just existing on paper.

The real work is not memorizing acronyms. It is defining scope, mapping controls to the right criteria, collecting evidence continuously, and making sure someone owns every gap before audit week turns reactive.

Why people ask for it

Enterprise buyers want assurance before sharing sensitive data.
Security reviews move faster when controls and evidence are already organized.
Upmarket sales often stall when a company cannot show operational maturity.

What SOC 2 stands for

SOC 2 stands for Systems and Organization Controls 2. In practice, teams usually use “SOC 2” to mean both the framework and the audit report that results from an independent assessment of their controls.

Who usually needs it

Any service organization that stores, processes, or transmits customer data may get asked for SOC 2. For startup teams, the trigger is often a prospect, procurement review, or larger customer asking for security assurance before a deal can move forward.

Trust Services Criteria

Every SOC 2 report includes Security. The other criteria depend on what your product does and what your customers handle.

Common Criteria

Security

The mandatory foundation for every SOC 2 report. It verifies that your systems and data are protected from unauthorized access and disclosure.

Key Requirements & Controls

Logical access controls
Implementing IAM, MFA, and SSO across all production environments
System monitoring
Continuous logging, intrusion detection, and active vulnerability management
Incident response
Formal recovery procedures tested through recurring tabletop exercises
Change management
Rigid code review protocols and automated deployment gates

Uptime and Resilience

Availability

Focuses on whether systems are available for operation and use as committed or agreed upon in SLAs.

Key Requirements & Controls

Data redundancy
Multi-region or availability zone coverage for critical data persistence
Disaster Recovery
Documented BCP and DR plans with measured Recovery Time Objectives
Capacity planning
Automated scaling and performance monitoring to prevent service degradation
Backup integrity
Regularly tested restoration procedures for all customer-facing databases

Data Classification

Confidentiality

Ensures that sensitive information is classified and protected from disclosure throughout its lifecycle.

Key Requirements & Controls

Encryption standards
AES-256 for data at rest and TLS 1.3 for data in transit
Secure disposal
Automated data destruction policies that match retention requirements
Classification
Systematic grouping of sensitive data based on risk and regulatory impact
Access reviews
Granular permission oversight for any personnel touching sensitive info

Accuracy and Completion

Processing Integrity

Relevant for systems that perform high-volume or critical transactions. It proves that processing is authorized, accurate, and on time.

Key Requirements & Controls

Input validation
Rigid API schema checks to prevent data corruption at the source
Error reconciliation
Automated workflows that detect and flag processing exceptions
System processing
Strict adherence to published SLAs for transaction speed and accuracy
Data integrity
Hash-based verification or checksums for large scale data movements

Personal Data (PII)

Privacy

Covers the collection, use, retention, and disclosure of personal information according to established privacy commitments.

Key Requirements & Controls

Consent management
Transparent flows for data collection and third-party sharing preferences
Subject Access Requests
Documented workflows for DSAR fulfillment within regulatory timelines
Data minimization
Rigid procedures ensuring only necessary PII is processed or stored
Privacy by design
Security reviews for every new feature involving personal data

Report Archetypes

Report
Archetypes

Choosing between Type I and Type II determines how you prove operational maturity to your customers.

Design Assessment

Type I: Point-in-time

"Are the controls designed correctly today?"

Evaluates the design of your controls on a specific date. This is the fastest route to a report, but offers no proof of long-term operational consistency.

Audit duration: 2–4 weeks
Focus: Structural integrity

Operational History

Type II: Over duration

"Did the controls operate correctly over time?"

The enterprise standard. Proves that your controls operated effectively over a duration, typically measuring 3, 6, or 12 months of operational data.

Observation: 3–12 months
Focus: Compliance consistency

Readiness Framework

Readiness
Framework

Readiness is not an exercise in policy drafting. It is the tactical work of building an operating system that your team can actually follow.

Policies and governance

Documented policies and procedures that match how the company actually operates.

Focus on operational follow-through and verifiable evidence.
Clear ownership, review cadence, approvals, and control accountability.

Focus on operational follow-through and verifiable evidence.
Risk assessment and follow-through

Contrast: one-time policy drafting.

Access and identity

Least-privilege access for infrastructure, code, and business systems.

Focus on operational follow-through and verifiable evidence.
Joiner, mover, and leaver workflows with reviewable access changes.

Focus on operational follow-through and verifiable evidence.
MFA and periodic access reviews for privileged systems.

Focus on operational follow-through and verifiable evidence.

Engineering and operations

Change management for production systems and critical code paths.

Focus on operational follow-through and verifiable evidence.
Logging, monitoring, incident response, and remediation follow-up.

Focus on operational follow-through and verifiable evidence.
Recurring checks that prevent silent control drift over time.

Focus on operational follow-through and verifiable evidence.

Vendors and trust surface

Vendor review for providers that touch production systems or customer data.

Focus on operational follow-through and verifiable evidence.
Current contracts, risk records, and third-party access awareness.

Focus on operational follow-through and verifiable evidence.
Trust basics like security information, policies, and supportable documentation.

Focus on operational follow-through and verifiable evidence.

Timeline

The Roadmap to Audit

Most teams feel the pressure when they wait until audit window starts and then reconstruct months of operational history.

Most teams move through the same phases: define scope, choose criteria, map controls, close obvious gaps, collect baseline evidence, then maintain the operating rhythm needed for audit.

The painful version happens when the company waits until a customer asks for proof and then tries to reconstruct months of settings, approvals, reviews, and screenshots under pressure.

Evidence Teams Usually Need

Policies, standards, diagrams, vendor inventories, and control descriptions.
Access review records, onboarding and offboarding proof, and approval history.
System settings, screenshots, exports, tickets, and pull requests showing controls in action.
Incident handling records, remediation tasks, and evidence that exceptions were resolved.

Where teams usually break down

What actually creates the scramble

Most audit pain is not caused by one missing policy. It comes from operational details that nobody cleaned up early enough.

01

Scope is still fuzzy when the auditor starts asking questions.

Teams are still figuring out which vendors, environments, and internal systems belong in the audit, so every answer turns into a re-scoping exercise.
02

Controls exist, but proof is scattered across screenshots, tickets, and memory.

The team knows the right settings are in place, but proving that quickly means digging through old exports, Slack threads, and one-off documents under pressure.
03

Gaps are known, but nobody owns the close-out work.

Access reviews, vendor follow-ups, and remediation tasks sit in separate tools, so issues stay “known” instead of becoming finished before the audit window tightens.

Where Liance fits

Turn SOC 2 from a scramble into calm operations

The goal is not to replace the auditor. It is to keep controls, proof, ownership, and remediation moving in one place so readiness does not drift between customer reviews, audits, and renewal cycles.

Need help turning SOC 2 requirements into an actual operating system?

We can walk through your scope, controls, evidence workflow, and where startup teams usually lose time before an audit.

Book an appointment Read common questions