SOC 2 Controls List (2026): All 5 TSCs Mapped to Evidence

This page maps every criteria family to the controls that satisfy it and the exact evidence auditors in our network request — including the gaps that draw the most exceptions in 2026. For how controls fit the wider picture, see our SOC 2 compliance guide and the SOC 2 Trust Services Criteria reference. To match with a firm that audits companies like yours, browse the SOC 2 auditor directory.

SOC 2 Criteria at a Glance

Criteria family	Designation	Count	Scope
Security (Common Criteria)	CC1–CC9	33	Mandatory for every SOC 2 report
Availability	A1.1–A1.3	3	Uptime, capacity, recovery
Processing Integrity	PI1.1–PI1.5	5	Complete, accurate, timely processing
Confidentiality	C1.1–C1.2	2	Protecting designated confidential data
Privacy	P1–P8 series	~18	Lifecycle of personal information

Source: AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022). Security is required; you scope in the other four based on the commitments you make to customers.

What Are SOC 2 Controls?

SOC 2 is principles-based: the AICPA gives you criteria and points of focus, not a prescribed control list. You design controls that fit your systems and risks.

A policy might say “access to sensitive data must be restricted.” The controls that make that real include:

• Multi-Factor Authentication (MFA): a second verification factor before users reach critical systems.
• Role-Based Access Control (RBAC): roles with preset permissions so employees see only the data their job needs.
• Access reviews: quarterly checks that former employees are de-provisioned and current permissions still fit.

Each is a distinct control an auditor can test against the relevant criterion. The controls are the evidence that your security commitments hold over time.

What Are the Five SOC 2 Trust Services Criteria?

SOC 2 rests on five Trust Services Criteria (TSC), defined by the AICPA in the 2017 TSC document with revised points of focus published in 2022. The 33 Common Criteria (CC1–CC9) cover the control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. The remaining four criteria sets — Availability, Processing Integrity, Confidentiality, and Privacy — apply only if you commit to them.

Here is what each criterion covers and the controls auditors expect.

Security: The Mandatory Foundation

Security is the only criterion required in every SOC 2 report. It protects systems and data against unauthorized access, disclosure, and damage that would undermine the other four promises.

In practice that means:

• Access controls: MFA and role-based permissions so only the right people reach sensitive systems.
• Firewalls and network monitoring: a perimeter plus active watch for suspicious traffic.
• Vulnerability management: scanning and patching weaknesses before an attacker finds them.

Without Security, the other criteria carry no weight.

Availability: Reliability You Can Prove

Availability is your commitment that systems run as promised in your SLAs. Controls include tested backups, a disaster-recovery plan you have actually run, and performance monitoring that catches trouble before customers do.

Processing Integrity: Accuracy on Time

Processing Integrity means your system processes data completely, accurately, and on time. It matters most for fintech, billing, and anything that runs calculations on customer data. Controls center on QA and data validation: testing code before it ships, checks on transaction processing, and logs that confirm data stays correct from input to output. For depth, see our guide to the SOC 2 Trust Services Criteria.

Confidentiality: Locking Down Designated Data

Confidentiality protects information that is sensitive but not necessarily personal — intellectual property, business plans, internal financials — and restricts access to a defined set of people. Controls include encryption at rest and in transit and NDAs.

Privacy: The Personal-Data Lifecycle

The Privacy criterion governs how you collect, use, retain, and dispose of personal information. Controls map to GDPR and CCPA obligations: privacy notices, consent capture, and documented retention and deletion. Privacy carries the most criteria of any supplemental category — the P1–P8 series.

Overview of The Five Trust Services Criteria

Trust Service Criterion	Core Objective
Security	Protect systems and data from unauthorized access and damage.
Availability	Ensure systems are operational and accessible as promised.
Processing Integrity	Ensure system processing is complete, accurate, and timely.
Confidentiality	Restrict access to sensitive, non-personal data.
Privacy	Govern the collection, use, and disposal of personal data.

Each criterion covers a different commitment. Together they set the scope your controls have to support.

How Do SOC 2 Controls Map to the Trust Services Criteria?

The tables below map common controls to their criteria reference, the evidence auditors in our network usually request, and the gap that most often creates an exception. For a deeper CC6/CC7 walkthrough, see our SOC 2 security controls guide.

Security Controls (CC1–CC9) Mapped to Evidence

The 33 Common Criteria are the core of every report. These are the controls auditors test first.

Control	CC reference	Evidence auditors request	Common gap
Code of conduct + background checks	CC1.1, CC1.4	Signed acknowledgments, screening records	New hires acknowledged after start date
Org chart + defined security roles	CC1.3, CC1.5	Org chart, role descriptions, board minutes	No evidence of board/management oversight
Security policies communicated to staff	CC2.1–CC2.3	Policy repository, training completion logs	Policies exist but staff never attested
Annual risk assessment	CC3.1–CC3.4	Dated risk register, treatment decisions	Stale assessment, no link to controls
Continuous control monitoring	CC4.1–CC4.2	SIEM dashboards, exception tickets	Monitoring is periodic, not continuous
Control activities / segregation of duties	CC5.1–CC5.3	Approval workflows, access matrices	One person owns both build and deploy
MFA + RBAC + access reviews	CC6.1–CC6.3	MFA config screenshots, quarterly review records	Reviews undated or skipped a quarter
Encryption at rest and in transit	CC6.7	Key config, TLS settings, cloud screenshots	In-transit covered, at-rest assumed
Deprovisioning on termination	CC6.2, CC6.3	Termination tickets with timestamps	Access revoked days after exit
Vulnerability scanning + patching	CC7.1	Scan reports, remediation SLAs	Findings logged, never closed
Intrusion detection / log monitoring	CC7.2–CC7.3	Alert logs, on-call rotation	No evidence alerts were triaged
Incident response plan	CC7.4–CC7.5	IR plan, post-incident reviews, tabletop notes	Plan never tested
Change management + code review	CC8.1	Pull requests, approvals, CI/CD logs	Emergency changes lack retroactive approval
Business-continuity + vendor risk	CC9.1–CC9.2	BCP, vendor SOC 2 reports, DPAs	No periodic vendor reassessment

In our network, access controls (CC6) draw the largest share of exceptions, most often from undated access reviews and slow deprovisioning. Auditors increasingly probe CC9.2 for AI vendors — model retraining and third-party LLM providers introduce risks teams often miss at reassessment time.

Availability Controls (A1.1–A1.3) Mapped to Evidence

Control	Criterion	Evidence auditors request	Common gap
Capacity monitoring	A1.1	Utilization dashboards, scaling alerts	No defined capacity thresholds
Backups + environmental protection	A1.2	Backup logs, redundancy/architecture docs	Backups run, restores never tested
Tested disaster-recovery plan	A1.3	DR plan + dated failover test results	Plan exists, no evidence it was run

Auditors want dated failover test results. Owning a DR document is the easy part; proof it works under pressure carries the criterion.

Processing Integrity Controls (PI1.1–PI1.5) Mapped to Evidence

Control	Criterion	Evidence auditors request	Common gap
Data definitions + processing specs	PI1.1	System description, data dictionary	Undocumented processing logic
Input validation	PI1.2	Validation rules, rejected-input logs	Validation only client-side
QA testing before release	PI1.3	Test cases, sign-offs, release tickets	No QA gate on hotfixes
Output accuracy checks	PI1.4	Reconciliation reports, error logs	No end-to-end reconciliation
Storage + retention integrity	PI1.5	Checksums, audit trails	No tamper-evidence on stored data

Most PI exceptions come from missing end-to-end reconciliation — proving the output matches the input across the full pipeline.

Confidentiality Controls (C1.1–C1.2) Mapped to Evidence

Control	Criterion	Evidence auditors request	Common gap
Identify + protect confidential data	C1.1	Data classification policy, encryption config, NDAs	No classification scheme
Secure disposal of confidential data	C1.2	Deletion logs, sub-processor disposal attestations	Deletion claimed, not verified

Confidentiality goes beyond encryption to disposal. Auditors frequently reject unverified de-identification or deletion claims, so keep deletion logs and sub-processor attestations.

Privacy Controls (P1–P8 series) Mapped to Evidence

Privacy carries the most criteria — notice (P1), choice and consent (P2), collection (P3), use, retention and disposal (P4), access (P5), disclosure and notification (P6), quality (P7), and monitoring and enforcement (P8).

Control	Criterion	Evidence auditors request	Common gap
Published privacy notice	P1	Privacy policy, version history	Notice does not match actual practice
Consent capture	P2	Consent records, opt-in/opt-out logs	No record of consent
Data-collection limits	P3	Data-flow maps, collection inventory	Collecting more than disclosed
Retention + secure disposal	P4	Retention schedule, deletion logs	No defined retention periods
Data-subject access (DSAR)	P5	DSAR request log, response timestamps	No process to honor access requests
Disclosure + breach notification	P6	Sub-processor list, breach playbook	No breach-notification timeline
Data quality	P7	Correction workflows	No way to correct inaccurate PII
Monitoring + enforcement	P8	Privacy complaint log, remediation records	No internal privacy oversight

Where Do SOC 2 Controls Most Often Fail?

SOC 2 is principles-based: you design controls for your own risks, and auditors flag templates that don’t connect to identified threats — AI data exposure, supply-chain dependencies, and vendor sprawl among them. The sections below show where companies in our network lose the most time, the CC references involved, and a concrete fix.

1. Design Controls to Fit Your Risks (CC1, CC3)

There is no prescribed list. Start with CC1 (Control Environment) to set ownership and CC3 (Risk Assessment) to decide which controls you actually need. A stale or generic risk assessment is one of the first things an auditor catches.

Action plan

• Use the AICPA 2017 TSC (revised 2022) as your source of truth, not a third-party checklist.
• Map your highest-impact risks (AI data exposure, supply-chain attacks) to CC1.2–CC1.5 and CC3.1–CC3.4 in a one-page matrix.
• Review the risk register quarterly and date every entry so the assessment is demonstrably current.

2. Logical Access: MFA Everywhere (CC6)

User and entity access controls (CC6.1–CC6.8) draw the most exceptions in our network — usually from missing MFA on a system, undated access reviews, or deprovisioning that lags termination.

Action plan

• Enforce MFA across endpoints, internal apps, and APIs (Okta, Duo) with no exceptions.
• Automate deprovisioning via SCIM so access is revoked on termination, not days later.
• Run quarterly reviews of all privileged accounts and keep dated, signed records.

3. Change Management and Evidence Quality (CC5, CC8)

Auditors value organized, verifiable proof over sophisticated tooling. CC8 (Change Management) and CC5 (Control Activities) ask you to prove changes were authorized, tested, and documented — owning a CI/CD platform is not the same as proving it.

Action plan

• Structure evidence by CC family in folders such as /CC6_Access/ and /CC8_Change_Management/.
• Tie pull requests to approvals and CI/CD logs so every production change has a trail.
• Make sure emergency changes get retroactive approval recorded in the ticket, not only a Slack thread.

4. AI and Vendor Risk (CC9)

In 2026, auditors probe CC9.2 for AI startups — they want to see that risk mitigation covers model behavior over time, beyond the underlying infrastructure. Model drift, retraining, and third-party LLM providers introduce risks teams often skip when they reassess vendors. The EU AI Act’s phased obligations (general-purpose AI rules applied from August 2025) raise the bar for companies serving EU users.

Action plan

• Keep an immutable log of training data, fine-tuning jobs, and model versions (for example, S3 Object Lock).
• Add model drift and bias checks to your pipeline and review outputs on a set cadence.
• Reassess third-party AI and data sub-processors at least annually, with their SOC 2 reports on file.

5. Monitoring: Move From Spot-Checks to Continuous (CC4)

Manual, periodic control reviews are a common reason Type 1 companies struggle on their first Type 2. CC4.1–CC4.2 (Monitoring Activities) favor monitoring that surfaces control failures quickly.

Action plan

• Wire a compliance platform (Drata, Vanta) to your SIEM, cloud provider, and ticketing system.
• Automate evidence collection and route exceptions to a remediation queue.
• Pilot on a set of critical controls before expanding to your full scope.

6. Incident Response: Test the Plan (CC7.4–CC7.5)

Incident response is part of the control environment. Auditors examine your ability to contain incidents, restore service, and learn from each event.

Action plan

• Maintain an Incident Response Plan with severity levels, containment steps, and communication paths, reviewed by management at least annually.
• Define a response team with named roles and a 24/7 contact list.
• Run a tabletop exercise at least annually and document outcomes and fixes.

7. Availability: Test Your Failover (A1.1–A1.3)

A DR plan that has never been run is a frequent exception. Auditors want dated test results, not a document.

Action plan

• Document your redundant architecture (multi-AZ, cross-region replication) in the system description.
• Run a full failover test at least once a year and keep the dated results in evidence.
• Define and monitor RPO/RTO targets so backups map to a commitment, not a guess.

8. Confidentiality: Prove Deletion (C1.1–C1.2)

Confidentiality goes beyond encryption to disposal. Auditors reject unverified de-identification and deletion claims, so the proof matters as much as the policy.

Action plan

• Automate retention and deletion policies in your data stores (S3, ADLS).
• Keep deletion logs and provide on-demand attestations.
• Vet sub-processors’ disposal practices and keep their attestations on file.

9. Processing Integrity: Reconcile End to End (PI1.1–PI1.5)

For fintech and data pipelines, most PI exceptions stem from missing end-to-end reconciliation. You must prove the output matches the input completely and on time.

Action plan

• Add input and output validation, with rejected-input and error logs as evidence.
• Run automated data-quality tests (for example, dbt) on each pipeline run.
• Keep reconciliation reports that trace data from input through stored output.

10. Privacy: Implement the Full P-Series (P1–P8)

The Privacy criterion is scoped into a growing share of AI and SaaS deals, driven by GDPR, CCPA, and the wave of US state privacy laws. Partial implementation reads as a gap.

Action plan

• Map PII data flows to the relevant privacy criteria, especially access (P5) and disclosure (P6).
• Automate consent capture and keep opt-in/opt-out records (OneTrust or similar).
• Run periodic DSAR drills that test your access and breach-notification procedures.

How Do You Implement and Document SOC 2 Controls?

Clear, organized proof matters as much as the control itself. Here is how to document the work in a way an auditor can actually test.

Start With a Gap Analysis

A gap analysis compares your current security setup against the Trust Services Criteria you are targeting. The output is a prioritized list of fixes — your password policy might be solid but you may have no documented quarterly access review.

Assign an Owner to Every Control

Assign a named person or team responsible for running, monitoring, and updating each control. When an auditor asks who manages firewall rules or background checks, you need a name ready.

• Control: Quarterly user access reviews.
• Owner: Head of IT.
• Responsibility: Reviews happen, are documented, and required access changes complete within five business days.

Build Accessible Documentation

An auditor should be able to pick any control at random and trace how it was implemented, how it works, and how it was monitored across the period. Evidence quality matters more than tooling. A well-instrumented stack with disorganized proof still draws exceptions.

Keep three layers:

1. Policies and procedures: the high-level rulebooks (Information Security Policy, Change Management Policy) that define what you do.
2. Control descriptions: what each control does, who owns it, and the CC reference it maps to. Clear descriptions cut audit prep time.
3. Evidence artifacts: the proof — screenshots, logs, signed forms, meeting notes — that controls operated.

Collect Evidence Continuously

Evidence collection is a continuous habit, not a week-before-audit scramble. Use tools that generate logs automatically, and organize the repository by Common Criteria family so prep stays fast. For manual items like a quarterly risk meeting, use a standard minutes template, fill it every time, and store it in one place. Consistent documentation over the full period carries more weight than spotty evidence.

How Do You Prepare for a SOC 2 Audit?

The goal is to find and fix weak spots before fieldwork starts.

Choosing Between a Type 1 and Type 2 Report

The report type drives your timeline, cost, and scope.

• SOC 2 Type 1: a snapshot. The auditor confirms your controls are designed correctly on a single date. It is a faster, cheaper first step.

• SOC 2 Type 2: assesses both design and operating effectiveness over a period — usually 6 to 12 months. Most enterprise customers require it because it shows the controls worked over time.

Many young companies start with Type 1, then move to Type 2 to meet customer demands. See our breakdown of the SOC 2 Type 2 audit cost before you commit.

How to Select the Right Audit Firm

Your auditor shapes the whole engagement. Vet for:

• Experience: a CPA firm with a track record auditing companies like yours. Ask for references.
• Industry fit: an auditor who knows SaaS, fintech, or healthtech grasps your risks faster.
• Communication: responsive and clear, since you will work with them closely.

A low-quality audit can get rejected by a sharp customer, forcing a redo. The cheapest bid is rarely the cheapest outcome. Browse the SOC 2 auditor directory to compare firms by industry and get matched.

An auditor’s job is to independently verify your controls are designed and operating correctly.

Your Audit Readiness Checklist

Our SOC 2 compliance checklist covers the full process; these steps are the core.

1. Self-assessment: an honest internal gap analysis against your chosen criteria.
2. Remediate gaps: fix what you found — update policies, roll out tools, train the team.
3. Organize evidence: one central place for every policy, log, and screenshot.
4. Prepare your team: brief the people who will be interviewed and asked to pull evidence.

SOC 2 is now a baseline requirement for B2B SaaS — many companies run two or more audits a year and bundle SOC 2 with ISO 27001. For recent data, see compliance statistics and trends.

Answering Your Top SOC 2 Control Questions

How Many SOC 2 Controls Do I Really Need?

There is no fixed number. It depends on your business, your services, and which criteria you scope in. A lean startup might run 50–70 well-chosen controls; a larger company can have hundreds. The goal is to cover your risks against the applicable criteria, not to hit a count.

What’s the Difference Between a Control and a Policy?

A policy is the rule; a control is how you enforce and prove it. You need both.

Policy: all employees must use strong, unique passwords for company systems.

Controls:

• The system enforces a minimum password length of 12 characters.
• Complexity rules require uppercase, lowercase, numbers, and symbols.
• An automated process forces password rotation per your policy.

Can I Just Use a Template for My Controls?

A template is a starting point. Experienced auditors spot a copy-pasted control list quickly — tailor every control to your tech stack, workflow, and risks. Platforms like Vanta, Drata, or Secureframe give you the foundation; you supply the specifics.

How Often Should We Review Our SOC 2 Controls?

Review controls at least annually. Pull the review forward whenever you:

• Launch a major new product or service.
• Add a significant new platform to your stack.
• Change how you handle or store customer data.
• Go through a major reorganization.

Continuous reviews keep your posture current and the next audit easier.

Is There an Official AICPA SOC 2 Controls List?

No. The AICPA publishes criteria — the 2017 Trust Services Criteria with revised points of focus (2022) — not a list of controls. You design controls that satisfy the 33 Common Criteria plus any supplemental criteria you scope in. Any “official control list” you find online is a vendor’s interpretation, not an AICPA standard.

---

Choosing the right auditor has a big effect on cost, timeline, and how painful the process feels. If you want to compare firms by pricing, industry fit, and timeline, start with the SOC 2 auditor directory.