SOC 2 Type II
20 requirements

SOC 2 Type II Requirements: Complete Guide to Trust Services Criteria

SOC 2 Type II is built on five Trust Services Criteria (TSC) defined by the AICPA. The Security criteria (also called Common Criteria or CC) is mandatory for every SOC 2 audit, while Availability, Processing Integrity, Confidentiality, and Privacy are optional based on your services. This guide breaks down the key requirements across all five categories with plain-English explanations and links to the policies you need.

Security (Common Criteria) — Required

The Security criteria is mandatory for all SOC 2 engagements. It covers the foundational controls that protect information and systems from unauthorized access, disclosure, and damage.

CC1.1

COSO Principle 1: Demonstrates Commitment to Integrity and Ethical Values

Your organization must have a code of conduct and demonstrate that leadership takes ethics and integrity seriously. This means documented values, background checks, and disciplinary procedures.

CC1.2

COSO Principle 2: Board Independence and Oversight

Your board or oversight body must exercise independent oversight over internal controls. For startups without formal boards, this means having leadership review and approve security policies regularly.

CC5.1

Control Activities: Risk Mitigation

You must define and perform control activities to mitigate risks to acceptable levels. This means having documented procedures for how you handle identified risks, including technology controls.

CC6.1

Logical and Physical Access Controls

You must implement controls to restrict logical and physical access to your systems. This includes authentication mechanisms, role-based access, and physical security for offices and data centers.

CC6.2

Access Provisioning Based on Authorization

New user accounts and access must be provisioned based on documented authorization. You need a process for granting, modifying, and revoking access based on job roles and the principle of least privilege.

CC6.3

Role-Based Access and Least Privilege

Access to systems must be granted based on roles and follow the principle of least privilege. Users should only have access to the systems and data they need for their job function.

CC6.6

System Boundary Protection

You must protect system boundaries using firewalls, intrusion detection, and network segmentation. Traffic entering and leaving your environment must be monitored and controlled.

CC6.7

Transmission and Movement of Data

Data in transit must be encrypted and protected. This applies to all data transfers whether over the internet, between internal systems, or to third parties.

CC7.1

Detection of Configuration Changes and Vulnerabilities

You must have monitoring in place to detect unauthorized changes to configurations and identify new vulnerabilities. This includes vulnerability scanning, configuration monitoring, and intrusion detection.

CC7.2

Monitoring for Anomalies and Security Events

You must monitor your systems for anomalies and security events that could indicate a breach or attack. This includes log collection, alerting, and regular review of security events.

CC7.3

Evaluation of Security Events

When a security event is detected, you must evaluate whether it constitutes a security incident. There must be a defined process for triaging, classifying, and escalating security events.

CC7.4

Incident Response and Remediation

You must have a documented incident response plan that includes containment, eradication, recovery, and post-incident review. The plan must be tested regularly.

CC8.1

Change Management

All changes to infrastructure, software, and configurations must follow a documented change management process. This includes testing, approval, and rollback procedures.

CC9.1

Risk Mitigation Through Business Continuity

You must identify, assess, and mitigate risks that could affect business continuity. This includes business continuity planning, disaster recovery, and testing of recovery procedures.

CC9.2

Vendor and Third-Party Risk Management

You must assess and manage risks associated with third-party vendors. This includes evaluating vendor security practices, contractual requirements, and ongoing monitoring.

Availability

The Availability criteria addresses whether your systems are available for operation and use as committed. This is relevant for SaaS companies with uptime SLAs.

A1.1

Capacity Planning and Performance Monitoring

You must monitor system capacity and performance to ensure availability meets commitments. This includes planning for growth, setting thresholds, and responding to capacity issues before they cause outages.

A1.2

Recovery and Business Continuity

You must have tested disaster recovery and business continuity plans that allow you to restore systems within committed timeframes. Backup and recovery procedures must be documented and tested regularly.

Confidentiality

The Confidentiality criteria addresses how you protect information designated as confidential. This applies to companies handling proprietary data, trade secrets, or confidential customer data.

C1.1

Identification and Classification of Confidential Information

You must identify and classify confidential information. A data classification policy should define what counts as confidential, how it is labeled, and who can access it.

C1.2

Disposal of Confidential Information

Confidential information must be disposed of securely when no longer needed. This includes policies for data retention periods and secure deletion procedures.

Privacy

The Privacy criteria addresses how personal information is collected, used, retained, disclosed, and disposed of. This is relevant for companies handling personal data.

P1.1

Privacy Notice and Consent

You must provide clear privacy notices to data subjects and obtain consent where required. The notice must explain what data is collected, how it is used, and how individuals can exercise their rights.

Frequently Asked Questions

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

SOC 2 Type I evaluates the design of your controls at a single point in time. Type II evaluates both the design and operating effectiveness of your controls over a period (typically 3-12 months). Type II is considered more rigorous and is what most customers request.

Is SOC 2 Security criteria mandatory?

Yes. The Security criteria (Common Criteria) is mandatory for all SOC 2 engagements. The other four criteria — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and selected based on your services and customer requirements.

How many controls are in SOC 2?

SOC 2 does not prescribe a specific number of controls. Instead, it defines criteria that you must meet. Most organizations implement 80-120 controls depending on which Trust Services Criteria they include. The Common Criteria alone typically requires 60-80 controls.

How long does it take to prepare for SOC 2 Type II?

Most organizations need 3-6 months to prepare for their first SOC 2 Type II audit. This includes implementing controls, documenting policies, and building an evidence trail. Using PoliWriter to generate your policy suite can reduce the documentation portion from weeks to hours.

Do I need all five Trust Services Criteria?

No. Only Security (Common Criteria) is required. You should include additional criteria based on what is relevant to your services. Most SaaS companies include Security and Availability. Companies handling sensitive data often add Confidentiality and Privacy.

What policies do I need for SOC 2?

At minimum, you need policies covering information security, access control, change management, incident response, risk assessment, vendor management, business continuity, disaster recovery, data classification, and acceptable use. PoliWriter generates all of these customized to your organization.

Generate SOC 2 Type II policies automatically

PoliWriter creates all the policies you need to satisfy SOC 2 Type II requirements, customized to your organization. AI-powered, audit-ready, hours not months.

Get Started Free