Companies usually begin the SOC 2 process with a misdirected question: how long until the report arrives. The more useful question is what an auditor will need to see before the examination period can even start. SOC 2 readiness is the work that happens beforehand — the policies, evidence trails, and control operations that make the examination a review of existing practice rather than a scramble to create documents that should have existed months earlier.
The consequence of skipping that work is familiar: controls get implemented in a rush during the observation window, evidence is collected retroactively and looks manufactured, and the final report carries qualifications that prospective customers ask about for the following year.
This guide outlines what readiness involves: the criteria in scope, the foundation documents, the evidence auditors examine, how roles divide, and a realistic timeline.
What Readiness Means in Practice
Readiness means the organization can demonstrate, with dated artifacts, that its controls operated consistently throughout the period under review. Three conditions must hold at once:
- The controls exist and are appropriate for the commitments you make to customers.
- The controls operated for the full period, not only when someone was watching.
- Evidence of that operation is retrievable, attributable, and consistent across systems.
A readiness assessment tests all three and produces a gap list. Without that list, the first time you learn a control is undocumented is during fieldwork, when correcting it is at its most expensive.
Scope and the Trust Services Criteria
Scope decisions drive cost, effort, and the usefulness of the report. Define the criteria you intend to include and the system boundary precisely. The boundary describes the infrastructure, software, people, procedures, and data that deliver the service. Drawing it too broadly pulls irrelevant systems into the audit; drawing it too narrowly invites customer objections and, in the worst case, produces a report that does not cover what you sold.
Security is the common baseline. Availability addresses whether the system is operational as committed. Confidentiality covers information designated as confidential, while privacy addresses personal information collected, used, retained, and disclosed as committed. Most first-time reports include security alone, or security with availability.
The Foundation: Policies, Roles, and Governance
Before evidence matters, the organization needs documented intent that matches reality. A typical foundation includes an information security policy set, a risk assessment, an asset inventory, access control and change management procedures, an incident response plan, a vendor management process, and a business continuity plan.
The most common readiness failure is producing a policy template that describes controls the company does not operate. Written intent that differs from daily practice is worse than a modest policy that is followed, because auditors test both the document and the operation, and discrepancies become exceptions.
Assigning Ownership and Writing Testable Controls
Readiness stalls when responsibility is diffuse. Name a single accountable owner with executive sponsorship and enough authority to change processes, and define who maintains evidence, who reviews policies annually, and who approves exceptions. Controls should then be mapped to the criteria and written so they can be tested: who performs the activity, how often, what record it produces, and what happens when it is missed. Vague commitments such as “access is reviewed as appropriate” cannot be tested and will be flagged.
Evidence: What Auditors Actually Examine
Evidence collection is where most of the pre-audit effort belongs. Auditors want to see that controls operated across the whole period, which means sampling records rather than accepting a description. Typical areas include:
- Access management — onboarding and offboarding records, access reviews, and privilege approvals with dates.
- Change management — tickets showing testing, approval, and deployment for changes made during the period.
- Vulnerability and patch management — scan output, remediation timelines, and exception approvals.
- Monitoring and alerting — configuration showing alerts exist, plus records that they were reviewed and actioned.
- Incident response — incidents during the period, how they were handled, and post-incident reviews.
- Risk assessment — the assessment performed in the period and evidence that results were acted upon.
- Vendor management — the inventory of subservice organizations and their reviews or reports.
- Training and continuity — awareness completion records with dates, plus business continuity and restore test results.
Auditors sample records rather than accepting a description, so controls must leave a trail across the whole period. Where a control cannot be automated, schedule it and record completion in a shared tracker so the audit becomes a collection exercise rather than an investigation.
A Realistic Timeline
Timelines depend on the size of the environment and the maturity of existing processes, but a typical sequence looks like this:
- Weeks one to two: scope definition, boundary agreement, and criteria selection.
- Weeks two to six: readiness assessment, gap list, and prioritization.
- Weeks four to twelve: remediation — writing policies, configuring controls, establishing evidence routines.
- Weeks twelve onward: the observation period, during which controls must operate consistently.
- Thereafter: fieldwork, draft review, management responses, and report issuance.
The observation window is the part organizations underestimate. A period-based report covers operating effectiveness, so controls must be live before it begins. Attempting to compress that period by starting remediation late pushes the report date out by months, which is where readiness work pays for itself.
Frequently Asked Questions
How long does readiness take before an audit can start?
For a small environment with some process maturity, remediation often takes one to three months, after which the observation period begins. Organizations starting with little documentation should plan for longer, especially if controls must run for a full review period.
Do we need a separate readiness assessment?
It is strongly advisable for a first examination. A readiness assessment identifies gaps while they are cheap to fix and clarifies scope before the auditor’s clock starts, which usually reduces total cost despite the added step.
Can readiness work be done internally?
Yes, and many companies do it. The trade-off is time and objectivity. Internal teams know the environment well but may not know how auditors test controls, so organizations often combine internal effort with external guidance on scope and evidence expectations.
Readiness is the discipline of making your security program demonstrable. Scope it deliberately, write policies that match practice, assign clear ownership, and generate evidence continuously rather than in a panic. Do that and the audit becomes verification of work already done — the version of the process that finishes on the date you planned.
This article is general information only and is not professional, legal, or audit advice. Audit requirements and criteria interpretations vary by practitioner and by the commitments you make to customers. Consult a qualified auditor or compliance advisor before planning your program.