A readiness assessment is the step between deciding to get a SOC 2 and starting the observation period. Done well, it tells you exactly what stands between you and a clean first report, in what order to fix it, and when you can start. Done badly, it produces a long spreadsheet of criteria marked red, amber, and green, and very little you can act on.
The difference is in what the assessment covers and what it hands you at the end. This article sets out the areas a useful readiness assessment should reach, the outputs to insist on, and how to judge one, whether you run it yourself or bring someone in.
What readiness is for
A readiness assessment answers one question: if the observation period started today, which controls would fail, and why? It is a form of gap assessment, aimed at a specific audit.
It differs from the audit in two ways. Nothing is reported to anyone outside your organization, so findings cost nothing except the work to fix them. And it can look at design and operation together, so you learn whether a control exists on paper, in practice, or both.
What it is not: a pre-audit that guarantees a result. Only your auditor can form an opinion, and only on evidence from the period.
The eight areas it should cover
A readiness assessment that only checks controls against criteria is half the job. The useful ones cover the whole engagement.
1. Scope
Confirm the decisions that define the report: services covered, system boundary, locations, categories, and report type. If these are not settled, nothing else can be assessed reliably. How to scope your first SOC 2 report covers what each decision involves.
2. Commitments
List the service commitments your report will be measured against, from contracts, service level agreements, data processing agreements, and public statements. An assessment that never reads your contracts cannot tell you whether your controls meet what you promised.
3. Controls against criteria
For each criterion in scope, identify the controls that address it, and assess each control on two questions: is it designed to meet the criterion, and is it operating today? A control that exists in policy but not in practice is a gap, even if the spreadsheet calls it covered.
4. Evidence
For each control, ask what evidence it produces and try to produce it. This is the step weak assessments skip. A control that runs but leaves no record will fail testing as surely as one that does not run. Check that evidence is dated, attributable, and comes from the system where possible.
5. Policies
Check that each required policy exists, is approved, and matches practice. The practical failure is a policy that promises a frequency or a standard the team does not meet. The auditor tests against the policy, so the policy has to be true.
6. Vendors and subservice organizations
Identify which vendors are subservice organizations, how each will be treated in the report, and whether you have current SOC reports for them. Check that your vendor review process exists and has records.
7. Customer responsibilities
Draft the complementary user entity controls and check them against your product and contracts. Gaps here surface late if nobody looks early.
8. The system description
Check whether a draft exists and whether it matches the system. Teams often leave the description until the end, then find it contradicts the controls. Writing the SOC 2 system description covers what it must contain.
The outputs you should get
An assessment is only as useful as what it leaves behind. Insist on these:
- Not done:
A scope statement, agreed internally and ready to share with your auditor
- Not done:
A control matrix mapping each control to the criteria it addresses
- Not done:
A gap list, with each gap described specifically enough to act on
- Not done:
An owner and a target date for every gap
- Not done:
A priority order, separating what must be fixed before the period starts from what can follow
- Not done:
An evidence plan saying how each control's evidence will be produced and kept during the period
- Not done:
A recommended period start date, with the conditions that must be met first
The gap list is the core. "CC6.2 not met" is not a gap description. "Leaver access is removed by manual ticket, with no check that every system was covered, and no record of completion time" is.
Gaps readiness commonly finds
The same gaps show up in many first assessments. If your assessment found none of these, check that it looked:
Leaver access with no timing evidence. Access was removed, but nothing records when, so timeliness cannot be shown.
A risk assessment with no fraud risk and no review of what changed.
Vendor reviews with no record. The team knows its vendors but cannot show a dated review of any of them.
Backups never restored. Relevant where availability is in scope, and often for business continuity under the common criteria too.
Unapproved or stale policies, or policies that promise more than the team does.
No record of oversight. Nobody above day-to-day management has a dated record of reviewing security.
Who should run it
You can run readiness yourself, use an advisor, or ask an audit firm. Each has trade-offs.
Running it yourself is cheapest and builds understanding in the team that will operate the controls. Its weakness is that you assess against your own reading of the criteria, which is the reading most likely to have blind spots.
An outside advisor brings experience of what auditors test. Look for one who reads your evidence rather than interviewing your team and taking answers on trust.
An audit firm knows how auditors think. If the firm that will perform your audit also offers readiness, ask how it handles independence. The AICPA's independence rules limit the services an audit firm can provide to a client it examines, and designing or operating your controls is management's responsibility. Some organizations use one firm for readiness and another for the audit for that reason.
Whichever route you choose, the assessor should look at real evidence. An assessment based only on interviews tells you what people believe, not what the systems show.
How to judge whether it was useful
After the assessment, a skeptical compliance lead should be able to answer these questions without reopening it:
What exactly is in scope, and has the auditor seen that?
Which gaps must close before the period starts, and who owns each one?
Which controls have we seen produce evidence, and which have we not?
When can the period start, and what has to be true first?
If the answers are vague, the assessment was a checklist, not readiness work.
Once gaps are closed, the next decisions are timing. Choosing your SOC 2 Type II observation period covers length and dates, and first audit mistakes and how to avoid them covers what tends to go wrong after you start. The SOC 2 readiness checklist walks through the common criteria area by area if you want a starting point.
How TrustLynce helps
TrustLynce's readiness dashboard shows readiness per framework and a gap analysis against the criteria you choose. For teams that want an outside view, TrustLynce's audit readiness services include a dedicated advisor.