Blog

Your First SOC 2 Type 2 Audit: What to Expect

July 1, 2026 · The avow team

A step-by-step walkthrough of your first SOC 2 Type 2 audit: scoping, the observation period, evidence requests, sampling, exceptions, and the report.

The one-line version

A SOC 2 Type 2 audit is a licensed CPA firm collecting evidence that your controls actually operated over a period of time — commonly 3 to 12 months — and then writing an opinion about it. Type I tests whether your controls are designed well at a single point in time. Type II tests whether they ran consistently across the whole window. That difference is why Type II takes longer, demands more evidence, and produces the report your customers actually ask for. If the distinction is fuzzy, start with SOC 2 Type I vs Type II.

One vocabulary correction up front, because it trips up every first-timer: you do not get “SOC 2 certified.” A SOC 2 report is an attestation issued under the AICPA’s SSAE 18 standard. There is no certificate and no pass/fail stamp — there is an auditor’s opinion and a detailed report. More on the categories in What Is SOC 2?.

The phases, end to end

Here is the whole flow before we go deep on each part.

Kickoff and scoping

Scoping is where your audit’s cost and difficulty get set, so treat it as a real decision, not paperwork.

Three things get nailed down:

1. Which Trust Services Criteria. Security (the Common Criteria) is always in scope. Availability, Processing Integrity, Confidentiality, and Privacy are optional and driven by what you actually do and what customers demand. Adding criteria means more controls and more evidence. Do not add Privacy “to look thorough” if no one is asking for it. See the Trust Services Criteria breakdown before you commit.
2. The system boundary. Which product, which infrastructure, which supporting tools (identity provider, ticketing, cloud accounts, code repos). Sub-service organizations like AWS or GCP get carved out — you rely on their SOC 2, you do not re-audit their data centers.
3. The observation period. A first Type 2 usually runs 3 to 6 months to get a report out faster; renewals typically run a full 12 months so they tile back-to-back with no gaps. For the timeline math, see How Long Does SOC 2 Actually Take?.

The critical thing about the period: the clock is retrospective. The auditor tests what already happened. You cannot go back and create an access review for a month you skipped. Whatever your controls say they do, they need to have been doing it for the entire window.

The observation period (the part that decides your outcome)

This is where the audit is won or lost, and it happens before the auditor does much of anything. During the period your controls just need to run on schedule and leave a trail:

• Access reviews happen quarterly (and get documented).
• Offboarding revokes access within your stated SLA.
• Change-management tickets link to code review and approval.
• Vulnerability scans run and findings get triaged.
• Security awareness training gets completed by everyone.

The failure mode is not “we do not have controls.” It is “we have controls but no timestamped proof they ran in month two.” Collecting evidence continuously, rather than scrambling at the end, is exactly the gap compliance-automation platforms like avow close: they pull evidence from your cloud, identity, and code systems on a schedule, so the period generates its own paper trail.

Evidence requests: the PBC list

When fieldwork starts, the auditor sends a PBC list — “provided by client.” It is a spreadsheet of every artifact they want, mapped to controls. Expect a mix of:

• Documents: policies, your risk assessment, vendor list, org chart, network diagram.
• Configurations / screenshots: MFA enforcement, password policy, encryption settings, logging config, backup config.
• Populations: complete lists the auditor will sample from — all employees hired in the period, all terminations, all change tickets, all production access grants.
• System-generated evidence: audit logs, ticket exports, alert history.

Two things matter enormously here. First, completeness of populations. If you hand over a list of “changes” that is missing three deploys, the auditor cannot trust the whole population, and that undermines every sample drawn from it. Second, screenshots must show context — the URL, the date, the setting. A cropped screenshot with no timestamp gets kicked back and slows everything down.

Sampling and testing

Auditors do not inspect every single event. They sample. For a control that fired 400 times over the period, they might pull a sample of 25 and inspect each one. Sample sizes scale with how often the control runs and how much the auditor relies on it; a control that runs daily gets a bigger sample than one that runs annually.

The testing methods they apply:

• Inquiry — they ask how the control works (walkthroughs).
• Observation — they watch it happen.
• Inspection — they read the evidence (the ticket, the log, the review).
• Re-performance — they redo the control themselves to confirm the result.

Inquiry alone is never enough for Type II; every operating-effectiveness conclusion has to be backed by inspection or re-performance across the sample.

Handling exceptions

An exception is a specific instance where a control did not operate as described — one terminated user whose access lingered a week, one change that shipped without a linked review. Exceptions are normal. A first audit with zero exceptions is rarer than founders assume.

What happens next:

1. The auditor documents the exception factually.
2. You get to write a management response — root cause, scope (was it one instance or systemic?), and remediation.
3. The auditor decides whether the exception is isolated or indicates the control is not operating effectively.

The distinction that matters: an isolated, well-explained exception usually stays in the report as a noted deviation while the control still earns an effective conclusion. A pattern of the same failure means the control failed, which can drive the opinion toward qualified. The most common cause of ugly exceptions is not doing the control at all for part of the period — which loops right back to why the observation period is everything. For the traps that create them, read 5 SOC 2 Mistakes Startups Make.

The final report and the opinion

The auditor drafts the report, you review for factual accuracy (not to soften findings), and the CPA firm signs it. A SOC 2 Type II report contains:

• The auditor’s opinion.
• Management’s assertion.
• A system description you write, describing your service and controls.
• The test matrix — every control, the test performed, and the result, including any exceptions.

The four opinion types:

Most well-prepared first audits land an unqualified opinion, sometimes with a few noted exceptions in the test results.

How to prepare so there are no surprises

• Do a readiness assessment first. Run the SOC 2 Readiness Checklist and close design gaps before the period starts, not during it.
• Pick the period deliberately. Start it only once your controls are genuinely operating — day one of the window is day one of scrutiny.
• Assign an evidence owner. One person accountable for the PBC list beats five people each assuming someone else has it.
• Automate collection. Continuous evidence capture removes the end-of-period scramble and prevents the “we did it but cannot prove the date” exception.
• Dry-run your populations. Before fieldwork, pull your own list of hires, terminations, and changes and confirm it is complete and reconciles to your systems.

Prepared teams experience the audit as mostly administrative. Unprepared teams experience it as a month of firefighting over evidence that no longer exists. The difference is entirely in what you did during the observation period, not during fieldwork.