SOC 2 Audit Preparation Guide: A Step-by-Step Playbook for SaaS Teams

Let's get one thing out of the way: preparing for a SOC 2 audit is not glamorous work. It's spreadsheets and policies and screenshots and access reviews and a lot of conversations that start with "wait, who owns that control?"

But it's also not the nightmare people make it out to be. The companies that struggle with SOC 2 prep are almost always the ones that started without a plan — or worse, started with someone else's plan that didn't fit their organization.

This guide is the plan. We've laid out every phase, in order, with the kind of detail that actually helps you assign work and set deadlines. Not theory. Not "it depends." Concrete steps, realistic timelines, and the places where SaaS companies consistently lose weeks they didn't need to lose.

For a downloadable gap analysis template, grab the SOC 2 Checklist.

Before We Start: The Timeline Nobody Wants to Hear

Here's the honest version.

If you're starting from scratch — no formal security policies, no prior audit, no compliance tooling — you're looking at roughly 3 to 6 months of preparation before your audit observation period even begins. That covers scoping, gap analysis, control design, implementation, documentation, and getting your evidence collection processes running.

Then comes the observation window. For a SOC 2 Type II (which is what enterprise buyers want), your auditor needs to see controls operating effectively over a sustained period. That's typically 6 to 12 months, though some firms will accept a 3-month window for a first-time report.

So. Best case, you're looking at about 6 months from kickoff to a Type II report in hand. More commonly, 9 to 14 months.

A SOC 2 Type I — which evaluates control design at a single point in time — can be done faster. Some companies use a Type I as a stepping stone while they build toward Type II. That's a legitimate strategy, especially if you have active deals waiting on compliance documentation.

The takeaway: Start earlier than you think you need to. The number one regret we hear from SaaS compliance leads is "we should have started six months ago."

Phase 1: Scoping Your Report (Weeks 1–2)

Scoping is the highest-leverage decision in the entire process. Get it right, and everything downstream becomes clearer. Get it wrong, and you'll spend months building controls for criteria that don't belong in your report — or, worse, you'll leave out criteria your customers expect.

Pick Your Trust Services Criteria

Every SOC 2 report includes Security. That's mandatory. The other four — Availability, Processing Integrity, Confidentiality, and Privacy — are yours to choose.

For most SaaS companies, the answer is Security + Availability + Confidentiality. Processing Integrity gets added if your product transforms, calculates, or processes data that customers rely on for decisions. Privacy is rarely included for B2B companies (most handle it through separate GDPR/CCPA programs).

How to decide: Pull up your customer contracts, MSAs, SLAs, privacy policy, and marketing site. Every commitment you've made — uptime guarantees, data handling promises, confidentiality clauses — maps to a criterion. If you've said it, scope it.

Define Your System Boundaries

This is the part that sounds straightforward and then takes three meetings to resolve.

You need to document exactly what's "in scope" for your audit. That includes:

• Infrastructure. Cloud providers, regions, accounts. Are you on AWS? GCP? Multi-cloud? Which accounts and environments are in scope — just production, or staging and dev too?
• Software. Your application, APIs, admin tools, and internal dashboards. If a system touches customer data, it's probably in scope.
• People. Which teams and roles have access to in-scope systems? Engineering, DevOps, customer support, executives — all potentially relevant.
• Processes. Onboarding, offboarding, incident response, change management, vendor reviews. The human workflows that support your controls.
• Data. What types of customer data flow through your systems? Where is it stored, processed, and transmitted?

A common mistake here: scoping too broadly. If your dev environment doesn't touch customer data, don't include it — you're just creating extra work. Conversely, don't artificially narrow scope to make the audit easier if it means leaving out systems that customers reasonably expect to be covered.

Choose Type I or Type II

If you've never had a SOC 2 report and you have deals that need one soon, consider starting with a Type I to get something in prospects' hands quickly. Then begin your Type II observation window immediately after.

If you have the runway (6+ months before you'll need the report in a deal), skip Type I and go straight to Type II. It's what enterprise buyers care about, and doing both adds cost without proportional value.

Phase 2: Gap Analysis (Weeks 2–4)

Now you know what's in scope. The next question is: how far are you from where you need to be?

A gap analysis compares your current state — the controls you already have in place, the policies you've already written, the evidence you're already collecting — against the requirements of each Trust Services Criterion you've selected.

How to Run It

Take the Common Criteria (CC1 through CC9 for Security, plus whichever additional criteria you've scoped) and walk through them one by one. For each criterion, ask three questions:

1. Do we have a control that addresses this? Maybe you already have MFA enforced, access reviews running quarterly, and incident response documented. Great. That's a control.
2. Is the control documented? Having a practice isn't the same as having a policy. Auditors need written documentation that describes the control, who's responsible, and how it works.
3. Are we collecting evidence? If the control exists and is documented but you have no logs, screenshots, or records proving it's working — that's still a gap for Type II.

The output of this exercise is a gap matrix: a spreadsheet (or whatever tool you use) that maps every relevant criterion to your current state, identifies gaps, and prioritizes remediation.

Download our SOC 2 Checklist for a structured template that covers all five TSC with control mapping and evidence fields.

Where Gaps Typically Hide

After watching dozens of SaaS companies go through this exercise, a few patterns are predictable:

Policy documentation. Almost every company has more controls in practice than on paper. The gap isn't "we don't do this" — it's "we do this but never wrote it down." Expect to spend significant time formalizing policies for access management, change management, incident response, data classification, acceptable use, and vendor management.

Vendor risk assessments. CC9.2 requires you to assess and monitor third-party risk. Most SaaS companies rely on 20 to 50+ vendors. Having a documented risk assessment for each one — and a process for annual reviews — is a bigger lift than it sounds.

Employee security training. You probably do some version of security onboarding. But is it documented? Is there a record of who completed it and when? Can you show ongoing training, not just one-time?

Access reviews. You might have RBAC and MFA. But do you periodically review who has access to what, confirm it's still appropriate, and document the results? Quarterly access reviews are a standard expectation.

Business continuity and disaster recovery. Having a BCP/DR plan in a Google Doc isn't enough. You need evidence of actual testing — tabletop exercises, failover tests, restore-from-backup drills — with documented outcomes.

Get Expert Help If You Need It

This is the phase where an experienced advisor pays for itself. If your team hasn't been through a SOC 2 before, you'll spend a lot of time guessing at what "sufficient" looks like for each criterion.

YSecurity works with SaaS companies on exactly this problem — hands-on cybersecurity services that include gap assessments, control design, and audit readiness support. They understand both the AICPA framework and the practical realities of SaaS infrastructure, which means you're not building generic controls from a template. You're building controls that fit your actual environment and risk profile.

The difference between "we think we're ready" and "we know we're ready" usually comes down to whether someone with audit experience reviewed your gap analysis before you started building.

Phase 3: Control Design and Implementation (Weeks 4–12)

This is where the real work happens. You've identified your gaps. Now you need to close them.

Designing Controls That Auditors Respect

Every control should answer four questions:

• What does it do? (A clear description of the control activity)
• Who owns it? (A named person or role — not "the team")
• How often does it happen? (Continuous, daily, weekly, quarterly, annually)
• What evidence does it produce? (Logs, tickets, screenshots, sign-offs, reports)

Here's an example that illustrates the difference between vague and auditable:

Vague: "We review user access periodically."

Auditable: "The IT Operations Lead reviews all active user accounts in Okta and AWS IAM quarterly (Q1/Q2/Q3/Q4). The review is tracked in a Jira ticket that includes the reviewer's name, the date, the list of accounts reviewed, and any changes made. Removed or modified accounts are documented with justification."

See the difference? The second version can be tested. An auditor can pull up the Jira tickets, verify the dates, check that all accounts were covered, and confirm changes were logged. The first version gives the auditor nothing to work with.

The Controls Most SaaS Companies Need

Your specific control set depends on your scope, but here's what the core usually looks like for a SaaS company pursuing Security + Availability + Confidentiality:

Access Management

• SSO with MFA enforced for all employees and contractors
• Role-based access control (RBAC) with documented role definitions
• Least-privilege access policies — especially for production systems
• Quarterly access reviews with documented remediation
• Automated deprovisioning tied to your offboarding process

Change Management

• Pull request workflows with required code review and approval
• Separation of duties — the person who writes the code shouldn't be the only one approving it
• Documented change management policy covering standard, emergency, and infrastructure changes
• Automated CI/CD with testing gates before production deployment

Incident Response

• Written incident response plan with defined severity levels
• On-call rotation and escalation procedures
• Post-incident review process (blameless postmortems, documented lessons learned)
• Communication plan for notifying affected customers

Monitoring and Logging

• Centralized logging for all in-scope systems (application logs, access logs, infrastructure logs)
• Alerting on anomalous behavior and security events
• Log retention that covers your audit observation period (minimum)
• Regular review of monitoring outputs — not just "we have Datadog" but "someone looks at it."

Data Protection

• Encryption at rest and in transit for customer data
• Data classification policy
• Data retention and destruction procedures
• Backup procedures with documented and tested restores

Vendor Management

• Vendor inventory with risk tiers
• Annual risk assessments for critical vendors
• Review of vendor SOC 2 reports or equivalent certifications
• Contractual protections (data processing agreements, SLAs)

People

• Background checks for employees with access to customer data
• Security awareness training at onboarding and annually
• Acceptable use policy
• Documented onboarding and offboarding procedures

Business Continuity

• BCP/DR plan documented and reviewed annually
• Recovery time objectives (RTO) and recovery point objectives (RPO) are defined
• DR testing performed at least annually with documented results
• Multi-region or failover architecture (for the Availability criterion)

Implementation Tips That Save Time

Write policies first, then implement. It's tempting to start building controls and circle back to documentation later. Don't. Policies give you a blueprint, and they're often the longest pole in the tent. Start writing on day one.

Use templates, but don't copy-paste. Generic policy templates are fine as a starting point. But your auditor will notice if your access management policy describes a system you don't use. Customize everything to reflect your actual environment.

Automate evidence collection early. If you wait until your audit window to figure out how to export access logs from Okta or pull deployment records from GitHub, you'll be scrambling. Set up automated exports, scheduled screenshots, or GRC tool integrations during implementation — not after.

Don't boil the ocean. You don't need to be perfect. You need to be sufficient and consistent. A simple control that runs reliably every quarter beats a complex control that runs once and then gets forgotten.

Phase 4: Evidence Collection and the Observation Period (Months 3–12+)

For a Type II report, this is the marathon. Your controls are in place, your policies are written, and now you need to demonstrate that everything works — not just on the day you set it up, but continuously over the observation period.

What Counts as Evidence

Auditors want to see artifacts that prove your controls are operating as described. The specifics vary by control, but common evidence types include:

• System-generated logs. Access logs, deployment logs, monitoring alerts, and backup completion records. The best evidence is the kind that happens automatically and can't be easily fabricated.
• Tickets and records. Jira tickets for access reviews, incident reports, and change requests. Timestamps matter — they prove the work happened within the observation window.
• Screenshots. Configuration screenshots showing MFA is enforced, encryption is enabled, and firewall rules are in place. Date-stamp or annotate them.
• Sign-offs. Documented approvals for access changes, policy reviews, and vendor assessments. A name, a date, and a decision.
• Meeting notes and agendas. Security review meetings, risk assessment sessions, and management reviews. These prove governance is happening, not just existing on paper.
• Training records. Completion logs from your security awareness training platform, with dates and participant lists.

The Evidence Calendar

Set up a recurring schedule so evidence collection doesn't pile up at the end. Something like:

Weekly: Review monitoring dashboards. Check for open incidents. Verify backup completion.

Monthly: Pull access logs. Review new vendor additions. Confirm training completion for recent hires.

Quarterly: Conduct formal access reviews. Run vulnerability scans. Review and update risk assessments. Test a DR scenario.

Annually: Full policy review and update cycle. Comprehensive vendor risk reassessment. BCP/DR tabletop exercise. Penetration testing.

Build this into your team's workflow as recurring tasks — in your project management tool, your calendar, wherever your team actually tracks work. The worst version of evidence collection is "we'll gather everything the week before the auditor asks for it."

Continuous Readiness vs. Audit Cramming

There are two ways to approach SOC 2 evidence:

The cramming model: Ignore it for 11 months, then spend 4 frantic weeks assembling screenshots and exports before your auditor arrives. This works exactly once, and even then it's miserable. Your evidence will have gaps, your team will be burned out, and your auditor will notice the inconsistencies.

The continuous readiness model: Build evidence collection into daily and weekly operations. When audit time comes, you're pulling from an organized repository — not reconstructing history from Slack messages and memory.

Every company that's been through more than one SOC 2 cycle ends up at continuous readiness. The question is just how painful the first cycle has to be before you get there.

Phase 5: Selecting and Working With Your Auditor (Overlaps with Phases 2–4)

Don't wait until you're "ready" to engage an auditor. The best time to have an initial conversation with a CPA firm is during or right after your gap analysis — months before the actual audit begins.

How to Choose a Firm

Not all SOC 2 auditors are created equal. Here's what to look for:

SaaS experience. An auditor who mostly does SOC 2 for financial institutions will have a different set of expectations than one who works with cloud-native SaaS companies. You want someone who understands CI/CD pipelines, cloud infrastructure, and modern dev practices — not someone who's going to ask about your server room.

Size match. Big Four firms are thorough but expensive and often slow. Boutique firms specializing in SOC 2 tend to be faster, more responsive, and more affordable — but make sure they're a licensed CPA firm with SOC experience. There's a sweet spot in the middle that works for most growth-stage SaaS companies.

Readiness assessment. Many firms offer a pre-audit readiness assessment (sometimes called a "gap assessment" or "readiness review"). This is gold. It gives you a preview of what the auditor will look for and flags issues you can fix before the formal examination starts. Yes, it costs extra. It's almost always worth it.

Communication style. You'll be working closely with this firm for weeks or months. Do they explain things clearly? Are they responsive? Do they give you specific remediation guidance, or just a list of findings? Ask for references from other SaaS companies they've audited.

During the Audit

Once the formal examination begins, your job is to make the auditor's life easy. That means:

Organize your evidence in advance. Don't make the auditor chase artifacts. Set up a shared folder or evidence repository organized by criterion and control. Label everything clearly. Include date ranges.

Assign an internal point person. Somebody on your team needs to own the auditor relationship — scheduling walkthroughs, answering questions, coordinating evidence requests across teams. If this responsibility is diffused across five people, things will fall through the cracks.

Be honest about gaps. If you know a control had a lapse during the observation period — an access review was late, a backup test was missed, an incident wasn't documented properly — tell the auditor proactively. Auditors respect transparency, and a disclosed exception is much better than one they discover and you have to explain.

Respond to requests quickly. Audit timelines stretch when evidence requests sit unanswered. Set an internal SLA for auditor requests — 48 hours is reasonable — and hold your team to it.

What the Report Looks Like

When it's done, your auditor delivers a SOC 2 report that includes:

• Management's assertion. Your company's statement about its controls.
• Auditor's opinion. The CPA firm's independent assessment of whether your controls meet the relevant criteria.
• System description. A narrative describing your systems, infrastructure, processes, and control environment.
• Tests of controls. The specific procedures the auditor performed and the results. This is where any exceptions or qualified opinions show up.

A "clean" report means no exceptions — every control tested as described. But a report with minor exceptions isn't a disaster. What matters is how you address them. Most enterprise buyers can live with an exception or two as long as you've remediated the issue and can explain what happened.

Phase 6: After the Audit — Where Most Companies Drop the Ball

You've got the report. Congratulations. Now comes the part nobody warns you about: keeping the whole machine running.

The Report Is a Starting Line, Not a Finish Line

Your SOC 2 report has a shelf life. Most enterprise buyers want to see a report that's less than 12 months old, which means you're on an annual audit cycle from now on. The controls, evidence collection, and documentation maintenance that got you through the first audit? That's your new normal.

Companies that treat SOC 2 as a one-time project — hire a consultant, cram for the audit, file the report, move on — get brutalized by the second cycle. Their evidence has gaps. Their policies are stale. Their team members who "owned" compliance have moved to other roles.

The companies that breeze through year two (and beyond) are the ones who embedded compliance into their operating rhythm during year one.

Security Questionnaires: The Hidden Tax

Here's what catches people off guard. You assumed that having a SOC 2 report would make the security questionnaire problem go away. It doesn't. In fact, it sometimes makes it worse — because now more prospects take you seriously, which means more prospects reach the stage where they send you a 300-question DDQ.

Having the report gives you the answers. It doesn't give you the time to fill out every questionnaire manually.

This is the operational bottleneck Cyberbase was designed to eliminate. The platform's Context Engine ingests your SOC 2 report, policies, control documentation, and prior questionnaire responses — then generates accurate, context-aware answers to new DDQs and security questionnaires as they come in. It doesn't spit out canned responses. It understands the specific way your organization implements controls and tailors answers accordingly. And it learns: every interaction makes it more precise.

The numbers tell the story. The Augment Code team — whose CISO, Jon McLachlan, co-founded Cyberbase alongside Sasha Sinkevich — used the platform to process 155 contracts and saved 743 hours in a single year. That's a 13:1 ROI. And those hours weren't coming from an outsourced firm. They were coming back to an internal team that had better things to do.

Your Trust Portal: Compliance on Your Terms

There's another layer to this. Even before a prospect sends you a formal questionnaire, they want to understand your security posture. They're evaluating whether you're worth the procurement effort.

Cyberbase's Trust Center lets you publish your compliance documentation — certifications, SOC 2 overview, security practices, data handling policies — on a public-facing page that prospects can browse on their own time. No back-and-forth emails requesting the report. No NDA dance before they can see your cert. No sales team playing middleman for a document that should be self-serve.

The kicker? It's free. Forever. No annual subscription, no usage caps. Competitors like SafeBase/Drata, Vanta, and Secureframe charge $6,000 to $15,000+ per year for similar trust center functionality. Cyberbase gives it away because the Trust Portal is the front door to their broader platform — DDQ automation, AI contract redlining, and the Context Engine that ties it all together.

If you're going to invest months in SOC 2 preparation, you should get maximum leverage from the result. A report that lives in a shared drive and gets emailed on request is leaving value on the table.

The Full SOC 2 Audit Prep Timeline — At a Glance

9 Mistakes That Derail SOC 2 Audits

We've been around enough SaaS audit cycles — through our own work and through conversations with security leaders on The Security Podcast of Silicon Valley — to see the same mistakes recur. Here's the list nobody gives you upfront.

1. Starting too late. This is the most common mistake by a wide margin. The deal is in motion, the buyer wants a SOC 2 report, and suddenly, compliance becomes urgent. You can't compress a 9-month process into 9 weeks. Start before the first customer asks.

2. Scoping too broadly. Including every system, every environment, and every employee in scope sounds thorough. It's actually counterproductive. Scope should reflect what's relevant to the services you provide to customers — not everything your company touches.

3. Writing policies after building controls. Controls without policies are just practices. And practices without documentation are invisible to auditors. Write the policy first, then build the control to match.

4. Treating it as an IT-only project. SOC 2 touches engineering, HR (onboarding, training, background checks), legal (vendor contracts, data processing agreements), and leadership (governance, risk acceptance). If your compliance effort lives entirely within the IT or security team, you're missing pieces.

5. Choosing the wrong auditor. A cheap audit from an inexperienced firm can be worse than an expensive one from a good firm. If your auditor doesn't understand modern SaaS infrastructure, you'll waste hours explaining things that shouldn't need explaining — and you might end up with findings that reflect the auditor's confusion rather than actual gaps.

6. Ignoring vendor management until the last minute. You need a complete vendor inventory, risk tiers, and documented assessments. For critical vendors, you should be reviewing their SOC 2 reports or equivalent certifications. This takes longer than people budget for.

7. Not testing DR and backup recovery. "We have backups" is not evidence. "We restored from backup on March 15, 2026, and here's the test report documenting the process and results" — that's evidence. The same goes for disaster recovery. If you haven't tested your failover, you don't know if it works.

8. Letting evidence collection lapse mid-observation. If your quarterly access review was supposed to happen in Q2 and it didn't, you have a gap in your observation period that your auditor will flag. Set reminders. Assign owners. Track completion.

9. Treating the report as the end goal. The report enables enterprise sales. But it only keeps enabling sales if you maintain the controls, keep documentation current, and operationalize the questionnaire response process. Otherwise, you're paying for an annual audit that supports a compliance posture that's already outdated.