Talk to a specialist
Home / SOC 2 guide / Readiness assessment

SOC 2 · Practical business guide

SOC 2 Type 2 readiness assessment: gaps, priorities and deliverables

Use this readiness checklist to test the scope, controls and operating evidence for your intended SOC 2 Type 2 examination. Turn findings into owned improvements, verify the result and prepare a clear handoff to the independent CPA firm.

In this guide
Identify gaps in scope, control operation and evidenceEstablish a scope and evidence baselineExamine whether the control can achieve its purposeEstablish the population, then inspect representative eventsWrite findings that distinguish the problem typeTurn readiness findings into verified improvementsHypothetical example: a SaaS company discovers incomplete change evidenceHypothetical example: a BPO tests workforce assignment controlsPrepare a complete evidence handoff to the independent firmFrequently asked questionsPlan the next decisionRelated SOC 2 guides

Identify gaps in scope, control operation and evidence

A SOC 2 readiness assessment evaluates whether the organisation has a clear system boundary, relevant controls and usable evidence for its intended examination. It should identify gaps before they become rushed explanations during fieldwork. The practical output is a set of decisions and improvements with owners, priorities and closure evidence. A readiness report is not the independent SOC 2 examination report and should not be represented as one.

AICPA’s public guide description distinguishes the system description and applicable control criteria within an assertion-based examination. Readiness can help management prepare those elements and operate the underlying programme, while the CPA firm retains responsibility for the independent engagement. Agree that separation of roles and any independence considerations early. References: AICPA SOC 2 reporting guide public description; AICPA SOC suite of services.

Start with the proposed report user and service. A readiness assessment built around a generic company checklist may miss the product, location or supplier the customer actually depends on. Confirm the intended boundary and discuss the relevant criteria with the independent firm before investing heavily in evidence collection or policy rewriting.

Establish a scope and evidence baseline

Collect a concise service description, major commitments, system and data-flow information, workforce responsibilities and relevant supplier relationships. Identify the intended date or period and category coverage for discussion with the CPA. Record assumptions and unresolved questions. The baseline should be detailed enough to guide review while remaining understandable to management and service owners.

Inventory existing evidence by purpose and period. Policies, configurations, tickets, logs, approvals and test results answer different questions. A current screenshot can show a setting at one time; it cannot necessarily establish historical operation. A policy can show an intended rule; it cannot prove that every relevant event followed it. Label these distinctions at the start to avoid treating a full folder as a complete evidence base.

Identify owners who can explain the work. Security may coordinate readiness, but human resources, engineering, operations, procurement and management often operate material controls. Invite them into the assessment rather than asking one coordinator to reconstruct every process second-hand. Their involvement also makes remediation more realistic because the people responsible understand the finding.

Set safe evidence-handling rules. Use read-only access, protected exports or controlled demonstrations as appropriate. Avoid transferring unnecessary customer content, credentials or sensitive investigation material into a general assessment workspace. The readiness process should establish assurance without creating new uncontrolled data exposure.

Examine whether the control can achieve its purpose

A design review asks whether the planned control addresses the relevant risk or requirement in the scoped service. Identify the trigger, responsible role, action, decision criteria, evidence and response to failure. A statement such as access is reviewed periodically is incomplete if nobody knows the population, reviewer or action following an inappropriate permission.

Follow dependencies. An offboarding process may depend on reliable workforce notification and a complete application list. A change approval may depend on the ability to distinguish production changes from routine configuration. A recovery control may depend on keys and supplier access. The control can look reasonable in isolation while failing because an upstream input is missing.

Review how exceptions are handled. A process that works only for the easiest cases may fail during an emergency, unusual customer request or staff absence. Define authorised alternatives and preserve accountability. Avoid creating an exception route so broad that it becomes the normal path without meaningful review.

Keep control wording aligned with actual intent. Overly ambitious descriptions can create obligations the organisation has not designed or resourced. Weak wording can conceal a real risk. Management should decide the appropriate control and implement it, with professional guidance on criteria mapping, rather than treating the readiness exercise as a search for language that makes gaps less visible.

Establish the population, then inspect representative events

Operating review asks whether the process is being performed and whether records support that conclusion. Select representative activities such as workforce changes, deployments, supplier reviews, incidents and recovery tests. The readiness team can use targeted sampling to find problems, but should not imply that its sample substitutes for the independent firm’s examination procedures.

Understand the population before inspecting examples. If the organisation cannot identify all relevant production changes, a few approved tickets may not establish that the process covers the environment. Reconcile sources where practical: deployment records against change tickets, workforce events against account removals, supplier payments against the relevant inventory. Record limitations where completeness cannot be established.

Check timeliness and follow-through. An access reviewer may identify inappropriate permissions that are never removed. A vulnerability ticket may be closed without a retest. An incident lesson may remain unassigned. Evidence should connect the initial activity to the decision and completed action, not stop at the point where someone acknowledged the issue.

Preserve failures honestly. A missed review or late removal is useful readiness evidence because it reveals where the process needs improvement. Do not backdate approvals or create records implying that historical work occurred when it did not. The team can document present investigation and correction accurately while discussing the examination implications with the CPA.

Write findings that distinguish the problem type

Separate unclear scope, inadequate design, inconsistent operation and unavailable evidence. These problems require different responses. An evidence retrieval issue may be solved by locating existing records; a process that was never performed cannot be repaired by organising folders. A design gap may require a system change, while a scope gap may require another stakeholder or supplier to participate.

A useful finding states what was observed, the affected service or control, supporting evidence, why it matters and what would demonstrate improvement. Avoid generic ratings without explanation. A manager should be able to understand the consequence and assign action without asking the assessor to translate every line of the report.

Prioritise by risk, examination relevance and dependencies. A broad privileged-access exposure may deserve immediate action. An incomplete policy index may need correction but not the same urgency. Some foundational work, such as a reliable asset or workforce inventory, may enable several controls. Explain those dependencies so the roadmap supports coherent implementation.

Record questions that require the independent firm’s judgement. Readiness advisers can help prepare evidence and clarify facts, but they should not guarantee an opinion or tell management that a particular exception will be immaterial. Current AICPA public discussion warns about quality risks in rushed SOC services. A credible readiness process makes difficult facts visible early. Reference: Journal of Accountancy: promises of fast and easy threaten SOC credibility.

Turn readiness findings into verified improvements

Assign each action to an owner with authority over the change, not automatically to the compliance coordinator. Define the target condition, dependencies, expected evidence and review point. A task labelled improve change management is too vague; a task specifying the change population, approval route and verification gives engineering and management a shared outcome.

Distinguish immediate containment from permanent correction. Restricting a risky access path may reduce exposure while a more complete role design is implemented. Record the interim limitation and the condition for replacing it. Temporary arrangements need ownership and follow-up so they do not become an undocumented permanent state.

Verify implementation with meaningful tests. A revised access process should demonstrate an approved grant and removal through the relevant systems. A logging change should produce useful events and a review outcome. A recovery change should show the service can be restored under the agreed conditions. Document what the test establishes and what remains outside it.

Reassess readiness at a deliberate checkpoint. Review open high-impact items, evidence coverage and material scope changes with management and the independent firm. The decision to begin or continue an examination should be based on accurate facts, not the percentage of checklist rows coloured green. Keep unresolved issues explicit and avoid promising that a clean readiness presentation guarantees the final report outcome.

Hypothetical example: a SaaS company discovers incomplete change evidence

A fictional SaaS company believes it is ready because every code change receives peer review. A readiness walkthrough compares deployment records with repository approvals and finds a separate administrative console used for production configuration. Those changes can alter customer access but do not pass through the same review process. The existing evidence is valid for one path, not for the complete change population.

The team maps the configuration path and identifies its owner, risk and appropriate approval process. Engineering explains which changes are urgent and which can follow routine review. Management approves a design that preserves emergency capability with clear authorisation and follow-up. The control description is updated to reflect the actual process rather than pretending all changes occur through source code.

A pilot records representative changes and compares them with the relevant system events. One manual path remains difficult to identify, so the team improves logging and ownership before declaring the task closed. The readiness finding retains the original evidence limitation and the date the new process began operating.

The company discusses the reporting-period implications with the independent firm. It does not create retrospective approvals for changes that were never reviewed. The value of readiness is that the organisation discovers and improves a material path while it can still make deliberate decisions about scope, timing and evidence.

Hypothetical example: a BPO tests workforce assignment controls

A fictional BPO manages customer document-processing work through several portals. Its central access policy is clear, and internal accounts are removed promptly when staff leave. Readiness sampling finds that reassigned workers retain access to prior customer portals because assignment changes are not treated like departures. The control weakness sits between operations, customer contacts and technical administration.

The assessment distinguishes the effective internal account process from the incomplete customer-access lifecycle. It identifies the relevant population of assignments and the evidence needed from customer-controlled systems. The BPO develops a service-specific access register with approval, change and confirmation steps, while account managers coordinate the customer dependencies.

A controlled test follows a worker moving from one account to another. The new access is granted correctly, but removal from one customer portal requires a manual request that was omitted from the first design. The team adds the step and retests. It also checks whether local quality-review files remain accessible after the assignment ends.

The readiness output gives management a clear implementation problem and evidence of correction. It does not label the entire organisation unready simply because one path failed, nor does it hide the failure behind a strong internal identity platform. The report supports a proportionate decision about remaining work and examination planning.

Prepare a complete evidence handoff to the independent firm

The handoff should include the agreed scope, current system description work, control map, relevant evidence locations, material changes and unresolved matters. AICPA’s description criteria are intended for preparing and evaluating the system description; the public resource record confirms that purpose, while the full criteria should be used through authorised access. Reference: 2018 SOC 2 Description Criteria, revised implementation guidance 2022.

Explain the readiness method and its limits. State which areas were interviewed, observed or tested and which evidence periods were reviewed. The CPA firm will determine its own procedures. Readiness documentation should make that work more efficient by clarifying the environment, not attempt to preselect only favourable evidence or constrain independent enquiry.

Ensure management and control owners can explain the programme themselves. A consultant should transfer knowledge and editable records so the organisation can respond accurately when questions arise. Staff should distinguish what the control is intended to do, what actually happened and where the evidence is retained.

After handover, maintain the programme. Workforce, systems and suppliers continue changing. Readiness is a point in a continuing process of operating and improving controls, not an enduring state granted by a report cover. The strongest engagement leaves the organisation better able to recognise change, preserve evidence and address weaknesses without waiting for the next external review.

Frequently asked questions

Is a readiness assessment the SOC 2 report?

No. It prepares management and identifies gaps. The independent CPA examination and resulting report are separate work with their own requirements and professional judgements.

Can we recreate missing historical evidence?

You can investigate and document what can be supported, but do not fabricate or backdate records. New controls and records demonstrate present or future work, not activities that never occurred.

What should readiness deliver?

A clear scope, evidence-based findings, prioritised actions, owners and verification criteria, together with an honest account of limitations and questions for the independent firm.

Plan the next decision

For readiness support, identify the service, intended report user, target date or period and the evidence already available. Ask for a review that separates design, operation and evidence gaps, followed by a roadmap with testable closure conditions.

Discuss readiness for the report your customer requires with CyberVantage360. Our SOC 2 readiness and implementation service can be scoped around findings that separate design, operation and evidence gaps, with owners and testable closure criteria.