The SOC 2 Audit Process: Timeline, Steps, and What to Expect

The SOC 2 audit process can feel opaque, especially for SaaS teams going through it for the first time. Auditors use terminology that overlaps with but differs from engineering language. Timelines seem to stretch unpredictably. Evidence requests arrive in waves that disrupt sprint cycles. The entire experience is easier to manage when you understand exactly what happens at each stage, why it happens, and what the auditor is looking for.

This guide walks through the entire SOC 2 audit process from start to finish — from selecting your CPA firm to receiving and distributing your final report. Every section includes the specific actions SaaS teams should take, the pitfalls to avoid, and the timeline expectations that match real-world engagements.

Selecting an Auditor

Your SOC 2 report must be issued by a licensed CPA (Certified Public Accountant) firm. This is a non-negotiable requirement set by the AICPA. Security consultancies, penetration testing firms, and compliance platforms cannot issue SOC 2 reports — only CPA firms with the appropriate attestation credentials can.

What to Look For

Industry experience with SaaS and cloud environments. An auditor who primarily serves manufacturing or healthcare companies will struggle to evaluate a Kubernetes-based microservices architecture. Ask specifically: “How many SaaS/cloud-native companies have you audited in the past 12 months?”

Firm size and its tradeoffs:

• Big 4 (Deloitte, EY, PwC, KPMG): Maximum brand recognition. Their SOC 2 reports carry weight with the largest enterprises. Downsides: highest cost ($80K-$200K+), less flexibility on timelines, and your engagement may be staffed by junior associates with limited SaaS context.
• Mid-tier firms (BDO, Grant Thornton, RSM, Moss Adams, Schellman): Strong balance of credibility and SaaS expertise. Many mid-tier firms have dedicated technology/SaaS audit practices. Cost: $30K-$80K. These firms are the most common choice for growth-stage SaaS companies.
• Boutique firms: Specialized SOC 2 practices with deep technical knowledge. Often more responsive and flexible. Cost: $20K-$50K. The tradeoff: some enterprise procurement teams may not recognize the firm name, though this matters less than SaaS teams typically assume.

Communication style and responsiveness. You will be working closely with this firm for weeks or months. During the selection process, evaluate how quickly they respond to your questions, how clearly they explain their process, and whether they assign a dedicated engagement manager.

Questions to Ask Potential Auditors

1. How many SOC 2 audits have you completed for SaaS companies in the past year?
2. What does your evidence request list look like? Can we see a sample?
3. How do you handle evidence from compliance platforms like GRCTrail, Vanta, or Drata?
4. What is your typical timeline from engagement letter to final report?
5. Do you offer combined Type I + Type II pricing?
6. Who will be the engagement partner, and who will be doing the day-to-day testing?
7. How do you communicate during the audit — portal, email, shared drive?
8. What is your approach to exceptions — do you flag them early or only in the draft report?

Typical Engagement Timeline

The selection process itself takes 2-6 weeks:

1. Week 1-2: Issue RFPs to 3-5 firms, or schedule introductory calls
2. Week 2-4: Receive proposals, compare scope, pricing, and team composition
3. Week 4-6: Select firm, negotiate engagement letter, agree on timeline and scope

In practice: Do not start the auditor selection process at the last minute. If a customer needs your SOC 2 report by Q4, begin selecting your auditor no later than Q1 — earlier if you have significant preparation work ahead.

Pre-Audit Preparation (3-6 Months Before)

The preparation phase is where SaaS teams invest the most effort. What you do here determines whether your audit runs smoothly or becomes a fire drill.

Readiness Assessment and Gap Analysis

Before engaging your auditor, perform an honest evaluation of your current control environment against the Trust Service Criteria you plan to include.

A readiness assessment identifies:

• Controls that exist and are operating — These are ready for audit
• Controls that exist but are not consistently followed — These need operational reinforcement
• Controls that are partially implemented — These need to be completed
• Controls that do not exist — These need to be designed and implemented from scratch

See our SOC 2 risk assessment guide for a structured approach to identifying and prioritizing gaps.

In practice: A typical growth-stage SaaS company completing a readiness assessment discovers 15-30 control gaps. Most involve documentation (policies that exist informally but are not written down), process formalization (access reviews that happen ad hoc but not on a schedule), or tooling (logging that exists but is not centralized or monitored).

Define Your System Description and Scope

Your system description is a critical document in the SOC 2 report. It describes:

• Infrastructure: Cloud providers, data centers, network architecture
• Software: Applications, databases, middleware, third-party services
• People: Organizational structure, roles, responsibilities, hiring and termination procedures
• Procedures: Operational processes, including manual and automated controls
• Data: Types of data processed, data flows, and data boundaries

The scope defines what is included in the audit and, equally important, what is excluded. For a SaaS company, the scope typically covers the production environment and all supporting systems (CI/CD, monitoring, identity management) but may exclude corporate IT, marketing systems, or development environments.

SaaS example: A SaaS company scoping their audit might include their AWS production account, GitHub organization, Okta tenant, PagerDuty instance, and Jira project — while excluding their corporate Google Workspace, marketing automation platform, and local development machines.

Implement Missing Controls

Based on your gap analysis, prioritize and implement controls that are missing or incomplete. Common implementations for SaaS companies include:

• Formal security policies — Information security policy, acceptable use policy, data classification policy, incident response plan (see SOC 2 policies and procedures guide)
• Access management — Centralized identity provider with MFA enforcement, role-based access to production, automated deprovisioning on termination
• Change management — Required pull request reviews, branch protection rules, automated testing in CI/CD pipeline
• Logging and monitoring — Centralized log aggregation, alerting for security events, defined escalation procedures
• Vendor management — Inventory of sub-service organizations, annual security reviews, contractual requirements (see SOC 2 vendor management guide)
• Risk assessment — Formal risk register, annual risk assessment process, risk treatment plans

Begin Evidence Collection

Do not wait for the audit to start collecting evidence. Begin capturing evidence for every control as soon as it is implemented. This is especially critical for Type II audits where you need to demonstrate sustained operation over the review period.

Evidence takes many forms:

• Screenshots of system configurations (MFA settings, encryption settings, network rules)
• Exports from tools (access lists, audit logs, vulnerability scan results)
• Meeting records (risk assessment minutes, incident response reviews, access review sign-offs)
• Tickets (change management records, incident tickets, onboarding/offboarding tasks)

See our SOC 2 evidence collection guide for a comprehensive list of what auditors expect.

Conduct Internal Testing

Before the auditor arrives, test your own controls. This internal audit identifies issues you can fix before they become exceptions in your report.

In practice: Assign a team member who is not the control owner to test each control. Can they verify that the last four quarterly access reviews were completed? Can they confirm that every production change in the past month went through the required approval process? Can they find evidence that the annual risk assessment was performed? Anywhere the answer is “no” is a gap that needs remediation before the audit.

Designate Your Audit Team

Identify the people who will interact with the auditor:

• Audit coordinator — The single point of contact who manages the relationship, schedules interviews, and tracks evidence requests. This is often the compliance lead, security lead, or head of engineering.
• Control owners — The individuals who can speak to how each control operates. For SaaS companies, this typically includes the VP of Engineering, DevOps/SRE lead, IT admin, HR lead, and security engineer.
• Executive sponsor — A C-level (usually CTO or CISO) who provides the management assertion and signs off on the system description.

The Audit: Phase by Phase

Phase 1: Planning and Scoping (1-2 Weeks)

The engagement begins with the auditor understanding your environment and agreeing on the audit parameters.

What happens:

• Kickoff meeting — The auditor’s engagement team meets your audit team. They review the scope, timeline, communication protocols, and evidence submission process.
• System description review — The auditor reviews your draft system description and may request modifications for clarity, completeness, or alignment with AICPA standards.
• TSC confirmation — Final agreement on which Trust Service Criteria are included in the examination.
• Sub-service organizations — Identification of third-party vendors whose controls are relevant to your service (e.g., AWS for infrastructure, Stripe for payments). The auditor determines whether to use the “inclusive” or “carve-out” method for each.
• Examination period — For Type II, formal agreement on the start and end dates of the review period.

What the auditor delivers: An initial evidence request list (often called a PBC — Prepared by Client — list). This document lists every piece of evidence the auditor needs, organized by control area. A typical PBC list contains 80-200+ items.

SaaS team action: Review the PBC list immediately. Assign each item to a control owner with a deadline. Identify any items you cannot produce and discuss with the auditor early — it is far better to address evidence gaps upfront than to scramble during testing.

Phase 2: Control Walkthroughs (2-4 Weeks)

The auditor performs detailed walkthroughs of your control environment.

What happens:

• Interviews with control owners — The auditor meets with each control owner to understand how controls operate in practice. These are not interrogations — they are structured conversations. The auditor asks questions like: “Walk me through what happens when a new employee joins the company. How do they get access to production systems? Who approves that access? How is it documented?”
• Policy and procedure review — The auditor reads your security policies, operating procedures, and process documentation. They verify that these documents are current, approved by management, and communicated to relevant personnel.
• Control mapping — The auditor maps your controls to specific Trust Service Criteria points of focus. Each TSC point of focus must have at least one control addressing it.
• Design assessment — The auditor evaluates whether each control, as designed, would effectively satisfy the relevant criteria. This is where the auditor identifies design deficiencies — controls that exist but would not prevent or detect the risk they are intended to address.

For Type I engagements: This phase also includes limited testing — the auditor inspects a small number of control instances to confirm that the control is implemented as described. For example, they might verify that one access review was completed, that one change management ticket shows proper approval, or that encryption is currently enabled on the database.

SaaS team action: Prepare control owners for interviews. They should be able to describe their controls without reading from a script, explain what evidence demonstrates the control is operating, and identify any recent changes to the process. Authenticity matters more than polish.

Phase 3: Testing of Operating Effectiveness (Type II Only — 3-6 Weeks)

This is the most intensive phase of a Type II audit and does not apply to Type I engagements.

What happens:

The auditor tests whether controls operated effectively throughout the entire review period. They use four primary testing techniques:

Inspection — Examining documents, records, and configurations. Example: Reviewing 25 randomly selected change management tickets to verify each one has the required approvals, testing evidence, and deployment documentation.

Observation — Watching a control being performed in real time. Example: Observing the security team conduct their daily log review process.

Re-performance — The auditor independently executes the control to verify the result. Example: Re-running a reconciliation calculation to confirm it produces the same output as your system.

Inquiry — Asking control owners about specific instances. Inquiry alone is never sufficient — it must be corroborated by one of the other techniques.

Sample sizes and populations:

The auditor determines sample sizes based on control frequency and the population of control instances:

Control Frequency	Population (12-month period)	Typical Sample Size
Annual	1	1 (test the single instance)
Quarterly	4	2-4
Monthly	12	5-8
Weekly	52	15-25
Daily	365	25-45
Per occurrence	Varies	25-50+ (based on population)

Evidence request waves: Expect multiple rounds of evidence requests. The auditor may request additional samples if initial testing reveals issues, or may need clarification on evidence already submitted. Responsiveness during this phase directly impacts the audit timeline.

SaaS team action: Have evidence organized and accessible before this phase begins. If you are using a compliance platform, ensure all automated evidence collection is functioning and that manual evidence has been uploaded on schedule. Assign a dedicated person to triage and respond to auditor requests within 24-48 hours.

Phase 4: Reporting (2-4 Weeks)

What happens:

• Exception identification — The auditor compiles any instances where controls did not operate as designed. Each exception includes a description of what was expected, what was found, and the potential impact.
• Draft report preparation — The auditor prepares the complete SOC 2 report, including their opinion, your system description, and the detailed control testing results.
• Draft report review — You review the draft for accuracy. This is your opportunity to correct factual errors in the system description, provide context for exceptions, and draft management responses.
• Management response — For any exceptions, you write a formal response explaining the cause, the remediation actions taken or planned, and the timeline for resolution. This response appears in the final report alongside the exception.
• Final report issuance — After incorporating your feedback and management responses, the auditor issues the final signed report.

SaaS team action: Allocate 3-5 business days for the draft review. Have your executive sponsor, legal counsel, and audit coordinator review the draft. Pay particular attention to the system description (it becomes a public-facing document shared with customers) and any exceptions (your management responses will be read by every customer who requests the report).

Understanding Your Report

A SOC 2 report follows a standardized structure. Understanding each section helps you interpret your results and prepare for customer questions.

Section I: Independent Service Auditor’s Report (The Opinion)

This is the most important section. The auditor’s opinion states whether your controls met the selected Trust Service Criteria.

Unqualified opinion — The best outcome. The auditor concludes that your controls were suitably designed (Type I) or operating effectively (Type II) in all material respects. This does not mean zero exceptions — it means any exceptions were not material enough to affect the overall opinion.

Qualified opinion — The auditor identified issues significant enough to affect their conclusion for one or more criteria. A qualified opinion is a red flag for enterprise buyers and typically requires significant remediation before the next audit cycle.

In practice: The vast majority of SOC 2 reports receive an unqualified opinion. Auditors work with you throughout the engagement to address issues. A qualified opinion usually indicates a systemic breakdown — not a few minor exceptions.

Section II: Management’s Assertion

Your management’s formal statement that the system description is accurate, controls are suitably designed, and (for Type II) controls operated effectively during the review period. This is signed by an executive — typically the CTO or CEO.

Section III: Description of the System

The detailed system description covering infrastructure, software, people, procedures, and data. This section is co-authored by you and refined by the auditor. Enterprise buyers read this section to understand what your service does and how it is secured.

Section IV: Trust Service Criteria, Controls, and Test Results

The detailed control matrix. For each Trust Service Criteria point of focus, this section lists:

• The specific control(s) you have in place
• The auditor’s test procedure
• The test results (including any exceptions)

This is the longest section of the report and the one that technical reviewers scrutinize most carefully.

Section V: Other Information

Optional section for supplementary information that is not directly part of the examination. Some companies include additional context about their security program, certifications, or planned improvements.

What Exceptions Mean

Exceptions are not failures. They are instances where a control did not operate as designed. Common examples:

• An access review was completed one week late
• Two out of thirty sampled change management tickets were missing a required approval
• A backup restore test was not performed in one quarter

Exceptions become problematic when they are:

• Pervasive — The same control failed in a high percentage of tested instances
• Material — The failure relates to a critical control with significant risk implications
• Unremediated — The issue was identified but no corrective action was taken

A well-written management response acknowledges the exception, explains the root cause, describes the remediation, and commits to a timeline. Enterprise buyers expect a few minor exceptions — they are concerned when exceptions suggest systemic issues or management indifference.

Common Audit Pitfalls

SaaS teams encounter the same issues repeatedly. Avoiding these saves weeks of audit delays and prevents unnecessary exceptions.

Incomplete Evidence for the Full Review Period

The problem: Controls were implemented partway through the observation period. The first three months have no evidence.

The fix: Align your Type II observation period with your control implementation timeline. If controls were not in place until June, do not start your observation period in January. Discuss timing with your auditor during the planning phase.

Policies That Do Not Match Actual Practices

The problem: Your incident response policy describes a process involving three escalation tiers, a war room, and a formal post-mortem within 48 hours. In reality, incidents are handled in a Slack channel with ad hoc resolution.

The fix: Write policies that describe what you actually do, not what you aspire to do. Auditors test against your documented policies. If reality differs, that is an exception. It is better to have a simple, accurate policy than an impressive, aspirational one.

Missing Vendor Management Documentation

The problem: You rely on 15 third-party services but have no vendor inventory, no security assessments, and no contractual language requiring SOC 2 or equivalent compliance from vendors.

The fix: Build a vendor inventory, classify vendors by risk level, collect SOC 2 reports or security questionnaire responses from high-risk vendors, and ensure contracts include appropriate security and data protection clauses. See our SOC 2 vendor management guide for a complete framework.

Last-Minute Control Implementations

The problem: Controls are implemented in the weeks before the audit, leaving no operating history for the auditor to test.

The fix: Start early. Controls implemented in the final month of the observation period provide almost no testable evidence. The auditor needs to see controls operating consistently over time.

Poor System Description That Does Not Match Reality

The problem: The system description describes an architecture that was accurate 18 months ago but does not reflect a major re-architecture, a cloud migration, or the addition of new services.

The fix: Update the system description as part of your pre-audit preparation. Have your engineering team review it for technical accuracy. Include architecture diagrams that match your current production environment.

After the Audit

Receiving your SOC 2 report is not the end — it is the beginning of a continuous compliance cycle.

Remediate Exceptions

Address every exception identified in the report. Document the remediation, including what changed, when it was implemented, and how you verified the fix. Your next auditor will specifically test whether prior-year exceptions have been resolved.

Plan for Next Year

SOC 2 is an annual commitment. Begin planning your next audit cycle immediately:

• Confirm your auditor for the next period (or begin a new selection process if switching firms)
• Adjust your observation period if needed — most companies settle into a rolling 12-month cycle
• Update controls based on lessons learned from the current audit
• Expand scope if you plan to add Trust Service Criteria for the next cycle

Share Your Report With Customers

Establish a standard process for distributing your report:

1. Customer requests the report (usually through sales or security team)
2. Mutual NDA is signed (if not already in place)
3. Report is delivered through a secure channel (secure link with access controls, not as an email attachment)
4. Track who has received the report and when

Maintain Continuous Compliance

The gap between annual audits is where compliance erodes. Implement continuous monitoring to ensure controls keep operating throughout the year, not just during audit season.

How GRCTrail Helps

GRCTrail is built to streamline every phase of the SOC 2 audit process:

• Readiness assessment — Automated gap analysis that maps your current environment against SOC 2 requirements and generates a prioritized remediation plan
• Policy library — Pre-built, SOC 2-aligned policy templates customized for SaaS companies, ready for your review and adoption
• Evidence automation — Continuous collection from 50+ integrations (AWS, Azure, GCP, Okta, GitHub, Jira, and more), eliminating manual screenshot collection
• Auditor collaboration — Structured portal where your auditor can review evidence, request clarifications, and track progress without email chains
• Control monitoring — Real-time dashboards showing control health, with alerts when controls stop operating as expected
• Vendor management — Centralized vendor inventory with automated SOC 2 report collection and risk scoring
• Multi-year tracking — Track exceptions, remediations, and audit history across cycles to demonstrate continuous improvement

Related Guides

• SOC 2 Type I vs Type II: Differences, Costs, and Which to Choose
• SOC 2 Trust Service Criteria: The Complete Guide
• SOC 2 Policies and Procedures: What You Need to Document
• SOC 2 Evidence Collection: What Auditors Want to See

Get started with GRCTrail →