SOC 2 compliance: The complete guide (What it is, how it works, and how to get your report)

Every service company that touches customer data eventually hits the same wall: a prospect will not sign until you can prove your security holds up. That proof increasingly means SOC 2.

SOC 2 does not produce a certificate. It produces an independent attestation report, issued by a licensed CPA firm after a formal audit. It is also voluntary. No law requires it. However, enterprise buyers call for it, which is why voluntary rarely feels optional in practice.

This guide covers what SOC 2 evaluates, who needs it, Type I versus Type II, how the audit process works, realistic timelines and costs, and how to get your report faster.

Key takeaways

• SOC 2 compliance is a voluntary security framework from the AICPA that evaluates how service organizations protect customer data across five Trust Service Criteria.
• It results in an independent attestation report, not a certificate, issued by a licensed CPA firm after a formal audit.
• Two report types exist: Type I (a point-in-time design review) and Type II (a 3 to 12-month operating effectiveness review). Most enterprise buyers require Type II.
• A first audit typically takes 3 to 12 months end-to-end, depending on your control readiness and observation period.
• Compliance automation platforms significantly reduce audit burden, evidence collection time, and auditor hours.

What is SOC 2 compliance?

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the AICPA (American Institute of Certified Public Accountants). It evaluates how a service organization protects customer data across five Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy.

The deliverable is the part people get wrong. SOC 2 does not end with a certificate. It ends with an attestation report, a document in which an independent CPA firm attests to whether your controls are designed correctly and, in the case of Type II, whether they operated effectively over time. If you want a deeper look at how that report ties into your broader defenses, see our blog on SOC 2 compliance and your security posture.

Underneath SOC 2 sits a standard called SSAE 18, the standard underlying SOC 2 audits, which replaced SSAE 16, and before that SAS 70. That lineage matters less than it sounds. The audit firm interprets and applies it, and your controls get defined collaboratively with the auditor based on the AICPA’s criteria. The jargon is auditor plumbing, not homework you owe.

“Compliance,” in this context, means three things working together: you operate controls, you produce evidence that they run, and an independent CPA attests to their effectiveness. A green dashboard is not compliance. Attested evidence is.

SOC 2 is one report in a family. It helps to see where it sits:

In practice, only about 4 to 5% of service organizations end up needing SOC 1, since it targets controls that affect financial reporting. SOC 3 is a shorter, public-facing summary derived from a SOC 2 Type II report. For most companies, when someone says "we need your SOC report," they mean SOC 2. If you are ready to move, Scrut supports the full path to SOC 2 attestation.

Why is SOC 2 compliance important?

SOC 2 signals that your organization takes data security seriously enough to have it independently verified. The benefits are concrete, and they compound.

Builds customer trust: A SOC 2 report tells customers that a licensed third party examined how you handle their data. That external verification carries far more weight than a self-declaration on your website.

Enhances business reputation: In a crowded market, an attestation report sets you apart. It is proof of maturity that most early-stage competitors cannot show.

Attracts larger clients: Enterprise procurement teams and regulated industries, particularly financial services and healthcare, routinely require a SOC 2 Type II report before onboarding a vendor, regardless of deal size. A missing report stalls deals at the exact moment revenue is on the line.

Improves internal security practices: The audit process surfaces control gaps before a breach does. Teams using automation catch drift continuously rather than only at audit time, so problems get fixed when they appear, not months later.

Accelerates other frameworks: SOC 2 controls overlap substantially with ISO 27001. Scrut’s GRC practitioners put the recorded overlap at 70%, and the control set carries over meaningfully to HIPAA as well. Teams pursuing both frameworks reuse the bulk of their work. 

Supports cyber insurance underwriting: Insurers increasingly use SOC 2 evidence to assess risk posture when setting premiums and coverage, so a clean report can influence what you pay. Treated well, SOC 2 becomes less of a cost line and more of a lever. You can turn SOC 2 compliance into a growth strategy when it shortens sales cycles rather than lengthening them.

The operational difference shows up in audit cycles. Matt Black, Director of Information Security at Contentstack, describes what changed when his team moved off spreadsheets:

Who needs SOC 2 compliance?

Any service organization that stores, processes, or transmits customer data on behalf of clients should consider SOC 2. That covers SaaS companies, cloud service providers, managed IT services, data centers, healthcare technology vendors, fintech platforms, and HR or payroll systems.

SOC 2 is voluntary. No law requires it. What drives adoption is commercial pressure: enterprise buyers, regulated-industry procurement teams, and partner ecosystems increasingly require a SOC 2 report before they will work with you. Marketplace listings and banking partnerships often make it a hard gate.

For most companies, the need becomes urgent at one of four moments:

1. An enterprise deal stalls at procurement because you cannot produce a report.

2. A prospect sends a security questionnaire you cannot credibly answer.

3. A VC or board makes it a condition of investment or a growth milestone.

4. A marketplace or partner listing requires it before you can go live.

Where SOC 2 matters most, by industry:

If you are early-stage, the playbook differs by sector. See how this works for SOC 2 for SaaS companies.

The five SOC 2 Trust Service Criteria explained

SOC 2 is built on five Trust Service Criteria (TSC). Each one covers a different dimension of how you protect data and run your systems.

Security (the Common Criteria): Security is also called the “Common Criteria” (CC) because many of its controls are shared across all five criteria. It is the only mandatory TSC; every SOC 2 report includes it. Security protects systems against unauthorized access, use, and tampering through access control, monitoring, and risk management. CC 6.1 (logical and physical access) is central here and one of the most heavily tested controls in the entire framework.

Availability: Confirms that systems and services are available for operation and use as agreed. This is where disaster recovery plans, uptime commitments, and SLA obligations live. CC 7.1 (configuration and vulnerability management) supports both Security and Availability.

Processing integrity: Ensures that system processing is accurate, complete, timely, and authorized. It matters most for organizations doing large batch file processing, where a data error carries real consequences.

Confidentiality: Protects information designated as confidential, from customer data to intellectual property, across its full lifecycle: handling, storage, transmission, and disposal.

Privacy: Governs how personal information is collected, used, retained, and disclosed. At its core, it comes down to a few principles: collect only what you need and with proper consent, use it only for the stated purpose, retain it only as long as necessary, secure it against unauthorized access, and give individuals a way to access and correct their data.

Security is mandatory. The practical baseline is Security plus Confidentiality plus Availability, since the incremental cost over Security-only is modest, roughly 1.2x. Add Processing Integrity if you do large batch file processing; add Privacy if you collect PII. Over-scoping is not penalized, but it costs money, so scope to your actual data and commitments.

For a deeper walkthrough, see how to satisfy the SOC 2 Trust Service Criteria and the SOC 2 control list by criteria.

SOC 2 controls: what they are and how to choose them

A control is a specific, implementable safeguard that reduces the likelihood or impact of a risk. Controls are the bridge between a policy statement (the intent) and evidence (the proof). Auditors evaluate controls, not policies.

Controls come in three types, and a mature program layers all three:

• Preventative: Stops the bad thing from happening. Example: IAM role policies enforcing least-privilege access (addresses CC 6.1).

• Detective: Identifies when something has happened or is happening. Example: CloudTrail logging with SIEM alerts for anomalous admin access (addresses CC 7.1).

• Corrective: Fixes the issue after detection. Example: automated revocation of temporary credentials after a defined period (addresses CC 6.1).

The CC series is the largest and most heavily tested cluster. CC 6.1, logical and physical access, is the longest criterion and the one most likely to produce exceptions.

First-time companies most often get caught on six technical controls: CC 6.4, 6.6, 6.7 (encryption), 6.8 (antivirus), 7.1 (configuration and vulnerability management), and 8.1 (change management). These are also the controls automation handles best. Once integrations are in place, the evidence collects itself.

A SOC 2 control set covers six structural elements: control environment, monitoring, access controls, system and operations controls, change management, and risk mitigation. Choose controls based on your risk assessment and your customers’ security needs.

One distinction matters more than any other: a policy document is not an implemented control. Uploading a policy template and marking a control “done” does not satisfy a rigorous auditor. The control has to be demonstrably operating, with evidence to match.

Here is where auditors spend their time, and where gaps most often appear:

For the full picture, see the complete SOC 2 control list. Quarterly access reviews should be handled systematically. You can automate access reviews rather than chasing screenshots every quarter.

SOC 2 Type I vs. Type II: What’s the difference and which do you need?

The short answer: Type I checks whether your controls are designed correctly at a single point in time. Type II checks whether they operated effectively over a defined period. Type II is the real commercial credential.

Type I assesses control design as of a specific date. The report reads “as of [date].” It verifies that your controls exist and are built correctly, along with what tools and strategies you have in place. It is faster and cheaper, because the audit firm verifies far less evidence. Early-stage enterprise prospects will often accept it as a signal that you take security seriously.

Type II assesses operating effectiveness over a period of 3 to 12 months. The testing is deeper and longer, so the fees are higher, but this is what mid-market and enterprise buyers, financial services, healthcare, and government procurement actually mean when they ask for SOC 2.

Should you skip Type I? According to Kush Kaushik, Co-founder of Scrut Automation, roughly 70% of companies go straight to Type II. Type I makes sense in two situations: your controls were implemented recently, and you need a quick signal to close early customers, or you cannot yet sustain a multi-month observation period. If your controls are stable, proceed directly to Type II. There is no penalty for starting with Type I, but there is no need to pay for it twice if you are ready.

Every SOC 2 report carries one of four audit opinions:

• Unqualified: a clean pass.

• Qualified: a pass with specific exceptions noted. Most buyers accept these when the exceptions are minor.

• Adverse: a failure, typically tied to fabricated evidence or fundamental control breakdowns. These are extremely rare.

• Disclaimer of opinion: the auditor could not reach a conclusion, usually because samples were missing (for example, no new hires during the period, so onboarding controls could not be tested).

A note on SOC 3: It is a shorter, public-safe summary derived from a SOC 2 Type II report, safe to post on your website without an NDA. It cannot be derived from a Type I, and it cannot be issued if the underlying Type II carries a qualified opinion.

Organizations generally obtain a new report annually to demonstrate ongoing control effectiveness

Can be used to obtain a SOC 3 report?

No

Yes, provided the SOC 2 opinion is unqualified and other eligibility requirements are met

Ready to plan the engagement? See how to set up your SOC 2 audit and the deeper guide on mastering the SOC 2 audit process.

What is a SOC 2 audit? A process walk-through

A SOC 2 audit is performed by an independent CPA firm and runs through six phases. Here is what actually happens at each stage, and where first-timers get caught out.

A. Planning and scoping

You define which systems, services, and Trust Service Criteria are in scope. The step most first-timers do not realize they own is the “description of the system” (Section III of the report). 

You draft it first. It describes your services, infrastructure, people, processes, and subservice organizations (like your cloud providers). The audit firm uses this description to define the controls and test procedures the entire audit runs on, so getting it right up front prevents scoping surprises later.

B. Risk assessment

You identify threats, rate them by probability and impact, and document your treatment decisions. A first-time risk assessment that will satisfy an auditor covers the full scope of the system, including the cloud environment where your product actually runs, not just the office and physical data center. Missing the cloud is one of the most common gaps.

C. Control testing

The auditor evaluates control design and, for Type II, operating effectiveness. Behind the scenes, the CPA firm builds a full stack of work papers, often 400 to 500 documents per engagement, as part of their own quality management and peer review obligations. You do not see most of this. You provide evidence; the auditor does the rest.

D. Gathering evidence

Over the observation period, you collect recurring evidence: quarterly access reviews, BCP/DR testing (at least annually), vulnerability scan results and remediation records, security training completion, and change approval logs. These are precisely the areas where compliance drift happens most often between audit cycles. Without a system that flags missed cycles automatically, the gap only surfaces at the next audit.

E. Reporting

The auditor drafts the report with their opinion and any exceptions. One item is never automated: the management assertion letter. Your top management signs a written declaration, on company letterhead, stating that you followed what the system description says you follow. That letter goes into the report. 

Organizations can also add a Section V management response to explain exceptions, which gives context without contradicting the auditor’s findings.

F. Remediation and follow-up

You address any control weaknesses, document resolutions, and use the findings to strengthen the program before the next cycle.

For more, see best practices for a successful SOC 2 audit, the types of audit evidence auditors collect, and how to handle audit evidence documentation.

SOC 2 compliance timeline: How long does it really take?

SOC 2 Type I typically takes 1 to 3 months to prepare and complete once controls are in place. SOC 2 Type II requires a minimum 3-month observation period, with total timelines of 6 to 12 months from first implementation to report issuance.

Whether you land at 3 months or 12 depends on five factors:

1. Control readiness at the start. Organizations with mature controls already running can begin the observation period almost immediately. Those starting from scratch spend the first stretch building.

2. Gap remediation time. How long it takes to close identified gaps, including pen test findings, policy gaps, and access control gaps. Engineering bandwidth usually sets the pace here.

3. Recurring activity cadence. Access reviews happen quarterly; BCP testing happens at least annually. The observation period has to capture at least one cycle of each required activity, which is exactly why the AICPA set a 3-month minimum.

4. Auditor scheduling and report drafting. Add 4 to 8 weeks for the audit firm's work papers and report drafting after evidence collection closes.

5. Compliance automation. Teams using a GRC platform typically reach audit-readiness faster because evidence is collected continuously rather than assembled by hand before the audit.

A realistic sequence looks like this: gap assessment in January, remediation closed by the end of January, a 3-month practice period, then a Type II audit starting May 1 with a February-to-April observation window.

The automation effect is measurable. Kenneth Haugen, IT Manager at Athenium, reported cutting delays in understanding requirements and submitting evidence by more than 80% with automation.

Start with a SOC 2 readiness assessment, and learn how to scope your SOC 2 audit right before you begin.

SOC 2 audit cost: what to budget for your first report

The classic answer is “$10,000 to $50,000,” but that range hides more than it reveals. The real cost depends on your auditor, your tooling, your headcount, and how many Trust Service Criteria you scope. 

Here is a breakdown for a 50 to 100-person SaaS company targeting three criteria (Security plus Confidentiality plus Availability):

Automation reduces manual effort, streamlines evidence collection, and can lower both consulting and audit costs over time.

Where companies overspend

Buying enterprise-grade EDR/XDR tools when Microsoft Defender would satisfy audit requirements. Purchasing infrastructure-scanning licenses (like Nessus or AWS Inspector) when a GRC platform’s cloud testing module covers the same scope for less. Over-scoping to five criteria when three is enough for most buyers. 

One real example: a company with a handful of physical servers bought a $6,500 scanning license they never fully used, when the same testing could have been done for a fraction of that.

What scope does to cost

Security-only is your baseline (call it 1x). Adding Availability and Confidentiality brings it to roughly 1.2x. Processing Integrity and Privacy add further, and only make sense if your data and processing actually require them.

A compliance automation platform typically pays for itself by reducing auditor hours (audit firms quote less when GRC-platform evidence is available), eliminating manual consultant prep, and compressing the timeline. For the engineering side of this equation, see how much engineering time SOC 2 compliance costs and the broader view on comprehensive compliance cost economics.

How Scrut helps with your SOC 2 report

Getting your SOC 2 report should not mean living in spreadsheets and late-night evidence hunts. Scrut brings compliance automation to the parts of the process that drain the most time.

The platform automates evidence collection across your cloud, code, and identity stack, so recurring activities like access reviews, vulnerability scans, and change logs are captured continuously rather than reconstructed before an audit. 

Continuous monitoring flags drift the moment it appears, not once every 90 days. Because auditors get a clean, timestamped evidence trail, the audit itself runs faster and often costs less.

Ron Buell, CTO of Sounding Board, put it directly: Moving to the platform gave his team visibility into exactly what an audit requires, which pushed them to tighten their information security and access management programs. And once that practice is in place, prep largely disappears. In his words, if you keep policies, evidence, and pen test results current, “there really is no prep because it's all done.”

Book a demo to see how Scrut can accelerate your SOC 2 journey.

FAQs

1. What does SOC 2 compliance mean?

SOC 2 compliance means a service organization operates security controls across the relevant Trust Service Criteria, produces evidence that those controls run, and has an independent CPA firm attest to their design and effectiveness. The output is an attestation report, not a certificate.

2. What is SOC 2 Type 2 compliance?

SOC 2 Type II compliance evaluates whether your controls operated effectively over a defined period, with a minimum 3-month observation window (commonly 3 to 12 months). Unlike Type I, which is a point-in-time design check, Type II proves your controls actually worked over time. It is the report most enterprise and regulated buyers require.

3. How do you get SOC 2 compliance?

Define your scope and system description, run a gap assessment, remediate gaps, then operate your controls through the observation period while collecting evidence. An independent CPA firm audits your controls and issues the attestation report. A GRC platform can compress the readiness and evidence-collection stages significantly.

4. How is SOC 2 different from SOC 1?

SOC 1 evaluates controls over financial reporting; SOC 2 evaluates data security, availability, confidentiality, processing integrity, and privacy. Only about 4 to 5% of service organizations need SOC 1. For technology and cloud companies handling customer data, SOC 2 is the relevant report.

5. Who are SOC 2 auditors?

SOC 2 auditors are independent CPA firms licensed by the AICPA and enrolled in the AICPA peer review program (attestation engagements cannot be signed by an independent CPA who is not part of a peer-reviewed firm). When choosing one, check their CPA license and peer review status, and confirm the assigned auditors understand information security (look for CISA, CISSP, or ISO 27001 lead auditor credentials).

6. Does SOC 2 require penetration testing?

SOC 2 does not explicitly mandate penetration testing, but it is strongly recommended and widely expected. Pen testing evaluates whether your security controls hold up against simulated attacks and supports the evidence auditors look for under the Security criteria.

7. Can SOC 2 compliance software help you get your report faster?

Yes. Compliance automation software continuously collects evidence, monitors controls for drift, and gives auditors a clean trail to work from. That reduces manual prep, shortens the readiness timeline, and often lowers auditor fees, since firms spend fewer hours when platform evidence is available.

‍