Preparing for SOC 2: A Readiness Guide

Reviewed by Marcus Dunhill, CISA, CISSP

SOC 2 preparation takes 6 to 12 months for most organizations starting near-zero on documentation. The process follows a predictable sequence: readiness assessment, gap remediation, control environment build-out, evidence collection, and audit trail organization. According to ISACA's 2024 State of IT Audit survey, 68% of first-time SOC 2 organizations underestimate preparation timelines by 3 or more months. Getting the sequence right eliminates the scrambling, re-audits, and budget overruns that sink first-time efforts.

You've decided to pursue SOC 2. Now you're staring at a blank whiteboard asking where to start. You don't need to hire a consultant, but you do need a roadmap. The preparation phase is where most companies waste time and money — not because they do the wrong things, but because they do them in the wrong order or without a clear starting point.

The good news is that preparing for SOC 2 follows a predictable sequence. You assess where you stand, identify the gaps, build your control environment, document everything, and create an organized audit trail. Get this phase right and your audit will be smooth. Get it wrong and you'll scramble during fieldwork, run up additional auditor fees, and discover that something you thought was working actually isn't. This guide walks you through the logical sequence so you can avoid the most common mistakes.

Starting With an Honest Assessment

A readiness assessment is the single highest-ROI step in the entire SOC 2 process because it prevents you from paying an auditor $150 to $400 per hour to find gaps you could have identified yourself. Before you engage an auditor and before you commit to a timeline, evaluate whether your controls actually exist and are documented. You don't need to hire an expensive consultant — you can do it internally or with someone who knows your systems well — but you do need to answer hard questions.

A readiness assessment answers four specific things. First, what controls do you have today? The answer is usually "more than you think, but they're just not documented." You probably already have access controls, change management processes, monitoring systems, and incident response procedures. They're in someone's head or scattered across wiki pages and email chains. The question is whether they're formalized and documented enough that an auditor can verify them. Second, which Trust Service Criteria are most relevant to your business? You don't need to cover all five criteria — you only need the ones that matter for what you actually do. A SaaS company probably needs Security and Availability. A data processing company might need Security, Processing Integrity, and Confidentiality. Getting scope right early saves time and money later.

Third, where are the real gaps? These fall into two categories. You might have gaps in documentation — you do quarterly access reviews but you've never documented the process or collected evidence that you did them. Or you might have gaps in controls themselves — you claim you have a disaster recovery plan, but you've never actually tested it, or you say you review access quarterly but you've actually only done it twice in the past year. Those gaps have to be closed before the auditor arrives. They're not the auditor's job to find and fix — they're your job to fix proactively.

The output of a readiness assessment is a prioritized list of work: critical things that must be fixed before the audit can start, important things that should be fixed during preparation, and nice-to-have improvements that can wait. This list becomes your roadmap for the next six to twelve months.

Building Your Control Environment Systematically

Building a control environment means ensuring that you have repeatable processes in place to do the things you claim you do. It doesn't mean installing expensive new software or hiring a security team. Start with the most critical controls: access management, change management, monitoring, and incident response. For each control, you need three things: a policy, a procedure, and evidence.

The policy is the written rule — "We require MFA for all administrative access" or "We perform quarterly access reviews." Policies don't need to be elaborate or lengthy. A one-page policy that clearly states what you require and why is better than a ten-page tome that nobody reads. The procedure is how you actually enforce the policy: step-by-step instructions that someone outside your company could follow. If your policy says quarterly access reviews, your procedure should describe which systems are reviewed, how the review is conducted, who approves it, and how evidence is documented. Evidence is proof that you did it — access review logs, approval emails, signed documentation, anything showing the control operated.

This is where companies struggle because they treat policy as the hard part when it's actually the easy part. Writing a policy mostly means deciding what you already do and writing it down. The hard part is making sure you're actually following the policy consistently and documenting that you did. If your incident response policy says you notify affected customers within 24 hours of discovering a breach, your procedures need to make that actually happen, and you need evidence showing that you've done it. An incident log showing that you discovered a breach on Tuesday and notified customers on Wednesday is far more valuable to an auditor than a well-written policy that you've never executed.

Build your control environment incrementally. Start with the highest-risk areas and the controls that matter most to your customers — Security comes first. Then expand to other areas. The mistake of trying to be perfect immediately — drafting a 50-page security policy for a company of ten people — is wasted effort. What you actually need is clarity about what you do and how you do it.

Documenting What You Actually Do

Documentation is where most companies stumble because it's tedious work that doesn't feel like security. But it's non-negotiable. According to a 2023 Coalfire audit trends report, documentation gaps account for roughly 43% of all SOC 2 exceptions — making it the single largest category of findings.

The policy should include what you require, why you require it, and who's responsible. The procedure should include step-by-step instructions detailed enough that someone could follow them. Most companies already have these in someone's head or scattered across Confluence pages and shared drives. You're mostly organizing and clarifying, not inventing from scratch. Start with the high-risk areas: security, incident response, access management, and change management. Expand to other areas like data retention, disaster recovery, and vendor management. Store your documentation in a version-controlled system — a shared drive with dates, a wiki with change history, whatever — so the auditor can see when things were created and updated.

Here's a critical point that trips up organizations: don't document what you wish you were doing. Document what you're actually doing. If you don't actually review access quarterly, don't write a policy saying you do. Either start reviewing access quarterly or document that you review it semi-annually. The auditor will find mismatches between documented controls and actual practice, and those mismatches become findings. It's much better to claim a slower review cycle that you actually follow than to claim quarterly reviews that you're only doing two times a year.

Collecting Evidence Your Controls Work

For each technical control, you need evidence showing it's actually enabled and working. This evidence looks like system configuration screenshots showing the setting is turned on, logs showing the control is operating, and test results showing the control works. A common gap is that companies have technical controls in place but they're not collecting evidence that they're working. If you require MFA but you're not logging MFA usage, how will you prove it to the auditor? Start collecting logs for every technical control you claim to have.

Here's the timing issue that catches most organizations off guard: you need months of log data to satisfy an auditor doing a Type 2 audit. If your audit observation period is six months, the auditor needs six months of logs showing your controls were operating. If you turn on logging three weeks before the auditor arrives, you have three weeks of evidence for a six-month audit period. You'll have to re-audit after collecting a full six months of logs, which means extending the timeline and paying for additional auditor time. Start collecting logs now, months before the audit.

For companies using cloud platforms like AWS or Azure, much of the evidence collection is automated. You can download logs and configuration reports directly from your cloud provider. For on-premises systems, you might need to set up logging if you haven't already. This is where technical staff becomes crucial — they need to understand that the audit isn't about having controls, it's about proving they work. Evidence collection is the time-intensive part of preparation. Budget for months of continuous log collection so that by the time the auditor shows up, you have a full history of your controls working.

Organizing Your Evidence Library

An organized evidence library is the difference between a $50,000 audit and a $75,000 audit because auditor hours spent waiting for you to find documents are auditor hours you're paying for. Create a centralized location — a shared drive, a wiki, a dedicated folder structure, whatever makes sense for your team — where the auditor can find everything they need.

Organize it by Trust Service Criterion, by control, or by time period. Include your policies and procedures, your evidence of control operation, your access reviews, your change logs, your incident reports, your vulnerability assessments, your disaster recovery test results, and everything else that proves you do what you claim. When the auditor shows up, the audit trail and evidence library should be ready. The auditor should be able to point to a control and you should be able to say "here's our policy, here's evidence we're following it, here's the log showing it happened."

Start organizing your evidence library two to three months before the audit. Use a simple spreadsheet or database to track what evidence exists, where it is, and what control it supports. This map becomes your evidence checklist during the audit. When the auditor asks for evidence of quarterly access reviews, you can immediately point them to the folder containing all four quarters of reviews with dates and approvals. This efficiency saves time and money because the auditor isn't waiting for you to scramble through email or shared drives to find things.

The evidence library is also useful for you. As you prepare, it becomes clear very quickly what you're missing. If you create an evidence tracker and realize you have no documentation of incident responses for the past year, you know you have work to do before the audit. That's exactly the situation where you want to discover gaps during preparation, not when the auditor is testing.

Realistic Timeline for Preparation

Plan for 6 to 12 months from readiness assessment to audit start if you're starting from near-zero on documentation. Most of that time isn't technical work — it's the unglamorous work of documenting processes, collecting logs, doing evidence organization, and making sure everything you claim is actually true.

Here's a realistic sequence. Months one and two are for your readiness assessment and gap identification. This is when you figure out where you stand and what work is ahead. Months two and three are when you build critical controls you're missing and start collecting evidence. This is the phase where your technical staff is busy implementing logging, configuring monitoring, setting up processes that didn't exist before. Months three through six involve heavy documentation work, evidence collection, and populating your evidence library. This is where you take the policies that live in your head and write them down, where you start collecting months of log data, where you begin organizing your evidence. Months six through nine are for evidence organization, policy refinement, and testing controls to make sure they actually work. This is when you verify that the quarterly access review you documented actually happened the way you described. Months nine through twelve are final evidence collection and a final audit readiness check before you officially engage the auditor.

If you're doing Type 2, this timeline is concurrent with your control operation — you're collecting evidence continuously while your controls run. You need months of evidence to demonstrate that your controls worked consistently. If you're doing Type 1, you can compress the timeline because you're only proving controls worked on a single day. Small companies with simple control environments might do it in four to six months. Large companies with complex environments might take twelve to eighteen months. The variability is huge because it depends on where you're starting from.

The biggest mistake companies make is underestimating this timeline. They think they'll spend a month documenting and they'll be ready. Then they're three months in and realize they need to actually test their disaster recovery plan, or they've never done a formal access review, or they need to implement change management for deployments. Budget conservatively. Better to finish early than to rush and have the audit reveal you're not actually ready.

Getting Preparation Right

Preparation for SOC 2 is about systematic assessment, building and documenting your controls, collecting evidence continuously, and organizing everything so the auditor can verify your claims. Start with a readiness assessment so you know where you stand and don't pay for an auditor to find obvious gaps. Build your control environment systematically, starting with the highest-risk areas that matter most to your customers. Document what you actually do, not what you wish you were doing. Collect evidence continuously — logs, screenshots, documentation — that proves your controls are working. Organize everything in an audit trail and evidence library before the auditor arrives.

A company that skips or rushes preparation will find that the audit is inefficient, that remediation costs spike, and that they have to re-audit after fixing gaps. A company that does preparation right will have a smooth audit, stronger controls, and a more valuable SOC 2 report at the end.

Frequently Asked Questions

How long does SOC 2 preparation take if we already have some documentation?
Organizations with existing documented policies and active controls typically compress preparation to 3 to 6 months. The main time savings come from skipping the control-building phase and moving directly into evidence collection and gap remediation. According to ISACA survey data, organizations with pre-existing ISO 27001 certification reduce SOC 2 preparation time by roughly 40%.

Can we do a readiness assessment ourselves or do we need a consultant?
Internal readiness assessments work for organizations with at least one person who understands the Trust Service Criteria and can evaluate controls objectively. Third-party readiness assessments typically cost $10,000 to $30,000 and provide an independent perspective. The choice depends on your internal expertise, not on any regulatory requirement.

What is the most common reason SOC 2 preparation timelines slip?
Evidence collection gaps. Organizations discover mid-preparation that they lack months of log data, have never formally conducted access reviews, or have no documented incident response history. These gaps cannot be fixed retroactively — you need to start collecting evidence and wait for the observation period to accumulate.

Should we use compliance automation software during preparation?
Compliance automation platforms ($10,000 to $50,000 per year) reduce manual evidence collection by integrating with cloud providers, identity systems, and ticketing tools. They are cost-effective for organizations with 50 or more employees and cloud-native infrastructure. For smaller organizations with simple environments, a well-organized shared drive and spreadsheet tracker achieves the same result.

What happens if we start the audit before preparation is complete?
The auditor discovers control gaps during fieldwork, which results in findings that require remediation and potential re-testing. Re-testing typically adds $5,000 to $20,000 in additional auditor fees and extends the timeline by 4 to 8 weeks. In severe cases, the auditor may recommend pausing the engagement entirely until gaps are closed.

How do we prioritize which controls to build first?
Start with Security controls — access management, MFA, logging, and incident response — because Security is mandatory in every SOC 2 scope and represents the highest-risk area. Then address controls related to whichever additional Trust Service Criteria your customers require. Availability controls (monitoring, change management, disaster recovery) are the second most commonly requested.