How to Run a SOC 2 Readiness Assessment in 2026: The Complete Checklist

A SOC 2 readiness assessment is essentially a dry run of your audit. Its purpose is to identify gaps in your controls, documentation, and evidence before an external auditor issues a formal opinion. In 2026, running a readiness assessment involves more than just policy drafting; it requires validating that your automated tools are actually collecting the screenshots and evidence needed for the audit.

While automation platforms can check infrastructure configurations, they often miss the application-level workflows that auditors scrutinize. If you don't verify that you can produce evidence for every control—specifically manual screenshots for complex workflows—you risk failing the assessment when it counts.

What Is a SOC 2 Readiness Assessment?

A readiness assessment (often called a gap analysis) compares your organization's current security posture against the AICPA's Trust Services Criteria (TSC). The goal is to answer a simple question: "If the auditor arrived today, would we pass?"

For a standard SOC 2 Type 1 or Type 2 audit, the assessment covers five potential Trust Services Criteria, though most startups begin with just Security (Common Criteria):

1. Security (Common Criteria): Required for every SOC 2. Covers access control, HR, risk management, and physical security.
2. Availability: Uptime, disaster recovery, and backups.
3. Confidentiality: Data classification and deletion.
4. Processing Integrity: System inputs/outputs (common for fintech).
5. Privacy: Personal data handling (GDPR/CCPA overlap).

The output of a readiness assessment is a remediation plan—a list of things you need to fix, document, or configure before the actual audit window begins.

The 2026 SOC 2 Readiness Checklist

To conduct a thorough assessment, you need to evaluate controls across four main domains. This SOC 2 readiness checklist covers the specific evidence artifacts auditors will request.

1. HR and People Operations (CC1, CC2)

Auditors look for consistency here. The most common gap is missing evidence for contractors or employees who left the company.

• Onboarding Packets: Do you have signed offer letters and background check results for 100% of employees?
• Security Training: Can you produce a log showing every employee completed training upon hire and annually?
• Policy Acknowledgement: Do you have timestamps showing employees accepted the Information Security Policy?
• Offboarding Checklists: For every terminated employee in the sample period, can you prove access was revoked within 24 hours? (This usually requires screenshots of the revocation, not just a Jira ticket saying it was done).

2. Logical Access Controls (CC6)

This is where most exceptions occur. Auditors focus heavily on how you grant and restrict access.

• Access Reviews: Have you performed a quarterly User Access Review (UAR) of all critical systems?
• MFA Configuration: Is Multi-Factor Authentication enforced on email, cloud infrastructure (AWS/GCP), and source code repositories (GitHub/GitLab)?
• Role-Based Access Control (RBAC): Can you show a matrix defining what permissions each role has?
• Admin Access: Is administrative access restricted to a specific group, and is that group list accurate?

3. Change Management (CC8)

If you are a software company, this is the most technical part of the audit.

• Pull Request Reviews: Is branch protection enabled? Can you prove that no code goes to production without a peer review?
• Change Tickets: If you use Jira or Linear, does every production deployment link back to a ticket describing the change?
• Emergency Changes: Do you have a documented process for hotfixes that bypass standard review, and is there evidence of retroactive approval?

4. Vendor Risk Management (CC9)

You are responsible for the security of the tools you use.

• Vendor Inventory: Do you have a list of all critical sub-processors?
• Vendor Reviews: Have you reviewed the SOC 2 reports of your critical vendors (AWS, Slack, Gusto) within the last 12 months?

How to Run a Readiness Assessment Using Drata or Vanta

If you use a GRC platform, you might assume the "readiness score" on your dashboard is the final word. It isn't.

When running a Drata SOC 2 readiness assessment (or using Vanta/Secureframe), the tool performs two types of checks:

1. Automated Checks: Via APIs, it verifies that MFA is on in Google Workspace, hard drives are encrypted via MDM, and AWS S3 buckets aren't public. These are generally reliable.
2. Policy/Upload Checks: The tool asks you to upload a document. It marks the control as "Ready" as soon as something is uploaded. It does not validate the content of that upload.

The Trap: You might have 100% passing checks in your GRC dashboard but still fail the audit because the evidence you uploaded is low quality, outdated, or irrelevant. The tool checks for the presence of a file, not the validity of the evidence.

Where Traditional Readiness Assessments Fail

The biggest blind spot in most readiness assessments is the "manual evidence gap."

Most modern compliance platforms connect to APIs. They are excellent at monitoring AWS, GitHub, and Google Workspace. However, they cannot see inside applications that lack compliance APIs.

The "Observation" Problem

Auditors don't just trust APIs; they perform "observation and inspection." They want to see:

• Screenshots of your internal admin panel permissions.
• Screenshots of error messages when an unauthorized user tries to access a restricted setting.
• Screenshots of the actual settings page in tools that don't integrate with your GRC platform (e.g., a niche marketing tool or a custom internal dashboard).

If your SOC 2 readiness 2026 plan relies solely on API-based monitoring, you will likely scramble during the audit week to manually capture hundreds of screenshots. A true readiness assessment involves doing this manual capture now to ensure the settings are actually correct.

How to Score Your Readiness

When you run your assessment, rate every control using a simple Red/Amber/Green (RAG) status.

Status	Definition	Action Required
Green	Control is designed, implemented, and generating automated evidence.	None. Verify evidence retention.
Amber	Control is designed but relies on manual processes (e.g., manual UARs).	Automate evidence collection or schedule strict calendar reminders.
Red	Control is missing or evidence is inconsistent.	Immediate remediation. Do not start the observation period.

The "Design vs. Operating Effectiveness" Distinction

For a Type 1 audit, you only need to prove the control is designed (it exists at a point in time). For a Type 2 audit, you must prove operating effectiveness (it worked consistently over 6-12 months).

If you're prepping for a Type 2, a "Green" score requires proving that you didn't just fix the control yesterday, but that you have a history of it working. This is the part that trips up first-timers. You can't backfill evidence. If you missed a quarterly access review three months ago, that control is effectively "Red" for the upcoming audit period, and there's no way to fix it retroactively.

Common Readiness Gaps That Trip Up Startups

These are the gaps that come up again and again. If you only spot-check four things, make it these:

1. The "Terminated User" Window: You removed an employee from Slack, but forgot to remove them from GitHub for 3 days. The auditor will sample this specific employee.
2. The "Merge Without Review": An admin temporarily disabled branch protection to force a merge and forgot to turn it back on.
3. The "Generic Admin Account": You have a shared login (e.g., admin@company.com) that multiple developers use. This violates non-repudiation requirements (CC6.1).
4. The "Empty Ticket": You have a Jira ticket for a change, but no screenshot or log showing the test results attached to it.

Next Steps

A readiness assessment is only useful if you act on what it finds. Once you've identified the Red and Amber controls, assign an owner to each one with a deadline.

If you find that your team is spending hours manually capturing screenshots for the "Amber" controls—like internal admin panels, custom tools, or non-integrated SaaS apps—consider how to automate that collection before the audit window opens.

Learn More About SOC 2 for Bootstrapped B2B SaaS

For a complete guide to navigating the audit process without overspending, see our guide on the bootstrapped founder's guide to SOC 2, including detailed cost breakdowns and timeline expectations.