7 SOC 2 Controls Auditors Check First (2026)

There is no AICPA-prescribed order in which every auditor checks SOC 2 controls. The seven areas below are a practical triage list: they sit close to the system boundary, produce evidence an auditor can sample, or expose gaps between a control description and what the team actually does.

Use the list with the AICPA Trust Services Criteria, your engagement scope, and the customer commitments in the system description. The SOC 2 controls list is the broader reference page; this article is for deciding what to stage before fieldwork.

What should you check before SOC 2 fieldwork?

Evidence-heavy area	Relevant criteria	Evidence to stage	Primary owner
Identity, access, and non-human accounts	CC6.1–CC6.5, as applicable	IdP configuration, provisioning and termination records, access reviews, privileged-access records, service and agent account inventory	IT or security
Change management and production releases	CC8.1	Change population, approvals, code reviews, deployment records, test results, emergency-change follow-up	Engineering
Logging, monitoring, and incident response	CC7.2–CC7.5	Log-source inventory, alert triage, escalation records, incident plan, tabletop or post-incident records	Security or operations
Risk, vulnerability, and vendor boundaries	CC3.1–CC3.4, CC7.1, CC9.1–CC9.2	Risk register, scan results, remediation decisions, vendor and subprocessor reviews, model-provider assessment	Security, procurement, or legal
Data protection and secure disposal	CC6.7 and C1.1–C1.2 when scoped	Data-flow map, classification, transmission settings, key-management evidence, deletion records	Security or data owner
Availability, backup, and recovery	A1.1–A1.3 when scoped	Capacity evidence, backup records, restore or failover results, recovery commitments, test follow-up	SRE or operations
Control ownership and evidence provenance	CC1–CC5 plus the system description	Org and owner matrix, policy acknowledgments, management assertion support, source exports, validation notes	Management and control owners

This grid is a starting point. The auditor decides the procedures and samples based on the engagement, the control design, the population, and the evidence available.

1. Identity, access, and non-human accounts

Prepare:

• an in-scope application and infrastructure inventory;
• provisioning, role-change, and termination records from the source system;
• current role or group definitions and completed access reviews;
• privileged, break-glass, service-account, and non-human identity records; and
• identity-provider settings that show the authentication controls actually enforced.

The exact frequency and technology depend on the control description. CISA’s MFA guidance recommends using MFA wherever possible and prioritizing phishing-resistant methods for sensitive access. Treat that as security guidance, not a universal SOC 2 wording requirement.

For AI-enabled systems, record the agent identity, tools it can call, data it can access, approval path, and logs of high-impact actions. NIST’s 2026 concept paper on software and AI agents makes identity and authorization a central adoption question; the paper does not create a new SOC 2 criterion.

2. Change management and production releases

Stage a population from the systems that actually deploy to production, not only a project-management export. For a sample, the auditor may need the request or pull request, approval, test result, deployment timestamp, and evidence that an emergency change was reviewed afterward.

Useful checks:

• Does the change population cover every production path?
• Can the team distinguish normal, standard, and emergency changes?
• Is approval recorded before deployment when the control requires it?
• Are changes to infrastructure, access policy, model configuration, and prompts treated consistently with the system description?
• Can the team explain changes that bypassed the normal workflow?

The relevant mapping is CC8.1. The SOC 2 change-management guide has the deeper control design discussion.

3. Logging, monitoring, and incident response

Start with a log-source inventory for identity, production, cloud administration, application security, and other systems named in the scope. Then show how the team protects logs, reviews high-risk events, and records the response. CISA’s business logging guidance recommends enabling, centralizing, protecting, and monitoring logs on business systems.

The mapping is CC7.2–CC7.5 for monitoring, detection, response, and recovery activities. Vulnerability identification belongs with CC7.1, not the incident-response mapping. NIST SP 800-61r3 is the current incident-response reference and supersedes the older revision; use it to improve the response program, not as a substitute for scoping the SOC 2 control.

The absence of a security incident does not remove the need for evidence. A tabletop exercise, alert-triage record, or review of a simulated event can show that the process was exercised when no real incident occurred.

4. Risk, vulnerability, and vendor boundaries

Stage:

• the current risk assessment and the method used to score or prioritize risks;
• vulnerability findings, remediation decisions, accepted risks, and closure evidence;
• penetration-test or other independent assessment results when they support the control design;
• vendor inventory, due diligence, contracts, security reports, and reassessments; and
• data-flow and subprocessor records for AI or other external processing services.

For AI products, include the model provider’s retention and training terms, the data sent to the provider, the provider’s own subprocessors, and the failure or misuse scenarios the team considered. These facts belong in the vendor and system boundary analysis; an AI label alone does not decide which criteria are in scope.

The core mappings are CC3.1–CC3.4, CC7.1, and CC9.1–CC9.2. The SOC 2 vendor-management requirements guide covers the customer and subservice side in more detail.

5. Data protection and secure disposal

Stage:

• a data-flow diagram showing collection, processing, storage, transfer, and deletion;
• classification rules and the systems that enforce or record them;
• transmission and storage configuration for the relevant systems;
• key-management roles, access, and lifecycle records when encryption is part of the control; and
• deletion, retention, or subprocessor-disposal evidence when Confidentiality or Privacy commitments require it.

The mappings are CC6.7 for authorized data transmission and C1.1–C1.2 when Confidentiality is scoped. C1.2 concerns secure disposal; it is not a general encryption criterion. The SOC 2 encryption requirements guide and Confidentiality criteria explainer cover the narrower implementation questions.

6. Availability, backup, and recovery

Prepare:

• availability and capacity commitments from contracts or the system description;
• capacity thresholds, scaling alerts, or service-monitoring records;
• backup completion and retention records;
• restore, failover, or recovery-test results with the scenario, outcome, and follow-up; and
• documented RTO and RPO where those objectives are part of the service commitment.

The mapping is A1.1–A1.3. Do not promise a universal test frequency or recovery target in the control unless the organization has chosen and documented it. The SOC 2 availability criteria guide explains the category, while the business-continuity controls guide covers the implementation side.

7. Control ownership and evidence provenance

Stage:

• the system description and a current control-to-owner matrix;
• management approvals and policy acknowledgments;
• the source export or record behind each evidence item;
• the transformation, filters, date range, and exclusions applied by a compliance tool; and
• the reviewer’s sign-off and explanation for missing or exceptional records.

The AICPA’s March 2026 FAQ on software tools used in SOC 2 examinations addresses tool use and the need to consider completeness, accuracy, auditor responsibilities, and independence. A GRC platform can make evidence easier to organize; it cannot make an incomplete export complete or replace the CPA’s examination.

What turns a control gap into an audit exception?

The auditor decides whether a deviation is an exception based on the control, the testing performed, and the effect of the deviation. The practical warning signs are consistent:

• the policy says one thing and the source record shows another;
• the team cannot produce the population or explain its completeness;
• a review happened but has no attributable approval or date;
• a subservice or AI provider is absent from the documented boundary; or
• evidence stops before the period stated in a Type 2 report.

Do not “fix” a missing historical record by recreating it. Explain the gap, preserve what exists, and ask the auditor how it affects the engagement. The SOC 2 audit fieldwork checklist covers sample populations, evidence requests, and exception testing in more detail.

A practical pre-fieldwork triage sequence

1. Confirm the boundary. List systems, people, data, locations, cloud services, models, and subprocessors in the report.
2. Confirm the promises. Match customer commitments to the selected TSC categories and control descriptions.
3. Trace evidence. For each control, identify the source, owner, period, population, and approval record.
4. Resolve explanations. Separate missing evidence, control deviations, scope changes, and tool-export problems before fieldwork begins.

This sequence makes the article useful without pretending that auditors follow a fixed seven-step script.

Common questions

Are these the only controls auditors check?

No. The control areas depend on the system, selected criteria, report type, control descriptions, and auditor’s procedures. This is a high-value triage list, not a complete SOC 2 controls catalog.

Does every SOC 2 audit include Availability, Confidentiality, or Privacy?

No. Security is required. The other categories are scoped when they match the service commitments, customer requirements, and information flows.

Do auditors require one specific security tool?

No. The criteria evaluate control objectives and evidence. A company can use different tools — or lightweight processes — if the control is suitably designed, operated, and supported by reliable evidence.

Use this page to stage the first evidence packet, then move to the SOC 2 controls list for the full criteria-to-evidence reference and the SOC 2 evidence request list for source-system pulls.