SOC 2 Readiness Assessment Checklist: 15 Steps to Prepare for Audit

A $400K annual contract, six months of sales effort, and three executive presentations. Then the procurement team sends a two-line email: “Please provide your SOC 2 Type 2 report.”

You do not have one. The deal stalls. Your competitor, the one with a clean SOC 2 report, closes it instead. 

For SaaS companies selling into mid-market and enterprise accounts, a SOC 2 report has moved from “nice to have” to “non-negotiable.” The good news is that SOC 2 audit preparation follows a predictable path. The bad news is that most teams underestimate the gap between “strong security” and “audit-ready documentation.” 

This SOC 2 readiness assessment checklist covers 15 steps across five phases, from defining scope through sustaining a continuous compliance program. It is built for teams preparing for their first SOC 2 or resetting after a difficult initial audit. For a broader walkthrough of SOC 2 requirements, see our SOC 2 compliance checklist.

What Is a SOC 2 Readiness Assessment (and What It Is Not)

A SOC 2 readiness assessment is a pre-audit exercise in which a qualified advisor evaluates whether your controls are designed and operating at a level to meet the AICPA Trust Services Criteria (TSC).. 

It does not produce a SOC 2 report or replace the audit, but rather prepares you for it.

The distinction matters because teams frequently confuse three related activities:

• A gap analysis compares your current controls to the relevant TSC and documents the deltas..
• A readiness assessment goes further. It includes the gap analysis plus evidence-readiness testing, system description review, mock sampling, and operational cadence validation. It tells you what is missing and whether you can prove what exists.
• A formal SOC 2 audit is an attestation engagement performed under AT-C 205 by a licensed CPA firm. The auditor forms an independent opinion on whether your controls meet the criteria. Only a CPA firm can issue the report.

One critical constraint: AICPA independence rules (AT-C 105) require that the firm performing readiness assistance cannot make management decisions or audit its own work. 

The SOC 2 Guide (November 2022 edition) also states that the service auditor must exercise care to avoid making decisions on management’s behalf during readiness engagements. This is why many organizations engage a GRC advisory partner for readiness and a separate CPA firm for the audit.

A readiness assessment is only as useful as your willingness to act on its findings. If gap-report items sit in a backlog for months, you have paid for a document, not readiness.

SOC 2: Readiness assessment vs gap analysis vs formal audit

The 15-Step SOC 2 Readiness Assessment Checklist

These 15 steps follow the sequence used by real programs, organized into five phases:

• Strategic foundation
• Team and auditor setup
• Readiness assessment
• Remediation and observation
• Formal audit and sustainment.

Phase 1: Strategic foundation

1. Confirm the business trigger and choose Type 1 or Type 2

Every SOC 2 program starts with a business reason. Name it clearly, because the trigger determines urgency, scope, and budget.

The most common triggers include an enterprise customer requiring SOC 2 during pre-funding due diligence at Series B or later, a lost deal to an SOC 2-certified competitor, or compounding regulatory pressure from HIPAA, GDPR, or state privacy laws. 

A common pattern is that startups tend to go for other alternatives like security questionnaires, escrow agreements, or custom contractual assurances. But enterprise buyers often reject them and prefer only SOC 2 reports. Leaving the deal on the table, going to a competitor that has one.

Once the trigger is clear, the next decision is Type 1 or Type 2.

• Type 1 report evaluates control design at a single point in time. 
• The Type 2 report evaluates both design and operating effectiveness over a defined period, typically 3 to 12 months. 

Enterprise procurement overwhelmingly prefers Type 2 because it proves controls actually worked over time, not just that they existed on paper one afternoon.

Here is a practical decision framework:

• If the customer needs a report within four months and you have no prior audit, start with Type 1 as a bridge. Plan Type 2 immediately after.
• If you have six or more months of runway, skip Type 1 entirely. Go straight to Type 2. This avoids about $15,000 to $30,000 in duplicate audit fees.
• If your controls are already operating and documented (for example, you maintain ISO 27001), proceed directly to Type 2.

As the Fly.io engineering team noted after their own SOC 2 journey, you cannot travel back in time to close a gap you had six months ago. Type 2 penalizes retroactive fixes. The earlier you start operating your controls, the cleaner your observation period.

2. Select Trust Services Categories based on business need

The AICPA’s 2017 Trust Services Criteria (with Revised Points of Focus, 2022) defines five categories. Security is mandatory. The other four are optional.

• Security (Common Criteria CC1 through CC9) covers access controls, system operations, change management, risk assessment, and monitoring. It is included in 100% of SOC 2 reports.
• Availability addresses whether systems are accessible per agreed service levels. The 2024 CBIZ SOC Benchmark Study found 75.3% of SOC 2 reports included it, up from 71% in 2023. Elect it if you have uptime SLAs or serve as a SaaS or hosting provider.
• Confidentiality protects information designated as confidential, including trade secrets, IP, and sensitive business data. CBIZ reported a jump from 34% inclusion in 2023 to 64.4% in 2024. Elect it when customer contracts impose confidentiality obligations beyond a standard NDA.
• Processing Integrity validates that system processing is complete, accurate, timely, and authorized. It is uncommon for most SaaS companies. Elect it for payment platforms, transaction processors, or analytics engines.
• Privacy addresses personal information collection, use, retention, and disposal. It is often better served by ISO 27701 or a dedicated privacy framework. Do not volunteer it unless a customer specifically requires it.

A common mistake, flagged by auditing firms, is that organizations pile on additional criteria without a clear business need. 

Each added category multiplies controls, evidence requirements, and the risk of a qualified opinion. Start with Security. Add Availability if you have contractual SLAs. Defer the rest unless procurement explicitly requires them.

For organizations considering both SOC 2 and ISO 27001, the frameworks share significant overlap in controls, and a dual-compliance approach can reduce audit fatigue. Our ISO 27001 vs SOC 2 comparison breaks down when each framework applies.

3. Define system scope and boundaries

AICPA DC Section 200 defines a system through five components: Infrastructure, Software, People, Procedures, and Data. Your scope decision determines which products, environments, integrations, and teams fall within the audit boundary.

Start with a clear inventory. 

• Which cloud accounts (AWS, Azure, GCP) host in-scope workloads? 
• Which SaaS tools process customer data (Stripe, Auth0, Twilio, Datadog)? 
• Which teams have access to production systems?

If your infrastructure runs on AWS or Azure, those providers are subservice organizations. Most companies use the carve-out method, meaning the cloud provider’s own SOC 2 report covers their controls, and your audit covers the controls you build on top. 

The shared responsibility model on AWS and Azure maps directly to SOC 2 scoping.

Three common scoping mistakes to avoid:

• Including staging and development environments unnecessarily, which expands evidence requirements without business value
• Forgetting third-party integrations that touch customer data, such as payment processors or analytics tools
• Excluding HR and people processes like onboarding, offboarding, and background checks, which auditors test under CC1 and CC6

The scope decision is the single largest driver of cost and timeline. Get it right before anything else moves forward.

Phase 2: Team, auditor, and tooling

4. Assign ownership with a RACI matrix

SOC 2 readiness is roughly 30% technical work and 70% process and documentation, as a practitioner on the DEV Community put it after a first Type 2 attempt. Without clear ownership, the 70% drifts.

Every SOC 2 program needs these roles filled:

• Executive sponsor (CEO or CRO): Approves the budget, signs the management assertion and communicates organizational priority. Time commitment: two to four hours per month
• Program lead (CISO or compliance manager): Owns the day-to-day program, coordinates across teams and manages the auditor relationship. Time commitment: 15 to 25 hours per week during readiness
• IT/Engineering owner: Implements technical controls, configures monitoring, and produces system-generated evidence. Time commitment: eight to 15 hours per week
• HR owner: Manages onboarding and offboarding evidence, training records and background checks. Time commitment: three to five hours per week
• Legal: Reviews the system description, customer contracts and data processing agreements. Time commitment: two to four hours per month
• Vendor/procurement owner: Manages third-party risk assessments, collects vendor SOC reports. Time commitment: 5 to 8 hours per week during readiness

Example of a RACI ownership alignment to drive consistent SOC 2 execution

5. Select and vet your service auditor

Only a licensed CPA firm can issue a SOC 2 report under SSAE 18 and AT-C 205. The quality of that firm determines whether your report earns trust or raises questions.

This step took on new weight after March 2026.

An anonymous whistleblower investigation raised concerns about Delve, a Y Combinator-backed compliance platform valued at $300 million. 

The allegations pointed to highly standardized auditor language, repeated boilerplate across SOC 2 reports, and patterns that led some analysts to question the rigor of control testing. 

According to reporting from Captain Compliance and IANS Research, 493 of 494 leaked reports used nearly identical language, and all 259 Type II reports claimed zero security incidents and zero personnel changes. 

Y Combinator removed Delve from its directory in early April 2026. The AICPA issued a public notice stating it was looking into the allegations.

The lesson is that auditor independence is not a formality. It is the mechanism that gives your report credibility.

Use this vetting checklist when selecting your service auditor:

• Verify AICPA peer review. Every CPA firm issuing SOC reports must undergo a triennial peer review. Look up the firm at aicpa.org/forthepublic/peerreview
• Confirm independence. The auditor cannot have performed management functions or audited their own work (AT-C 105). If your GRC platform vendor also provides the auditor, that arrangement warrants scrutiny
• Ask for named engagement partners. If the firm cannot identify who will sign the report, that is a warning sign
• Request a sample report structure. Look for firm-specific language, analysis, and judgment. Identical boilerplate across clients suggests templated rather than examined conclusions
• Evaluate the fee model. If total audit fees fall below $15,000 for a Type 2, investigate how the auditor is compensated and whether corners are being cut
• Confirm observation-period logistics. Will the auditor conduct interim testing during the observation period or only test at period-end? Interim testing catches issues earlier
• Verify physical presence and jurisdiction. Confirm the audit team is based where they claim and can conduct walkthroughs if needed

Network Intelligence works alongside CPA firms as an advisory and managed compliance partner. We do not issue SOC 2 reports. That separation is intentional. It keeps auditor independence intact while giving your team the readiness support that the auditor cannot provide.

6. Evaluate automation tooling with honest expectations

Compliance automation platforms collect evidence, map controls, and generate dashboards. They do this well. They do not implement controls, write accurate system descriptions, make scoping decisions, train staff, test incident response plans, or form audit opinions.

After the Delve allegations, this distinction matters more than ever. Speed without auditor independence produces reports that do not hold up under scrutiny.

Practitioner reviews on G2 and Capterra surface recurring friction with GRC platforms: surprise billing at renewal, vendor-count caps that trigger tier upgrades, and slow support during audit-critical windows. One compliance director described months of being left without guidance during a critical audit phase.

The honest position: you need a tool, advisory services, and a credible auditor. The tool automates evidence collection. The advisor builds the program. The auditor forms the opinion. For a detailed comparison of how platforms differ, see our compliance automation tools breakdown or our Drata vs Vanta analysis.

Phase 3: The readiness assessment

7. Map existing controls to the 2017 Trust Services Criteria

The Common Criteria (CC1 through CC9) are mapped to the 2013 COSO Internal Control framework and organized into nine domains: Control Environment, Communication and Information, Risk Assessment, Monitoring Activities, Control Activities, Logical and Physical Access, System Operations, Change Management, and Risk Mitigation.

Across all five Trust Services Categories, the 2017 TSC contains 61 criteria and approximately 300 points of focus. Per TSP 100.07, points of focus are illustrative, not mandatory. Your organization designs its own controls to meet the criteria.

If you already hold ISO 27001:2022 certification, you likely cover around 80% of SOC 2 Security criteria. 

If your security program aligns with NIST CSF 2.0 (released February 2024), the new Govern function maps directly to CC1 (Control Environment) and CC9.2 (vendor risk management), giving you a head start on two of the most frequently tested areas.

Start the mapping with CC6 (access controls), CC7 (system operations), and CC8 (change management). These three areas generate the most exceptions. Then work backward through CC1 to CC5 for governance, risk, and monitoring controls.

For each control, document four things: 

• Control description
• Owner
• Evidence artifact
• Operational cadence (daily, weekly, monthly, quarterly).

8. Conduct the formal readiness or gap assessment

This is the core deliverable of the readiness phase. Walk through every in-scope criterion, test whether evidence exists, and rate gaps by severity.

Expected deliverables include a gap report with severity ratings (critical, high, medium, low), a remediation roadmap with timelines and owners, a draft system description, and an evidence inventory showing collection status for each control.

Duration varies. A focused readiness engagement for a small SaaS company with a security-only scope takes 2 to 6 weeks. Multi-TSC mid-market engagements run 2 to 4 months.

Cost reality by company size (first-year, all-in estimates):

• Seed/startup under 50 employees: $20,000 to $50,000
• Growth stage, 50 to 250 employees: $50,000 to $100,000
• Mid-market, 250 to 800 employees: $100,000 to $200,000 or more

These ranges include readiness assessment, remediation, audit fees, and technology investments. They do not include internal staff time, which commonly adds $50,000 to $75,000 in loaded opportunity cost over six months. These numbers come from cross-industry reporting by CPA firms and advisory organizations, not from any single vendor.

9. Build the policy set and link every policy to the operating practice

These foundational policies form the documentation backbone of most SOC 2 programs: Information Security, Access Control, Change Management, Incident Response, Business Continuity and Disaster Recovery, Risk Assessment, Data Classification, Acceptable Use, Vendor Management, HR Security (covering onboarding and offboarding), Encryption, and Logging and Monitoring.

If your Access Control Policy states quarterly access reviews, auditors will sample every quarter of the observation period. A single missed review in month four of a 12-month window becomes a documented exception. 

For each policy, define the operating procedure that executes it, the control owner who is accountable, the evidence artifact that proves execution, and the review cadence that keeps the policy current.

10. Stand up evidence collection with operational cadence

Evidence is the product of SOC 2. Your controls are invisible to auditors without proof that they operated consistently.

Auditors select samples based on control frequency. For monthly controls, expect approximately 25 samples across a 12-month period. For quarterly controls, auditors typically test all four instances. For per-occurrence controls like access provisioning or change approvals, expect 25 to 40 samples. If one sample fails, the auditor may expand the sample size.

Three categories of evidence, ranked by auditor preference:

• System-generated (strongest): CloudTrail logs, AWS Config snapshots, Okta audit trails, GitHub pull request and merge records. Automated, timestamped, tamper-resistant
• Ticket-based (acceptable): Jira or ServiceNow tickets with timestamps, approvals, and resolution documentation
• Manual screenshots (weakest): Last resort. High risk of inconsistency. Auditors increasingly question screenshot-based evidence

Retain evidence for a minimum of 12 months. Align retention to your observation period plus a three-month buffer.

Build a collection cadence: weekly access review checks, monthly control self-testing, quarterly vendor risk reviews, and annual policy reviews with a formal risk assessment. 

Automating evidence collection from your existing tools (AWS, Azure, Okta, GitHub, Jira) eliminates the “screenshot tax” that drains engineering time. For a comparison of security audit tools that automate this workflow, see our coverage of the leading platforms.

Phase 4: Remediation and observation

11. Remediate the five most common exception areas

Audit exceptions are not theoretical. They follow patterns. Based on practitioner reporting and auditor publications, these five areas account for the majority of findings on first-time SOC 2 audits.

• CC6: Access control gaps: Bastion Technologies reports that roughly 68% of qualified opinions stem from weaknesses in CC6 criteria. The most common failure is inconsistent access reviews. 

The fix: Implement quarterly access reviews with ticket-based evidence for every review cycle. Automate deprovisioning across all platforms, not just SSO. AWS IAM keys, deploy keys, SSH credentials, and third-party application accounts each need individual revocation with evidence.

• CC7.2: Log integrity failures: Having logs is not the same as proving their integrity. Sometimes engineering teams have millions of log entries in their SIEM, but when the auditor asked whether they could demonstrate that the logs are complete and unmodified, they could not. 

The fix: Enable log integrity validation (for example, CloudTrail log file validation on AWS), use immutable storage, and implement active log monitoring that demonstrates completeness.

• CC7.4: Untested incident response plans: An incident response plan that has never been tested is just a document. Auditors test whether the plan works, not whether it exists. 

The fix: Run tabletop exercises at least annually. Document the scenario, participants, findings, and remediation actions. The exercise record is the evidence, not the plan itself.

• CC8.1: Change management traceability: Pull request reviews are a piece of change management, not the whole picture. Auditors testing CC8.1 expect a traceable chain from the change request to approval, to testing evidence, to the production deployment record. 

The fix: Link every production change to a ticket, an approval, a test result, and a deploy record. If your CI/CD pipeline does not automatically produce this chain, build it before the observation period begins.

• CC9.2: Vendor risk management: This is the control area teams forget entirely. One practitioner admitted they had never formally documented which vendors had access to customer data, never verified vendor SOC reports, and never performed a vendor risk assessment. 

The fix: inventory all vendors with customer data access, collect their current SOC 2 or ISO 27001 reports, perform annual risk assessments, and document ongoing monitoring.

12. Run the observation period (Type 2) or close the point-in-time (Type 1)

For Type 1, controls must be designed and in place on the report date. No observation window. Timeline from readiness completion to audit: 1 to 3 months.

For Type 2, controls must operate effectively throughout the entire observation period. Common initial periods are three months (fastest path), 6 months (most common for first-timers), or 12 months (standard for annual renewals).

Note: You cannot retroactively fix a control gap from an earlier month. If your access reviews lapsed in month three of a 12-month window, that gap is documented as an exception. There is no going back. 

During the observation period, maintain your evidence collection cadence without interruption. Run monthly control self-audits. Track exceptions in real time. If a control fails, document the failure, root cause analysis, and remediation immediately. Auditors test the response to control failures as part of CC4 (Monitoring Activities).

13. Conduct a mock audit dress rehearsal

About 2 to 4 weeks before the formal audit begins, run a full walkthrough.

Test every control with the control owner. Can they explain what the control does, where the evidence is stored, what happens during an incident, and what has changed since the last review? 

If any owner cannot answer these questions, remediate before the auditor arrives. Test the document request list (DRL) workflow. 

Check whether your team can produce all the requested artifacts within 48 hours. If evidence scattered across Google Drive, Confluence, Jira, and individual laptops can be consolidated before the audit to avoid delays.

Check the system description for misstatements. The description must accurately reflect how the system operates today, not how it was designed to operate. Auditors flag discrepancies between the description and observed practice.

Phase 5: Formal audit and continuous compliance

14. Execute the formal SOC 2 examination and manage exceptions

You technically cannot “fail” an SOC 2 audit. The auditor issues one of four opinions:

• Unqualified (clean): Controls meet the criteria. This is the goal
• Qualified: Exceptions exist but are not pervasive. The report describes each exception, management’s response, and the auditor’s assessment
• Adverse: Controls fundamentally do not meet the criteria. This is rare and serious
• Disclaimer: The auditor cannot form an opinion due to scope limitations. Also rare

Most first-time audits surface some exceptions. Exceptions do not automatically trigger a qualified opinion. That determination depends on the significance and pervasiveness of the findings.

Enterprise procurement teams read the full report, including the section describing exceptions. A clean, unqualified opinion shortens sales cycles. A qualified opinion extends them. An adverse opinion or disclaimer is a deal-killer.

During the audit, you may be able to provide additional evidence or remediate issues, but the auditor may not be able to retest until the next observation period.

15. Sustain the program with continuous monitoring and annual refresh

SOC 2 Type 2 reports must be contiguous. There should be no gap between observation periods. Plan the next audit cycle two to three months before the current report period ends.

Bridge letters cover the gap between the end date of a report period and a customer’s fiscal year-end. They confirm that there have been no material changes to controls since the report date. Enterprise customers and their auditors frequently request them quarterly.

Automate evidence collection. Run monthly control health checks. Track three metrics: evidence collection completeness rate, control exception rate, and mean time to remediate control drift.

As the company grows, the scope expands. New products, new cloud regions, new regulatory requirements, and new customer contracts may require the addition of Trust Services Categories. 

Availability becomes necessary when you sign SLA-backed contracts. Confidentiality becomes necessary when contracts include data-handling obligations beyond those in standard NDAs.

The operational standard is straightforward: if you only feel compliant during audit season, you are not compliant. You are temporarily organized.

How Network Intelligence Helps You Move from Readiness to Continuous Compliance

Network Intelligence is a cybersecurity services firm with 23 years of experience across SOC 1, SOC 2, ISO 27001, PCI DSS, HIPAA, and HITRUST. 

We are not a SaaS-only compliance tool. We are not the auditor. We are the managed compliance partner that sits between your team and the CPA firm.

Our approach follows the ADVISE framework (Assess, Design, Visualize, Implement, Sustain, Evolve), structured to move organizations from point-in-time readiness to continuous compliance.

Through Transilience AI, our AI-powered GRC platform, organizations get:

• Zero-touch evidence collection from AWS, Azure, GCP, Okta, GitHub, and Jira, with no manual screenshots
• Real-time control mapping to Trust Services Criteria with continuous drift monitoring
• Automated audit-ready evidence packets that auditors can access directly
• Multi-framework support across SOC 2, ISO 27001, HIPAA, PCI DSS, and HITRUST, so one control satisfies multiple compliance requirements
• Predictable pricing that covers labor, tools, consultation, and audit management

Our managed compliance service handles readiness assessment, remediation support, evidence management, auditor coordination, and ongoing program management. 

The result is audit outcomes delivered in two to three months, with the operational confidence that compliance does not regress between audit cycles.

If you are evaluating SOC 2 readiness or preparing for your first audit, connect with our SOC 2 advisory team to discuss your scope, timeline, and compliance goals.

Build a SOC 2 Program That Outlasts the Audit

After March 2026, the compliance market is recalibrating. Cheap certifications and rubber-stamped reports carry real reputational risk. Enterprise buyers are reading reports more carefully, checking auditor credentials, and asking harder questions.

IBM’s 2024 Cost of a Data Breach Report puts the global average breach cost at $4.88 million, with healthcare breaches averaging $9.77 million. The cost of weak assurance is no longer abstract.

A credible SOC 2 program is a competitive moat. Network Intelligence helps organizations build that program with managed compliance services. 

Talk to an expert to start your SOC 2 readiness assessment.