By the DCYBR Advisory TeamSenior GRC practitioners | CISA | CISSP | 12+ years advising SaaS companies through AICPA-aligned Type 1 and Type 2 auditsLast updated: May 2026
TL;DR: A complete SOC 2 readiness checklist covers six areas: cloud infrastructure, identity and MFA enforcement, change management, HR security records, incident response, and vendor risk. Most SaaS teams that come to us have the controls in place. What they are missing is the evidence trail that proves those controls ran consistently. That gap is what delays audits and triggers exceptions.
Most SaaS founders we talk to are not starting from zero. They have MFA enforced, they use GitHub with branch protection, they are on AWS or GCP. The problem is not the controls. It is the proof.
A SOC 2 readiness checklist is not about checking whether security exists. It is about confirming that you can hand an auditor the exact technical artifact for any control, on any date within your audit window, without scrambling. That is the standard CPA firms hold you to. And that is where most teams are underprepared when fieldwork begins.
Before the Checklist: Two Things That Have to Come First
Organizations preparing for SOC 2 readiness often review both the official Trust Services Criteria published by the AICPA and the cloud provider’s shared responsibility documentation before starting evidence collection. The AICPA explains how auditors evaluate security, availability, confidentiality, and privacy controls during SOC engagements, while AWS documents which security responsibilities remain customer-owned versus AWS-managed within AWS environments. Teams can review the official guidance through AICPA Trust Services Criteria Overview and AWS SOC Compliance Documentation before beginning readiness assessments and evidence collection.
Define your audit boundary. The AICPA requires you to inventory every system that stores, processes, or transmits customer data. That boundary determines which controls, which configurations, and which logs fall in scope. If you have not mapped this before your readiness assessment, the gap analysis will take longer and cost more.
Build your source populations. A source population is a complete, unfiltered list of every active item in a category: all employee accounts, all cloud instances, all repositories. Auditors match your evidence against these raw lists. One missing account, one undocumented instance, and fieldwork stops while you reconcile.
At DCYBR, the first thing we do in a gap assessment is pull these populations and compare them against what the compliance platform is actually tracking. That single step surfaces more audit blockers than any checklist item.
The SOC 2 Readiness Checklist
1. Cloud Infrastructure Configurations
Auditors want programmatic exports, not screenshots taken the day before fieldwork. The evidence needs to show what your configuration looked like throughout the audit window, not just at the moment you were asked.
What to have ready:
- IAM configuration exports showing root account MFA status, service account permissions, and API key rotation records
- Network perimeter documentation: security group configs, VPC policies, confirmation that external access is locked down at the policy level
- Storage access settings confirming public access is blocked, not just at the object level but at the bucket or project policy level
- Encryption parameter exports for databases (AES-256 at rest) and all public-facing endpoints (TLS in transit)
The most common failure here is teams pulling a current-state export on day one of fieldwork. If your audit window started three months ago, that export proves nothing about what was in place then. Automated, dated exports from the start of the window are the only way to cover this cleanly.
2. Identity and MFA Enforcement
A green checkmark in Vanta or Drata showing MFA is enabled is a monitoring signal. It is not audit evidence. What auditors ask for is an exported user list from your identity provider showing MFA enrollment status for every active account across the full population.
What to have ready:
- Tenant-wide MFA enrollment report from Okta, Azure AD, or Google Workspace covering every account, not just admins
- Policy-level MFA enforcement config showing that MFA cannot be bypassed by user preference
- Privileged access review records showing that elevated accounts were reviewed on schedule
If your identity provider report shows 47 users and your HR system shows 52 active employees, auditors flag the discrepancy before testing a single sample. Reconciling those populations before fieldwork is a basic readiness step that a lot of teams skip.
3. Change Management and SDLC
Every code deployment in the auditor's sample needs a complete, linked chain of evidence. This is the area where we see the most exceptions during mock audits, not because teams lack a process, but because the trail breaks somewhere between the ticket and the deploy log.
For each sampled deployment, auditors need:
- The ticket (Jira, Linear, or equivalent) showing the approved business justification for the change
- The pull request record showing automated test results and an independent peer approval from someone who did not write the code
- The deployment log from your CI/CD pipeline showing the commit hash, deployment timestamp, and confirmation it matches production
Slack threads and email chains do not satisfy this requirement. They are easy to edit after the fact and do not link programmatically to the change. Branch protection rules in GitHub or GitLab are the standard artifact because they are automated and tamper-proof.
For SaaS engineering teams, the way this integrates with your audit depends heavily on your stack. We cover that in detail in our SOC 2 for SaaS companies guide.
4. HR Security Records
HR controls are sampled on a per-event basis, meaning every hire and every termination during the audit window is a potential sample. The most common gap we find here is that background checks and NDAs exist but are stored in a spreadsheet or a drive folder rather than tied to a system record.
What to have ready:
- Background check clearances matched directly to each employee's hire date: the actual clearance document, not a tracker entry
- Signed NDAs and confidentiality agreements for all employees and contractors with system access
- Account provisioning tickets showing the request, approval, and execution timestamp for each access grant
- Offboarding logs showing that access was revoked within your defined SLA after termination, with system-generated timestamps
The offboarding piece catches teams the most. If an employee leaves on a Friday and access is revoked the following Monday, that gap needs to be explained. If your SLA is 24 hours and you cannot prove it was met for a sampled termination, that is an exception.
5. Risk Assessment and Incident Response
These are annual controls, which means auditors pull fewer samples, but the documentation depth they expect is significant.
What to have ready:
- A completed risk register with identified hazards, likelihood and impact ratings, assigned owners, and documented remediation actions: not a template that was filled out once and never touched
- A full security incident log covering all alerts, investigations, and resolution actions across the audit window, even for low-severity events
- Incident response tabletop test documentation: meeting notes and results from a simulation run within the last 12 months
- Disaster recovery test output: system-generated records showing a successful recovery from backup, including the actual recovery time and recovery point achieved
If the last tabletop was run more than a year ago, or if the DR test result is a screenshot of a successful restore with no supporting logs, expect those to be flagged.
6. Vendor and Subprocessor Risk Management
Every vendor that touches customer data in your pipeline needs a documented annual review. Most teams have a vendor list. What they do not have is a documented review of that vendor's SOC 2 report with notes on how their complementary controls map to your internal operations.
What to have ready:
- The vendor's most recent SOC 2 report: downloaded, reviewed, and dated
- A written record mapping their Complementary User Entity Controls (CUECs) to how your organization satisfies them
- A central vendor risk tracker showing review dates, certification status, and risk ratings for each high-risk subprocessor
For a full breakdown of what the evidence package looks like across all six areas, see our SOC 2 evidence checklist.
What Automated Platforms Miss
Compliance platforms like Vanta, Drata, and Secureframe are part of our standard process at DCYBR. We configure and integrate them for every engagement. But they have a real limitation that teams learn about at the wrong time, during fieldwork.
Automated platforms poll your systems on a schedule. Anything that changes between polling cycles, or that sits outside the API connection, does not get captured. Auditors do not certify dashboards. They verify raw population records. When those do not match what the platform is reporting, it is your team that has to explain the gap.
| Control Area | What the Platform Shows | What Auditors Need |
|---|---|---|
| Identity & MFA | MFA currently enabled | Exported user list with enrollment status for every account |
| Change Management | Branch protection active today | Ticket to PR to commit hash to deploy log for each sample |
| Vendor Management | Vendor contract uploaded | Reviewed SOC 2 report with CUEC mapping |
| HR Security | Background checks linked | Individual clearances matched to onboarding dates |
This is why our process includes a mock audit before the CPA firm begins fieldwork. By the time your auditor asks for samples, every artifact is staged, reconciled against source populations, and confirmed to exist for the full audit window.
How DCYBR Gets You There
Our readiness process is built for SaaS teams that need SOC 2 to unblock enterprise deals, not for teams with six months and a compliance headcount.
In Week 1 we run a gap assessment: missing controls, documentation gaps, and audit blockers against your actual system. Not a generic template. Your specific stack, your audit boundary, your evidence posture.
Weeks 2 through 4 cover control implementation: policies, platform configuration on Drata, Vanta, or Secureframe, integrations, and evidence preparation. Engineering involvement is kept minimal and targeted.
Weeks 4 through 6 are the mock audit and final preparation. We run through fieldwork conditions, remediate any remaining gaps, and coordinate with your CPA auditor so you enter the formal engagement prepared.
Most teams reach audit-ready status in 30 to 45 days. The formal CPA audit begins after that, once the evidence window is complete.
If you are pursuing Type 2, our process includes a 90-day monitoring window with monthly compliance health checks, vendor review support, and full audit support through completion, all included in the engagement. For a detailed breakdown of what changes between Type 1 and Type 2 from an evidence standpoint, read our SOC 2 compliance audit guide.
Frequently Asked Questions
How long does SOC 2 readiness take?
For most SaaS teams using AWS, GCP, or Azure with 10 to 100 employees, we get to audit-ready in 30 to 45 days. The audit window itself, the period your controls need to run before a Type 2 report, is separate and typically 90 days minimum.
What is the difference between a readiness assessment and the audit?
A readiness assessment is the internal review that identifies gaps before a CPA firm is involved. The audit is the formal AICPA-accredited engagement that produces the attestation report. Most teams that skip the readiness step and go straight to audit face delayed timelines and unexpected exceptions once fieldwork begins.
Do I need a compliance platform to get SOC 2?
Not technically, but in practice, running a clean Type 2 audit without one is significantly harder. We work with Drata, Vanta, and Secureframe and configure the platform as part of our engagement. The platform handles continuous monitoring; we make sure what it is monitoring actually matches your audit scope.
What happens if evidence is missing for a sampled period?
The control is considered to have failed for that period. Depending on how significant the control is and how many samples are affected, it can result in a qualified opinion or a formal exception in the final report. The mitigation is to present alternative evidence such as backup logs or system metadata that demonstrates the control operated even if the primary artifact is unavailable.
How much does SOC 2 readiness cost with DCYBR?
Type 1 readiness starts at $12,000. Type 2 is $18,000. Our Hybrid path, Type 1 through Type 2 with a single partner, is $25,000 and is the most common engagement for teams that want to close enterprise deals quickly and then sustain the report. All engagements include support through audit completion, not just through readiness.
Most teams start with a 20-minute readiness call to confirm scope and timeline. If you are preparing for your first audit and want to understand exactly where your gaps are before committing to a platform or a CPA firm, reach out to DCYBR. For teams earlier in the process, our SOC 2 for SaaS companies guide is a good starting point to understand how scoping decisions affect your readiness timeline.
Ready to get started?
Need SOC 2 Type 2 readiness in 4–6 weeks? Start in 72 hours at DCYBR.com.