SOC 2 Trust Services Criteria
Crosswalk to NIST CSF 2.0 · 36 controls · Updated April 2026.
SOC 2 is an AICPA attestation framework organized around five Trust Services Criteria — Security (Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. A SOC 2 Type II report covers the design and operating effectiveness of controls over a 6–12 month period.
About SOC 2
SOC 2 is the most commonly requested third-party attestation from U.S. enterprise buyers. The framework itself is not a control list — it is a set of criteria that the auditor verifies your controls address. Your control set is custom to your environment; the auditor issues a report attesting that the controls operate effectively.
A Type I report attests to control design at a point in time. A Type II report attests to operating effectiveness over a period (usually 6 or 12 months). Type II is what most enterprise buyers request.
SecurityStack crosswalks SOC 2 Trust Services Criteria to NIST CSF 2.0 categories. Organizations pursuing SOC 2 typically also run a NIST CSF assessment internally — the crosswalk below is the bridge between the two.
Primary audience: SaaS vendors, cloud service providers, and any organization whose enterprise customers require third-party attestation of security controls.
Controls by domain
36 controls across 17 groups. Mapping strengths to NIST CSF 2.0 categories are summarized below.
A1/CC6 1 control
| Control ID | Name |
|---|---|
| SOC2-A1.1 | Maintains current processing capacity |
A1/CC9 2 controls
| Control ID | Name |
|---|---|
| SOC2-A1.3 | Recovery infrastructure components |
| SOC2-CC9.1 | Identifies and manages business disruption risks |
CC1 4 controls
| Control ID | Name |
|---|---|
| SOC2-CC1.1 | COSO Principle 1: Commitment to integrity |
| SOC2-CC1.2 | Board oversight of cybersecurity risk |
| SOC2-CC1.3 | Establishes reporting lines and authorities |
| SOC2-CC1.4 | Demonstrates commitment to competence |
CC1/CC2 1 control
| Control ID | Name |
|---|---|
| SOC2-CC2.2 | Internally communicates about control activities |
CC1/CC5 2 controls
| Control ID | Name |
|---|---|
| SOC2-CC1.5 | Enforces accountability through policies |
| SOC2-CC5.2 | Selects and develops control activities |
CC2 - Communication 2 controls
| Control ID | Name |
|---|---|
| SOC2-CC2.1 | CC2.1 Obtains/generates relevant quality information (COSO P13) |
| SOC2-CC2.3 | CC2.3 Communicates with external parties on internal control matters (COSO P15) |
CC3 4 controls
| Control ID | Name |
|---|---|
| SOC2-CC3.1 | Specifies risk appetite |
| SOC2-CC3.2 | Identifies and analyzes risk |
| SOC2-CC3.3 | Evaluates fraud risk |
| SOC2-CC3.4 | Assesses likelihood and impact |
CC4 3 controls
| Control ID | Name |
|---|---|
| SOC2-CC4.1 | Monitors controls through ongoing evaluations |
| SOC2-CC4.2 | Evaluates and communicates deficiencies |
| SOC2-CC5.3 | Deploys control activities |
CC4/CC7 1 control
| Control ID | Name |
|---|---|
| SOC2-CC7.3 | Evaluates and implements remediation |
CC5 - Control Activities 1 control
| Control ID | Name |
|---|---|
| SOC2-CC5.1 | CC5.1 Selects/develops control activities for risk mitigation (COSO P10) |
CC6 3 controls
| Control ID | Name |
|---|---|
| SOC2-CC6.2 | New internal/external users provisioned with least privilege |
| SOC2-CC6.3 | Removes access to protected assets when no longer needed |
| SOC2-CC6.6 | Logical access restricted to authorized users |
CC6 - Logical/Physical Access 3 controls
| Control ID | Name |
|---|---|
| SOC2-CC6.4 | CC6.4 Restricts physical access to facilities/protected assets |
| SOC2-CC6.5 | CC6.5 Discontinues protections when no longer needed |
| SOC2-CC6.8 | CC6.8 Controls against threats from malicious software |
CC6/A1 1 control
| Control ID | Name |
|---|---|
| SOC2-CC6.7 | Restricts transmission, movement, removal of information |
CC6/CC7 1 control
| Control ID | Name |
|---|---|
| SOC2-CC6.1 | Restricts logical access to assets |
CC6/CC7/CC8 1 control
| Control ID | Name |
|---|---|
| SOC2-CC8.1 | Authorizes, designs, develops changes |
CC7 4 controls
| Control ID | Name |
|---|---|
| SOC2-CC7.1 | Detects and monitors threats |
| SOC2-CC7.2 | Evaluates the significance of threats |
| SOC2-CC7.4 | Responds to identified vulnerabilities |
| SOC2-CC7.5 | Identifies and develops remediation activities |
CC9 2 controls
| Control ID | Name |
|---|---|
| SOC2-A1.2 | Environmental protections (for SaaS dependencies) |
| SOC2-CC9.2 | Assesses and manages vendor risk |
Crosswalk density to NIST CSF 2.0
Top 12 NIST CSF categories by number of SOC 2 controls mapped. The distribution tells you where the framework's emphasis sits against NIST's six functions.
| NIST category | Controls mapped |
|---|---|
| PR.IR | 5 |
| PR.AA | 5 |
| PR.DS | 4 |
| RC.RP | 4 |
| GV.RM | 4 |
| GV.RR | 3 |
| GV.PO | 3 |
| RC.CO | 3 |
| ID.RA | 3 |
| RS.MI | 3 |
| AN.TE | 3 |
| DE.CM | 3 |
Frequently asked questions
Type I or Type II?
Type II for most enterprise sales. Type I can be useful as an early milestone while you build the operational history needed for Type II, but enterprise buyers generally treat Type I as a signal of intent rather than a meaningful attestation.
Which Trust Services Criteria should we include?
Security (Common Criteria) is always required. Availability is common for SaaS. Confidentiality is common for anything handling customer data. Processing Integrity is specific to transaction-processing services. Privacy is required when you handle personal information and is often subsumed by GDPR/CCPA compliance conversations.
How does SOC 2 compare to ISO 27001?
SOC 2 is U.S.-centric, attestation-based, flexible on control selection. ISO 27001 is international, certification-based, prescriptive about ISMS structure. Many SaaS companies pursue both. If you only have resources for one, SOC 2 is typically easier to sell to U.S. buyers; ISO 27001 is typically easier to sell internationally.
Next
See your stack against SOC 2
Start a free assessment, select SOC 2 as a required framework, and see which controls your current tools already cover — and which gaps need new investment.