90 Day SOC 2 Readiness Playbook: Catch 8–15 Audit Gaps

90 Day SOC 2 Readiness Playbook: Catch 8–15 Audit Gaps

A SOC 2 readiness assessment is a structured dry run that checks whether your controls, evidence, and documentation would survive a real audit before you pay an auditor to find out the hard way. The next move, once you know that, is simple: lock your system scope on a two-page diagram and get an auditor or mock auditor looking at it within the next two weeks. Everything else in the checklist follows from that one decision.

TL;DR:

A SOC 2 readiness assessment identifies control gaps before the formal audit, with auditor-aligned reviews balancing cost and confidence for first-timers.
Most organizations find 8 to 15 significant gaps during mock audits, which require two to four weeks of remediation efforts.
Consistent ownership and automated reminders for evidence deadlines reduce risks of stale controls and failed assessments.
A control matrix with current statuses and evidence is essential to accurately simulate real audits and spot issues early.
Readiness projects typically span six to eighteen months from initial assessment to final report, depending on environment complexity and remediation speed.

Table of Contents

• What Is a SOC 2 Readiness Assessment?
• Why Run Readiness Before the Formal Audit?
• The Phased SOC 2 Readiness Checklist
• Type I vs. Type II: When to Bring In Your Auditor
• The Gaps Auditors Find Most Often
• How Long Readiness Takes and What It Costs
• Tools That Support Continuous Evidence Collection
• Why Deadline-Driven Practices Reduce Audit Risk
• Validating Readiness With a Mock Audit and Control Matrix
• Getting Internal Teams Ready, Not Just the Documents
• Risks That Derail Readiness Projects
• Maintaining Readiness After You Pass
• How SOC 2 Readiness Affects Client Trust and Sales
• What I Got Wrong Watching Readiness Projects Fail
• Where a Deadline-Driven Platform Fits Into Readiness
• Sources
• FAQ

What Is a SOC 2 Readiness Assessment?

A SOC 2 readiness assessment is a controlled review of your environment against the AICPA’s Trust Services Criteria before the actual audit begins. It produces three concrete outputs: a gap register listing every control that isn’t fully in place, a remediation plan with owners and deadlines, and an evidence list mapping each control to the artifact that proves it works. Skip any one of those three and you don’t have a readiness assessment, you have a status meeting.

The distinction that trips people up is who runs it. A self-assessment, done entirely in-house using a checklist or spreadsheet, is cheap and fast but carries real blind spots, because the person grading their own controls tends to grade generously. An auditor-performed readiness review, run by the same firm or a different CPA firm that will eventually issue your report, costs more and takes longer to schedule, but it tells you what the actual audit will find, not what you hope it finds.

Most organizations land somewhere in between, and that middle ground breaks into three practical tiers:

• DIY readiness: internal team owns the checklist, control matrix, and evidence collection with no outside review. Fastest and cheapest, highest risk of missed evidence expectations.
• Auditor-aligned readiness: internal team does the work, but a CPA firm reviews scope, control design, and a sample of evidence at set checkpoints. Aprio recommends this tiered model specifically because it catches evidence-format mismatches before they become audit exceptions.
• Auditor-performed readiness: a CPA firm runs the full gap analysis. Highest cost, highest confidence, best for first-time Type II candidates with complex environments.

If this is your first SOC 2 cycle, auditor-aligned is the sweet spot. Pure DIY only makes sense if someone on your team has actually sat through a SOC 2 audit before.

Why Run Readiness Before the Formal Audit?

Skipping straight to the audit is how organizations end up with a qualified opinion, a report that lists exceptions instead of a clean pass. Auditors don’t grade on effort. If a control was supposed to run for the full observation period and it only started three months in, that’s an exception on the final report, and there’s no fixing it after the fact.

Readiness catches the failure modes that show up over and over: access reviews that happened once instead of quarterly, change tickets missing approval timestamps, and vendor risk assessments that exist for the big vendors but not the smaller ones the auditor happens to sample.

The real cost trade-off: readiness guides consistently report first-time programs surfacing 20 to 60 remediation items during the gap analysis. Fixing those before the audit costs engineering hours you control. Fixing them after the auditor flags them costs those same hours, plus auditor rework fees, plus a delayed report your sales team was counting on.

The Phased SOC 2 Readiness Checklist

Treat readiness as five sequential phases, not a single project. Each phase has a clear exit condition, and jumping ahead before the previous phase is done is the single most common reason readiness projects stall.

Phase 1: Scoping

Pick your system boundary first. This means naming which product, service, or business unit is actually in scope, which Trust Services Criteria beyond the mandatory Security criterion you’ll include (Availability, Confidentiality, Processing Integrity, Privacy), and whether you’re pursuing Type I or Type II.

Map your subservice organizations here too. If AWS or a payroll processor performs part of your control environment, decide now whether you’re carving them out (inclusive method) or relying on their own SOC reports (carve-out method). Build a two-page scope diagram showing systems, data flows, and boundaries. This single artifact prevents more scope creep than any policy document you’ll write, because it gives the auditor something concrete to react to in the first meeting.

Phase 2: Control Design and Mapping

Build your control matrix now, before you write a single policy. Each row needs seven columns: the Trust Services Criteria reference, a plain-English control description, a named control owner (not a team, an actual person), the evidence artifact path, automation status, the last test date, and a remediation deadline if the control isn’t fully operating.

This matrix becomes your single source of truth for the rest of the project. Every gap you find later gets logged against a specific row.

Phase 3: Implement and Document

Write and publish the policies your control matrix references: access control, change management, vulnerability management, incident response, and vendor risk. Then implement the technical controls behind them, multi-factor authentication, role-based access, patch cadences, and vendor questionnaires. Documentation without implementation is worthless in an audit; implementation without documentation is nearly as bad, because the auditor can’t verify what they can’t see written down.

Phase 4: Evidence Collection and Gap Assessment

Write test scripts for each control, essentially a one-paragraph description of how you’d verify it’s operating. Build a document request list mirroring what an auditor will ask for. Then run a “Test of One”, pull a single sample of evidence for each control and check whether it actually proves what you claim. This phase is where most gaps surface, because it’s the first time anyone actually looks at the evidence instead of assuming it exists.

Phase 5: Mock Audit, Remediation, and Retest

Run a mock audit roughly 90 days before your Type II observation window closes, using auditor-style sampling rather than a friendly internal walkthrough. Expect 8 to 15 significant gaps even on a well-prepared program. Budget two to four weeks after the mock audit for remediation and retesting before you consider the environment audit-ready.

Auditors sample; they don’t average. A control that’s Ready nine months out of twelve is not a Ready control.*

When you brief your auditor ahead of fieldwork, hand them the control matrix with current statuses attached rather than a narrative summary. It saves a full meeting and signals you actually ran a real readiness assessment, not a checklist exercise.

Type I vs. Type II: When to Bring In Your Auditor

A Type I report tests whether your controls are designed correctly as of a single point in time. A Type II report tests whether those same controls actually operated effectively across an observation window, typically three to twelve months. Type II is the report most enterprise buyers and procurement teams actually want to see, because it proves the controls worked over time, not just on paper.

Only a licensed CPA firm can issue either report; that’s an AICPA rule, not a market preference. That single fact shapes when you should bring an auditor into the process.

• Before scoping is finalized: a short alignment call to confirm your system boundary and Trust Services Criteria selection matches what the auditor expects to test.
• During control design: a review of your control matrix and evidence formats, before you spend months collecting evidence in a format the auditor won’t accept.
• Before the observation window opens (Type II only): confirmation that controls are actually operating, not just documented, since anything that starts mid-window creates a partial-period exception.
• At the mock audit stage: many CPA firms will run or review a mock audit as a paid engagement distinct from the formal audit.

Engaging an auditor early costs a bit more up front but consistently prevents the most expensive failure mode: collecting the wrong evidence for months and discovering it during fieldwork, when there’s no time left to fix it.

The Gaps Auditors Find Most Often

A handful of failure patterns show up in nearly every readiness assessment, and they’re almost always fixable with a specific artifact, not a policy rewrite.

• Access reviews and MFA: auditors want quarterly access review records showing who reviewed, what changed, and a timestamp, plus MFA enforcement logs for every privileged account. A verbal confirmation that “we review access” is not evidence.
• Change management provenance: every production change needs a traceable chain, a ticket, a linked pull request, an approval, and a CI/CD deployment log. Missing any link in that chain is one of the most common exceptions auditors write up.
• Vendor management: you need a current vendor inventory, signed risk questionnaires, contract language covering data handling, and evidence you actually monitor vendors after onboarding, not just at signing.
• Vulnerability management: a defined scan cadence, documented remediation SLAs by severity, and tickets that show a vulnerability was actually closed, not just detected.
• Ownership gaps: controls with no single named owner are the fastest way to fail a mock audit, because “the team handles it” isn’t an answer an auditor accepts.

Weak access controls and patching gaps are the initial access vectors auditors care most about, which is exactly why those two categories generate more exceptions than any other control family.

Pro Tip: If a control’s evidence lives in three different tools and nobody can produce it on demand, that’s a gap even if the control itself is working. Auditors test the evidence trail, not your intentions.

How Long Readiness Takes and What It Costs

Timelines scale with how mature your environment already is, but the patterns are consistent enough to plan around. First-time Type II candidates typically spend two to six weeks on the initial gap analysis and eight to twelve weeks on remediation before the observation window even opens.

End to end, a first Type II report commonly takes six to eighteen months from kickoff to issued report. If a sales deal or investor requirement is driving a target quarter, work backward from that date, subtract the observation window length, then subtract remediation time, and that gives you your real start date, not the date you feel ready to start.

The line item that surprises most teams isn’t the auditor’s fee. It’s the engineering hours spent building evidence pipelines and fixing access control gaps discovered mid-project, work that competes directly with product roadmap time.

Tools That Support Continuous Evidence Collection

Automation earns its place in a readiness program by cutting the manual work of pulling evidence every quarter, not by replacing the judgment calls that decide whether a control is designed correctly in the first place.

Strong automation candidates include identity provider integrations (Okta, Azure AD, or similar) for access review evidence, endpoint management tools for patch compliance, vulnerability scanners for cadence and closure tracking, CI/CD logs for change management provenance, and HRIS triggers that generate provisioning and deprovisioning evidence automatically when someone joins or leaves.

• Pull access review evidence directly from your identity provider instead of manual spreadsheet exports.
• Feed vulnerability scan results into a system that links each finding to a remediation ticket and closure date.
• Automate HR-triggered provisioning and deprovisioning evidence so onboarding and offboarding create their own audit trail.
• Store every artifact in a tamper-evident system with defined retention, linked back to its control matrix row.

None of this replaces the human judgment an auditor applies during sampling, and software supply chain provenance still needs manual verification that no scanner catches on its own. Aim to automate roughly 45 to 55 percent of Common Criteria evidence collection from the start; that target reduces sampling friction without pretending automation can carry the whole program.

Why Deadline-Driven Practices Reduce Audit Risk

The control matrix only works if someone actually owns each row, and ownership only means something if it’s tied to a deadline someone gets reminded about. That’s the operational gap most readiness programs hit: the matrix looks great in a spreadsheet, then a quarterly access review quietly slips because nobody set a recurring trigger for it.

A practical workflow looks like this: assign a named owner to each control matrix row, set an automated reminder ahead of the evidence due date, require the owner to deposit the evidence artifact into a linked store, and escalate to a manager automatically if the deadline passes with no evidence logged. That loop is exactly how license and certification tracking works in other compliance-heavy fields, where a missed renewal date carries real operational consequences, not just an audit exception.

Validating Readiness With a Mock Audit and Control Matrix

The control matrix is your readiness program’s ground truth, and the mock audit is how you test whether that ground truth would survive contact with a real auditor. Run them together, not as separate exercises, because a matrix that looks complete on paper often falls apart the moment someone applies auditor-style sampling to it.

Start by pulling your control matrix and confirming every row has a current status, a named owner, and a linked evidence artifact, not a placeholder. Then bring in someone who wasn’t involved in building the controls, ideally your auditor or a mock auditor firm, and have them sample evidence the way a real audit would: pick a handful of controls at random, request the underlying artifact, and check whether it actually proves the control operated during the claimed period.

Expect this to be uncomfortable. Well-prepared programs still turn up 8 to 15 significant gaps during a mock audit, usually a mix of stale evidence, missing approval timestamps, and controls that were “true” in spirit but not documented in a way an outside party could verify. That’s the point of running it now instead of during the real fieldwork.

Log every finding back into the control matrix as a new gap register item with a remediation deadline, then retest. Two to four weeks is a realistic remediation window for most mock audit findings. If your mock audit turns up zero gaps, that’s usually a sign the sampling wasn’t rigorous enough, not that your program is flawless.

Getting Internal Teams Ready, Not Just the Documents

SOC 2 readiness fails almost as often from people problems as from missing controls. Engineers who don’t know they’re a control owner can’t produce evidence on demand, and a policy nobody’s read isn’t a control, it’s a document.

Start by naming owners explicitly in the control matrix and telling each person directly what they’re responsible for and by when. A shared spreadsheet nobody checks is not the same as an owner who knows their name is attached to a specific evidence deadline.

Run a short training session, thirty minutes is usually enough, covering what SOC 2 actually requires, what “evidence” means in an audit context, and where to deposit artifacts. Engineers frequently assume a control is fine because the underlying system works; auditors care whether you can prove it worked, which is a different bar entirely.

Give department leads visibility into their team’s open gap register items rather than routing everything through a single compliance owner. A security manager chasing fifteen engineers individually for evidence doesn’t scale past a small team, and it turns compliance into a bottleneck people resent.

Finally, treat the mock audit as a training exercise, not just a checkpoint. Walking an engineer through why their change management ticket got flagged teaches them what “audit-ready” actually looks like far better than a policy document ever will.

Risks That Derail Readiness Projects

The most common failure isn’t a missing control, it’s a wrong assumption about how much progress you’ve actually made. Self-graded checklists tend to drift toward “In progress” or even “Ready” long before the evidence backs that up, and nobody catches it until the mock audit or, worse, the real one.

Scope creep is the second major risk. Adding a new Trust Services Criterion or a new system to the boundary mid-project resets significant portions of your control matrix and evidence collection, and teams routinely underestimate how much that costs in time.

Treating readiness as a one-time project rather than an operating rhythm causes evidence to go stale between the readiness assessment and the actual audit fieldwork, sometimes months apart. A control that was operating correctly in March means nothing if nobody can prove it kept operating in August.

Watch for these specific pitfalls:

• Grading controls as Ready based on intent rather than tested evidence.
• Expanding scope after the control matrix is already built, without revisiting affected rows.
• Assuming automation covers a control fully when it only covers data collection, not the underlying judgment.
• Letting a single person hold undocumented knowledge of how a control actually works.

None of these are exotic risks. They’re the same five or six patterns showing up across nearly every first-time SOC 2 program.

Maintaining Readiness After You Pass

A SOC 2 report is a snapshot of a period that already ended, not a permanent status. The moment your Type II observation window closes, the clock starts again for the next one, and controls that quietly lapse between audits are exactly what generate exceptions the second time around.

Keep the control matrix alive as a living document rather than an artifact you build once a year. Every new system, vendor, or process change should trigger a review of whether it affects an existing control or needs a new row entirely.

Build recurring evidence collection into your calendar rather than scrambling before the next audit. Quarterly access reviews, ongoing vulnerability scan cadences, and vendor monitoring all need standing triggers, not a rush every renewal cycle.

Assign continuous ownership the same way you did during initial readiness, and treat any lapsed deadline as a gap register item immediately rather than waiting for the next formal assessment to surface it. Organizations that treat SOC 2 as a continuous operating discipline, rather than an annual fire drill, consistently walk into their next Type II audit with far fewer surprises.

How SOC 2 Readiness Affects Client Trust and Sales

For B2B software companies, a SOC 2 report increasingly functions as a sales prerequisite rather than a nice-to-have. Enterprise procurement teams routinely ask for a current Type II report before a deal moves past legal review, and a missing or stale report can stall a signature for weeks while security teams request an alternative.

Readiness itself, even before the formal report, signals something to prospective clients during due diligence. A vendor that can produce a current control matrix and a clear remediation timeline looks materially more credible than one fumbling for documentation on a call.

The trust dividend compounds over renewal cycles too. Clients who onboarded partly on the strength of your SOC 2 status tend to ask fewer security questions at renewal, because the report itself does the reassurance work that would otherwise fall on your sales and security teams in every single contract cycle.

What I Got Wrong Watching Readiness Projects Fail

The mistake I see most often isn’t a missing control. It’s optimistic self-scoring, marking something “Ready” because the team meant well, not because the evidence would hold up to a real sample. That single habit is why so many organizations walk into fieldwork blindsided.

Run the mock audit at the 90-day mark, not later, and expect real gaps, 8 to 15 is normal even for a well-prepared team. Then use calendar-driven reminders and escalation rules so remediation deadlines don’t quietly slip the way access reviews always seem to.

The teams that pass cleanly aren’t the ones with perfect controls from day one. They’re the ones honest enough to grade themselves poorly early, while there’s still time to fix it.

— Kuldeep

Where a Deadline-Driven Platform Fits Into Readiness

Expiryedge exists for exactly the problem that derails most SOC 2 programs: control owners losing track of when evidence is due. Instead of chasing fifteen engineers across Slack every quarter, you assign each control matrix row to a named owner inside the platform, attach the evidence artifact, and let automated reminders handle the follow-up before the deadline, not after it’s already missed.

That structure maps directly onto the phases covered above: automated reminders ahead of access review and vulnerability scan cadences, escalation trails when an owner misses a deadline, and a centralized record you can hand your auditor instead of assembling one under deadline pressure. The same recurring-deadline logic that keeps property compliance calendars on track applies just as well to a SOC 2 control matrix, since both are really the same problem: recurring obligations with real consequences if nobody’s watching the date.

If your readiness project is currently tracked in a spreadsheet nobody updates consistently, start a free trial of ExpiryEdge and set up your first control owner reminders before your next mock audit.

Sources

• AICPA: SOC for Service Organizations — overview
• CISA: Weak security controls and practices routinely exploited for initial access
• Aprio: SOC 2 readiness assessment: don’t start with an exception on the books
• SOC2Auditors: SOC 2 Readiness Assessment: 7-Step Framework (2026)

FAQ

How often is SOC 2 compliance required?

SOC 2 itself isn’t a one-time certification with a fixed renewal date; most enterprise clients expect a current report covering the trailing twelve months, so organizations typically go through a Type II audit annually to keep that window current.

What is a SOC 2 compliance checklist?

A SOC 2 compliance checklist walks through scoping, control design, implementation, evidence collection, and a mock audit, with each item scored as Not started, In progress, or Ready and tied to a named owner and evidence artifact.

What is the difference between SOC 1, SOC 2, and SOC 3?

SOC 1 covers controls relevant to a client’s financial reporting, SOC 2 covers security and related Trust Services Criteria for service organizations, and SOC 3 is a shorter, publicly shareable summary of a SOC 2 report without the detailed testing results.

What does SOC 2 compliance actually mean?

It means an independent CPA firm has tested your organization’s controls against the AICPA’s Trust Services Criteria and issued a report confirming those controls are designed correctly (Type I) or operated effectively over a period of time (Type II).

How long does a SOC 2 readiness assessment take?

For first-time Type II candidates, the initial gap analysis typically takes two to six weeks, with remediation running another eight to twelve weeks before the observation window opens.

Recommended

• How Fire Safety Inspection Tracking Works for Compliance Teams
• How Clinical Staff License Monitoring Works: Compliance Guide
• Benefits of Automated Compliance Tracking for Teams
• How to Set Up a Property Compliance Calendar That Works