Compliance Guide

SOC 2 Compliance Readiness Guide: How to Score Your Maturity

A practical walkthrough of SOC 2 compliance — what the trust criteria actually require, how to run a readiness assessment, the most common gaps we see, and how our free compliance scorecard can get you started today — no CPA firm required for this first step.

Updated: October 4, 2026|10 min read

What Is SOC 2?

SOC 2 — short for System and Organization Controls 2 — is an auditing framework developed by the American Institute of CPAs (AICPA). It was created to give service organizations a standardized way to demonstrate that they manage customer data responsibly. Unlike compliance frameworks that prescribe specific technical controls (PCI DSS requires firewalls, for example), SOC 2 isprinciple-based. It asks you to define a set of controls and prove they achieve a stated security objective. This flexibility is both a strength and a challenge — it means your SOC 2 program can be tailored to your business, but it also means scoping the engagement correctly is the single most important decision you will make.

Any organization that stores, processes, or transmits customer data on behalf of others is a candidate for SOC 2. This includes SaaS providers, data processing platforms, cloud infrastructure companies, managed service providers, and increasingly, downstream subcontractors in regulated supply chains. If your customers ask for a SOC 2 report during procurement, you are not alone — a 2025 survey by the AICPA found that over 70% of enterprise procurement teams now require a SOC 2 Type II report from technology vendors before contract signing. That number has grown every year since 2020.

There are two report types you need to understand. A Type I report evaluates whether your controls are designed appropriately at a single point in time. Think of it as a spot-check: do the right policies exist? Are the right system configurations in place? AType II report adds the dimension of time — it evaluates whether those controls operated effectively over a sustained period, typically 6 to 12 months. Enterprise buyers nearly always require a Type II report because it gives them confidence that your controls are not just window dressing but are actually working in practice. Most practitioner guidance, including this guide, treats readiness as a Type II target because that is what the market demands.

The cost of SOC 2 readiness and certification varies widely depending on your organization's size, scope, and current security maturity. For a small SaaS team (10-50 employees), budget between $30,000 and $70,000 for the first Type II audit, plus 3-6 months of internal remediation time before the auditor even starts the observation period. Understanding this cost structure upfront helps leadership set realistic expectations and avoids the most common pitfall: starting the audit clock before the organization is actually ready.

The Five Trust Service Criteria

Every SOC 2 engagement is built around one or more of five trust service criteria defined by the AICPA. While Security is mandatory in every SOC 2 report, the remaining four are optional and should match the commitments you make to your customers. One of the most common mistakes first-time organizations make is selecting too many criteria. A Security-only scope is perfectly acceptable and is how most organizations start.

1. Security — Mandatory in Every Report

Security is the universal criterion — it appears in every SOC 2 report. It requires that the system is protected against unauthorized access (both logical and physical), unauthorized disclosure of information, and damage to the system or data. The AICPA maps Security to a set of controls called the Common Criteria (CC), which overlap substantially with NIST SP 800-53 and ISO 27001 Annex A. Key controls include logical access controls (CC6.1), physical protections (CC6.4), vulnerability management (CC7.1), and system monitoring (CC5.1). If you do nothing else for SOC 2 readiness, security controls are where you must invest.

2. Availability

Availability covers whether the system is available for operation and use as committed to customers. If your contracts reference specific uptime percentages — "99.9% availability" or "less than 5 minutes of unplanned downtime per month" — then Availability should be in scope. Controls include capacity planning, disaster recovery plans, backup and restoration testing, incident response procedures for outages, and redundant infrastructure. One key distinction auditors make: an Availability control is not sufficient just because you have backups. You also need evidence that restoration has been tested on a recurring basis and that recovery time objectives are being met.

3. Processing Integrity

Processing Integrity requires that system processing is complete, valid, accurate, timely, and authorized. This criterion is most relevant for platforms that perform financial calculations, data transformations, workflow orchestration, or any operation where a processing error could materially affect customers. If your SaaS platform calculates invoices, processes payroll data, or routes transactions, Processing Integrity should be on your scope list. Typical controls include input validation, data completeness checks, error handling and alerting, and reconciliation procedures that detect and correct processing discrepancies.

4. Confidentiality

Confidentiality protects information designated as "confidential" from unauthorized disclosure. This criterion applies when your customer contracts or data processing agreements define specific categories of data as confidential — a common clause in MSAs and DPAs. Controls include data classification and handling policies, encryption at rest and in transit, network segmentation for sensitive data, and access logging with audit trail retention. Confidentiality often overlaps with Security in practice, but the distinction matters: Security protects the system, while Confidentiality protects the data. Including both in scope means documenting separate control objectives even if the same technical controls satisfy both.

5. Privacy

Privacy addresses how personal information is collected, used, retained, disclosed, and disposed of, in conformity with the organization's privacy notice and with AICPA's Generally Accepted Privacy Principles (GAPP). This criterion is most commonly scoped alongside Security when the organization handles PII under GDPR, CCPA, or state-level privacy laws like New York SHIELD Act or California CPRA. Privacy controls include notice and consent mechanisms, privacy impact assessments, data retention schedules, and processes for data subject access requests. Before adding Privacy to scope, confirm that your privacy notice is comprehensive and that your data inventory maps to what the notice says you collect.

Readiness Tip: Start With Security Only

Over-scoping is the #1 cause of budget overruns in first-year SOC 2 programs. If you are starting from scratch, scope your first Type II report to Security only. Once you have that report in hand — typically 9 to 12 months after starting readiness — you can expand scope in subsequent years as customer requirements evolve. Most organizations add Availability in year two and evaluate Confidentiality and Privacy based on the types of data they process.

Readiness Assessment Walkthrough

A SOC 2 readiness assessment is a gap analysis you run before you engage a CPA auditor. The goal is not to pass or fail — it is to identify where your current controls fall short of the trust criteria you selected. Running a thorough readiness assessment before the formal audit clock starts can save you months of rework and tens of thousands of dollars in auditor-driven remediation. Here is the step-by-step process we recommend.

Step 1: Define Your System Scope

Document precisely which systems, data flows, people, and processes are in scope for the SOC 2 report. This starts with writing a system description — a narrative that describes what your in-scope system does, what data it processes, who accesses it, how it connects to other systems, and where the data lives at each stage. Scope creep is the #1 readiness killer. Document carefully: "the customer-facing SaaS platform that manages document signing workflows" instead of "the whole company IT environment." If you need help deciding what is in scope, ask yourself: if this component were compromised, would it affect the confidentiality, integrity, or availability of customer data? If no, it is almost certainly out of scope.

Your system description should also include a data flow diagram showing how data moves between components. The diagram does not need to be Visio-perfect — even a simple hand-drawn diagram scanned and annotated is acceptable to most auditors. What matters is that the flow is complete and matches the actual architecture. Auditors are trained to spot gaps between what your diagram says and what your configuration management tools show.

Step 2: Map Each Trust Criterion to Specific Controls

For each trust criterion in scope, identify the AICPA-defined controls (listed in theTrust Services Criteria (TSC) document) that apply to your environment. The TSC document organizes controls into Common Criteria (CC) categories — CC6 deals with logical and physical access, CC7 addresses monitoring and incident response, CC8 covers change management, and so on. Create a mapping table with five columns:

TSC control reference (e.g., CC6.1 — Logical Access Controls)
Your implementing control or policy (e.g., "Azure AD with SSO, MFA enforcement, and quarterly access reviews")
Control owner (the person responsible for maintaining this control)
Current maturity status (Not Started / Defined / Implemented / Monitored)
Evidence location (where an auditor would look to verify — a wiki page, a system config, a log source)

This mapping table becomes the backbone of your entire SOC 2 program. It is also the first artifact your auditor will ask to see. Getting it right — with realistic maturity ratings and clear evidence references — is the single highest-leverage activity in the readiness process.

Step 3: Assess Each Control for Design, Implementation, and Effectiveness

For every row in your mapping table, evaluate the control across three dimensions. SOC 2 auditors assess controls at three levels, and a weakness at any level counts as a finding:

Design: Do you have a documented policy, procedure, or system configuration that addresses this specific control? A policy that is not documented does not exist from the auditor's perspective.
Implementation: Is that design actually deployed across the entire in-scope environment? A policy that is documented but only loosely followed in practice is a gap.
Operating effectiveness: Do you have evidence — logs, reports, tickets, test results — proving the control worked continuously throughout the observation period? A control that was working when you set it up but degraded over time is a finding.

Use a simple RAG (Red/Amber/Green) scoring system for each control. Red means no design exists — you are starting from scratch. Amber means designed but not fully implemented, or implemented but not yet proven effective over time. Green means designed, implemented, and operating effectively with evidence you can produce on request. This three-color visualization gives you and your leadership an immediate, honest picture of readiness without needing to read through pages of narrative.

Step 4: Build Your Remediation Backlog

Sort your Red and Amber controls by the product of business impact and remediation effort. High-impact, low-effort items should be tackled first — these quick wins build momentum and demonstrate progress to leadership. Typical quick wins include:

Documenting existing security practices that are currently done informally but not written down as formal policies
Enabling MFA on accounts where the platform already supports it but it has not been enforced
Configuring basic logging and alerting on systems that already support it but were never configured
Running a tabletop exercise using a published scenario (CISA Tabletop Exercise Packages are free and well-structured)

For each remediation item, assign an owner and a target completion date. Budget 3 to 6 months for the full remediation phase before the Type II observation period begins. Expect that some items — especially those requiring cross-team coordination or new tool procurement — will take longer than you estimate. Build in at least one month of buffer.

Step 5: Run a Dry Run Before the Auditor Arrives

Before the real auditor walks through the door, schedule an internal dry run. Assign a colleague (or, ideally, an external readiness assessor who has not been involved in your remediation) to play the role of auditor. Ask them to select a sample of 5 to 7 controls from your mapping table and request evidence for each. Can your team produce the policy document in under 10 minutes? Does the log export actually cover the full observation period? Do the control owners know where their evidence lives without having to ask around? If a dry run reveals gaps, you lose time but not a report. If those same gaps surface during the real audit, you may face a qualified opinion or delayed report — both of which have real business consequences.

Common Gaps We See

Across the mid-market and growth-stage organizations we work with, the same readiness gaps appear consistently regardless of industry. Recognizing these patterns early — before your auditor identifies them — is one of the highest-value things you can do in your preparation.

1. No Formal Risk Assessment Process

SOC 2 requires a documented risk assessment that identifies threats to the in-scope system, estimates likelihood and business impact, and drives control selection and prioritization. This is perhaps the most common gap. Many organizations "know the risks" informally but have no written risk register, no defined risk appetite, and no schedule for periodic reassessment. Without this foundational document, the auditor cannot verify that your control set is risk-appropriate rather than arbitrary. The fix: conduct your first formal risk assessment using a framework like NIST SP 800-30 or ISO 27005, document it, and establish a schedule for annual updates.

2. Incident Response Plan Exists but Has Never Been Tested

A printed incident response plan sitting in a binder does not satisfy SOC 2's operating effectiveness requirement. Auditors will ask for evidence of a tabletop exercise or live drill conducted within the past 12 months, complete with documented findings, remediation items tracked to closure, and updated plan versions reflecting lessons learned. Organizations that remediate this gap typically start with a two-hour tabletop exercise using a ransomware scenario — just the exercise and resulting after-action report is enough evidence. The CISA Tabletop Exercise Packages provide free, well-designed scenarios that map directly to SOC 2 control objectives.

3. Change Management Is Informal or Undocumented

Deploying code or configuration changes without documented review, testing, and approval is standard practice at startups and small engineering teams. It is also one of the most common SOC 2 audit findings. The auditor looks for a written change management policy that describes how changes are requested, reviewed, tested, approved, deployed, and documented. Even a lightweight Git-based workflow — pull request with peer review, CI pipeline passing, tagged release, and a deployment log — is sufficient, provided it is documented in policy and consistently followed. The key is demonstrating that changes follow a repeatable, controlled process rather than being deployed ad-hoc.

4. Monitoring Without Documentation or Defined Response Procedures

Many organizations run excellent monitoring stacks — SIEM, EDR, cloud workload monitoring, uptime dashboards — but have never documented what exactly they monitor, which alert thresholds trigger response actions, or how alerts are triaged and escalated. SOC 2 auditors need to see that monitoring is systematic, not ad-hoc. A straightforward monitoring policy listing monitored event categories, alert thresholds, notification SLAs, and escalation paths bridges this gap. Include a statement of retention — how long logs are kept and why that period was chosen based on your risk assessment.

5. Vendor Management Is Reactive or Missing Entirely

SOC 2 expects you to manage the risks posed by your own service providers and sub-processors. If your cloud infrastructure provider has a SOC 2 report, great — collect it and document the review. If your critical SaaS dependencies do not have SOC 2 (or equivalent third-party attestations), you need compensating controls in your vendor risk management program. At minimum, maintain an inventory of all sub-processors with risk tiering, an annual review cycle, and contractual provisions requiring breach notification. Organizations that remediate this gap early often start with a simple spreadsheet, then graduate to a dedicated vendor risk platform as their vendor population grows.

Using Our Compliance Scorecard to Jump-Start Your Readiness

The SOC 2 readiness process can feel overwhelming when you are staring at 50+ controls, five trust criteria, a TSC document running 80+ pages, and an auditor whose expectations you have not yet calibrated. That is exactly why we built theCompliance Readiness Scorecard. It translates the SOC 2 trust criteria into a practical, scored self-assessment that takes about 10 minutes to complete.

The scorecard covers 25 controls across six domains that map directly to SOC 2 Common Criteria and supporting controls:

Governance & Policy — Written security program, risk assessments, role definitions, policy review cycles
Access Control — MFA, least privilege, offboarding procedures, quarterly access reviews
Data Protection — Data classification, encryption at rest and in transit, backup and restoration testing
Network Security — Firewall architecture, network segmentation, endpoint detection, patch management cadence
Incident Response — Documented IR plan, tabletop exercises, breach notification mapping, external retainer
Security Awareness — Onboarding training, ongoing awareness, phishing simulations, reporting mechanisms

Each control is weighted by its impact on overall compliance posture. Controls that address the most commonly exploited vulnerabilities — MFA, encryption, incident response testing, and risk assessments — carry higher point values because they are central to every major compliance mandate, not just SOC 2. After you complete the assessment, the scorecard calculates:

An overall readiness percentage that benchmarks your current posture against what a SOC 2 auditor would typically expect
A category-level breakdown so you can see at a glance which domains are strong and which need investment
Actionable recommendations based on your score tier — specific next steps, not generic advice

The scorecard is 100% free, runs entirely in your browser with no data stored on our servers, and requires no registration. It is designed as a pre-readiness-check — not a replacement for a formal gap analysis conducted by a qualified assessor, but an excellent starting point if you are wondering, "Are we even close to ready?" Our most common user feedback is that the category breakdown alone is worth the 10 minutes, because it tells leadership exactly where to focus budget and attention.

Ready to start?

Take our Compliance Readiness Scorecard to get your baseline score in under 10 minutes. It covers the same domains your SOC 2 auditor will evaluate — knowing your gaps now saves time and money later.

Take the Compliance Readiness Assessment

Final Thoughts

SOC 2 compliance is not a one-time project you complete and forget. It is the outcome of embedding security practices into how your organization operates day to day — how you write code, manage access, respond to incidents, train employees, and select vendors. The readiness assessment is your roadmap. Whether you score 30% or 90% on our scorecard, the next action is the same: identify your gaps, prioritize the fixes that reduce the most risk, and start the remediation work. Every SOC 2-compliant organization began exactly where you are now — with an honest look at where they stood and a plan for where they needed to go.

If you are early in your SOC 2 preparation journey, we recommend three actions today:

Take the scorecard. Our Compliance Readiness Scorecard gives you a baseline in 10 minutes. Share the results with your leadership to build awareness and urgency.
Write your system description. A one-page narrative of what your in-scope system does and how it processes data. This single document shapes everything else in the readiness process.
Map controls to criteria. Use the TSC document to build your mapping table. Even if you only draft the first column of controls, you will have a concrete picture of the work ahead.

From there, the path is clear: remediate, dry run, and then engage a licensed CPA firm to begin your Type II observation period. The process is well understood, the standards are public, and the market rewards organizations that invest the time to get it right.Start with our scorecard— and good luck on your SOC 2 journey.

Frequently Asked Questions About SOC 2 Readiness

How long does the full SOC 2 readiness process take?

Most organizations need 3 to 6 months of remediation work before starting the Type II observation period. The observation period itself is a minimum of 6 consecutive months for a Type II report. Plan for 9 to 12 months from kickoff to report in hand.

Do I need all five trust criteria in my first engagement?

No. Security is mandatory, but the other four criteria are optional and should match your customer commitments. Starting with Security-only is standard practice. You can add criteria in subsequent years as customer requirements evolve.

Can I use the compliance scorecard as my official gap analysis?

The scorecard is a pre-readiness self-assessment — it helps you understand where you stand before engaging professionals. A formal gap analysis conducted by a qualified assessor is recommended before starting the actual audit. The scorecard is the first step, not the last.

What is the SOC 2 checklist for readiness?

A comprehensive SOC 2 readiness checklist includes: risk assessment, access controls with MFA, encryption at rest and in transit, documented incident response plan with tested exercises, change management policy, monitoring and alerting with defined response procedures, backup and recovery testing, vendor risk management program, and security awareness training. Our Compliance Scorecard turns this checklst into a scored self-assessment.

Disclaimer: This guide provides general information about SOC 2 compliance readiness for educational purposes. It does not constitute professional audit advice. Consult a licensed CPA firm for official SOC 2 audit services and formal gap analyses.

Keywords: SOC 2 compliance, SOC 2 readiness assessment, compliance scorecard, SOC 2 checklist, SOC 2 preparation