SOC 2 Compliance Guide: Trust Services Criteria, Type 1 vs Type 2, and Readiness

Who needs SOC 2

SOC 2 is designed for service organizations: SaaS vendors, cloud and hosting providers, managed service providers, data processors and other businesses whose systems handle customer data. The AICPA describes SOC reports as giving users "valuable information that is needed to assess and address the risks associated with outsourcing services" (AICPA SOC suite).

It is different from SOC 1. AICPA conference panellists describe SOC 1 as focused on user entities' internal control over financial reporting (ICFR), while SOC 2 takes "a much broader perspective" covering security, availability, processing integrity, confidentiality and privacy (AICPA Insights). If your customers' auditors rely on your system for their financial statements (for example, payroll or billing processing), you may need a SOC 1 as well.

The Trust Services Criteria

The 2017 TSC are built on the 17 principles of the COSO Internal Control — Integrated Framework (2013). ASEC added supplemental criteria for:

• Logical and physical access controls: how access is restricted, provisioned and removed.
• System operations: how deviations, including security incidents, are detected and handled.
• Change management: how changes are identified, authorized and controlled.
• Risk mitigation: how business disruption and vendor and business-partner risks are handled. Criterion CC9.2 covers vendor risk management.

The criteria fall into two groups:

1. Common criteria (CC1–CC9). These cover the control environment, information and communication, risk assessment, monitoring and control activities, plus the supplemental areas above. On their own they are enough for the Security category.
2. Category-specific criteria for Availability, Processing Integrity, Confidentiality and Privacy. When you add one of these, the complete set is the common criteria plus that category's additional criteria.

Each criterion comes with points of focus. These are illustrative characteristics, not a mandatory checklist. Your controls should meet the criterion's intent in your own environment.

The system description

Management also prepares a description of the system. It must follow the 2018 SOC 2 Description Criteria (DC 200, with Revised Implementation Guidance – 2022). The description sets the boundaries of the examination: the services, principal service commitments and system requirements, system components, and subservice organizations. Auditors test against what you describe, so a vague description weakens the whole report.

Type 1 vs Type 2

For a Type 1, "the service auditor is evaluating controls as of a specific date". The AICPA's own discussion of evidence collected after the as-of date shows why the timing of that date matters (AICPA Insights). The AICPA publishes an illustrative SOC 2 Type 2 report that shows the structure: the auditor's opinion, management's assertion, the system description, and the tests of controls with their results.

SOC 3 is a general-use summary built on the same criteria, and you can publish it. SOC 2 reports are restricted to specified users, such as customers and prospects, usually under an NDA.

Process and timeline

1. Scope. Choose the services, systems, locations, subservice organizations (for example, your cloud provider) and the TSC categories.
2. Readiness assessment. Map your existing controls to the criteria and close the gaps.
3. Choose a CPA firm. SOC examinations are attestation engagements under AICPA standards. The AICPA says it will act where auditors "have not performed audits in accordance with professional standards, not been enrolled in peer review, and/or are unlicensed" (AICPA notice).
4. Type 1 (optional) as of a chosen date.
5. Type 2 observation period. Controls must operate, and leave evidence, for the whole period you agree with the auditor.
6. Fieldwork and reporting. The auditor samples evidence, documents exceptions and issues the opinion.
7. Repeat. Most organizations renew every year so the report stays current. Customers often ask for a bridge letter to cover the gap between the end of the period and today.

The AICPA doesn't set a fixed duration or price. Both depend on scope, the number of categories, your control maturity and the firm.

Penalties and consequences

SOC 2 is voluntary, so there are no statutory fines. The consequences come through contracts and the market:

• deals stall during security review
• an opinion with exceptions or qualifications is shared with every customer who reads the report
• you may breach contract clauses that require a current report

Because the report is shared widely, a weak one can do more harm than having none.

Mapping to related frameworks

• COSO 2013: the common criteria follow COSO's 17 principles directly.
• ISO/IEC 27001: both cover risk assessment, access control, change management, incident response and supplier management. ISO certifies a management system, while SOC 2 attests to controls over a period. Many organizations run both off one control set.
• NIST CSF 2.0: CSF outcomes such as GOVERN and PROTECT line up with the common criteria. CSF is a self-applied framework with no attestation.
• HIPAA, GDPR, PCI DSS: a SOC 2 can provide evidence for these, but it does not replace their specific legal or contractual requirements.

Readiness checklist

1. Write down your service commitments: SLAs, security clauses and privacy terms.
2. Pick the TSC categories that match those commitments. Security is always in scope.
3. Draft the system description against DC 200 early.
4. Build a control matrix that maps each control to criteria CC1–CC9 and any additional categories.
5. Assign an owner, a frequency and an evidence type to each control.
6. Inventory your subservice organizations. Decide between the carve-out and inclusive methods, and collect their SOC reports.
7. List the complementary user entity controls (CUECs) your customers must perform.
8. Run access reviews, change-management tickets, vulnerability management and incident drills well before the period starts.
9. Vet the CPA firm: licensing, peer review and SOC experience.
10. Collect evidence continuously during the observation period, not at the end of it.

Common pitfalls

• Treating points of focus as a checklist. They are illustrations, not requirements.
• A scope that doesn't match what you sell. If a product line customers buy isn't covered, the report doesn't answer their question.
• Evidence gaps mid-period. One missed quarterly access review can become an exception in a Type 2.
• Ignoring subservice organizations. Your cloud provider's controls need to be addressed in your report.
• Choosing an auditor on speed or price alone. The AICPA's 2026 pieces on the risks of quick-turn SOC engagements and on SOC tool-provider arrangements warn about "fast and easy" promises.

How AssureCore helps

AssureCore keeps SOC 2 controls, evidence, policies and risks in one workspace. That includes a Controls Register, Evidence Management with expiry alerts and control linking, a Risk Register, and Audit Reports with PDF and CSV exports. Cross-framework Mapping lets you reuse that work for ISO 27001, NIST CSF and the other frameworks AssureCore supports. AssureCore prepares you for an audit; it does not replace the independent CPA examination.

Frequently asked questions

Official references

• AICPA – 2017 Trust Services Criteria (With Revised Points of Focus – 2022)
• AICPA – Trust Services Criteria (red-lined PDF, 2022 points of focus)
• AICPA – 2018 SOC 2 Description Criteria (Revised Implementation Guidance – 2022)
• AICPA – SOC suite of services and 2026 notices
• AICPA – Illustrative Service Auditor's SOC 2 Type 2 Report
• AICPA Insights – Maintaining high standards for SOC engagements

Related frameworks

• ISO 27001 guide
• NIST CSF guide
• HIPAA guide
• CSA STAR guide