SOC 2 Controls: Full List, Use Cases, and What Auditors Expect

Image by AI

In the modern SaaS economy, trust is the most valuable currency. Whether you are a seed-stage startup or an enterprise-scale cloud provider, a SOC 2 (System and Organization Controls 2) report is often the “gatekeeper” to high-value contracts.

However, achieving compliance isn’t just about “passing an audit.” It’s about building a robust security posture that satisfies the rigorous standards of the American Institute of Certified Public Accountants (AICPA). Central to this process are the SOC 2 controls, the specific safeguards you implement to meet the Trust Services Criteria (TSC).

This guide offers a technically in-depth exploration of the full list of SOC 2 controls, their real-world applications, and, crucially, what an auditor expects to see when they visit your organization.

The 5 Trust Service Criteria for SOC 2 Audit You Need to Know
An easy guide!

SOC 2 Framework: Criteria vs. Controls

Before diving into the list, we must clarify the terminology. Many organizations confuse Criteria with Controls.

• Trust Services Criteria (TSC): These are the high-level benchmarks set by the AICPA (Security, Availability, Processing Integrity, Confidentiality, and Privacy).
• Common Criteria (CC): These are the “Security” criteria, which are mandatory for every SOC 2 audit. They are the foundation upon which the other four optional pillars are built.
• SOC 2 Controls: These are the actions your company takes to meet those criteria. For example, if the criterion is “Logical Access,” the control is “Implementing Multi-Factor Authentication (MFA).”

The Full SOC 2 Controls List (Common Criteria)

The Common Criteria are organized into nine series. Below is the technical breakdown of the controls within these categories and what an auditor looks for.

Pro tip (E-E-A-T): The AICPA doesn’t just publish the CC criteria (CC1.1, CC6.1, etc.). Each criterion has “Points of Focus” that act like auditor-friendly prompts for what “good” looks like. If your controls and evidence align to the Points of Focus, you’ll sound more credible in scoping calls and you’ll reduce rework during testing.

CC1: Control Environment

This series focuses on organizational culture, integrity, and governance. It is the “Tone at the Top.”

AICPA Points of Focus (examples):

• Governance oversight: Security accountability is assigned and reviewed.

• Competence and expectations: Roles and responsibilities are defined, trained, and enforced.

• Integrity and Ethical Values: Formal codes of conduct and whistleblower policies.

• Board Oversight: Evidence that the board of directors reviews security metrics.

• Human Resources: Background checks for new hires, signed NDAs, and annual performance reviews.

• Auditor Expectation: Signed handbooks from every employee and minutes from board meetings showing security discussions.

• Evidence Example: Signed employee handbook acknowledgment + security training completion export (LMS) + board/leadership meeting notes where security is on the agenda.

CC2: Communication and Information

How information flows within the organization and to external stakeholders.

AICPA Points of Focus (examples):

• Quality of information: Policies, metrics, and logs are accurate and accessible.

• Internal/external communication: Security responsibilities and reporting channels are clear.

• Internal Communication: Ensuring security updates are shared via Slack, Email, or Town Halls.

• External Communication: Clear channels for customers to report vulnerabilities or for the company to report breaches.

• Auditor Expectation: Documented “Status Pages” or communication logs showing that users are notified of system changes.

• Evidence Example: Screenshot of public status page + security contact page / vulnerability disclosure policy + incident notification template + internal security announcements channel history.

Mastering IT Risk: The Role of a GRC Platform in Cybersecurity Management
Stop Leaving Your Security to Chance!

CC3: Risk Assessment

The process of identifying, analyzing, and managing risks.

AICPA Points of Focus (examples):

• Identify and analyze risks: Risks to objectives are documented with likelihood/impact.

• Assess fraud and change: Fraud risks and major changes are considered.

• Risk Identification: A formal risk register identifying threats (e.g., Ransomware, Insider Threats).

• Fraud Risk: Evaluating the potential for employee fraud or data theft.

• Auditor Expectation: A risk assessment spreadsheet reviewed and signed by leadership within the last 12 months.

• Evidence Example: Risk register with owners + last review/approval timestamp + meeting notes where top risks were reviewed + evidence of risk treatment decisions (accept/mitigate/transfer).

CC4: Monitoring Activities

How you ensure your controls are actually working over time.

AICPA Points of Focus (examples):

• Ongoing and separate evaluations: Controls are monitored continuously and periodically.

• Timely remediation: Exceptions are tracked to closure with accountability.

• Ongoing Evaluations: Use of GRC tools or automated scripts to monitor system configurations.

• Internal Audits: Regular “self-audits” or gap analyses.

• Auditor Expectation: Proof of “Remediation Plans” — if a monitor found a bug, did you track the fix to completion?

• Evidence Example: Continuous control monitoring alerts + exception log + ticket showing remediation + post-fix verification screenshot/report.

CC5: Control Activities

Developing the specific policies and procedures to mitigate risks.

AICPA Points of Focus (examples):

• Policies and procedures: Controls are documented and implemented consistently.

• Accountability: Approvals and reviews are performed by appropriate roles.

• Policy Management: A library of documented policies (InfoSec, Access Control, HR) reviewed annually.

• Auditor Expectation: Policy version history showing annual reviews and management approval.

• Evidence Example: Policy document with version history + annual review approval record + policy exception process (if used) with approvals.

CC6: Logical and Physical Access Controls

This is the most “technical” section. Auditors spend the most time here.

AICPA Points of Focus (examples):

• Access provisioning/deprovisioning: Access is approved, implemented, and removed promptly.

• Authentication and authorization: MFA/SSO and least privilege are enforced.

• Physical security considerations: Physical access is restricted where applicable.

• IAM & RBAC: Restricting access based on job roles (Principle of Least Privilege).

• Multi-Factor Authentication (MFA): Mandatory for all production environments.

• Offboarding: Revoking access within 24 hours of employee termination.

• Physical Security: Badge access to offices and data center security (usually covered by an AWS/GCP SOC report).

• Auditor Expectation: “The Termination Sample.” They will pick 5 ex-employees and ask for timestamped logs proving their access was revoked immediately.

• Evidence Example: Screenshot of IdP (Okta/Azure AD/Google Workspace) policy enforcing MFA + access review export + HRIS termination record + access revocation logs (IdP / SaaS admin logs) for sampled users.

Compliance Audit Software Explained: How to Choose the Best Fit
Find the Right Tool. Simplify Every Audit. devsecopsai.today

CC7: System Operations

Focuses on monitoring, incident response, and vulnerability management.

AICPA Points of Focus (examples):

• Detect and respond: Monitoring identifies anomalies and triggers response workflows.

• Vulnerability management: Weaknesses are identified, prioritized, remediated, and verified.

• Vulnerability Scanning: Monthly or quarterly scans of the network and application.

• Incident Response: A tested Incident Response Plan (IRP) with “post-mortem” documentation.

• Auditor Expectation: A “Tabletop Exercise” log — proof that your team sat down and practiced what to do during a breach.

• Evidence Example: Vulnerability scan report + remediation ticket(s) + patch/PR links + incident runbook + tabletop exercise agenda/attendees + incident postmortem template (even if unused).

CC8: Change Management

Ensures that changes to the system don’t introduce security flaws.

AICPA Points of Focus (examples):

• Change authorization: Changes are approved before deployment.

• Testing and rollback: Changes are tested and can be reversed safely.

• Peer Reviews: Requirement for code reviews (e.g., GitHub Pull Requests).

• Staging Environments: Testing code in a sandbox before production.

• Auditor Expectation: A random sample of 25 “Pull Requests” showing that no developer pushed code without a second person’s approval.

• Evidence Example: PR screenshots showing required reviewers + CI checks + deploy logs/release notes + change ticket linking to PR + rollback procedure/runbook.

CC9: Risk Mitigation

Managing the risks associated with third parties and business resilience.

AICPA Points of Focus (examples):

• Vendor and third-party risks: Critical vendors are identified, assessed, and monitored.

• Business continuity and resilience: The business can respond to disruptions.

• Vendor Risk Management (VRM): Reviewing the SOC 2 reports of your vendors (e.g., AWS, Stripe).

• Auditor Expectation: A “Vendor Inventory” with the latest SOC 2 report attached for every critical vendor.

• Evidence Example: Vendor inventory + signed DPA/SCCs (if applicable) + vendor SOC 2 reports + annual vendor review record + evidence of BCP/DR testing (even if tabletop).

The Common Criteria are organized into nine series (CC1 through CC9). Below is the technical breakdown of the controls within these categories.

Additional Trust Services Criteria (Optional)

While the Common Criteria (Security) is mandatory, you may choose to include others based on your service offering.

What the Auditor Expects: The Evidence Trap

When the auditor begins the examination, they aren’t looking for “good intentions.” They are looking for evidence. The gap between having a control and proving a control is where most companies fail.

The “Type 1” vs. “Type 2” Expectation

• SOC 2 Type 1: The auditor expects to see that you have designed the controls correctly. They check if the policy exists and if the technical setup is correct on that specific day.
• SOC 2 Type 2: The auditor expects to see “Operating Effectiveness.” This means they will sample data from across a 6–12 month window. If you forgot to do a monthly access review in June, you have a “finding” (an audit exception).

Key Evidence Items Auditors Demand:

1. Population Lists: A full list of all employees, all code changes, or all new customers during the audit period.
2. Sample Testing: The auditor will pick 25 random samples from your population and ask for screenshots or logs proving the control was followed for each.
3. The “Golden Thread”: Can you trace a ticket from a Customer Request -> JIRA Ticket -> Developer Branch -> Peer Review -> Staging Test -> Production Deploy?
4. Offboarding Logs: Evidence that an employee’s access was revoked within 24 hours of their termination date.

Photo by Sigmund on Unsplash

Use Cases for SOC 2 Controls

SOC 2 for AI Startups (2026): Model Drift, Training Data Provenance, and CC9.2 Scrutiny

In 2026, auditors increasingly ask AI startups to demonstrate that “security and risk mitigation” controls cover model behavior over time, not just infrastructure. Many teams hear this show up as heightened scrutiny on CC9.2 during walkthroughs—especially where model drift, retraining, and third-party AI vendors can introduce new risks.

What auditors want to see is practical governance around:

• Model drift monitoring: Defined thresholds, alerts, and review cadence for drift and performance regressions.
• Training data provenance: Where training/fine-tuning data came from, how it was approved, and how it’s protected.
• Retraining/change management: Retraining and prompt/guardrail updates treated as controlled changes (tie to CC8 evidence).
• Third-party AI/vendor risk: If you use hosted LLMs, vector DB vendors, or labeling services, show how you assess them (tie to CC9 evidence).

Evidence Examples (high-signal):

• Drift dashboard screenshot + alert configuration + monthly review notes
• Dataset inventory + approval record (ticket) + access controls on training buckets
• Model registry entry showing versioning + change request linking retrain → eval results → production deploy
• Vendor due diligence packet for model/LLM providers (SOC 2, security docs, DPAs)

Use Case A: The FinTech Startup (Processing Integrity)

A FinTech company processing $10M in transactions daily needs to prove that no data is lost or altered during transit.

• Control implemented: Automated checksums for every transaction batch.
• Auditor Expectation: Logs showing that any “mismatch” in checksums triggered an immediate alert and human intervention.

Use Case B: The HealthTech Platform (Confidentiality & Privacy)

A company storing patient records must ensure that data is only accessible to authorized medical staff.

• Control implemented: Database-level encryption and strict RBAC.
• Auditor Expectation: A list of everyone with “Admin” access and a signed justification for why each person needs that level of access.

How to Build Your Control Framework (Step-by-Step)

Building a SOC 2 control framework is a strategic exercise in translating abstract AICPA criteria into a repeatable technical lifecycle. To move from “security-conscious” to “audit-ready,” follow this four-step roadmap:

Step 1: Strategic Scoping

Scoping defines the “System” being evaluated. A scope that is too broad increases audit fees and complexity; one that is too narrow may fail to provide the assurance your customers require.

• Define the Perimeter: Most SaaS companies scope the Production Environment (e.g., AWS VPCs or Azure Resource Groups) and the “Support Tooling” that touches it, such as GitHub (source code), Jira (change management), and Okta (identity).
• The System Description: You must document your architecture, data flow, and boundaries. The auditor will use this narrative to verify that all critical touchpoints are accounted for.

Top 7 Cybersecurity Programs That Close 99% of Security Gaps
Close Gaps, Stop Attacks, Sleep Easy devsecopsai.today

Step 2: Technical Gap Analysis

This is a “stress test” where you compare current operations against the CC1–CC9 criteria. It identifies where your security posture lacks the necessary “digital paper trail.”

• Identify Missing Links: You might be doing the work (e.g., reviewing code), but is it documented? If a code change was made, can you link it to a specific Jira ticket and a peer approval log?
• Operational Readiness: Common gaps include “Ghost Accounts” (active accounts for former employees) and untested Disaster Recovery (DR) plans.

Step 3: Formalizing Policies

Policies are the “laws” of your organization. During an audit, the auditor verifies your actual behavior against these written rules.

• The Policy Library: You must maintain a core set of documents, including Information Security, Access Control, and Incident Response.
• The “If/Then” Rule: If your policy says “all employees undergo background checks,” but you skipped one for a contractor, you will receive an audit exception. Policies must be reviewed and re-approved by leadership annually.

Step 4: Automating Evidence Collection

The “old way” of SOC 2 involved engineers spending weeks taking manual screenshots. Modern compliance relies on GRC (Governance, Risk, and Compliance) automation.

• API Integration: Use GRC tools to connect directly to your cloud provider and HRIS. This allows for continuous monitoring , if an S3 bucket is made public, you are alerted instantly.
• Population Lists: Instead of manual exports, automation creates a “Golden Thread” of evidence (e.g., a full list of all 500 code commits in the audit window) that the auditor can sample with confidence.

7 GDPR Compliance Tools That Automate the Hard Work for You
Find the Perfect GDPR Tool for Your Business Fast! devsecopsai.today

Conclusion

A “Clean” SOC 2 report (officially called an “Unqualified Opinion”) is a powerful sales tool. It tells your customers that you don’t just care about security; you’ve built a culture that proves it every single day.

Success in a SOC 2 audit hinges on rigorous documentation and continuous monitoring. By mapping your controls to the Trust Services Criteria and preparing for the auditor’s sample testing early, you transform compliance from a burden into a competitive advantage.

Ready to Streamline Compliance?

Building a secure foundation for your startup is crucial, but navigating the complexities of achieving compliance can be a hassle, especially for a small team.

SecureSlate offers a simpler solution:

• Affordable: Expensive compliance software shouldn’t be the barrier. Our affordable plans start at just $259/month.
• Focus on Your Business, Not Paperwork: Automate tedious tasks and free up your team to focus on innovation and growth.
• Gain Confidence and Credibility: Our platform guides you through the process, ensuring you meet all essential requirements and giving you peace of mind.