SOC 2 readiness is the work performed before the examination begins: defining the system and criteria in scope, understanding the control requirements, assessing whether controls are suitably designed, resolving gaps, and organizing evidence for the auditor.
Readiness is not a guarantee of an unmodified opinion. It is a structured way to identify problems before fieldwork and present an accurate, supportable description of the system and controls.
| Weak readiness approach | Stronger readiness approach |
|---|---|
| Policies reviewed without system scope | Scope and applicable criteria defined first |
| Controls described without owners or cadence | Controls have owners, frequency, and evidence expectations |
| Evidence requested only when fieldwork begins | Evidence retained as controls operate |
| Gaps discovered by the service auditor | Design and evidence gaps assessed before fieldwork |
1. Define the System and Examination Scope
Start with the service, system boundaries, legal entity, infrastructure, software, people, procedures, data, and relevant subservice organizations. A readiness checklist cannot be accurate until the system being examined is clear.
Confirm:
- Service and system included in the description
- Locations and infrastructure supporting the service
- Data, processes, and people within the boundary
- Subservice organizations and the presentation method used
- Examination type: Type I or Type II
- Specified date for Type I or review period for Type II
- Trust Services Categories relevant to customer commitments and system requirements
Security, represented by the Common Criteria, is included in every SOC 2 examination. Availability, Processing Integrity, Confidentiality, and Privacy are included when applicable to the engagement.
For a practical way to reuse prior-cycle material without assuming it remains valid, see How to Scope a SOC 2 Audit From Last Cycle's Evidence.
2. Understand the Applicable Trust Services Criteria
The applicable criteria span areas such as the control environment, communication and information, risk assessment, monitoring, control activities, access, system operations, change management, and risk mitigation.
Do not treat each criterion as a request for a policy. Determine which controls address the criterion in the scoped system and how those controls can be evaluated.
| Readiness area | Questions to answer |
|---|---|
| Governance and control environment | Who owns security and oversight responsibilities? |
| Risk assessment | How are relevant risks identified, analyzed, and addressed? |
| Logical and physical access | How is access authorized, restricted, reviewed, and removed? |
| System operations | How are events, vulnerabilities, incidents, and recovery activities managed? |
| Change management | How are changes authorized, tested, approved, and deployed? |
| Monitoring | How are control deficiencies identified, communicated, and remediated? |
3. Build a Control Inventory
List the controls expected to address the applicable criteria. For each control, record:
- Control statement and intended objective
- Applicable criterion or criteria
- System, population, and boundary
- Owner and reviewer
- Frequency or triggering event
- Procedure performed
- Evidence expected
- Relevant exception and escalation process
A policy may establish a requirement, but it does not by itself demonstrate that the related operational control occurred.
4. Assess Design Before Testing Operation
For each control, ask whether the design could reasonably achieve its objective if performed as described. Look for unclear ownership, missing populations, inconsistent frequency, undefined evidence, or procedures that do not cover the full system boundary.
The examination type determines whether readiness is assessed at a specified date or across a review period:
- Type I: addresses the description and suitability of control design at a specified date.
- Type II: also addresses operating effectiveness throughout the specified review period.
Readiness for Type II therefore needs both suitable design and evidence that the controls operated during the period.
5. Identify and Resolve Readiness Gaps
Frequent readiness gaps can include:
- Access reviews that are not performed on the defined cadence or do not cover the full population
- Changes without retained authorization, testing, or approval evidence
- Incident, vulnerability, backup, or monitoring activities without attributable records
- Policies that do not match actual procedures
- Controls without clear owners, frequencies, or escalation paths
- Evidence that does not cover the relevant dates, systems, or population
Do not call every readiness gap an audit finding. Record the issue, affected criterion and control, remediation owner, due date, and evidence needed to demonstrate closure. The service auditor independently evaluates the controls during the examination.
6. Retain Evidence as Controls Operate
Evidence should be produced or retained on the natural cadence of the control. Examples include dated access-review records when reviews occur, approved change records when changes are deployed, incident records when events occur, and monitoring outputs at the defined frequency.
Avoid two opposite assumptions:
- A screenshot collected during fieldwork does not necessarily demonstrate operation throughout a Type II period.
- Automated collection does not by itself prove that a control was correctly designed or reviewed.
Evidence should be attributable, scoped, dated, retained, and traceable to the control it supports. See how to turn evidence freshness into a repeatable check.
Keeping that context connected also reduces the work of reconstructing it during readiness. Compass by Truvara works from available policies, controls, risks, and evidence to prepare source-linked proposals for human review and keeps unsupported material visible instead of filling the gap.
7. Perform a Readiness Review and Assemble the Package
Before fieldwork, confirm that:
- The system description matches the actual environment
- Applicable criteria are mapped to controls
- Control owners validate the descriptions
- Relevant evidence is available for the date or period
- Known deviations and gaps are documented accurately
- Complementary user entity controls and subservice-organization responsibilities are identified
- Requests, owners, and delivery methods are coordinated with the service auditor
The objective is not to make the package look perfect. It is to make it accurate, complete within scope, and supportable.
The Takeaway
SOC 2 readiness begins with scope, not evidence collection. Define the system and applicable categories, build a control inventory, assess design, resolve readiness gaps, and retain evidence as controls operate. For Type II, confirm that the evidence covers the specified review period rather than only the start of fieldwork.
FAQ
How long does SOC 2 readiness take?
There is no universal timeline. It depends on scope, examination type, existing control maturity, unresolved gaps, and whether sufficient evidence already exists for the relevant date or period.
What is the hardest part of SOC 2 readiness?
It varies by organization. Common challenges include defining scope, translating criteria into accurate controls, resolving design gaps, and retaining evidence that covers the relevant system and period.
Are all five Trust Services Categories required?
Security, represented by the Common Criteria, is included in every SOC 2 examination. Availability, Processing Integrity, Confidentiality, and Privacy are included when applicable.
What is the most common SOC 2 finding?
There is no universal “most common” issue supported by the Trust Services Criteria. Readiness teams should assess their own design, operation, scope, evidence, and known deviations rather than relying on a generic ranking.