Summary: A SOC 2 readiness assessment confirms three things before you commit real money to an audit: the right controls are in place, you have evidence to support them, and that evidence the is good enough for your auditor to rely on. This article is a step-by-step checklist for scoping, evidence, and the auditor’s role in your SOC readiness assessment.
Why do a SOC 2 readiness assessment before your audit?
A SOC 2 readiness assessment exists to answer one question before you spend real money finding out the hard way: Am I actually in a position to start a SOC 2 — Type I or Type II — and come out the other side without control deviations and with a clean opinion?
This means confirming three things up front: the right controls are in place, you have evidence to support them, and that the evidence is good enough for your auditor to actually rely on. Get those right and the audit is a formality. Get them wrong, or never check, and here’s what tends to happen to companies that skip readiness and head straight into the audit: exceptions in the report, control deviations, evidence that isn’t sufficient to support the auditor’s conclusions, and in the worst case a qualified opinion. If you want a clean report, then you have to stop the audit process, fix the gaps, and wait another four or more months to get your report. All of this from deficiencies you didn’t know you had, because nothing surfaced them first.
These are the real costs of skipping a readiness assessment. It isn’t just rework and lost time to closing the contract. It’s also reputation cost due to a report with exceptions on the record or a qualification that you then have to explain to the very customers who asked for the report in the first place.
Start here: a 30-second self-assessment
Before you read another word about how to run a readiness assessment, answer these three questions honestly. They predict, better than your company’s size or budget, whether you can do this yourself.
- Has anyone on your team personally taken a SOC 2 through to a clean opinion before — not just sat through one, but owned the controls and the evidence?
- Do you know which controls you actually need — and are you confident an auditor would agree, rather than tell you you’ve built too few or far too many?
- For each control, can you show it’s actually operating — produce the most recent instance of it running, not just point to a policy that says it should?
|
How to read your answers: |
|---|
|
The first question is the honest tell. If no one on your team has taken a SOC 2 through to a clean opinion before, experience — not effort — is what’s missing, and no tool can replace it.
Three ways to run a readiness assessment
There aren’t three different processes. The steps are the same for everyone. What changes is the level of auditor involvement you bring in at the moments where judgment, not effort, decides the outcome.
| Tier | What it is | Right for you if |
|---|---|---|
| 1: DIY | You run it yourself end-to-end | Someone in the role has taken a SOC 2 to opinion before and ideally run readiness assessments themselves |
| 2: Auditor-aligned | You do the work; your auditor validates scope, design, and evidence at the key gates | You have some experience but want an auditor check on the judgment calls |
| 3: Auditor-performed | Your auditor guides the design of controls and performs the gap assessment; you own remediation | You want confidence going into the audit with no surprises and don’t have deep SOC experience in-house |
A more practical path
A candid note before you work through the steps: even teams with real experience rarely produce a flawless DIY readiness assessment. The recurring failures are controls that aren’t written right, aren’t evidenced right, or don’t have sufficient reliable evidence to support an opinion on implementation (Type I) or operating effectiveness (Type II).
So the honest recommendation isn’t “DIY versus auditor.” It’s that running a readiness assessment with zero auditor involvement rarely makes sense. At a minimum, even if you DIY, involve your auditor in the design of controls and schedule periodic check-ins to confirm the evidence you’re unsure about is the evidence the auditor will actually look for.
Why your auditor belongs in this from the start
The instinct is to build everything first and bring the auditor in at audit time. That’s backwards, and it costs you in both directions.
The right scope from day one can make a difference
Scope too low. You look at the criteria, put in the controls you think are required, and the auditor arrives to find you’re missing 20 things needed for proper design of controls. Now you’re not ready, and your timeline slips while you remediate.
Scope too high. You buy a GRC tool and implement all 150 controls it ships with. The auditor tells you that you needed maybe 60. You’ve buried yourself, and your team, in work you never needed.
Bringing the auditor in at the start collapses both errors: right-sized scope, properly designed controls, and the fastest path to a clean report instead of a delayed or bloated one.
“Isn’t ‘involve the auditor early’ just a way to bill more hours?”
No — at least not the way it should work. Readiness should be a fixed-fee engagement: you’re told up front what it costs, what steps will be performed, and what comes off your plate, so you know the real cost on day one. Scoping and design of controls have to be agreed with your auditor at some point, we do that at no charge as part of the audit preparation process. Extra billings are rare and almost always tied to client delays during gap assessment testing, and even then, you should be told in advance and agree before any extra work happens. No surprise invoice after the fact.
“Doesn’t the auditor helping with scope compromise independence?”
No, because the auditor never acts on behalf of management. The line is bright and it matters:
- The auditor advises and guides, explaining what suitable design looks like, what risks each SOC 2 criterion requires you to address, and where evidence will need to hold up.
- The auditor does not select or design your controls. Management defines and owns them.
- During the gap assessment, the auditor inspects the controls management defined and reports what the evidence supports and what needs revision to be relied upon — but the auditor has no involvement in remediation. Management owns that.
That separation is what lets the auditor make the suitable-design statement in the eventual opinion. They couldn’t evaluate design objectively if they’d designed the controls themselves. The guidance informs; it doesn’t author.
The readiness assessment checklist
This is the process, in the order you’d actually run it. Each step is marked:
✓ Self-assessable — you can handle this with internal knowledge.
⚑ Judgment point — where DIY most often goes wrong; an auditor’s view materially de-risks it.
Phase 1 — Scope and design of controls
☐ Define the system(s) in scope. ✓
☐ Define the underlying infrastructure supporting your in-scope system. ✓
- Cloud or colo
- RDS
- SQL
- AMIs
- Authentication / SSO
- Supporting applications
☐ Define the Trust Services Categories relevant to your system. If you do this without your auditor, they may not agree on scope. ⚑
☐ Define the controls needed to address the relevant risks for the in-scope TSCs, and determine whether any criteria should be out of scope for your environment. Same pitfall: your auditor may disagree on scope or design. ⚑
☐ Align with your auditor on the TSCs and controls in scope, so you have proper design of controls. ⚑
|
What the design of controls meeting looks like (Tier 3): |
|---|
| The auditor arrives with pre-work done: they’ve taken every criterion for the in-scope TSCs, analyzed the risks each criterion requires addressed, and built a set of reference controls. Reference controls are a guide, not a mandate. Management isn’t required to adopt them; they exist to help you understand what kind of control satisfies each criterion. In a roughly four-hour session, the auditor and your control owners walk through them and land on the controls you’ll actually use. You leave with a list of the controls you defined, plus a running list of gaps noted along the way — a verbal gap assessment. |
Phase 2 — Implement and document
|
A note on work you’ve already done: |
|---|
| Many companies have implemented real security before they ever engage an auditor — information security policy, antivirus, baseline controls. That’s not a problem; much of it is reusable for SOC 2, and controls you have for your own business reasons (even ones SOC 2 doesn’t require) are fine to keep. Just don’t assume existing work maps one-to-one to SOC 2 scope. Design of controls is what defines the SOC 2 slice of your control environment. |
☐ Document the policies and procedures that support your in-scope controls. The auditor confirms sufficiency later. ✓
- Information Security Policy
- Disaster Recovery / Business Continuity
- Data Classification Policy
- Data Retention / Destruction Policy
☐ Complete your risk assessment, ensuring it touches all relevant risks for the in-scope TSCs and criteria. Leverage your GRC tool’s risk assessment functionality if you have one. ✓
Sequencing: policy/procedure documentation and the risk assessment belong after design of controls and before the gap assessment — that’s your implementation window. Some of it may spill to after the gap assessment, since the gap assessment surfaces things you didn’t know you were missing.
☐ Set up your GRC platform (if you’re using one) after scoping and design, never before. ⚑
- Select the relevant controls based on the scoping and design work above. Map controls in before design is done and you’ll over-implement — selecting more than your environment needs.
- Define the tasks in the tool that keep your time-bound controls operating: access reviews, recurring meetings, and security awareness training.
- Set up integrations with your audit source systems. The integration configuration must be viewable and validatable by your auditor, otherwise they cannot rely on the GRC platform as a source system.
|
Does the GRC tool help or just add overhead? |
|---|
| It helps only if you implement it right, configure it right, and maintain it. Done that way, it earns its keep in two ways: integrations pull audit data from your source systems and task reminders keep the recurring controls (access reviews and training) from quietly lapsing into exceptions. It becomes shelfware, a glorified filing cabinet, when it isn’t properly configured, holds the wrong control set, and isn’t maintained. The tool’s job is to help you do the things that maintain compliance, not just store proof you intended to. |
Phase 3 — Gap assessment and evidence
☐ Build test scripts and a document request list for the in-scope controls; share it so management knows exactly what will be asked, can question it, and can reconcile it to where evidence actually lives. In an auditor-performed engagement, the auditor builds these; the review itself often surfaces more gaps.
☐ Identify auditable evidence in place to support each control. If you do this without your auditor, the evidence you think will work may not work for them. ⚑
☐ Validate you can provide auditable evidence over a historical period — the Test of One. For each control, produce the most recent instance of it operating: ⚑
- New hire: background check performed, security awareness training completed, and code of conduct signed.
- Existing employee: performance review in the last year.
- Change management: most recent change ticket, tested and approved before implementation.
- Logical access: most recent access request approved before access was granted; terminated employee’s access removed timely.
- Populations: confirm you can pull a complete and accurate population from a source system for the populated controls (every change, access grant, new hire, and termination). Not critical for a Type I but is essential for a Type II.
|
Test of One ≠ Type II testing: |
|---|
| The Test of One is one recent sample to confirm a control is real and operating, not full-period operating-effectiveness sampling. A Test of One sample proves the control has been implemented, which is sufficient for a Type I. |
☐ Produce the gap report (auditor-performed): the controls tested, the results, the specific gaps, and recommendations for how management might remediate them.
Phase 4 — Remediate and schedule
☐ For each gap, develop a remediation plan and implement the control. Management owns remediation, the auditor has no involvement here. That ownership is exactly what keeps the auditor independent.
☐ Confirm timing with your auditor as far in advance as possible, so they can support your audit and hit your target for a report in hand.
|
The Type I single-engagement payoff (Tier 3): |
|---|
| Because a Type I is a point-in-time report, the testing performed during the gap assessment can be leveraged toward the Type I itself. If management remediates gaps within roughly 45 days of the initial gap assessment, the auditor can retest those controls and apply all of it toward issuing the Type I. In effect, you get a readiness assessment, a gap assessment, and a Type I out of a single engagement for a minimal incremental fee on the Type I. |
Final thoughts: so, can you do it yourself?
Yes, you can. But the gate isn’t your size; it’s experience. You need someone in the role who has been through the SOC reporting process, knows what reliable evidence actually looks like, and understands what controls need to be in place — ideally someone who has run readiness assessments before. A hired ex-auditor is the profile that makes DIY viable. Add a properly implemented GRC tool on top of that experience and DIY gets more achievable, because the templates and evidence guidance compound the in-house knowledge.
But the GRC tool is also where DIY quietly goes wrong. It will tell you the types of evidence that typically satisfies the controls you select, and your auditor may not agree. The risk in tool-led DIY is going down an evidence path the platform blessed, but your auditor won’t rely on. Make sure you’re producing auditable evidence your auditor agrees with, not just what the tool says is right.
And the honest part: even with experience in-house, a flawless DIY readiness assessment is rare. So the decision really comes down to one question — how confident do you want to be, walking into the audit, that you won’t hit a wall of issues? The less SOC experience you have on your team, the more that confidence has to come from having your auditor perform the readiness assessment for you.
Powell Jones leads Aprio’s ISO practice within the Risk Advisory & Assurance group, where the team delivers SOC 1, SOC 2, SOC 3, ISO 27001, PCI, and CMMC engagements for technology companies across the U.S.
