SOC 2 Audit Preparation Checklist for SaaS Companies

SOC 2 is not a product security audit. Misunderstanding that distinction is responsible for a lot of wasted preparation effort. Think of it like being graded not on how fast you can run, but on whether you showed up to practice every day and documented it.

What SOC 2 actually tests is whether your documented controls match what your team does in practice, and whether what your team does matches what you've promised customers. The framework is built around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory one. Every audit includes it. The other four are optional additions you layer on based on the nature of your product and your customer commitments.

The structural backbone of any SOC 2 engagement is the Common Criteria, organized into categories CC1 through CC9. These derive from the COSO Internal Control framework, with AICPA additions covering logical access, system operations, and change management. Every engagement applies these criteria. The optional TSC categories add on top of them, covering only the additional commitment areas relevant to your scope.

The current standard is the 2017 TSC, with revised points of focus issued in 2022. The criteria themselves did not change; the guidance around them was updated. Some older prep materials still reference the 2016 standard, which was superseded, so verify what your resources are citing before you rely on them.

Auditors are evaluating the alignment between what you've documented, what you do, and what you've promised. A technically sophisticated product with no documented controls will fail. A company with thorough documentation that reflects actual operations will pass, even if the underlying technology is relatively straightforward. The elegance of your architecture is largely irrelevant to the auditor.

Choosing Which Trust Services Criteria to Include in Scope

Start with your customer commitments, not with what looks credible on a security page.

The four optional criteria each answer a specific question about what your product does and who depends on it. Availability belongs in scope if downtime would materially harm your customers, which is true for infrastructure products, payment platforms, and anything handling real-time data. Confidentiality is relevant when customers have explicit contractual confidentiality requirements, including NDAs or data handling clauses in their agreements with you. Privacy applies when you store personally identifiable information, particularly categories that carry regulatory weight like healthcare data, government identification numbers, or data governed by GDPR or HIPAA. Processing Integrity belongs in scope when customers depend on the accuracy of your output for financial decisions, payroll, tax obligations, or similar operations where an error has downstream monetary consequences.

In practice, many SaaS companies doing their first audit choose Security only, or Security plus Availability and Confidentiality.

Scope has direct cost consequences. Adding Availability or Confidentiality will each add to the base audit cost. Adding Privacy will add considerably more, because the privacy criteria require significantly more documentation and controls around data subject rights and PII handling. Consult with your auditor for estimates specific to your engagement.

Before you finalize scope, go to your largest prospective enterprise customers and ask what they'll actually require in a vendor security review. Not what would be nice to have. What they will require. That conversation will save you from either under-scoping your report or over-engineering it with criteria no one will evaluate. Non-production systems can typically be excluded from scope as well; defining that boundary precisely reduces the audit surface area and the corresponding evidence burden.

Deciding Between Type 1 and Type 2 Before Preparation Begins

This decision shapes your entire timeline, so make it before you do anything else.

Type 1 assesses whether your controls are properly designed at a single point in time. Type 2 assesses whether those controls both exist and operated effectively over a sustained observation period. The minimum observation period for a Type 2 report is six months; the standard for mature compliance programs is twelve months of annual coverage.

Type 1 timelines run roughly three to six months from start to final report. Type 2 timelines run six to fifteen months for a first report, depending on when the observation window opens and how prepared you are when fieldwork begins. Once fieldwork starts, the typical window from fieldwork to delivered report runs nine to twelve weeks.

Enterprise security teams increasingly ask for Type 2 and will treat Type 1 as insufficient evidence of operational maturity. A Type 1 report proves you had controls at a moment in time; it doesn't prove you've been running them. I've seen sales teams get burned by this: they closed the gap on a deal with a Type 1 report, then had to go back to the same customer eight months later and explain why they still didn't have a Type 2.

Unless a specific deal requires documentation before your observation window can close, go straight to Type 2. The common workaround for time-pressured situations is to issue a Type 1 while simultaneously starting the Type 2 observation period. You get paper to share immediately; the Type 2 runs behind it and will be ready within the year.

Type 2 reports are valid for twelve months and require annual renewal. Build that renewal cycle into your calendar from the first day of preparation, not retroactively when the report expires and a prospect is waiting on it.

Assigning Ownership and Standing Up the Cross-Functional Team

Name a single audit owner before you do anything else. Not a team. Not a committee. One person who is accountable for timelines, evidence collection, and auditor communication.

At early-stage SaaS companies, that person is typically the CTO or a senior engineering lead until a dedicated security hire is in place. The specific title matters less than the clarity of accountability. Evidence requests stall when they land in a shared inbox or get distributed across an engineering team without a single person responsible for the response.

Here is the part that surprises most engineering-led companies: SOC 2 touches far more of the organization than infrastructure and code. An auditor at Schneider Downs noted that roughly fifty percent of the audit has nothing to do with the security of your software. It involves risk management and more people in the company than just engineering and DevOps.

The cross-functional stakeholders who need explicit roles in your audit preparation: engineering and infrastructure, IT and operations, HR for background checks and offboarding procedures, legal and procurement for vendor contracts and third-party risk, and executive leadership for policy approval and sign-off.

The deliverable from this step is concrete: a named audit owner, a RACI or equivalent responsibility assignment document, and a shared project calendar with milestone dates tied to your target report date. Without that document, the project drifts. With it, people stop asking whose job something is.

Conducting the Readiness Assessment to Find Gaps Before Auditors Do

A readiness assessment is an internal review of whether your controls are documented, consistently followed, and aligned with the Trust Services Criteria you've selected. It happens before you engage a formal auditor.

It is technically optional. Skipping it is expensive. When auditors find gaps during fieldwork, fixing them delays the report and will require re-engagement. Finding those same gaps yourself, weeks earlier, costs you remediation time but not audit fees.

What a readiness assessment catches that a generic checklist misses: logs that are incomplete or cover the wrong time period; controls with no named owner; policy documents that describe a process your team stopped following months ago; evidence that exists somewhere across your tools but isn't organized or retrievable when requested. That last one shows up constantly. The data is there. It just lives in five different systems with no coherent retrieval path, and nobody thought to solve that problem until an auditor asked for it on a Thursday afternoon.

The output of a readiness assessment is a prioritized remediation list, with gaps ranked by risk impact and by how long they'll take to close. That list becomes your roadmap for the months between now and the start of your observation window. It also tells you whether your current timeline is realistic. Some companies run this step using a compliance automation platform; others use a readiness consultant. Either approach works, as long as the output includes named owners and resolution dates. A status spreadsheet that says "gap identified" without a resolution date is not a remediation plan.

Completing the Formal Risk Assessment and Documenting It

The readiness assessment finds missing controls. The risk assessment is a different exercise: it formally identifies threats and vulnerabilities across your in-scope systems and documents how your organization responds to each one.

A SOC 2-compatible risk assessment requires several specific steps. Enumerate threats and vulnerabilities across your in-scope systems and data flows. Assign probability and impact scores to each risk scenario. Map existing or planned controls to each risk. Document the residual risk that remains after controls are applied.

The risk assessment is not a one-time deliverable. It must be reviewed on a defined cadence, typically annual, and updated whenever your systems, architecture, or the threat landscape changes materially.

The most common failure mode is a risk register that's too generic to be auditable. Risks described at a high level, such as "unauthorized access to customer data," without specificity about the systems involved, the threat vectors in scope, and the controls mapped to each, don't satisfy auditors and don't drive real control decisions. I've reviewed registers like this that took weeks to produce and were essentially useless when it came time to defend them.

The risk assessment also feeds directly into the policy layer that follows. You cannot write a credible access control policy or incident response policy until you've documented what you're protecting against and why. Get this right before you start building policies; the sequence matters.

Building and Approving the Core Policy Set

Policies are what you say you do. Controls are how you do it. Evidence is proof that you did it. All three must exist, and all three must align. A gap between any two of them is an audit finding.

For a Security-only SOC 2 scope, you need at minimum: an access control policy covering who can access what and how access is granted, reviewed, and revoked; a change management policy governing how code and infrastructure changes are reviewed, tested, and deployed; an incident response policy defining how security events are identified, escalated, contained, and documented; a vendor management policy establishing how third-party risk is assessed and monitored; and a business continuity and disaster recovery policy with documented recovery time and recovery point objectives, tied to tested procedures.

Each policy requires explicit leadership approval and a named review date. Undated or unsigned policies are among the most common audit findings, and they're entirely preventable. Every policy document should have a version number, an approval signature, and a scheduled review date.

Where companies consistently stumble is the non-technical side. Vendor reviews, HR procedures, and risk management processes are where the gap between what companies say they do and what they actually do is widest. A policy written to sound impressive but not followed is worse than having no policy, because it creates a documented and auditable discrepancy. Write policies that describe your actual operations. If your current operations don't meet the bar, close the gap first, then write the policy.

Implementing the Technical Controls Across Infrastructure and Access

Most SaaS engineering teams are already doing parts of this. The audit makes it systematic, documented, and testable.

On access and identity: multi-factor authentication must be enforced for all production systems and admin accounts, not just encouraged. Least-privilege access means users and services have only the permissions their role requires, enforced by configuration rather than convention. Formal access reviews must happen on a defined schedule, typically quarterly. Offboarding procedures must revoke access within a defined window after termination; this is one of the most commonly flagged gaps, because informal processes leave former employees with active credentials longer than anyone realizes.

On encryption and data handling: customer data must be encrypted both at rest and in transit. A data classification scheme that distinguishes sensitive from non-sensitive data within your scope is required to demonstrate that you know what you're protecting.

On vulnerability and patch management: regular vulnerability scanning on a documented schedule, a patch cadence with defined SLAs for critical findings, and annual penetration testing. Pen test results and remediation records are expected evidence for most Type 2 audits.

On logging and monitoring: centralized log collection across in-scope systems, alerting on security-relevant events like unauthorized access attempts and privilege escalation, and a log retention policy aligned with your observation period. If your retention settings cut off before the observation window opens, you have no auditable evidence for that portion of the period.

On change management: every production change goes through a documented review, whether that's a pull request approval process, a deployment checklist, or an equivalent control. Evidence of that review must be retrievable. Git history alone is insufficient if it doesn't demonstrate that a second party reviewed and approved the change.

Organizing and Collecting Evidence Before the Auditor Requests It

Auditors issue a list of evidence requests, sometimes called a PBC list, covering every control in scope. The quality, completeness, and organization of your response directly affects both the timeline and the likelihood of findings.

The evidence types by control category follow a predictable pattern. For access control: user access lists, access review records, offboarding tickets showing when access was revoked, MFA enrollment reports. For change management: pull request approvals, deployment logs, change tickets. For incident response: incident logs, post-mortems, and escalation records. Critically, if no major incidents occurred during the observation period, you still need documentation showing the process was tested and is operational; absence of incidents is not the same as absence of evidence. For vendor management: third-party risk assessments, vendor SOC 2 reports or security questionnaire responses, and contract records. For HR and personnel: background check records, security training completion logs, signed acceptable use agreements.

The most common evidence failure modes are worth naming plainly. Evidence is scattered across multiple tools with no unified retrieval path. Log retention settings cut off before the observation period started. Training completions are tracked informally with no exportable report format. All of these are solvable problems, but none of them are quick fixes when an auditor is waiting.

Build a centralized evidence repository, organized by control family, before the observation window opens. Doing it during fieldwork adds weeks to the timeline and increases the likelihood of gaps surfacing at the worst possible moment. If you're using a compliance automation platform, verify explicitly that it can produce auditor-ready exports; some platforms track compliance status effectively for internal purposes but generate formats auditors won't accept. Confirm this before fieldwork begins.

Selecting an Auditor and Understanding What the Formal Audit Process Involves

SOC 2 reports can only be issued by a licensed CPA firm. Not a consultant, not a compliance automation platform, not a law firm. This is a legal requirement embedded in the AICPA standard. Any vendor offering a SOC 2 report outside of that structure is offering something that looks like one but won't be accepted by enterprise security teams.

SaaS and cloud infrastructure experience matters more than firm size when you're evaluating auditors. Auditors unfamiliar with cloud-native architectures will ask for evidence in formats that don't exist in modern infrastructure, misinterpret the absence of on-premise controls as a gap, and slow the entire engagement. Ask prospective auditors directly how many SaaS or cloud-native companies they've audited in the past two years. The answer tells you a great deal about whether their methodology will actually fit your environment.

Pricing varies considerably across firm size and scope. Boutique firms with strong SaaS specialization will provide faster turnaround than large generalist firms for early-stage companies. Larger enterprise software companies with complex infrastructure or regulatory overlap will benefit from firms with broader resources. Get multiple quotes, and ask what the fieldwork-to-report timeline looks like for a company of your size and scope.

The formal audit process follows a consistent sequence: an entrance meeting to confirm scope, a fieldwork phase where the auditor reviews evidence against each control, a findings discussion, and a report drafting phase. Management responses to any exceptions are included in the final report. A finding during fieldwork is not a crisis; it's a normal part of the process. Companies that treat it as a crisis tend to be the ones who skipped the readiness assessment.

Start conversations with auditors before you've closed all your gaps. Good auditors will tell you what they'll expect to see, and that conversation helps you calibrate whether your remediation timeline is realistic relative to your target report date. The companies that finish this process with a clean report are not the ones with the most sophisticated infrastructure. They're the ones who started earlier than they thought necessary, assigned real ownership, and didn't convince themselves they could compress the sequence.