SOC 2 audit: How it works, what it costs, and how to prepare

SOC 2 has become the price of entry for selling software to anyone who takes security seriously. If a prospect’s procurement team asks for it, the deal usually stops until you can produce a report. 

This guide walks through what a SOC 2 audit actually is, how it works, what it costs, who is allowed to perform it, and how to prepare so the process does not derail your roadmap. 

It is written for the GRC managers, security leads, and founders who own this outcome without necessarily owning a compliance background.

Key takeaways

• A SOC 2 audit is an independent assessment of a service organization's controls against the AICPA Trust Services Criteria, producing an attestation report, not a certificate.
• Type I assesses control design at a point in time. Type II assesses operating effectiveness over a minimum three-month observation period.
• For a 50-100 person SaaS company, total costs commonly run $30,000 to $80,000+, depending on scope, auditor tier, and whether a GRC platform is in use.
• The process runs from scoping and risk assessment through control testing, evidence gathering, and a final report carrying the auditor's opinion.
• Common failure points cluster in access reviews, vulnerability management evidence, and the system description in Section III.

What is a SOC 2 audit?

A SOC 2 audit is an independent assessment of a service organization’s controls, measured against the AICPA’s Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. 

A qualified CPA firm tests those controls and issues an attestation report describing whether they are suitably designed and, in a Type II, whether they operated effectively over a defined period.

One correction worth making up front, because it trips up almost every first-timer: SOC 2 produces an attestation report, not a certificate. There is no “SOC 2 certificate” to hang on a wall or attach to a trust page. The deliverable is always a report signed by a CPA firm. Getting this wrong in a contract or a security questionnaire creates real exposure, so treat the language precisely.

It also helps to see where SOC 2 sits relative to the other frameworks buyers ask about.

Security framework outputs and issuers comparison

The distinction matters for who can actually sign the report. SOC 2 is an attestation engagement, and only CPA firms enrolled in the AICPA peer review program can perform one. An independent CPA who is not enrolled cannot sign a SOC 2 report. That constraint is the reason auditor selection is a more serious exercise than most teams assume, and it shapes both cost and timeline. 

If you are starting from zero, our SOC 2 compliance resources map the full path.

SOC 2 Type I vs. Type II: Which should you pursue?

The single most common source of confusion is the difference between the two report types, so it is worth getting precise.

A SOC 2 Type I report assesses whether your controls are suitably designed at a single point in time. The opinion reads, in effect: “these controls existed and were designed correctly as of this date.” Because the auditor is verifying design at a snapshot, there is far less evidence to test, which makes Type I faster and cheaper. It is a credible signal that you have thought seriously about security, and an early enterprise prospect will often accept it.

A SOC 2 Type II report goes further. It assesses whether those controls were designed correctly and operated effectively across a defined observation period, typically three to twelve months. This is the report that most enterprise buyers mean when they ask for SOC 2. Because the auditor is testing effectiveness over time, the engagement is longer, the evidence load is heavier, and the fee is higher.

SOC 2 Type 1 vs. SOC 2 Type 2 

So which do you pursue? According to Kush Kaushik, Co-founder of Scrut Automation, roughly 70% of Scrut’s client base skip Type I and go straight to Type II. That is a Scrut client figure, not an industry-wide number, but it reflects a real pattern: if a buyer is running a serious vendor risk program, a Type I answer often stalls the deal or requires an exception. 

The practical path most teams follow is a gap assessment first, then remediation, then a practice period of at least three months while controls actually run, then a Type II audit with an observation window (February through April, for example) that captures those controls operating. 

Our guide on SOC 2 Type I vs. Type II  goes deeper, and a SOC 2 readiness assessment is the usual starting point.

Type I earns its place when controls are genuinely new. If they are already running, it is an expensive stepping stone you can skip.

Who performs a SOC 2 audit?

SOC 2 audits are attestation engagements, and they must be performed by CPA firms enrolled in the AICPA peer review program. An independent CPA who is not enrolled in peer review cannot sign a SOC 2 report. This is a requirement rooted in the AICPA’s attestation standards, and it rules out a category of provider that first-timers sometimes approach by mistake.

In practice, audit firms fall into four categories. The Big Four are the largest and most recognized, and they tend to price at the top of the range. Boutique firms practice much like a Big Four firm, but with smaller teams and fewer clients. Small CPA firms are similar to boutiques, though quality varies widely from one to the next. The fourth category, independent auditors not enrolled in peer review, cannot perform SOC 2 attestation at all.

Verifying an auditor takes ten minutes on the AICPA website. Is the firm enrolled? Has the peer review happened? Did it pass? A firm that failed should share the report and explain what the areas of concern were. Willingness to share is itself a signal.

The peer review check is the floor. Above it, weigh the audit team’s information security credentials, because an auditor who does not genuinely understand security will struggle to assess controls you have implemented well. Look for CISA, CISSP, or ISO 27001 Lead Auditor credentials on the team, along with experience in your industry and with companies at your stage and technical maturity. Watch for red flags: firms not enrolled in peer review, auditors with no information security background, and pricing that seems implausibly low for the scope described.

For a deeper look at the tradeoffs, see selecting a qualified auditor and our SOC 2 audit preparation best practices.

How much does a SOC 2 audit cost?

For a 50-100-person SaaS company pursuing SOC 2 Type II with three Trust Services Criteria, total first-year spend commonly runs $30,000 to $80,000+. The ranges below are built from real component costs, not a single quoted figure.

SOC 2 cost breakdown for a 50–100 person SaaS company

A few of these figures deserve context. On the auditor line, the lower end reflects boutique and small CPA firms; the $50K figure reflects a real Big Four quote from a comparable client, not a universal floor. 

On penetration testing, cost scales with the number of products and test levels: a client with two products across two test levels produced four test reports at roughly a $14,000 spend. 

On the consultant line, a specialist working manually spends at least 20 working days, around 160 hours, and even a lower-cost information security consultant rarely bills below $100 an hour, putting $16,000 to $25,000 as a realistic floor. Senior specialists can bill in the hundreds per hour, pushing the number well past that.

Where do companies overspend? Almost always on tooling they do not need for the audit itself. A common example: paying roughly $6,500 for a Nessus license to cover seven or eight physical servers, when the same testing can be sourced for around $1,500. Another is over-engineering endpoint tooling. You can pass a SOC 2 audit with Microsoft Defender; XDR/EDR platforms like SentinelOne or CrowdStrike are a security-maturity choice, not an audit requirement. Buying standalone cloud-testing licenses (Nessus, AWS Inspector) when a GRC platform already covers infrastructure testing is the same mistake in a different form.

The real cost drivers are straightforward: the number of Trust Services Criteria in scope, employee headcount (auditors sample joiners and leavers), the number of cloud environments, and whether a GRC platform is deployed. That last point cuts the auditor bill directly. Audit partners who integrate with a platform pull evidence continuously and spend fewer hours reaching their opinion, which they pass through as lower fees. For a fuller breakdown, see our analysis of engineering time compliance costs and how compliance automation changes the math.

Why a SOC 2 audit matters

SOC 2 is worth the effort for one blunt reason: it unlocks revenue you cannot reach without it. Enterprise procurement teams and buyers in regulated industries, financial services, healthcare, SaaS selling upmarket, treat a SOC 2 Type II report as a vendor onboarding condition. No report, no contract. That is the commercial reality that pushes most companies to start.

Beyond the deal-unlock, a SOC 2 audit produces genuine value. It forces an honest look at your controls, gives customers independent assurance that their data is handled the way you claim, and streamlines the due diligence process, so prospects can review one report instead of running you through a hundred-question security questionnaire. It also sets you apart from competitors who have not done the work.

One point of accuracy: SOC 2 is a voluntary attestation, not a law or regulation. Unlike GDPR or HIPAA, no government mandates it and no regulator enforces it. You pursue it because the market expects it, not because a statute requires it. That distinction matters when you are explaining your compliance posture to a board or an insurer.

Kush Kaushik says, “One founder we work with described a contract hanging in the balance pending SOC 2, and needed it done without cutting corners. That is the pattern we see most: compliance shows up as a revenue blocker before it shows up as a security project.” 

For more on turning this into an advantage, see how SOC 2 compliance turns into a growth strategy and security as a revenue enabler.

How long does a SOC 2 audit take?

The observation period for a SOC 2 Type II is a minimum of three months. Most companies take six to twelve months from deciding to pursue SOC 2 to holding a final report. The gap between those numbers comes down to control readiness, not the audit itself.

A useful way to picture the sequence:

Gap assessment → Remediation → Observation period (min. 3 months) → Audit fieldwork → Report issuance

The biggest variable is usually the gap between your current controls and SOC 2 requirements, and how fast your engineering team can close it. Periodic controls matter too: if access reviews and BCP testing have never run, the observation period cannot start cleanly. Auditor scheduling and report turnaround add weeks you cannot compress. A GRC platform in use from the start cuts auditor time directly, which shortens the overall path.

The three-month floor exists in part because certain controls must have run at least once during the period. Access reviews are expected quarterly; a window shorter than three months cannot capture one. That single gap is the most common reason timelines stretch, and it is entirely preventable. (More on this in the preparation steps below.)

Between audit cycles, compliance drifts. Controls lapse quietly: an access review slips, a BCP test gets postponed, a policy goes unreviewed, a vulnerability scan runs late. 

According to Kush Kaushik, a continuous monitoring platform works like having driver-assistance sensors on a highway. You would be driving carefully anyway, but the sensors flag a problem before it becomes one. The platform moves a control from green to orange to red before a lapse turns into an audit exception, giving both your team and the auditor confidence that controls ran consistently across the whole period.

See our guides on SOC 2 scope, access reviews, and continuous compliance.

How to prepare for a SOC 2 audit (step-by-step)

Step 0: Write the system description first. Everything starts here. The system description (Section III of the SOC 2 report) defines your scope, your services, your infrastructure, your subservice organizations, and the controls that protect the system. Your auditor builds their test procedures directly from it, which means a vague or incomplete description creates friction throughout the entire engagement. 

Invest real effort in describing your principal service commitments clearly, so a reader who is lightly familiar with your industry understands what you are committing to, and accurately, so it covers your actual obligations. Scoping issues are the most common source of nasty audit surprises, and this document is where you prevent them.

Step 1: Define scope and select your Trust Services Criteria. Decide which systems, products, and environments are in scope, then choose your criteria. Security (the CC series) is mandatory. Availability and Confidentiality are worth adding. The marginal cost is small: Kush Kaushik’s estimate puts all three at roughly 1.2x the cost of security alone, and the credibility gain with enterprise buyers is significant. 

Processing Integrity and Privacy are additive based on your data model, large-batch processing, and PII handling, respectively. Add them when your business warrants it, not because the list is there.

Step 2: Select your auditor. Use the peer review verification process and the five questions from the section above. Confirm AICPA peer review enrollment first, then evaluate the team’s information security credentials and industry fit. Do not skip this; the wrong auditor makes a well-run program harder to attest.

Step 3: Run a gap assessment and remediate. Assess your current controls against the Trust Services Criteria, and make sure the assessment covers the full length and breadth of the scoped system, including cloud environments, not just policies and procedures. 

A common mistake is scoping a local data center thoroughly while forgetting the cloud where the product actually runs. A GRC platform automates most of this gap identification. Then build a remediation plan prioritized by risk impact, not by walking the control list alphabetically. Fix the critical gaps first. See our SOC 2 readiness assessment, SOC 2 control list, and compliance risk assessment resources.

Step 4: Run your first access review and BCP test before the observation period starts. These are periodic controls that the auditor will sample, and if they have never been executed, your observation period is effectively blocked. Run them at least once, document them cleanly, then begin the clock. This one step prevents more stalled timelines than any other.

The SOC 2 audit process: from scoping call to final report

The process runs through seven stages:

Scoping call → System description review → Risk assessment → Control testing → Draft report review → Management assertion letter → Final report issuance

Step A: Planning. The auditor’s work begins from the system description you provide. They build their control testing matrix from that document, defining the critical controls within each criterion and the procedures they will use to test them. A strong system description reduces friction across the entire audit. That is the direct return on the time you put into Step 0.

Step B: Risk assessment. SOC 2 requires a risk assessment but does not prescribe a methodology. A good-enough approach identifies threats, rates them by probability and impact, calculates a risk value, and mitigates the risks that breach your stated risk appetite, using ISO 31000 as a guidance reference. The critical test the auditor applies is coverage: does the assessment span the full scoped system? Underdoing it is the only failure mode here.

Step C: Control testing. This is where first-timers most often pick up exceptions, and the technical CC controls are the usual culprits. CC 6.1 (logical and physical access control) is the longest and most frequently exception-bearing criterion. CC 6.6 and CC 6.7 (encryption), CC 6.8 (antivirus/EDR), CC 7.1 (configuration and vulnerability management), and CC 8.1 (change management/SDLC) are the other technical areas where exceptions cluster.

Common SOC 2 Common Criteria controls and audit exception risks

Step D: Evidence gathering. Once control testing is underway, the audit’s scale becomes visible. In Kush Kaushik's experience, a CPA firm builds 400 to 500 working papers for a single report: a control testing matrix, sampling workpapers, exception logs, exception evaluation memos, and the management representation letter, much of which supports the firm's own peer review and quality management obligations.

On your side, the job is to make evidence complete, traceable, and available. A platform that maintains an uneditable log trail, recording when a policy was drafted, reviewed, and published, and confirming that an access review actually ran each quarter, gives the auditor the comfort level they need to reach a clean opinion.

Step E: Reporting. The draft report carries the auditor’s opinion. The opinion takes one of four forms. Unqualified is clean. Qualified means one or more criteria were not satisfied. Adverse means the auditor found evidence of manufactured or unreliable documentation, genuinely rare, but it happens. Disclaimer of opinion means the auditor could not reach a conclusion, typically because samples were missing.

It is worth distinguishing an exception from a qualification. An exception is a single control within a criterion failing; a qualification is the entire criterion failing, and it appears by name in the opinion. Some firms also include a management comment provision (Section V), where the organization can add context for an exception or qualification. 

Those comments are not audited by the firm, but they cannot contradict the audit findings. One more document closes the loop: the management assertion letter, in which senior management confirms in writing, on company letterhead, that the organization operated as described. The auditor incorporates it into the final report.

Step F: Remediation and follow-up. There is no “fail” in SOC 2. You get a report. It may have no findings, some findings, or major findings, but it is still a usable report. A qualified report or one with minor exceptions is far more common and far more commercially usable than first-timers expect. Buyers read the findings, ask about remediation, and move on. Use the results to drive continuous compliance rather than treating the audit as a once-a-year scramble.

For a fuller walkthrough, see master the SOC 2 audit, our guide to types of audit evidence, and audit evidence documentation.

SOC 2 audit best practices: What actually moves the needle

A successful SOC 2 audit is less about last-minute preparation and more about consistent execution across your people, processes, and technology. These practical best practices can make the difference between a stressful audit and a predictable one.

Culture

Leadership commitment to compliance has one measurable form: whether access reviews, BCP testing, and vulnerability management actually happen on cadence. Everything else is aspiration.

Documentation

Version control and a centralized repository are table stakes. The real risk is subtler: policy documents that exist but have never been reviewed or approved by named management. 

Auditors check approval trails, not just whether a document exists. A policy that top management “approved” with a one-line email reply, without evidence that anyone read it, is exactly the kind of gap a rigorous auditor catches.

Technology

It helps to be honest about what GRC automation genuinely delivers versus what it does not. The genuine gains are specific: uneditable log trails available to auditors at any point, automated access review workflows, policy approval trails, scheduled vulnerability scans, and cloud integrations that run control testing continuously. 

Before automation, a Big Four auditor might require screen recordings of every quarterly access review to build comfort. A clean timestamped trail replaces that.

What automation does not replace: human judgment on risk acceptance, the management assertion letter, and auditor independence. Treating a platform as compliance-in-a-box is the illusion auditors see through.

Matt Black, Director of Information Security at Contentstack, shares the benefits of automation:

Training

Security awareness training is a SOC 2 requirement. It must happen, and it must be documented. A post-training evaluation is not strictly required, but it strengthens the auditor’s comfort that the training was effective. Phishing simulations go a step further to confirm behavior actually changed. A learning management system produces the timestamped completion record the auditor needs, and retires the signed attendance sheet.

Ron Buell, CTO of Sounding Board, described the payoff plainly: “If you keep doing the policies, the evidence, and responding to pen test results as you go, there is effectively no audit prep, because it is all already done.” 

See how to automate compliance.  Also give our blogs on automated controls testing and security training and device monitoring a read.

How to read a SOC 2 report (what to look for beyond the opinion)

When a vendor’s SOC 2 report lands on your desk, you have 30 to 60 minutes and a decision to make. Here is where to focus.

1. Is the report current? Check the audit period. A report covering last year’s window may not reflect the vendor’s current control environment. If the current audit is in progress, ask for a bridge letter stating so.

2. Who is the auditor? Verify the CPA firm’s peer review status on the AICPA website. Check whether the peer review passed, was conditional, or failed.

3. What is the opinion type? Unqualified (clean), qualified, adverse, or disclaimer of opinion. The opinion page is the first thing to read, not the last.

4. What is in scope? Section III lists the products, infrastructure, locations, and subservice organizations covered. If the vendor runs on AWS but AWS is not listed as a subservice organization, ask why.

5. What are the exceptions? Read every one. A single exception in CC 6.1 for a departed employee whose credentials were never revoked is a material signal, regardless of a clean opinion on the criterion overall.

6. What are the complementary user entity controls (CUECs)? These are the controls the vendor expects you to implement. One company assumed its cloud provider’s SOC 2 report covered its own obligations, and missed access control exceptions because it had not configured IAM correctly on its side. The CUECs were there; nobody read them.

7. Does management’s assertion match the system description? A mismatch signals either scope creep or inaccurate disclosure, and it is worth a follow-up question. A report with minor exceptions is not a reason to reject a vendor. It is a reason to ask what the vendor has done about them since. 

For a checklist you can reuse, see our 9 easy steps to review a vendor's SOC 2 report.

Conclusion

A SOC 2 audit is less mysterious than it looks. It is an independent CPA firm testing your controls against the Trust Services Criteria and issuing a report, most often a Type II covering an observation period of three months or more. The cost tracks your scope, your auditor tier, and whether you automate. 

The timeline tracks your readiness, not the audit. And the outcome is a report, not a pass or fail, which buyers read and evaluate on its merits.

The teams that find SOC 2 painless are the ones that treat it as an ongoing practice rather than an annual event. Start with a strong system description, run your periodic controls before the clock starts, and keep evidence continuously so audit prep becomes a non-event. 

A SOC 2 readiness assessment is the right first step, and automated evidence collection is what keeps the program running between cycles. When you are ready to move, our SOC 2 compliance solution can help you get there without derailing your roadmap.

‍

FAQs

What is a SOC 2 audit?

A SOC 2 audit is an independent assessment of a service organization’s controls against the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, and privacy). A qualified CPA firm tests the controls and issues an attestation report, not a certificate.

What is a SOC 2 Type II audit?

A SOC 2 Type II audit assesses whether controls were both suitably designed and operating effectively over a defined observation period, typically three to twelve months. It is the report most enterprise buyers mean when they ask for SOC 2.

Who performs a SOC 2 audit?

SOC 2 audits are attestation engagements performed under SSAE 18 by CPA firms enrolled in the AICPA peer review program. An independent CPA not enrolled in peer review cannot sign a SOC 2 report.

How much does a SOC 2 audit cost?

For a 50-100 person SaaS company pursuing Type II with three criteria, total first-year cost commonly runs $30,000 to $80,000+, depending on auditor tier, tooling, and whether a GRC platform is in use.

How long does a SOC 2 audit take?

The observation period floor is three months. Most companies take six to twelve months from deciding to pursue SOC 2 to holding a final report, and the difference comes down to control readiness rather than the audit itself.