SOC 2 Controls List (2026): What Auditors Ask For

This page maps every criteria family to common controls, evidence examples, and recurring implementation gaps. It also includes an editable starter matrix you can tailor to your system, risks, and policies. Your auditor will set the actual evidence request and sample based on your scope and report period. 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.

If you’re headed into a Type 2 audit specifically, this list covers what to build. For how an auditor samples and tests each control for operating effectiveness over the observation window, see our SOC 2 Type 2 controls guide.

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	8	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.

The Complete SOC 2 Controls List: CC1–CC9, A1, PI1, C1, and P1–P8 Mapped to Evidence

The tables below map common controls to criteria references, evidence examples, and gaps worth checking before fieldwork. They are implementation guidance, not an official AICPA control list. For a deeper CC6/CC7 walkthrough, see our SOC 2 security controls guide.

Security Controls (CC1–CC9) Mapped to Evidence

The 33 Common Criteria define the mandatory Security category. Organizations implement controls that auditors test against them.

Control	Criteria 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
Perimeter access restrictions	CC6.1	Firewall rules, WAF settings, network diagram	Broad rules lack a documented business need
Provisioning + deprovisioning	CC6.2	Approved access and termination tickets	Access granted before approval or removed late
RBAC + access reviews	CC6.3	Role matrix, dated review records	Reviews do not assess actual permissions
MFA + credential protection	CC6.5	MFA enforcement, secrets-manager settings	MFA is available but not enforced
Authorized data transmission	CC6.7	TLS settings, transfer policy, DLP evidence where relevant	Transfer controls do not cover every in-scope channel
Protection of confidential data at rest	C1.1, when Confidentiality is scoped	Classification policy, encryption and key-management settings	Protection does not follow the data classification
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

Access reviews and deprovisioning are useful places to check before fieldwork because both produce dated evidence an auditor can sample. For AI vendors, include model providers, training-data flows, and subprocessors in the CC9.2 risk assessment rather than treating the cloud infrastructure as the whole vendor boundary.

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

A dated recovery-test result shows that the procedure operated; a disaster-recovery document alone does not.

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

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.

Where Do SOC 2 Controls Most Often Fail?

SOC 2 is principles-based: you design controls for your own risks, and generic templates fail when they do not connect to identified threats. The sections below show high-value readiness checks, the criteria involved, and a concrete response.

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)

For user and non-human access controls (CC6.1–CC6.8), check for missing MFA, undated access reviews, and 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, and the wider SOC 2 audit cost guide for how scope and criteria move the price.

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, or get matched with the right auditor and let us bring back 3–10 fit-based quotes for you.

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 services, risks, system boundaries, and which criteria you scope in. A compact control set may be enough for a narrow environment; a complex or multi-product environment may need far more. The test is coverage and consistent operation, not a target 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.