SOC 2 Audit Process and SOC 2 Audit Preparation

The SOC 2 audit process runs in three phases: planning, where you and a licensed CPA firm agree the scope, the criteria in scope, and the observation period; fieldwork, where the auditor tests your controls by interviewing owners, inspecting configuration, and sampling evidence from across the period; and reporting, where the firm issues its opinion. SOC 2 audit preparation is the work that happens before any of that: closing gaps, assigning owners, and building an evidence set that can survive sampling.

Almost everything that goes wrong in a SOC 2 audit goes wrong before the auditor arrives. Teams treat the audit as the project, when the audit is really a test of a program that was either running or not running during the months under review. This guide walks through what actually happens at each phase, what the auditor will ask for, and what the finished report contains.

What does a SOC 2 audit include?

A SOC 2 audit is an attestation examination performed by a licensed CPA firm against the AICPA's 2017 Trust Services Criteria, with revised points of focus issued in 2022. Security, known as the common criteria, is always in scope. Availability, processing integrity, confidentiality, and privacy are optional categories you add if your customers or your product require them.

Two things sit alongside the criteria and surprise first-timers. The first is the system description, which you write, not the auditor, following the AICPA's 2018 description criteria (DC 200, with revised implementation guidance in 2022). The second is management's assertion, a formal statement from your leadership that the description is accurate and the controls were suitably designed and, for a Type 2, operating effectively. The auditor's opinion is an opinion on your assertion. That framing matters: the audit is not the auditor writing a report about you, it is the auditor testing a claim you have made.

The three phases of a SOC 2 audit

For a Type 1 the observation period is a single date, so fieldwork tests design only. For a Type 2 it is a period, commonly 3 to 12 months, and fieldwork tests whether the controls operated throughout. The difference in effort between the two is almost entirely in the evidence, which is covered in SOC 2 Type 1 vs Type 2. If you are still deciding which SOC report your customer actually wants, start with SOC 1 vs SOC 2.

How do you prepare for a SOC 2 audit?

Preparation is four jobs, in this order. Define the control set against the criteria in scope. Give every control a named owner rather than a team. Close the gaps a readiness assessment exposes, before the observation period starts rather than during it. Then start collecting evidence continuously, because a Type 2 samples from the whole window and cannot be back-filled.

That last point is the one that costs teams a cycle. If your observation period opens on January 1 and you begin gathering artifacts in March, the auditor will sample January and February and find nothing. There is no honest way to reconstruct a quarterly access review that did not happen. The practical consequence is that evidence collection has to be running before the window opens, not after your kickoff call.

Work the control list rather than a generic checklist. Our SOC 2 controls list walks through the common criteria series and what each one expects, and the SOC 2 compliance checklist covers the sequencing.

What evidence will the auditor ask for?

Evidence requests cluster into a handful of recurring types, and knowing the shape of them ahead of time is most of the preparation:

• Populations and samples. You provide a complete list, such as every employee who joined or left during the period, or every production change. The auditor selects from it. An incomplete population is worse than a slow one, because it undermines everything sampled from it.
• Configuration screenshots and exports. MFA enforcement, password policy, encryption settings, logging configuration, backup schedules, dated at the time of capture.
• Recurring reviews. Quarterly user access reviews, vendor reviews, and risk assessments, with proof of who reviewed, when, and what changed as a result.
• Change management records. Pull requests with reviewer approval, CI results, and deployment records tying a change to an authorization.
• Monitoring and incident records. Evidence that systems are monitored and that alerts reach a human. If availability is in one of your scoped categories, the auditor will want a record of uptime and incidents across the period, which means a monitoring service that retains history rather than a dashboard showing only the present. Teams that already run continuous uptime and API monitoring can export that history instead of reconstructing an incident timeline from chat logs.
• Policies and acknowledgments. Approved, versioned policies plus proof that the staff they apply to have read them.

How does sampling work in a SOC 2 audit?

For a Type 2 the auditor tests a sample rather than every instance, then draws a conclusion about the whole population. If you onboarded 40 people during the period, they may test a handful of those onboardings end to end: was access approved, was it provisioned at the right level, was training completed. The sample size scales with how often the control runs and how much risk sits behind it.

The consequence is that consistency beats intensity. A control performed perfectly ten times and skipped once will likely surface, because the auditor is selecting without knowing which instances were clean. This is why "we will tidy it up before the audit" is not a strategy for a Type 2, and why controls that depend on somebody remembering tend to fail while controls that are scheduled and chased tend to pass.

What happens if the auditor finds an exception?

An exception is an instance where a control did not operate as described. One exception does not automatically mean a qualified opinion. The auditor considers how many instances failed, how severe the failure was, and whether any compensating control caught it. Minor, isolated exceptions are commonly noted in the report with management's response alongside them.

What you cannot do is delete the finding. A SOC 2 report with a small number of documented exceptions and a credible remediation plan is a normal artifact, and experienced security reviewers on the customer side read them without alarm. What damages trust is a report whose description does not match reality, or a company that quietly lets its coverage lapse and hopes nobody checks the dates.

How often are SOC 2 audits done?

SOC 2 reports cover a period, and there is no such thing as a permanent SOC 2 certification, so most companies run a Type 2 every year with the new period starting where the last one ended. Enterprise customers usually ask for a report no older than 12 months, and gaps between periods are visible.

When your report period ends before your customer's fiscal year does, they will typically ask for a bridge letter, sometimes called a gap letter: a statement from your management covering the interval between the end of the report period and the date they need. It is not an audit product and carries no auditor opinion, so it is not a substitute for the next report.

Who can perform a SOC 2 audit?

Only a licensed CPA firm can issue a SOC 2 report. This is the point where software vendors sometimes blur the line, so it is worth stating plainly: no platform, including ours, can certify you or issue an opinion. Compliance tooling gets the control set mapped, the evidence organized, and the gaps closed so the examination is a review rather than an excavation. The CPA firm independently tests and forms the opinion. Budget them separately, and see SOC 2 audit cost for what the audit itself runs and how long SOC 2 takes for realistic timelines.

The short version

Scope narrowly, start the evidence before the window opens, put a named human on every control, and expect the auditor to sample rather than skim. Teams that do those four things find fieldwork uneventful. Teams that treat the audit as the project spend the observation period discovering that the months already behind them cannot be fixed. Running the program in SOC 2 compliance software mostly buys you the thing that is hardest to buy back later: a complete evidence trail for a period that has already passed.