SOC 2 has become the de facto compliance standard for technology companies, SaaS providers, and any organization that stores or processes customer data in the cloud. Developed by the American Institute of Certified Public Accountants (AICPA), SOC 2 evaluates an organization’s controls based on five Trust Services Criteria. Unlike prescriptive frameworks that specify exactly which technologies to deploy, SOC 2 is criteria-based — it defines what your controls must achieve, but leaves the implementation details to you. That flexibility is both its strength and its primary source of confusion for organizations preparing for their first audit.

Type I vs. Type II: Understanding the Difference

Before diving into the criteria, it is important to understand the two types of SOC 2 reports, as this choice shapes your entire preparation timeline.

SOC 2 Type I evaluates the design of your controls at a specific point in time. The auditor examines whether your controls are suitably designed to meet the applicable Trust Services Criteria as of the report date. This is essentially a snapshot assessment. Type I reports are often used as a stepping stone — they demonstrate that you have built the right controls, even if you have not yet demonstrated their operational effectiveness over time.

SOC 2 Type II evaluates both the design and operating effectiveness of your controls over a defined period, typically six to twelve months. The auditor tests whether controls not only exist but actually function as intended throughout the observation window. Type II reports carry significantly more weight with customers and prospects because they provide evidence of sustained compliance, not just good intentions.

Most organizations start with a Type I to validate their control design, then transition to Type II within six to twelve months. Some choose to skip directly to Type II if their controls are already mature, but this carries more risk if gaps are discovered during the observation period.

The Five Trust Services Criteria

1. Security (Common Criteria — Required)

Security is the only mandatory category in SOC 2. It is also referred to as the Common Criteria because its requirements apply across all SOC 2 engagements. The Security criteria address protection of information and systems against unauthorized access, both physical and logical.

Key control areas to address:

  • CC1 — Control environment: Organizational commitment to integrity and ethical values, board oversight, organizational structure, and accountability. This includes policies, code of conduct, and tone from leadership.
  • CC2 — Communication and information: Internal and external communication processes, including how security policies are communicated to employees and how relevant information reaches decision-makers.
  • CC3 — Risk assessment: Formal risk assessment processes that identify and evaluate threats to the achievement of objectives. This must include consideration of fraud risk and changes in the business environment.
  • CC4 — Monitoring activities: Ongoing and periodic evaluations of control effectiveness, including how deficiencies are identified and communicated for remediation.
  • CC5 — Control activities: The specific policies and procedures that enforce management directives. This covers technology general controls, logical access, change management, and operational controls.
  • CC6 — Logical and physical access: Access control policies, user provisioning and deprovisioning, authentication mechanisms (including multi-factor authentication), physical facility security, and encryption of data at rest and in transit.
  • CC7 — System operations: Monitoring infrastructure, detecting anomalies, incident detection and response, and managing vulnerabilities.
  • CC8 — Change management: Processes for authorizing, testing, approving, and implementing changes to infrastructure, software, and configurations.
  • CC9 — Risk mitigation: Processes for selecting and implementing risk mitigation activities, including vendor management and business continuity planning.

2. Availability

The Availability criteria evaluate whether systems are operational and accessible as committed in service-level agreements (SLAs) or contracts. This is relevant for organizations whose customers depend on uptime guarantees.

Checklist items:

  • Documented SLAs with defined uptime targets and measurement methods
  • Capacity planning and performance monitoring processes
  • Disaster recovery and business continuity plans, tested at least annually
  • Redundant infrastructure for critical systems (failover, load balancing, geographic distribution)
  • Incident response procedures for availability-impacting events
  • Backup procedures with defined recovery time objectives (RTO) and recovery point objectives (RPO)
  • Environmental controls (power, cooling, fire suppression) for on-premises infrastructure

3. Processing Integrity

Processing Integrity addresses whether system processing is complete, accurate, timely, and authorized. This criteria matters most for organizations that perform data processing, financial calculations, or automated decision-making on behalf of customers.

Checklist items:

  • Input validation controls to verify data completeness and accuracy at system boundaries
  • Processing monitoring to detect errors, exceptions, and anomalies during execution
  • Output reconciliation procedures to confirm that results match expected outcomes
  • Error handling and correction procedures with defined escalation paths
  • Quality assurance processes for data transformations and calculations
  • Audit trails that track data through processing stages

4. Confidentiality

Confidentiality criteria evaluate how the organization protects information designated as confidential. This goes beyond personal information (which falls under Privacy) to include business-sensitive data such as intellectual property, financial data, trade secrets, and any other information classified as confidential by contract or policy.

Checklist items:

  • Data classification scheme that defines what constitutes confidential information
  • Encryption for confidential data at rest and in transit
  • Access controls restricting confidential data to authorized personnel based on need-to-know
  • Secure disposal procedures for confidential information and media
  • Confidentiality agreements (NDAs) with employees, contractors, and third parties
  • Data loss prevention (DLP) controls to detect and prevent unauthorized exfiltration
  • Retention and deletion policies aligned with contractual and regulatory requirements

5. Privacy

The Privacy criteria apply when the organization collects, uses, retains, discloses, or disposes of personal information. These criteria align with generally accepted privacy principles and overlap significantly with regulations like GDPR and CCPA.

Checklist items:

  • Published privacy notice that describes data collection, use, and sharing practices
  • Consent mechanisms where required by applicable law
  • Processes for individuals to access, correct, or delete their personal information
  • Data minimization practices — collecting only what is necessary for stated purposes
  • Third-party data sharing agreements with privacy protections
  • Breach notification procedures that meet applicable legal requirements
  • Privacy impact assessments for new products, features, or processing activities

Quick-Reference SOC 2 Checklist

Security (Common Criteria)

  • Logical and physical access controls documented and enforced
  • Change management process with approval workflows
  • Risk assessment completed and documented
  • Incident response plan tested within the last 12 months
  • System monitoring and alerting configured
  • Vulnerability management program with regular scanning

Availability

  • Uptime SLAs defined and monitored
  • Disaster recovery plan documented and tested
  • Capacity planning and performance monitoring in place
  • Backup procedures with verified restore capability

Processing Integrity

  • Data processing procedures documented
  • Input validation and error handling implemented
  • Quality assurance and reconciliation controls active

Confidentiality

  • Data classification policy defined and applied
  • Encryption at rest and in transit for confidential data
  • Retention and disposal procedures documented

Privacy

  • Privacy notice published and accessible
  • Consent mechanisms documented for data collection
  • Data subject request process defined and tested
  • Third-party data sharing agreements reviewed

Common Pitfalls in SOC 2 Preparation

Underestimating the evidence burden. SOC 2 Type II auditors need to see evidence that controls operated effectively throughout the observation period. Policies alone are insufficient — you need logs, screenshots, tickets, approval records, and other artifacts that demonstrate controls were actually followed. Start collecting evidence from day one of your observation period.

Scoping too broadly. Including all five Trust Services Criteria in your first SOC 2 increases cost, complexity, and the likelihood of findings. Most organizations start with Security (which is required) plus one or two additional criteria that align with customer expectations. Expand scope in subsequent years as your program matures.

Treating SOC 2 as a point-in-time project. Organizations that scramble to build controls before an audit and then relax afterward will struggle with Type II. Controls must be operational and consistently followed throughout the observation window. Build sustainable processes from the start.

Neglecting vendor management. Your SOC 2 scope extends to critical vendors and subservice organizations. If you rely on AWS for infrastructure and a third-party payment processor, auditors will ask how you evaluate and monitor those vendors. Ensure you have a vendor management program that includes periodic review of their SOC 2 reports or equivalent assurance. Organizations with complex vendor networks should also review our third-party risk management guide.

Ignoring the gap assessment. Conducting a readiness assessment before committing to an audit engagement saves time and money. A readiness assessment identifies gaps while there is still time to remediate them, rather than discovering issues during the formal audit. For a timeline-based preparation approach, see our audit readiness checklist.

Mapping SOC 2 to Other Frameworks with SCF

Organizations subject to SOC 2 rarely operate under a single compliance mandate. The same company may face ISO 27001 requirements from international customers, HIPAA obligations for healthcare data, and GDPR requirements for European users. Managing each framework in isolation creates duplicated effort and inconsistent control implementation.

The Secure Controls Framework provides cross-framework mappings that link SOC 2’s Trust Services Criteria to equivalent requirements in over 200 other standards. SCF Connect surfaces these mappings in a practical way: implement a control once in SCF Connect, and the platform tracks its applicability across every mapped framework. Evidence collected for SOC 2 automatically satisfies corresponding requirements in ISO 27001, NIST 800-53, HIPAA, and others.

This approach is particularly valuable for organizations that have already achieved SOC 2 compliance and need to expand into additional frameworks. Rather than starting from scratch, SCF Connect shows you which controls are already satisfied and where incremental work is needed.

How SCF Connect Streamlines SOC 2 Preparation

SCF Connect provides specific capabilities that reduce the effort and uncertainty of SOC 2 preparation:

  • Trust Services Criteria mapping: Every SOC 2 criterion is mapped to SCF controls with clear implementation guidance, so you know exactly what is expected for each requirement.
  • Evidence management: Attach policies, configurations, screenshots, and other artifacts directly to controls. When audit time arrives, your evidence package is already organized by criteria.
  • Gap analysis dashboards: Visualize your readiness across all selected Trust Services Criteria, identify unaddressed requirements, and prioritize remediation based on risk.
  • Cross-framework efficiency: Organizations managing SOC 2 alongside NIST CSF, CMMC, or GDPR can leverage shared controls rather than maintaining parallel compliance programs.

The difference between a smooth SOC 2 audit and a painful one usually comes down to preparation. Organizations that maintain continuous compliance posture — rather than scrambling before each audit cycle — consistently achieve cleaner reports with fewer exceptions.

Start your free trial to see how SCF Connect maps your existing controls to SOC 2 Trust Services Criteria and identifies exactly where you stand.

Frequently Asked Questions

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

A SOC 2 Type I report evaluates the design of controls at a single point in time. A Type II report evaluates both the design and operating effectiveness of controls over a period of time, typically 6-12 months. Type II reports carry more weight with customers and partners because they demonstrate sustained compliance.

How long does it take to get SOC 2 certified?

SOC 2 readiness typically takes 3-6 months for organizations starting from scratch. After the readiness period, a Type I audit takes 1-2 months, while a Type II audit requires a 3-12 month observation window plus 1-2 months for the audit itself. Using a common control framework can accelerate the process.

Which Trust Services Criteria are required for SOC 2?

Only the Security criterion (Common Criteria) is required for every SOC 2 report. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are optional and selected based on the services you provide and customer expectations.

How much does a SOC 2 audit cost?

SOC 2 audit costs typically range from $20,000-$100,000+ depending on scope, organization size, and whether it is Type I or Type II. Additional costs include readiness preparation, tooling, and remediation. Organizations managing multiple frameworks simultaneously can reduce total compliance costs through shared controls.

Related resources: