SOC 2 Requirements

What are the SOC 2 requirements?

SOC 2 is not a prescriptive checklist like PCI DSS. Instead, it is a principles-based framework built around the AICPA's Trust Services Criteria. That flexibility is powerful, but it also means organizations must interpret the criteria and design controls that fit their specific environment.

At its core, SOC 2 compliance requires that an organization demonstrate it has designed and implemented controls that satisfy the applicable Trust Services Criteria. Security is mandatory for every SOC 2 engagement. The remaining four criteria — availability, processing integrity, confidentiality, and privacy — are selected based on the services the organization provides and the commitments it makes to customers.

The five Trust Services Criteria

Each criterion contains a set of points of focus that auditors use to evaluate whether controls are suitably designed and operating effectively. Below is a summary of what each criterion requires.

1. Security (Common Criteria) — required

Security is the foundation of every SOC 2 report. It addresses whether the system is protected against unauthorized access, both physical and logical. The Common Criteria map closely to the COSO framework and cover nine broad categories:

• CC1 — Control environment: Governance structures, board oversight, organizational accountability, and ethical values.
• CC2 — Communication and information: Internal and external communication about policies, objectives, and responsibilities.
• CC3 — Risk assessment: Identifying and analyzing risks to achieving objectives, including fraud risk.
• CC4 — Monitoring activities: Ongoing evaluations to verify controls are present and functioning.
• CC5 — Control activities: Policies and procedures that mitigate identified risks, including technology general controls.
• CC6 — Logical and physical access: Restrictions on system access, credential management, encryption, and physical security.
• CC7 — System operations: Monitoring infrastructure for anomalies, incident detection, and response procedures.
• CC8 — Change management: Controls over changes to infrastructure, software, and configurations.
• CC9 — Risk mitigation: Identifying, selecting, and developing activities that address risks from business disruptions and vendor relationships.

Most startups find that CC6, CC7, and CC8 demand the most effort because they require tangible technical controls and ongoing evidence.

2. Availability

The availability criterion applies when the organization has made commitments about system uptime or disaster recovery. Requirements include:

• Defined and communicated availability commitments (SLAs, status pages)
• Capacity planning and performance monitoring
• Disaster recovery and business continuity plans that are tested regularly
• Incident response procedures for availability-impacting events
• Backup and restoration processes with documented recovery point and recovery time objectives

If your product has an SLA in customer contracts, availability is almost certainly in scope.

3. Processing integrity

Processing integrity focuses on whether the system processes data completely, accurately, and in a timely manner. This is relevant for platforms that perform calculations, transactions, or data transformations. Requirements include:

• Input validation and error handling
• Processing monitoring and reconciliation
• Output reviews and quality assurance
• Defined processing objectives and tolerances
• Procedures for handling processing errors and exceptions

Fintech companies, data pipelines, and billing platforms commonly include this criterion.

4. Confidentiality

Confidentiality applies to information designated as confidential, such as intellectual property, business plans, or data shared under NDA. Requirements include:

• Classification and labeling of confidential information
• Access restrictions aligned to classification
• Encryption in transit and at rest for confidential data
• Secure disposal procedures when confidentiality obligations expire
• Monitoring for unauthorized disclosure

Many organizations choose confidentiality in addition to security because customer contracts explicitly reference confidential data handling.

5. Privacy

Privacy addresses personal information collected, used, retained, disclosed, and disposed of in accordance with the organization's privacy notice. It is closely aligned with regulations like GDPR and CCPA. Requirements include:

• A published privacy notice that describes data practices
• Consent mechanisms and choice management
• Data minimization and purpose limitation
• Subject access, correction, and deletion processes
• Breach notification procedures

If your organization processes personal data and has a public privacy policy, auditors will evaluate whether your practices match your stated commitments.

Common controls that satisfy SOC 2 requirements

While every organization's control set is different, certain controls appear in nearly every SOC 2 environment:

The key is not just having these controls in place but being able to demonstrate they are operating consistently. That evidence collection burden is where most teams struggle, especially during a SOC 2 Type II audit that examines an extended observation period.

Scoping your SOC 2 requirements

Before you start building controls, define your scope carefully:

1. Identify in-scope systems — which applications, infrastructure, and third-party services touch customer data.
2. Select Trust Services Criteria — start with security and add criteria that align with customer commitments and contractual obligations.
3. Map existing controls — many organizations already satisfy 40-60% of SOC 2 requirements through existing security practices.
4. Perform a gap analysis — compare current state against the Trust Services Criteria to identify missing or immature controls.
5. Prioritize remediation — address high-risk gaps first, then work through lower-priority items before the audit begins.

A well-scoped audit reduces cost and avoids scope creep that delays the timeline.

Common mistakes

• Over-scoping: Including systems or criteria that are not relevant increases evidence requirements and audit complexity.
• Under-documenting: Controls exist but lack written policies, procedures, or evidence. Auditors need proof, not assertions.
• Ignoring the human element: Technical controls are important, but GRC programs also require training, awareness, and accountability.
• Treating SOC 2 as a one-time project: SOC 2 is an ongoing commitment. Controls must operate continuously, not just during audit prep.

How episki helps

episki maps every Trust Services Criteria point of focus to actionable controls with suggested narratives, testing procedures, and evidence requirements. Instead of building your control matrix in a spreadsheet, you get a structured workspace where controls are linked to owners, evidence, and review cadences from day one. Pre-loaded templates cover the most common control patterns, and the platform highlights gaps so you know exactly what needs attention before your auditor arrives. Compare episki to Vanta or start a free trial to see the full SOC 2 control library.