SOC 2 Audit Process: What to Expect

Reviewed by Marcus Dunhill, CISA, CISSP

The SOC 2 audit moves through five distinct phases — planning and scoping, evidence collection, fieldwork, testing, and report issuance — over a total timeline of 3 to 4 months for Type 1 and 9 to 15 months for Type 2. Total first-year cost including auditor fees and internal labor ranges from $50,000 to $250,000. According to ISACA's 2024 survey, 78% of organizations that complete a readiness assessment before engaging an auditor receive their report on schedule, compared to 41% of those that skip it.

Your auditor is arriving in two weeks. You know your controls exist, but you're not sure what actually happens during the audit, how prepared you need to be, or what the timeline really looks like. The SOC 2 audit process has distinct phases, each with specific deliverables and requirements. Understanding what's coming — what the auditor will ask for, where you'll need to invest effort, what the testing looks like, what success means — gives you the clarity to prepare effectively instead of scrambling at the last minute. This is the walkthrough of what actually happens, phase by phase, from the moment you engage an auditor through the moment you get your report in hand.

Planning and Scoping: Setting Expectations and Boundaries

Planning and scoping is the most consequential phase because the decisions you make here determine what's being evaluated and how much the entire audit will cost. You and your auditor agree on what systems, processes, and trust service criteria are included in the scope. This is where you draw boundaries. Maybe you're saying "we're evaluating our cloud infrastructure and our data processing systems, but we're not including our internal HR systems or our on-premises legacy systems." Or maybe you're scoping more broadly. Or maybe you're only scoping specific trust service criteria because your customers care about Security and Availability but not Privacy.

Scope is sometimes straightforward and sometimes contentious because bigger scope means more work for the auditor, which means higher fees, but it also means more of your organization is being evaluated. Keeping scope as narrow as possible minimizes cost, but creates a limitation: if you tell customers "SOC 2 only covers our cloud infrastructure" but your customers are asking about your overall security posture, you're giving them a partial picture. They'll come back asking why certain systems or processes weren't included. There's a balance between being cost-efficient and being comprehensive enough that the report actually answers customers' questions.

The planning phase also involves logistics that matter. When will the auditor's fieldwork happen, and for how long? How much access will they need to your systems, your people, and your documentation? What documentation do you need to have ready before they arrive? What's your target Type 1 or Type 2 timeline? These aren't trivial logistics. If your auditor says they need two weeks of fieldwork and you didn't plan for their access to systems and people, you're in trouble. Getting this phase right saves weeks of scrambling later because you've set clear expectations upfront. This is also where you should ask questions about the auditor's methodology and experience. Have they audited companies like yours before? How many SOC 2 audits have they done? What's their testing methodology? These conversations matter because they help you understand what to expect and whether the auditor's approach matches your needs.

Evidence Collection: Building Your Documentation Library Before the Auditor Arrives

Evidence collection is the most labor-intensive phase of the entire audit. This is where you pull together documentation proving that your controls actually exist and function. You need to be able to show the auditor your security policies and procedures, evidence that you followed those procedures (access logs, screenshots, onboarding documentation), configuration exports showing how your systems are set up, incident reports, access reviews, change management logs, and anything else that proves your controls worked the way you documented them.

Most companies underestimate how much evidence they need and how long it takes to collect. If your policy says "we review user access quarterly," you don't just show one access review. You need to show four access reviews — one per quarter — with documentation of who has access, who reviewed it, what was changed, and who approved the changes. If your policy says "we encrypt data at rest," you need configuration screenshots or technical documentation proving encryption is actually enabled. If your policy says "we patch within 48 hours of release," you need patch management logs showing your actual patching timeline. The auditor won't look at every single log entry or review. They'll sample — they'll review one access review in detail and then spot-check the other three. But they need material to sample from, and it all needs to be organized and ready.

The critical mistake is waiting until the auditor is there to start collecting evidence. Then you're panicking because you realize you can't find things, or you discover that you documented something informally but never wrote it down, or you realize you didn't actually do something your policy said you'd do. Start collecting evidence two to three months before the auditor's fieldwork begins. This gives you time to find things that don't exist and fix them before the auditor arrives, rather than discovering gaps during the audit and having to remediate them afterward.

Fieldwork: What the Auditor Actually Does

When the auditor's fieldwork phase begins (typically two to four weeks of activity, though not always continuously), they conduct interviews, review documentation, and observe systems. They're not trying to break into your systems or find every vulnerability. They're evaluating whether you're doing what you said you would do. The auditor interviews key personnel — IT staff, security staff, management — and asks them to walk through processes. "Show me how you handle user access requests." "Walk me through your process for employee onboarding." "What do you do when someone reports a security incident?" They're listening for consistency between what's documented and what actually happens. If the documentation says "we change default passwords immediately" but the IT person being interviewed says "honestly, I've never done that — I didn't know that was a policy," that's a red flag. That's inconsistency, which means either the policy isn't real or the process isn't being followed.

The auditor reviews your evidence library — the documentation, logs, and screenshots you've collected — to verify that your documented processes are actually being followed. They ask to see your systems and verify configuration. They might tour your facilities if you have physical infrastructure. They're looking for disconnects between your claims and reality. This is where things sometimes go sideways. A company's policy says they encrypt customer data but the auditor finds some data that isn't encrypted. That's a control failure. A company documents that they do incident response but there are no incident reports for the entire year. That's a control failure — either they didn't have any incidents (unlikely, according to Verizon's 2024 DBIR which found that 68% of breaches involve a human element) or they didn't document them.

The auditor's job in fieldwork is to find these gaps so you can remediate them. This is actually valuable. Finding a problem during fieldwork is better than discovering it later during testing. The interviews are part of the auditor's assessment too. They're evaluating whether the people running your controls understand the controls and care about them. If you have a security monitoring policy but the person responsible for monitoring doesn't understand how the monitoring works, that's a weakness the auditor will note.

Testing: Verifying That Controls Actually Work

After gathering all their evidence through observation, interviews, and documentation review, the auditor verifies that your controls function as described. This is different from reviewing documentation. If your policy says "we require MFA for all user logins," the auditor won't just look at your MFA policy — they'll test actual login attempts to verify MFA is actually enforced. If your policy says "we maintain an incident response plan," the auditor might review the plan and then ask you to walk through a hypothetical incident scenario to verify that people understand their roles and you could actually execute the plan.

If your policy says "we review access quarterly," the auditor looks at actual access reviews and verifies they're complete and signed off by management. They're sampling from your normal operations to verify the controls work. Testing can reveal that your controls have gaps. Maybe MFA is enforced for external users but not for internal users. That's a control gap. Your policy says "all users" but you're only protecting some users. The auditor notes this as a finding. Maybe your policy says you review access quarterly and it's now Q2, but you haven't done your Q1 review yet. That's a control failure for the audit period.

Testing is also where timeline issues and process breakdowns emerge. The auditor's testing is comprehensive but sampled. They don't test 100 percent of transactions or users. If you have 10,000 user access records, they'll test 50 of them thoroughly. If you deployed 1,000 patches this quarter, they'll verify a sample of them were deployed within your documented timeline. The idea is that if the sample shows controls working, the auditor can be reasonably confident the controls work overall. If the sample shows problems, they'll dig deeper or note it as a finding.

Remediation: What Happens When Problems Surface During Testing

Most companies have at least a few findings that require remediation. According to Coalfire's 2023 SOC 2 audit trends data, approximately 65% of first-time SOC 2 audits result in at least one exception. This is normal, not a sign of failure. Remediation means fixing the control that didn't work and providing evidence that it's now working. If testing found that you're not actually reviewing access quarterly, you remediate by doing the review and documenting it, then showing the auditor the evidence. If testing found that encryption isn't enabled for all data, you enable it and prove it.

The auditor might want to see evidence that the fix has been in place for a period of time to verify the remediation is sustainable, not a one-time fix for the audit. If you're doing Type 1, remediation can happen relatively quickly and you can still get your report. You fix the issue, show evidence of the fix, and the auditor includes a note about the exception in their report. If you're doing Type 2 and you have significant findings, you might need to remediate during the observation period and then have the auditor verify the fixes in future testing. The timeline impact depends on how serious the findings are and how quickly you can fix them. A simple control like "we need to document this procedure" takes a week to fix. A technical control like "we need to enable encryption on all systems" takes months.

Your auditor should give you guidance on what remediation looks like and how much additional time and cost it will add. The important mindset: remediation is expected. Almost every organization has some findings. The goal isn't a perfect audit with zero findings. The goal is a successful audit where you have few enough findings and remediation plans for the ones you do have.

The Report: Your Final Credential

Once testing is complete and any critical findings are remediated, the auditor compiles everything into your final report. The SOC 2 report has a standard structure: the auditor's opinion (did you pass or not?), management's description of your controls and control environment, the auditor's detailed testing results and findings, and supporting documentation. The auditor's opinion is typically "unmodified" (which means "pass") or "qualified" (which means "you passed but with some exceptions"). Exceptions are controls that didn't work as described.

An exception doesn't automatically mean you failed the audit. A qualified opinion with a few minor exceptions is common and acceptable to customers. But if you have significant exceptions or if critical controls failed, you might get an adverse opinion, which means "you didn't pass." When that happens, you typically remediate the issues and sometimes undergo another brief audit to verify the fixes work, which adds $15,000 to $40,000 in cost and several months of timeline.

Once you have a report, you get a final document that's typically 80 to 150 pages. It describes your system, your controls, the criteria they were tested against, and the auditor's opinion on whether those controls are effective. It includes detailed control descriptions so customers can see specifically what you're doing. The report is valid for roughly one year, with Type 2 reports regenerated annually during the ongoing observation period. After the audit, there's no ongoing regulatory reporting requirement — you don't have to report the results to anyone. But customers will ask to see it, so the report becomes a sales and retention asset.

Timeline and Cost Implications

A Type 1 audit typically takes 3 to 4 months from engagement to report. A Type 2 audit requires a 6 to 12 month observation period plus the audit phases on top of that, so you're looking at 9 to 15 months total. You can't shortcut the observation period. It's the foundation of what makes Type 2 credible.

The financial cost varies based on organization size and complexity. Auditor fees for Type 1 range from $15,000 to $50,000. Auditor fees for Type 2 range from $20,000 to $80,000. Internal labor cost for evidence collection, interviews, and audit management is substantial — plan for 500 to 3,000 hours of staff time depending on company size. The total first-year cost including auditor fees and internal labor typically falls between $50,000 and $250,000 depending on size and complexity. Subsequent years are typically 30% to 40% cheaper because the foundation is already built.

The Path Forward

The SOC 2 audit moves through distinct phases: planning and scoping where you define what's being evaluated and set expectations, evidence collection where you gather proof that your controls work, fieldwork and testing where the auditor verifies your controls through observation and testing, and the report where you get your credential. Some companies have findings that require remediation, which is normal and expected. Understanding what happens in each phase helps you prepare effectively and reduces scrambling. You now know what to expect, what documentation you need to gather, what the auditor will be looking for, and what the timeline actually looks like. That knowledge is worth an enormous amount because it lets you plan intelligently instead of treating the audit as a surprise.

Frequently Asked Questions

How long does SOC 2 fieldwork typically take?
Fieldwork runs 2 to 4 weeks for most mid-market organizations. The auditor conducts interviews, reviews documentation, and tests controls during this window. Larger organizations with complex infrastructure or multiple Trust Service Criteria in scope should expect fieldwork closer to 4 to 6 weeks.

What is the most common reason audits run over budget?
Disorganized evidence. When auditors spend hours waiting for documentation or chasing down staff for interviews, those hours are billable. Organizations that start evidence collection 2 to 3 months before fieldwork and organize materials by control or Trust Service Criterion reduce audit overruns by keeping the auditor productive during every billable hour.

Can we switch auditors between Type 1 and Type 2?
Yes, but switching resets some efficiency gains. A new auditor needs to re-understand your environment, which adds cost — expect fees closer to first-year levels. Staying with the same auditor for the Type 1 to Type 2 transition typically saves 15% to 25% on auditor fees because they already understand your control environment.

What happens if we get an adverse opinion?
An adverse opinion means critical controls failed testing. You remediate the failures, provide evidence that fixes are working, and typically undergo a follow-up audit engagement costing $15,000 to $40,000. The timeline extension is usually 3 to 6 months. Adverse opinions are rare — most organizations receive unmodified or qualified opinions.

Do auditors test every control or just a sample?
Auditors use sampling. For a company with 10,000 user access records, the auditor tests roughly 25 to 50 records. For 1,000 patches deployed in a quarter, they verify a representative sample. If the sample reveals problems, the auditor expands testing scope or documents the finding as an exception.

Is SOC 2 audit fieldwork disruptive to daily operations?
Fieldwork requires key personnel — IT, security, and management — to be available for interviews and evidence walkthroughs, typically consuming 10% to 20% of their time during the fieldwork window. The disruption is manageable with advance scheduling. The biggest operational impact is evidence collection in the months before fieldwork, not fieldwork itself.