If you’re pursuing a SOC 2 report, the fastest way to reduce confusion (and audit churn) is to understand what auditors actually test: soc 2 controls and criteria. SOC 2 is built on the AICPA Trust Services Criteria (TSC). Your organization designs controls (policies + processes + technical safeguards), and the auditor evaluates whether those controls are suitably designed (Type 1) and operating effectively over time (Type 2).
SOC 2 “criteria” vs “controls” (the difference that matters)
- Criteria are the what: the TSC requirements you must address (e.g., access control, change management, incident response, monitoring).
- Controls are the how: your specific mechanisms that satisfy the criteria (e.g., SSO + MFA enforcement, quarterly access reviews, CI/CD approvals, EDR coverage, SIEM alerting, IR runbooks).
So when someone says “we need SOC 2,” what they actually need is a defensible mapping between soc 2 controls and criteria and the evidence that proves those controls run consistently.
The Trust Services Criteria you’ll see most often
Most organizations start with Security (Common Criteria). Then, depending on customer and data needs, they add:
- Availability (uptime commitments, resilience, DR testing)
- Confidentiality (classification, encryption, data handling restrictions)
- Processing Integrity (accuracy/validity of processing—common for fintech/data platforms)
- Privacy (collection, use, retention, disclosure—often overlaps with privacy programs)
What auditors actually test (and why teams fail)
Auditors don’t just read policies; they test operational behavior. Common examples:
- Logical access: proof that MFA is enforced, privileged access is restricted, and access reviews are completed on schedule.
- Change management: evidence that production changes are approved, tracked, and can be tied to tickets/PRs (including emergency changes).
- Logging and monitoring: proof that logs exist, are protected from tampering, and alerts are triaged with documented outcomes.
- Incident response: proof of IR plan, training, and at least one tabletop or incident record showing execution.
- Vendor risk: proof you assess critical vendors and maintain a process for vendor security changes/incidents.
A strong approach is to build a control “chain” per criterion: Policy → Procedure → Technical Enforcement → Evidence. That structure makes soc 2 controls and criteria easy to explain to leadership, customers, and auditors.
Practical implementation tip: treat evidence as a product
Create a single evidence repository organized by control ID, with:
- Owner, frequency (daily/weekly/quarterly), and system of record
- Artifact naming conventions (ControlID_Date_ArtifactType)
- Links to immutable sources (IdP logs, ticketing approvals, Git commits, cloud audit logs)
This reduces last-minute screenshot chaos and makes Type 2 far easier.
SOC 2 Controls & Criteria (Beginner-Friendly Map)
Criteria = what SOC 2 expects. Controls = how you meet it. Use this table to understand soc 2 controls and criteria and what evidence auditors request.
| Criteria (What) | Typical Controls (How) | Common Evidence (Proof) |
|---|---|---|
| Security Common Criteria |
MFA + SSOLeast privilege
EDRSIEM monitoring Access controls, endpoint protection, monitoring, secure config baselines. |
IdP policies (MFA enforced), access logs, EDR coverage report, SIEM alerts & triage tickets. |
| Availability |
BackupsDR planUptime monitoring Business continuity, disaster recovery testing, capacity monitoring, incident readiness. |
Backup success logs, DR test report, uptime dashboards, incident tickets with timelines. |
| Confidentiality |
EncryptionData classificationAccess restrictions Encrypt at rest/in transit, classify sensitive data, limit access. |
TLS settings, KMS/key policies, encryption settings, data handling policy & training proof. |
| Processing Integrity |
Change managementQA checksInput validation Ensure systems process data accurately and completely (common in fintech/data platforms). |
PR approvals, CI/CD logs, test results, monitoring for failed jobs, defect ticket history. |
| Privacy |
RetentionConsentDSAR process Handle personal data: collection, use, retention, disclosure, and user requests. |
Privacy notice, data inventory, retention schedules, DSAR tickets, access logging for PII. |
| Change Management Security focus |
Ticket requiredApproval workflowEmergency process Track, review, test, and approve all production changes. |
Jira/ServiceNow tickets, GitHub PR approvals, deployment logs, emergency change post-approval proof. |
| Incident Response Security focus |
IR planTabletopsOn-call Steps for detecting, responding, and learning from incidents. |
IR policy/runbook, tabletop minutes, incident postmortems, on-call logs, comms templates. |
| Vendor Risk Security focus |
Vendor reviewsSOC reportsSecurity clauses Evaluate critical vendors and track security changes/incidents. |
Vendor assessment forms, vendor SOC reports, contract excerpts, vendor incident tracking records. |
Tip: Store evidence as ControlID_Date_Artifact (example: CC6.1_2026-01_AccessReview.xlsx).
Read more : Common Challenges in SOC 2 Compliance
.jpg "Common soc challenges")
[…] of SOC 2 Controls for Businesses Understanding SOC 2 Controls and Criteria Common Challenges in SOC 2 […]