Want the instant version first? This guide covers the full 7-step process. For a 90-second baseline (five questions, a score out of 100, and three prioritized findings written from your auditor’s chair), take the 90-second check at /soc-2-readiness-assessment/. Read this for the framework; use the tool for a quick starting baseline.

A SOC 2 readiness assessment is the structured gap analysis you run before your official audit begins. It evaluates your controls against the AICPA’s Trust Services Criteria so you can find and fix problems while they are still cheap to fix. Done well, it turns the audit into a confirmation of work already done, not a discovery exercise the auditor runs on your behalf.

The seven steps below follow the order auditors examine your program. Work through them in sequence.

Run readiness before you engage an auditor

Start your readiness assessment 3 to 6 months before you want the observation period to open, not after you have signed an engagement letter. Gaps found in week two of your own assessment cost a fraction of gaps found mid-audit, when your auditor’s clock is running and remediation timelines are compressed.

The readiness phase has a concrete output: a gap register that maps every missing or deficient control to a responsible owner and a remediation deadline. That register drives the next 10 to 12 weeks. Without it, teams patch the loudest problems and miss the structural ones.

From the auditor’s chair, the companies that arrive with a completed gap register close audits faster and with fewer exceptions. The ones that skip formal readiness spend the observation window firefighting.

Define your scope first

SOC 2 scope defines exactly which services, infrastructure, data flows, and third-party dependencies the auditor will examine. Getting it wrong is the single most common reason initial submissions are rejected, adding months and significant cost to a first audit.

Produce a two-page scope diagram before you write a single policy. It should name the specific product or service being certified, the cloud regions and data centers involved, and every third-party subservice provider that touches customer data (AWS, Stripe, your identity provider, and so on). Anything left ambiguous invites scope creep or a rejection.

Scope also determines which Trust Services Criteria apply. Security (the Common Criteria) is mandatory in every SOC 2 engagement. Availability, Confidentiality, Processing Integrity, and Privacy are added only when your service-level commitments to customers require them. Choosing additional criteria unnecessarily increases audit cost and the number of controls you must evidence. Lock scope in the first week and treat it as a signed contract between you and your audit team.

Map your controls to the Trust Services Criteria

Build a control matrix with the Trust Services Criteria as rows and your existing policies as columns. Mark which documents address each criterion, even partially. Every empty cell is a gap. Every row with a mark is content you can keep, revise, or reference rather than rewrite from scratch.

Most companies already have 60 to 70 percent of the required policy content scattered across Confluence pages, onboarding runbooks, and engineering wikis. The mapping exercise surfaces that existing coverage. The result is a short list of net-new policies you actually need, not a hundred-item template dump.

Structure the matrix with five columns beyond the TSC reference: control owner (a person, not a team), evidence artifact (the exact file or log, not a category), automation status, last tested date, and remediation deadline. Any row missing an owner or an evidence artifact is a guaranteed exception waiting to happen. The matrix becomes the single source of truth for your entire compliance program and the primary working document your auditors will reference throughout the engagement.

Automate evidence collection from day one

Wire up evidence collection before the observation period opens. Auditors increasingly expect continuous proof across the full audit window, not a folder of screenshots assembled in the final weeks. Mid-tier firms have raised SOC 2 Type II fees an estimated 12 to 18 percent since 2024 in part because manual evidence creates heavier sampling workloads. Automated evidence reduces that friction for both sides.

Target 45 to 55 percent of your Common Criteria controls automated from the start. The tools for this already exist in your stack:

  • Cloud configuration: AWS Config Rules, GCP Security Command Center, or Azure Policy flag misconfigurations continuously.
  • Log collection: AWS CloudTrail or equivalent, piped to a tamper-evident destination.
  • Patch management: Endpoint management tools (Kandji, Jamf) provide automated patch-status evidence.
  • Access reviews: Connect your identity provider (Okta, Azure AD) to your compliance platform to collect access logs without manual exports.
  • Vendor risk: Use your compliance platform to send, track, and store security questionnaires for third parties automatically.

Compliance automation platforms (Vanta, Drata, Secureframe) act as the integration layer. Based on 2026 market data, platform costs run roughly $7,500 to $30,000 per year for a 20 to 200 person company pursuing a first SOC 2 framework. These are our estimates from publicly reported pricing ranges, not figures confirmed by any specific firm. The ROI case is straightforward: manual evidence collection typically costs 3 to 5 times more over two audit cycles when you factor in internal labor, and second-year audit fees for companies with automated evidence commonly drop 30 to 50 percent as auditors already know the environment.

Harden access and vulnerability management

Replace annual manual access reviews with a quarterly cadence supplemented by event-driven de-provisioning, and enforce a sub-seven-day patch SLA for critical and high-severity findings. These two areas produce the majority of SOC 2 Type II exceptions.

The CBIZ 2024 SOC Benchmark Study, based on a review of 193 SOC reports, found that 54.9 percent of reports contained at least one control exception. The top four causes: business approvals and reviews (16.5 percent of exceptions), user access reviews (15.6 percent), terminations (12 percent), and change management (11.7 percent). For the first time, user access review failures became the leading driver of qualified opinions, pushing the qualification rate from 8 percent to 10.9 percent year over year. Annual access reviews are no longer a defensible position.

For vulnerability management, build a closed-loop pipeline: automated daily scans across all in-scope infrastructure, findings piped directly into your ticketing system (Jira or equivalent) with auto-assignment, and an SLA dashboard your auditor can inspect. The evidence trail must show not just that you found vulnerabilities but that you closed them within your stated SLA.

For access management, use SCIM provisioning from your identity provider and HRIS event hooks so that terminations and role changes trigger automatic de-provisioning within hours, not the next quarterly review. The log of every access change becomes continuous evidence that your user lifecycle controls are operating as designed.

Lock down vendor risk and change management

Build a documented vendor vetting workflow and tie every production deployment to a reviewed, approved ticket. Without both, fast-moving teams routinely collect exceptions in these two areas.

For vendor risk, every third party that touches customer data needs a completed security questionnaire on file before they go into production, a risk score (low, medium, high based on data sensitivity and access level), and contract language that flows down your security requirements. Set up alerts for public security incidents involving your key vendors. Auditors look for a repeatable process, not a one-time exercise. Your vendor register should show continuous monitoring across the year, not a batch of questionnaires gathered in the weeks before the audit closes.

For change management, every production deployment needs an immutable evidence trail: a ticket describing the business need, a pull request linked to that ticket, peer review and approval before merge, an automated CI/CD run, and a deployment log in your cloud audit trail. The pull request approval is not documentation of a policy. It is the evidence itself. If your engineers can push to production without a linked, approved ticket, that gap will surface as an exception. Automated CI/CD pipelines that enforce branch protection rules are the most reliable way to close it.

Validate with a mock audit

Engage an experienced SOC specialist roughly 90 days before your observation period closes to stress-test your controls against real evidence. About 85 percent of companies surface 8 to 15 significant gaps at this stage, gaps that would have become exceptions in the final report.

A mock audit is not a friendly review. The specialist should request evidence as an auditor would, sampling across the full observation period rather than examining only current-state snapshots. Give them your control matrix, your evidence folders, and access to your compliance platform. Their job is to find what does not hold up under scrutiny.

Gaps found at the 90-day mark are still fixable. Gaps found after the observation period closes require restatement, a process that adds significant time and cost. Budget two to three weeks for the mock audit itself and another two to four weeks for remediation and evidence re-collection before the formal audit begins.

After the audit, maintain the program. Companies that treat SOC 2 as a one-time project rather than a continuous program face a markedly higher failure rate in year two. A lean trust function, even a fraction of an FTE from security and engineering plus a fractional compliance lead, keeps controls current and evidence flowing so the second audit is a re-confirmation, not a fresh effort.

FAQ

How long does a SOC 2 readiness assessment take?

Four to six weeks for a focused team with a clear scope. The gap analysis, policy inventory, and control matrix can run in parallel. Remediation takes longer and depends on what you find: plan 8 to 12 weeks for implementation before the observation period opens.

Type I or Type II?

A Type I report assesses control design at a single point in time. A Type II assesses operating effectiveness over 3 to 12 months. Most enterprise buyers require Type II. Start with Type II planning from the beginning unless a specific deal is blocked and you need a report immediately.

Do we need a compliance automation platform?

Not technically required. But in 2026, auditors who previously accepted quarterly snapshots increasingly expect continuous evidence across the full audit window. Manual collection is slower and more expensive over two cycles. For a 50 to 200 person company, platform fees run $7,500 to $30,000 per year (our estimates from publicly reported ranges) and are typically recovered in reduced audit prep time and lower second-year audit fees. For a detailed readiness checklist, see our SOC 2 compliance checklist.

Finding the right auditor is the step that follows a completed readiness program. We match companies with vetted SOC 2 audit firms based on timeline, budget, and industry, without the sales call carousel. Find your SOC 2 auditor at /find-my-soc-2-auditor/.