A SOC 2 readiness assessment should establish what your evidence can support before the CPA examination.

What is a SOC 2 readiness assessment?

A SOC 2 readiness assessment examines whether the organization has defined the intended system boundary, designed the relevant controls, preserved evidence of operation, identified unresolved gaps, and prepared a coherent handoff for the independent service auditor.

The output should tell decision-makers what the current record supports, what remains conditional, and what must be corrected before examination. It should not be represented as a SOC 2 report, certification, audit opinion, or guarantee of an examination outcome.

SOC 2 readiness requirements for AI SaaS

The examination criteria do not become a separate framework merely because a service uses AI. The evidence boundary, however, may need to include AI-specific systems, providers, data flows, evaluation records, operational limitations, and change processes that a generic SaaS review could overlook.

1. Defined system boundary: Identify the in-scope AI service, environments, infrastructure, people, procedures, data, interfaces, subservice organizations, and customer responsibilities.
2. Control ownership and design: Record who owns each control, what the control is intended to accomplish, how often it operates, and which current policy or procedure defines it.
3. Dated operating evidence: Preserve attributable records for access reviews, approved changes, incident exercises, security testing, recovery tests, vendor reviews, exceptions, and remediation.
4. Evidence population and period: Identify the relevant population, examination period, sample source, collection date, exceptions, and any limitation on what the artifact can establish.
5. AI-specific dependencies: Document model and provider dependencies, intended-use boundaries, testing records, human oversight, change history, data handling, and material limitations.
6. CPA handoff boundary: Separate readiness findings from the independent service auditor’s testing, opinion, and report. Confirm the authorized criteria source and intended scope before exact mapping.

Start with the intended examination scope

A readiness project becomes unreliable when the team collects evidence before deciding which service, environments, commitments, locations, people, and third parties belong inside the intended system description. Overbroad scope creates unnecessary work. Narrow scope can leave customer-facing dependencies outside the evidence position.

Security is the common category. Availability, Confidentiality, Processing Integrity, and Privacy should be added only when the service commitments and intended examination require them. The authorized Trust Services Criteria source and exact categories should be confirmed with qualified review.

Control design and operating evidence are different

A policy or control description can help establish design at a point in time. It does not prove that the control operated throughout a period. SOC 2 Type II readiness therefore depends on recurring, dated records that can be associated with the control owner, population, period, sample, exceptions, and remediation.

If a quarterly access review is described but no completed review exists, the design record and the operating record must remain separate. Readiness work should expose that condition before the service auditor begins testing.

SOC 2 evidence collection should preserve context

Evidence should be identifiable without relying on a folder name or institutional memory. Useful collection fields include artifact owner, source system, collection date, evidence period, system association, control relationship, population, sample, exception status, content identity, review state, and freshness condition.

Common evidence areas include:

• Privileged-access assignments, approval records, MFA enforcement evidence, and completed access reviews
• Change requests, peer review, testing results, deployment approvals, and production change history
• Incident-response procedures, completed exercises, incident records, and post-incident actions
• Risk assessment, asset inventory, vendor and subservice-organization reviews, and accepted exceptions
• Backup records, completed restoration tests, monitoring records, and recovery objectives
• Security training, policy acknowledgments, vulnerability results, and remediation history
• AI model or provider inventory, data-flow records, evaluation evidence, human-oversight procedures, and material change records

The objective is not maximum document volume. It is a reviewer-traceable record showing which artifact supports which defined question, who accepted that relationship, and what limitation applies.

AI systems add evidence dependencies that generic SaaS preparation may miss

An AI service may depend on external model providers, vector stores, prompt or inference pipelines, model-routing logic, human review, evaluation records, customer-provided data, and rapidly changing subservice organizations. Those dependencies can affect system scope, data handling, change management, vendor oversight, availability, confidentiality, and processing commitments.

The readiness record should identify the material dependency, its role in the service, the evidence currently available, the responsible owner, and the condition that would require renewed review after a change.

Use the same evidence position for enterprise security questionnaires

Many AI SaaS companies encounter customer assurance questions before selecting a CPA firm or completing an examination period. A bounded readiness package can support those responses by separating what current evidence supports from what remains planned, conditional, or unresolved.

This matters because an enterprise security questionnaire records representations. The evidence package should show the basis for those representations and prevent a future commitment from being described as a control that already operates.

What the AGICOMPLY Baseline produces

The $3,500 ATO Readiness Baseline uses the same fixed commercial scope for a SOC 2 review context: one AI service and one intended examination or customer assurance boundary.

1. Evidence Inventory: what was supplied, by whom, for which system, and as of what date.
2. Mapping Summary: which evidence relationships are supported, conditional, or unresolved.
3. Gap Register: missing, weak, stale, contradictory, or incomplete artifacts.
4. Ordered Remediation Plan: what to address first based on reviewer dependency.
5. Chain-of-Custody Statement: the package boundary, integrity properties, review state, and change conditions.

The customer contracts separately with the CPA firm for the examination and report.

Frequently asked questions

Official sources

• AICPA SOC suite of services
• 2017 Trust Services Criteria with revised 2022 points of focus
• 2018 SOC 2 Description Criteria
• Illustrative SOC 2 Type II report