SOC 2 Controls List: All 61 Trust Services Criteria Mapped to Controls and Evidence (2026)

A SOC 2 controls list is the set of controls your company writes and operates to meet the AICPA’s Trust Services Criteria. There are 33 common criteria (CC1-CC9) in every SOC 2 report, plus 28 more if you add Availability, Confidentiality, Processing Integrity or Privacy. The AICPA publishes the criteria, not the controls, so there is no official list to copy: you design controls that fit your system, and a CPA firm tests them. Below are all 61 criteria with example controls, the evidence auditors ask for, and which ones a penetration test proves.

Invadel is a penetration testing firm, not a CPA firm, so we do not issue SOC 2 opinions (a SOC 2 audit firm does). Our part is the testing evidence: a SOC 2 penetration test scoped to your system boundary, most often a web application penetration test from $5,200 (pricing by size), free retest and attestation letter included. The criteria below are those in force in November 2026: the 2017 Trust Services Criteria with revised points of focus (2022).

What a SOC 2 controls list is: criteria, points of focus and controls

Layer	Who writes it	Fixed?	Example
Criteria	AICPA	Yes, 61 in total	CC6.3: access is granted and removed by role, with least privilege
Points of focus	AICPA	No, illustrative only	“Uses role-based access controls”
Controls	You	Yours to design	“Engineering leads review production access every quarter”
Tests of controls	Your auditor	Set by the auditor	Inspect the quarterly reviews; sample removals

Points of focus are guidance: the AICPA states that an entity is not required to address every point of focus. The criteria are the requirement. Every criterion in an included category is addressed unless it is not relevant to your services, in which case your system description says why.

CC1-CC5 follow the 17 principles of the COSO internal control framework (2013), which is why they read like governance rather than security engineering.

The five SOC 2 trust services criteria at a glance

Category	Criteria	Count	When it applies
Security (common criteria)	CC1.1 to CC9.2	33	Always. Every SOC 2 includes them
Availability	A1.1 to A1.3	3	You commit to uptime or recovery times
Confidentiality	C1.1 to C1.2	2	Contracts define data as confidential
Processing Integrity	PI1.1 to PI1.5	5	Customers rely on your processing being complete and accurate (payments, payroll, claims)
Privacy	P1.1 to P8.1	18	You collect, use, retain, disclose or dispose of personal information under privacy commitments (some criteria may not apply if customers collect it)
Total		61

Add a category only when a contract or customer needs it; each adds controls your auditor tests yearly.

SOC 2 common criteria CC1-CC9: the full controls list

In the Pentest column, Direct means auditors commonly map the test report to the criterion; Supporting means testing shows whether the control works, alongside the records that are the primary evidence; No means the evidence is documentary. Download all 61 criteria as a spreadsheet: SOC 2 control matrix (XLSX).

CC1 to CC5: the COSO-based criteria

Criterion	What it asks	Example controls	Evidence	Pentest
CC1.1	Commitment to integrity and ethical values	Code of conduct acknowledged at hire and annually	Signed acknowledgments	No
CC1.2	Board independence and oversight of internal control	Board reviews security at least annually	Meeting minutes	No
CC1.3	Structures, reporting lines and authorities	Org chart; named security owner	Org chart, role descriptions	No
CC1.4	Attract, develop and retain competent people	Background checks; security training	Check confirmations, training records	No
CC1.5	Accountability for control responsibilities	Performance reviews; sanctions policy	Review records	No
CC2.1	Quality information to support internal control	Asset inventory; data-flow documentation; logging	Inventory export, diagrams	No
CC2.2	Internal communication of control responsibilities	Awareness training; incident reporting channel	Training completion records	Supporting (phishing)
CC2.3	Communication with external parties	Customer notices; vulnerability reporting address	Notification records	No
CC3.1	Objectives clear enough to assess risk	Documented security commitments and system requirements	Contracts, SLAs, risk policy	No
CC3.2	Identify and analyze risks	Annual risk assessment and risk register	Dated risk register with owners	Supporting
CC3.3	Consider fraud risk	Fraud scenarios in the risk assessment	Risk assessment section	No
CC3.4	Assess changes that could affect controls	Risk review on major change	Change-triggered reviews	No
CC4.1	Ongoing and separate evaluations	Independent penetration test; control monitoring; scans	Pentest report, monitoring records	Direct
CC4.2	Communicate and correct deficiencies on time	Findings assigned owners and due dates by severity	Tickets, retest, risk acceptances	Direct
CC5.1	Select controls that reduce risk	Risk treatment mapped to controls	Risk-to-control matrix	No
CC5.2	General controls over technology	Baselines for access, infrastructure and development	Control matrix, configuration standards	Supporting
CC5.3	Deploy controls through policies and procedures	Policy set approved and reviewed annually	Policies with approval dates	No

CC4.1 is where the AICPA text names penetration testing: a point of focus lists it, with independent certification and internal audit, among the ongoing and separate evaluations management can use. CC4.2 is where the retest matters: open findings show deficiencies, and a retest shows them corrected.

CC6: logical and physical access controls

Criterion	What it asks	Example controls	Evidence	Pentest
CC6.1	Logical access security over protected assets	SSO with MFA; encryption at rest; segmentation; tenant isolation	IdP settings, encryption config	Direct
CC6.2	Register and authorize users; remove access when no longer needed	Approved provisioning; offboarding within a set time	Joiner and leaver tickets	No
CC6.3	Role-based access, least privilege, segregation of duties	Role matrix; quarterly access reviews	Signed reviews	Supporting
CC6.4	Restrict physical access to facilities and assets	Badge access; usually inherited from the cloud provider	Badge reports, provider SOC 2	Supporting (physical test)
CC6.5	Keep protecting assets until data is unrecoverable	Media sanitization; destruction certificates	Disposal records	No
CC6.6	Protect against threats from outside the boundary	Firewall and security group rules; WAF; MFA on remote access	Rule reviews, external test	Direct
CC6.7	Restrict and protect data in transmission and removal	TLS everywhere; device management; export restrictions	TLS config, MDM reports	Supporting
CC6.8	Prevent or detect unauthorized or malicious software	Endpoint protection; restricted installs; dependency scanning	EDR coverage, scan results	Supporting

CC7: system operations

Criterion	What it asks	Example controls	Evidence	Pentest
CC7.1	Detect new vulnerabilities, including those from configuration changes	Scans on a schedule and after major change; configuration baselines	Scan reports, remediation tickets	Direct
CC7.2	Monitor components for anomalies	Central logging; alerting; log retention	Alert rules, on-call records	Supporting (purple team)
CC7.3	Evaluate events to decide if they are incidents	Triage procedure; severity definitions	Triage tickets, incident log	Supporting (red team engagement or purple team)
CC7.4	Respond under a defined incident response program	Incident response plan; annual tabletop exercise	Plan, tabletop report	No
CC7.5	Recover from incidents	Restore procedures; post-incident reviews	Restore records, post-mortems	Supporting (ransomware readiness)

CC7.1’s points of focus name vulnerability scanning, periodically and after significant change. Scans meet that point of focus; a penetration test evidences CC7.1 and CC4.1 (how the two differ).

CC8 change management and CC9 risk mitigation

Criterion	What it asks	Example controls	Evidence	Pentest
CC8.1	Authorize, test, approve and implement changes	Reviewed pull requests; CI checks; separate environments	PR approvals, deployment logs	Supporting
CC9.1	Mitigate business disruption risk	Business continuity plan; cyber insurance	BCP, policy documents	No
CC9.2	Assess and manage vendor and partner risk	Vendor register; annual review of vendor SOC reports	Reviewed reports, contracts	No

CC9.2 works both ways: enterprise customers run their own CC9.2 control on you and ask for your SOC 2 report and a recent penetration test.

Availability, Confidentiality and Processing Integrity criteria

Criterion	What it asks	Example controls	Evidence	Pentest
A1.1	Monitor capacity and plan for demand	Capacity monitoring; autoscaling	Capacity dashboards, alert thresholds, scaling policies	No
A1.2	Environmental protections, backups and recovery infrastructure	Automated, isolated backups; multi-zone deployment	Backup job logs, backup configuration, provider SOC 2	Supporting (ransomware readiness)
A1.3	Test recovery plan procedures	Annual recovery test with a real restore	Dated restore test report with recovery times achieved	No
C1.1	Identify and maintain confidential information	Data classification; access restricted by class	Classification policy, data inventory, access lists	Supporting
C1.2	Dispose of confidential information	Retention schedule; deletion at contract end	Deletion tickets, deletion job logs, destruction certificates	No
PI1.1	Define data processed and product specifications	Documented processing specifications	Specifications, data definitions, customer documentation	No
PI1.2	Completeness and accuracy of inputs	Input validation; reject handling	Validation rules, rejected-record logs	Supporting
PI1.3	Processing controls	Reconciliations; job monitoring	Signed reconciliations, job failure alerts and tickets	Supporting
PI1.4	Complete, accurate, timely outputs	Output review; delivery confirmation	Output review records, delivery logs	No
PI1.5	Storage of inputs, in-process items and outputs	Integrity checks; retention	Integrity check reports, retention settings	No

Testing supports C1.1 and PI1.2-PI1.3 through authorization and business-logic checks: can one tenant read another’s records, or a user tamper with prices?

SOC 2 privacy criteria P1-P8

Criteria	What they cover	Example controls	Evidence	Pentest
P1.1	Notice of privacy practices	Published, versioned privacy notice	Notice with version history and review dates	No
P2.1	Choice and consent	Consent capture; opt-out handling	Consent records, opt-out logs	No
P3.1-P3.2	Collection, and explicit consent where required	Data minimization review; consent flows	Data inventory, collection review, consent screens	No
P4.1-P4.3	Use, retention and disposal	Purpose limits; retention schedule; secure deletion	Retention schedule, deletion logs	No
P5.1-P5.2	Data subject access and correction	Verified request handling	Request log with identity checks and response dates	Supporting
P6.1-P6.7	Disclosure, vendor commitments, breach notification, accounting of disclosures	Disclosure log; data processing agreements; notification procedure	Disclosure log, signed agreements, notification records	No
P7.1	Accuracy and completeness of personal information	Correction process	Correction requests and change records	No
P8.1	Inquiries, complaints and disputes	Complaint log with resolutions	Complaint log, resolution correspondence	No

P5 is where a test touches privacy: we check that access and export features return only the requesting user’s data.

Which SOC 2 controls a penetration test evidences, and what it costs

Every penetration test evidences CC4.1 (the engagement itself is an evaluation of your controls) and CC4.2 (findings, tickets and the retest). Other criteria depend on scope. Invadel’s published starting prices, each fixed in writing from your scope:

Test	Criteria it evidences beyond CC4.1 and CC4.2	From
Web application penetration test	CC6.1, CC6.3, CC6.7, CC7.1, C1.1, PI1.2, PI1.3	$5,200
API penetration test	CC6.1, CC6.3, CC6.7, CC7.1, P5	$4,000
External network penetration test	CC6.6, CC7.1	$4,200
Cloud penetration test	CC6.1, CC6.3, CC6.6, CC7.1	$6,800
Vulnerability scanning, free re-scan of fixes	CC7.1	$1,500 up to 250 devices
Phishing simulation, no retest	CC2.2	$3,600
Secure code review	CC8.1, CC6.8	$4,800
Ransomware readiness assessment	A1.2, CC7.5	$6,000
Physical penetration test, one NYC-metro office	CC6.4, where not carved out	$6,800
Purple team assessment	CC7.2, CC7.3	Quoted

For a first SOC 2, the web application test (covering the API the app calls) is usually the core; add an API test for a separately published API and an external network or cloud test for hosting. To test several times inside a Type 2 window, penetration testing as a service runs it as one fixed-price program; the pricing page and cost calculator cover the rest. Every penetration test includes a free retest and an attestation letter, maps findings to these criteria, and uploads into Vanta, Drata and Secureframe. The SOC 2 penetration testing evidence checklist lists what to hand the auditor, and SOC 2 pentest requirements explained covers timing.

Still choosing a tester? Our guide to SOC 2 penetration testing providers covers what auditors need from the report and how the Vanta and Drata partner directories work.

Controls that live outside your company: carve-outs and CUECs

Some criteria are met partly by other parties, and the AICPA’s SOC 2 description criteria require your system description to say so.

• Complementary subservice organization controls (CSOCs). Under the carve-out method, controls your cloud provider operates, such as data center physical security (CC6.4) and media destruction (CC6.5), sit outside your examination. You list what you rely on and show oversight under CC9.2 by reviewing the provider’s report. AWS, for example, publishes SOC 2 reports twice a year through AWS Artifact, each covering the previous 12 months, under a non-disclosure agreement.
• Complementary user entity controls (CUECs). Controls you assume customers operate: managing their users, configuring their SSO, protecting their API keys.

Test what you own in the shared responsibility model; our AWS penetration testing guide covers what providers permit.

How to write your own SOC 2 controls list

1. Fix the boundary and the categories that contracts actually require.
2. Start from commitments. In SOC 2, your objectives are your commitments to customers and your system requirements, so read contracts, SLAs and the privacy notice first.
3. Write each control in one sentence: who does what, how often or on what trigger, and where the evidence lives.
4. Map controls to criteria many-to-many. One access review can serve CC6.2 and CC6.3; CC6.1 usually needs several controls.
5. Keep the list short. A Type 2 auditor tests every control you list across the window, and one you cannot evidence becomes an exception.
6. Schedule the third-party evidence inside the window, with time to fix and retest. Our guides to SOC 2 Type 1 vs Type 2 and SOC 2 cost cover timing and budget.

Pursuing ISO 27001 or HITRUST too? Map each control to both: see our ISO 27001 checklist and HITRUST vs SOC 2, and ISO 27001 vs SOC 2 for how the two overlap. If customers’ auditors also want a SOC 1, SOC 1 vs SOC 2 shows which controls carry over.

Where SOC 2 controls pass on paper and fail under test

What testers commonly find behind a clean-looking control matrix:

Control on paper	What testing often finds	Criterion
MFA enforced at the identity provider	A legacy API token, service account or exposed admin port bypasses it	CC6.1, CC6.6
Role matrix and quarterly access reviews	A basic user calls an admin API endpoint or reads another tenant’s records	CC6.3, C1.1
Weekly vulnerability scanning	Unauthenticated scans only, or the production cluster excluded	CC7.1
Logging and alerting in place	Password spraying or a new cloud access key raised no alert	CC7.2
Daily backups	The same admin credentials that run production can delete them	A1.2

Each passes a document review. Testing is what exposes them, and a retest proves them fixed (see our guide to vulnerability remediation).

The proposed 2027 Trust Services Criteria

On October 28, 2026, the AICPA announced exposure drafts of revised Trust Services Criteria and description criteria: a targeted restructuring and new points of focus on AI governance, model monitoring, prompt manipulation and data poisoning. Comments close January 15, 2027; if approved, the criteria would apply to engagements beginning on or after December 31, 2027, with early adoption permitted (Journal of Accountancy).

Until then the 2017 criteria apply; if your product uses large language models, an AI and LLM penetration test from $4,500 covers prompt injection and data leakage.

Frequently asked questions

How many controls are in SOC 2? There is no fixed number. The AICPA defines 61 criteria (33 common plus 28 across the optional categories); the number of controls depends on your system and how you write them.

What are the five SOC 2 trust principles? Security, Availability, Processing Integrity, Confidentiality and Privacy, now officially the five trust services criteria categories. Security (the common criteria CC1-CC9) is in every SOC 2 report; the others are added when your commitments require them.

What are the SOC 2 common criteria CC1-CC9? Control environment, information and communication, risk assessment, monitoring activities, control activities, logical and physical access, system operations, change management and risk mitigation, in that order.

Is there an official SOC 2 controls list or template? No. The AICPA publishes criteria and illustrative points of focus; the controls are yours. Compliance platforms ship starter sets you can adapt.

Are SOC 2 points of focus mandatory? No. Points of focus are examples the AICPA gives to help you and your auditor judge whether a criterion is met. You are not required to address every one, and some will not fit your system. The criteria are what the auditor reports against.

Do SOC 2 Type 1 and Type 2 use the same controls? Yes. Both are examined against the same criteria and the same control list. A Type 1 report gives an opinion on whether the controls are suitably designed at a point in time. A Type 2 report also tests whether they operated effectively across a period, so every control needs evidence from the whole window, not one screenshot.

Which SOC 2 criteria does a penetration test cover? Every test is an evaluation under CC4.1, and its findings, tickets and retest evidence CC4.2. Technical tests also map to CC7.1 and, by scope, CC6.1 and CC6.6, and support others such as CC6.3, C1.1 and PI1.2. No criterion requires a test, but a CC4.1 point of focus names penetration testing, and auditors and customers commonly expect one.

The short version

A SOC 2 controls list is yours to write, against 61 fixed AICPA criteria, of which the 33 common criteria apply to every report. A penetration test maps directly to five of them and supports many more, if it lands inside the window and the fixes are retested. Start with a SOC 2 penetration test, most often a web application penetration test from $5,200 with a free retest (see pricing), or send your scope and get a fixed price in writing the same day.