SOC 2 readiness assessment: how to find and close your gaps before the audit

The enterprise prospect's security team wants a SOC 2 report before the contract moves, and your team says you are "nearly ready". Nobody can say what "nearly" means in weeks, or which gaps an auditor would find first. A SOC 2 readiness assessment answers that before the auditor does.

It measures your controls against the Trust Services Criteria, so you know your gaps, how long closing them will take and when to book the audit. This guide is for founders, COOs and security leads at UK B2B tech firms with 25 to 100 staff, many already holding or pursuing ISO 27001. It sets out the two decisions to make first, a six-step gap method, a way to rate each gap by its effect on the audit opinion, and the project plan that follows.

What is a SOC 2 readiness assessment?

A SOC 2 readiness assessment measures your controls against the AICPA Trust Services Criteria before a CPA firm examines them. It starts with two decisions, the report type and the criteria in scope, then tests each control's design and evidence. It ends with rated gaps and a remediation roadmap that tells you when to book the audit.

For what SOC 2 is and why buyers ask for it, start with our SOC 2 overview. This page assumes you already know you need a report and want to know how far away it is.

The readiness assessment is your work, not the auditor's. A SOC 2 report is an attestation: the Journal of Accountancy, the AICPA's own journal, describes SOC reports as examinations performed by CPAs under the AICPA's attestation standards. Nothing you produce in readiness appears in that report. What appears is how your controls perform once the examination starts.

If you have run an ISO 27001 gap analysis, the shape will feel familiar. Our ISO 27001 gap analysis guide uses the same logic of scope, walk, evidence, score and roadmap. The difference is the yardstick: SOC 2 measures you against criteria and your own service commitments, not a certifiable management system standard.

Which two decisions come first in a SOC 2 readiness assessment?

A SOC 2 readiness assessment answers two questions before it tests anything. First, will you commission a Type 1 or a Type 2 report, and what observation window does that imply? Second, which trust services categories beyond Security belong in scope? Both decisions belong to your management, and both change what the assessment has to test.

Decision 1: Type 1 or Type 2. A Type 1 report covers whether your controls are suitably designed on a single date. A Type 2 adds whether they operated effectively across a period. For readiness, the choice sets the bar: a Type 1 needs controls designed and in place, while a Type 2 needs them running and leaving evidence from the first day of the window.

The Journal of Accountancy's guide to SOC 2 engagements notes there is "no generally accepted minimum useful period" for a SOC 2 report, so the window length is agreed with your auditor and your buyers. Our SOC 2 Type 1 vs Type 2 guide covers the full comparison and how to time a first window.

Decision 2: which categories beyond Security. The same guide treats scope as management's call: management decides which services and trust services categories the report covers, and should weigh the needs of report users, including their regulatory obligations. A SOC 2 report can include any combination of Security, Availability, Processing Integrity, Confidentiality and Privacy.

Keep the scope tight. Add a category when a buyer's contract, questionnaire or regulator asks for it, not because it sounds thorough. Every category you add is more criteria to walk, more controls to evidence and more places for an exception to land.

How do you run a SOC 2 readiness assessment, step by step?

Run a SOC 2 readiness assessment in six steps: set the scope and system boundary, walk the common criteria, walk any additional criteria in scope, check each control's design, check evidence that it operates, then rate every gap and build the roadmap. Each step feeds the next, so skipping the evidence step makes every later rating unreliable.

Step 1: Set the scope and system boundary

Name the service the report will cover, then draw its boundary. List the infrastructure, software, people, procedures and data that deliver it, and mark where your cloud providers and other suppliers sit. The JofA guide is clear that a system is more than hardware and software: it includes people, procedures and data.

Write the boundary down early, because it becomes the backbone of your system description. The AICPA's description criteria (DC 200) are the benchmark for preparing and evaluating that description, so the readiness assessment should check your draft against them.

Step 2: Walk the common criteria

The common criteria are the Security criteria in the AICPA's 2017 Trust Services Criteria, numbered CC1 to CC9. Walk them group by group, with the people who own each area in the room. The table gives the questions we recommend asking; it is a planning aid in our words, not the criteria text.

If your controls grew out of engineering practice, expect CC1 to CC4 to need the most new paperwork. Those groups ask for governance decisions that leave a written record.

Step 3: Walk any additional criteria in scope

If Decision 2 added Availability, Confidentiality, Processing Integrity or Privacy, walk those criteria next. Each brings its own expectations, such as capacity and recovery for Availability or retention and disposal for Confidentiality. Our guide to the Trust Services Criteria covers each category in detail.

Step 4: Check control design

For each criterion, name the control that meets it, its owner and what it is meant to prevent or detect. A design gap is a criterion with no control, or a control that could not meet the criterion even if it ran perfectly. This step is what a Type 1 examination tests, so it must be clean before you commission one.

Step 5: Check evidence of operation

Interviews tell you what people believe happens. For each control marked as designed, ask for the records it produced: the last access review, a recent change ticket, the latest leaver's access removal. The AICPA's SOC 2 report review checklist notes that inquiry-based procedures are not appropriate on their own, so a control you can only describe is not yet ready.

Choose the samples yourself and cover a period, not a moment. For a Type 2, the question is whether the control could show evidence for every occurrence across the window you plan to open.

A readiness assessment that finds nothing has usually tested nothing.

Step 6: Rate the gaps and build the roadmap

Give each gap a rating by its likely effect on the audit opinion, as set out below, then turn the rated findings into the phased plan in the roadmap section. The rating decides the order; the plan decides the dates. Working from a written checklist of criteria, controls and evidence keeps the walk complete and makes the ratings repeatable next year.

How should you rate gaps in a SOC 2 readiness assessment?

Rate each gap by what it would do to the audit opinion if it were still open when the auditor tested it. A gap that could qualify the opinion comes first. A gap likely to produce a test exception comes next. Description and documentation fixes follow, then improvements. The scale is ours; the consequences follow how SOC 2 opinions work.

The AICPA's review checklist explains that a qualified opinion means the auditor "identified material factors affecting the opinion". Those factors can come from misstatements in the system description, from control design or operating effectiveness exceptions, or from a lack of evidence, which the checklist calls a scope limitation. It also notes that an unmodified opinion does not mean no exceptions were found.

That gives four practical ratings:

Rate against your own evidence, not against the team's confidence. If nobody can produce a record, the gap cannot be rated lower than High.

What does an existing ISO 27001 ISMS already cover for SOC 2?

An ISO 27001 management system gives a SOC 2 readiness assessment a strong head start: a risk assessment, policies, named owners, an internal audit cycle and controls that already leave records. The AICPA publishes a mapping between ISO 27001 and the Trust Services Criteria. Gaps usually remain in the system description, service commitments and period-long operating evidence for every control.

Run a carry-over pass before walking the criteria, so the team does not rebuild what already exists. The AICPA's mapping of the 2017 Trust Services Criteria to ISO 27001 compares the two sets of requirements and is available to AICPA members. If you do not have access, map your Statement of Applicability against the criteria groups in the table above.

The biggest difference is how evidence is tested. A SOC 2 Type 2 report describes the auditor's tests of operating effectiveness and their results, so every in-scope control needs records across the whole period.

If you are earlier in the journey, our ISO 27001 guides cover building the management system that SOC 2 then draws on.

What should a SOC 2 project plan look like after the assessment?

A SOC 2 project plan turns rated gaps into six phases: scope and resources, risk assessment, control remediation, evidence build-up, a mock audit or Type 1, and the observation window. Close gaps in rating order, Critical first, and fix nothing in a way that leaves no record. The window opens only when every in-scope control is running.

Phase 1: Scope and resources. Confirm the report type, categories and system boundary from the two decisions. Name an executive owner, a day-to-day lead and an owner for each control area, and agree how much of their time the project needs.

Phase 2: Risk assessment. Refresh or build the risk assessment for the in-scope system, because control choices should follow risks. Owners of an ISO 27001 ISMS can usually extend their existing assessment rather than start again.

Phase 3: Control remediation. Close Critical and High gaps first. Fix design before operation: a control that cannot meet its criterion will not improve by running longer.

Phase 4: Evidence build-up. Switch every control to producing records, and test that the records exist before the window opens. We recommend running each periodic control at least once in this phase, so the first occurrence inside the window is not also the first ever.

Phase 5: Mock audit or Type 1. Re-test a sample of controls as an auditor would, or commission a Type 1 to get an independent view of design. Fix what this finds before committing to a window start date.

Phase 6: Observation window. Open the Type 2 window on a date you choose. From that day, every in-scope control is on the record, and the work becomes keeping controls running, not building them.

The observation window does not care when you meant to start the control.

Keep the findings register live through all six phases. Updated as gaps close, it becomes the progress tracker, and it shows the auditor at planning that you know your own weak points.

Who should run your SOC 2 readiness assessment?

You can run a SOC 2 readiness assessment internally, with an independent adviser or, with care, through your eventual service auditor. Internal teams know the system, but scoring colleagues' work impartially is hard. Advisers add independence and pattern knowledge. Your service auditor can help only within AICPA independence rules, because the same firm must later give an impartial opinion.

The independence point matters most. AICPA rules on nonattest services apply when a CPA firm does other work for a client it will also examine. A Journal of Accountancy article on maintaining independence with nonattest services explains that the CPA "cannot assume management's responsibilities" and must be satisfied that the client's management will meet them. The same article describes a self-review threat: the risk that an auditor will not properly evaluate work its own firm performed.

The AICPA's ethics guidance on SOC engagements and tool providers adds that service auditors should apply the Code of Professional Conduct in its entirety in SOC 2 examinations.

In practice, the three routes compare like this:

• Internal. Lowest cost and closest to the system. Works when someone understands the criteria and can challenge colleagues' work.
• Independent adviser. Brings an outside view and a ready method, and has no stake in the eventual opinion. Your management still owns every decision.
• Your service auditor. Knows exactly what it will test, but its help is limited to what keeps it independent. Ask how it will protect its independence before you agree.

Whichever route you choose, the readiness work can come from anyone, but the opinion can only come from a licensed CPA firm. Software tools can organise evidence, but the AICPA's journal points out that tool providers which are not CPA firms "cannot attest" that controls are effective.

What should a SOC 2 readiness assessment output include?

A SOC 2 readiness assessment output should contain the two scoping decisions, a findings register with the evidence behind every rating, a heatmap by criteria group, a phased remediation plan with owners and dates, a first draft of the system boundary, and a short summary for leadership stating when the audit can realistically be booked.

Each part serves a different reader:

• Scoping decisions. Report type, categories in scope and the reasons, written so the auditor can confirm them at planning.
• Findings register. Every criterion, its control, owner, rating and the evidence sampled. This is the working document for the people closing gaps.
• Heatmap. CC1 to CC9 and any additional categories on one page, coloured by rating. This is what leadership reads.
• Remediation plan. The six phases with owners, dependencies and target dates, ending at a proposed window start.
• System boundary draft. The service, its components and its suppliers, ready to grow into the system description.
• Leadership summary. Readiness today, the three to five gaps that drive the timeline and the decisions needed.

A good output turns straight into a checklist the team can work through, item by item, until every row is closed.

What are the most common SOC 2 audit preparation mistakes?

The most common SOC 2 audit preparation mistakes are scoping more categories than buyers asked for, treating policies as evidence, opening the observation window before controls run, assuming an ISO 27001 certificate covers SOC 2, and asking the future auditor to design controls it will later test. Each makes readiness look closer than it is.

Watch for these in particular:

1. Scoping for appearance. Adding a category that no buyer, contract or regulator asked for, then finding it is the one holding the report back.
2. Counting documents, not records. A signed policy shows design intent. Only records show operation.
3. Opening the window early. A control switched on in the window's second month cannot show it operated throughout.
4. Skipping the description. The system description is assessed against DC 200, and errors in it can affect the opinion.
5. Blurring roles with the auditor. Management owns the controls and the decisions; the auditor's role is limited by independence rules.
6. Rating generously. Optimistic ratings shorten the plan on paper and lengthen it in practice.

The fix for most of these is the same: base every rating on evidence, and finish with a plan someone owns. Done that way, the readiness assessment becomes the first working version of the control set your buyers will rely on.

Frequently asked questions