SOC 2 Requirements: What's Mandatory and What's Optional

This page maps what SOC 2 requires and sends you to the guide for each requirement area. Some buyers write the report name as SOC II. It is the same examination.

Lists titled “SOC 2 requirements” often mix three different things: criteria the AICPA publishes, example controls that vendors suggest, and habits individual auditors bring. We keep them apart below. For the criteria one by one, use the Trust Services Criteria guide. For example controls and the evidence behind them, use the SOC 2 controls list. For the order of work, use the compliance checklist. This page answers a narrower question: what does SOC 2 require of your company, and where do you go for each part?

What SOC 2 requires at a glance

A customer can ask for more than the AICPA does. A contract may name Type 2, a particular category, or a period length. Those are buyer requirements, and they sit on top of this table. The criteria come from the AICPA’s 2017 Trust Services Criteria with revised points of focus (2022), which the AICPA currently publishes. The 2022 revision changed points of focus, not the criteria, as Schellman’s summary of the revision describes.

The mandatory part: Common Criteria CC1–CC9

Every SOC 2 report is evaluated against the Common Criteria, and in practice that is the Security category. The Common Criteria are also part of the criteria set for the other four categories, so adding Availability or Privacy adds criteria and replaces none. The AICPA text says the Common Criteria are enough to evaluate Security on their own.

CC1 to CC5 line up one-to-one with the 17 principles of the COSO internal control framework. That is why a Security-only audit tests governance, risk assessment, and monitoring as well as technical settings. CC6 to CC9 add criteria for logical and physical access, system operations, change management, and risk mitigation, including vendors. Our common criteria guide walks through CC1 to CC5 and the COSO structure, and the Trust Services Criteria guide maps every series.

The optional part: four categories

Add a category when customers rely on what it covers:

• Availability (A1, 3 criteria), when you commit to an uptime, capacity, or recovery target.
• Processing Integrity (PI1, 5 criteria), when the accuracy of your processing is the product, as with payments, billing, or calculations.
• Confidentiality (C1, 2 criteria), when contracts require you to protect and dispose of designated business information.
• Privacy (P1–P8, 18 criteria), when you collect and handle personal information and a buyer needs assurance over it in the report.

A category is the unit of scope. The AICPA text says that for each category in the engagement, all of its criteria are usually addressed. A criterion drops out only when it does not apply to the service. The AICPA’s own example is P3.1 for a service that does not collect personal information directly from the people it concerns. Together the four add 28 criteria to the 33 Common Criteria, for 61 in all. Privacy is the largest addition, and each category you add means more criteria to test and more evidence to keep.

Start from your customer contracts and security questionnaires. The Trust Services Criteria guide has a decision table by customer promise, and the scope determination guide covers the system boundary that comes first.

What SOC 2 does not require

• SOC 2 has no fixed list of controls. CC6.1, for example, asks that you implement logical access security over protected information assets. It does not name a product or a setting.
• No criterion names multi-factor authentication or penetration testing, and encryption appears only in points of focus. Auditors still ask how you meet the outcome, and for these three the usual answer is the control itself. The guides below cover each one.
• You do not have to address every point of focus. They are examples, and management can adapt them or use other characteristics that fit the system.
• No frequency is fixed. A cadence such as quarterly access reviews usually comes from your own policy, and the auditor then tests whether you followed it.
• There is no SOC 2 certificate. The result is an attestation report with an opinion.
• No law requires SOC 2. It is a voluntary standard, and customers ask for it in security reviews and contracts.

What the audit requires from you

The criteria are the yardstick. The engagement around them asks for four things from management and one qualified examiner.

A system description. It sets the boundary of the report: the services, infrastructure, software, people, procedures, data, subservice organizations, and customer commitments in scope. The AICPA’s description criteria govern it and do not set a format. If a production workflow that handles customer data is missing from the description, that is a scope problem before any testing starts.

A management assertion. Under the AICPA’s attestation standard, AT-C section 205, the service auditor asks management for a written assertion and written representations. Our management assertion letter guide covers what it says and who signs it.

Policies and procedures that put controls into action. CC5.3 expects control activities deployed through policies that set expectations and procedures that carry them out. A policy that staff do not follow is likely to surface as an exception.

Evidence. A Type 1 report gives the auditor’s opinion on whether controls were suitably designed as of a date. A Type 2 report adds whether they operated effectively throughout a period, so the auditor tests dated records from across that period and the records must exist from its first day. The AICPA sets no universal minimum for the period. You agree it with your auditor, and our observation period guide covers the planning windows. The Type 1 vs Type 2 guide covers which to choose.

A licensed CPA firm. The report is the auditor’s opinion, so a CPA firm that is independent of your company has to perform the examination. The SOC 2 auditor requirements guide covers what that means when you choose a firm.

An AICPA illustrative Type 2 report contains management’s assertion, the system description, and the service auditor’s report with tests of controls and results, as the AICPA’s illustrative report shows. Buyers read the opinion and any listed exceptions. Our SOC 2 audit report guide explains how.

Where to go for each requirement area

Each row names the criteria the area maps to, what an auditor may sample, and the guide that covers it. The sampling column is an example from our guides, not an AICPA list. Your auditor sets the actual requests.

If your question is about the engagement rather than a requirement area, start here:

Common questions

Do SOC 2 requirements differ by company size?

The criteria do not change with size. The controls that meet them do, which is why a ten-person team and a large company can both earn a clean report with very different control sets.

Do the requirements change by the type of data we handle?

The Common Criteria stay the same. Data type changes which optional categories you consider: personal information points to Privacy, designated business information points to Confidentiality, and processing that customers rely on for accuracy points to Processing Integrity. A SOC 2 report also does not by itself show compliance with a law such as HIPAA, which has its own requirements.

What do the requirements mean for engineering?

Much of the work that lands on engineering sits in three groups of criteria. CC6 covers access and data protection, CC7 covers monitoring and incident response, and CC8.1 covers changes to production. In practice that means enforced MFA, logged and reviewed alerts, and pull requests with an independent approver. Start with the MFA, incident response, and change management guides.

For the whole path from scoping to an issued report, see the SOC 2 compliance guide. To compare firms by scope, pricing, and timeline, start with the SOC 2 auditor directory.