SOC 2
Compliance
The Complete Guide (2026)
The SOC 2 report is the attestation your buyers typically ask for in security review. We’ve broken it down section by section: what it actually requires, how the audit works, what it costs, how long it takes, and how modern teams get audit-ready in weeks instead of quarters. Updated for the 2026 threat and AI landscape.
What is SOC 2?
SOC 2 (System and Organization Controls 2) is a framework from the AICPA (American Institute of Certified Public Accountants) for how service organizations protect customer data. A licensed CPA firm examines your security practices against the Trust Services Criteria and issues a report with its opinion. That report is what your buyers ask for during the security review.
One thing worth getting right from the start: SOC 2 is an attestation, not a certification. There is no SOC 2 certificate and no pass/fail badge. An independent auditor attests to whether your controls are designed and operating as described, and the output is a detailed report, not a logo. Most of the market says SOC 2 certification anyway, and that may be fine in conversation, but knowing the difference matters when a prospect’s security team reads your report closely. It’s also the first of several SOC 2 myths worth clearing up early.
SOC 2 sits inside the broader SOC report family: SOC 1 covers financial reporting controls, SOC 2 covers data security, and SOC 3 is a public summary of SOC 2. If you’re new to the whole System and Organization Controls world, the short version is that SOC 2 is the one SaaS buyers care about. The SOC 2 framework is voluntary, but for most cloud companies selling to mid-market or enterprise, it’s functionally mandatory: no report, no deal.
A few things worth knowing upfront:
- SOC 2 is defined and governed by the AICPA, and only licensed CPA firms can perform the examination.
- A SOC 2 report covers a defined scope and period. It renews annually, so it’s an ongoing program, not a one-time project.
- What gets examined is your controls in operation, with evidence. Policies alone don’t pass an audit.
Everything the auditor examines traces back to five categories of criteria, so that’s where scoping starts.
The five Trust Services Criteria
SOC 2 measures your organization against five Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory one; the other four are added based on what you do and what your customers expect.
The five are sometimes still called the SOC 2 trust principles, their pre-2017 name.
| Criterion | What it covers | Scope it in if |
| Security (mandatory) | Protection of systems and data against unauthorized access. Called the “common criteria” because the other four build on it. | Always in. Every SOC 2 includes it. |
| Availability | Whether your systems are up and usable as promised. | You commit to uptime SLAs, which most SaaS companies do. |
| Processing Integrity | Whether processing is complete, accurate, and authorized. | Customers depend on your processing being correct: payments, payroll, data pipelines. |
| Confidentiality | Protection of information designated confidential, from contracts to customer business data. | You hold sensitive business information under NDA-type commitments. |
| Privacy | How you collect, use, retain, and dispose of personal information. | You hold PII and customers or regulators expect privacy commitments. |
A practical rule that holds for most SaaS companies: start with Security, Availability, and Confidentiality. Add Privacy if you handle personal data at scale, and Processing Integrity if customers rely on your processing being exact.
Each criterion you add expands the audit and the evidence burden, so scope accordingly. Each criterion applies across five components of your system: infrastructure, software, people, data, and procedures.
Why SOC 2 matters in 2026
Verizon’s 2026 Data Breach Investigations Report found that 48% of breaches now involve a third party, up 60% in a single year, and that vulnerability exploitation has overtaken stolen credentials as the number one way attackers get in, at 31% of breaches. To the companies you sell to, that makes every vendor a potential breach path, including you. Their answer might be to scrutinize vendors more closely before signing, which is the security review your deals now go through.
That’s the context in which SOC 2 has become the default trust artifact for B2B software. In Sprinto’s Business ROI of Compliance 2026 report, SOC 2 and ISO 27001 together accounted for more than 85% of the certifications companies chose to pursue. That concentration isn’t just about coverage; it maps to outcomes. Respondents pursuing SOC 2 and ISO 27001 reported a 14% lift in RFP win rates, ahead of every other framework in the survey.
Three shifts define what SOC 2 in 2026 means in practice:
1. Security reviews now gate revenue: Across our conversations with customers, the trigger for starting SOC 2 is almost never internal ambition. It’s a customer mandate in an RFP, an investor requirement before a round closes, or a deal stalled in procurement. Some teams arrive after an incident has already cost them. SOC 2 has become less a security project and more a revenue project with security underneath. That shift is strongest for cloud-based SaaS companies.
2. AI use is now in scope: The 2026 DBIR flagged a sharp rise in the use of shadow AI at work, and auditors have followed suit. If your team uses LLM tools that touch customer data or production code, expect questions: which AI tools are approved, who has access, what data flows into them, and whether they’ve been through your vendor review process. AI vendors are vendors.
3. Auditors are asking harder questions. Multiple compliance leads have told us the same thing this year: after high-profile audit-quality scandals, examiners now want to see the underlying evidence, not a summary of it. That rewards teams whose evidence collection runs continuously, and exposes those who pull it together in a pre-audit scramble.
SOC 2 itself doesn’t version as ISO standards do. There’s no ‘SOC 2:2026’ and no transition deadline; the Trust Services Criteria have been stable since 2017, with updates to points of focus in 2022. Typically, what changes are auditor expectations and what falls within scope. The business benefits of SOC reports compound accordingly: faster security reviews, shorter sales cycles, fewer questionnaires answered from scratch.
Understanding why is the short part. The longer part is what SOC 2 actually asks of you, which starts with the requirements.
SOC 2 requirements
In SOC 2, requirements mean the individual criteria under each Trust Services Category that your controls must satisfy. The Security category alone contains 33 criteria, and all five categories together span 61. Unlike ISO 27001, SOC 2 doesn’t hand you a checklist of prescribed controls. It defines outcomes your organization must achieve and leaves the how to you, which is flexible and also why first-timers can find it disorienting.
The criteria range from:
- Access control
- Change management
- Risk assessment
- Incident response
- Vendor management
- Monitoring
They also cover areas that teams often overlook, such as organizational structure, board oversight, and internal communication.
Satisfying a criterion takes three things: policies and procedures that describe what you do, documentation that proves you do it, and controls that operate consistently through the audit period. Even granular questions like password requirements trace back to specific criteria under Security.
Let’s look at a quick example. Confidentiality has just two criteria: first, identify what counts as confidential information and how long you’ll keep it; second, protect it from exposure or deletion before then. Controls like data classification and encryption policies are simply how you meet those two requirements.
To sum up, requirements define what must be true. Controls are how you make it true
SOC 2 controls
A requirement states an outcome; a control is the specific, repeatable thing you do to achieve it. For example, ‘restrict access to authorized users’ is a requirement. Quarterly access reviews, MFA enforcement, and automated deprovisioning when someone leaves are controls that satisfy it.
What a control looks like to an auditor is concrete, and for a SaaS company in 2026 that increasingly includes the delivery pipeline itself. A snapshot of what good evidence looks like:
- Access reviews: A record showing each system, each user, their permission level, who reviewed it, what changed, and when. A policy PDF doesn’t count.
- Change management: The pull request shows approval before merge every time, all period long.
- Pipeline security: CI/CD running least-privilege, workflow-file changes reviewed like application code.
- Secrets: credentials in a secrets manager rather than in code, with secret scanning on and rotation after any exposure.
- Offboarding: access is removed on exit, with a timestamped record to prove it.
For a SaaS company in 2026, auditors increasingly want that rigor applied to the delivery pipeline itself: who can push to production repos, whether CI/CD runs with least privilege, whether secrets live in a manager rather than in code, and whether workflow-file changes get reviewed like application code.
Controls fall into a handful of groups, each tied to one or more criteria: access control, change management, vendor management, disaster recovery, and infrastructure, including how data centers factor in when you run on AWS, GCP, or Azure and inherit some controls from your cloud provider.
You don’t have to invent this from a blank page. Sprinto ships a pre-mapped SOC 2 control set, and Sprinto AI maps controls to framework requirements from the full control library, so you start from a working baseline and adapt it to how your team actually operates.
With criteria and controls in view, the next decision is which type of report to pursue.
SOC 2 Type 1 vs Type 2
A Type 1 report examines whether your controls are suitably designed at a single point in time. A Type 2 report examines whether those controls operated effectively over a period, typically 3 to 12 months, called the observation window, during which your controls run in the real world while the auditor collects evidence that they held up. Type 1 checks that you built the right controls; Type 2 checks that they actually ran, day after day, across the whole window.
Think of a fire safety inspection: Type 1 confirms that alarms and extinguishers are installed and working on the day the inspector visits, while Type 2 reviews months of logs to confirm they were tested and maintained throughout that period.
| Type 1 | Type 2 | |
| What’s examined | Control design | Control design and operation |
| Time frame | A single point in time | An observation window of 3–12 months |
| Time to report | 1–2 months with automation | 4–6 months with automation |
| Audit fee | Lower | Higher, since the auditor samples evidence across the window |
| What buyers make of it | An interim signal you’re on the way | The report enterprise buyers actually expect |
These Type 1 vs Type 2 differences drive everything downstream. Type 1 works as an interim signal while your Type 2 window runs. Plenty of teams now skip Type 1 entirely and go straight to Type 2 to save a duplicate audit fee; the tradeoff is a longer wait for your first report.
The wider SOC family is a common point of confusion too, so here’s the short version:
- SOC 1: Controls relevant to your customers’ financial reporting. Matters if your product touches their financials.
- SOC 2: Data security against the Trust Services Criteria. The one SaaS buyers ask for.
- SOC 3: A general-use summary of a SOC 2 you can publish openly.
- Specialty reports: SOC for Cybersecurity and SOC for Supply Chain, which most SaaS companies never need.
Whichever type you pursue, the output is the same artifact: the report itself.
The SOC 2 report
A SOC 2 report has five main parts:
- The auditor’s opinion letter: the headline. An ‘unqualified’ opinion means the auditor found your controls designed (Type 1) or designed and operating (Type 2) as described. A ‘qualified’ opinion flags material problems, and buyers read it that way.
- Management’s assertion: Your formal statement that the system description is accurate.
- The system description: What’s in scope, written by you.
- The criteria in scope: Which Trust Services Criteria the examination covered.
- Tests and results: What the auditor tested and what they found, including any exceptions.
Two of these parts cause most of the trouble. The first is the system description, which you write, not the auditor. It names your product, the infrastructure and repositories in scope, your identity providers, subservice organizations like AWS, and, increasingly, the AI tools your team uses. The problem is that this drifts. Teams add tools, change infrastructure, and move people between roles mid-window, and when the description no longer matches what the auditor sees, fieldwork stalls while you reconcile the two. Reviewing it before the audit starts saves you that.
The second is the testing section, where exceptions show up. An exception is a case where a control didn’t operate as intended, such as an offboarded employee whose access lingered beyond your SLA. One or two won’t sink a report; the auditor records them next to your response, and a report with a couple of well-handled exceptions and clear remediation often reads as more credible than a spotless one. Buyers are looking at the pattern, not the presence of a single miss.
A few things that trip people up in practice. Reports are shared under NDA, usually through a trust center rather than over email. A Type 2 report covers a fixed window, so when a buyer wants assurance for the months since your last report ended, you give them a bridge letter confirming that controls have remained in place.
Knowing what the report contains makes the next question easier to answer honestly: do you need one at all?
Who needs SOC 2, and who can wait
SOC 2 is worth doing the moment you need it and a drain on money and attention when you don’t, so the first decision is about timing, not effort. Pursue it too early, and you pay for a report no one asked for. Wait until a signed deal depends on it and you’re closing that deal months late.
Here’s the practical filter.
a. You probably need SOC 2 if:
- Prospects ask for it in security reviews, RFPs, or vendor questionnaires.
- You’re a SaaS or cloud company storing or processing customer data.
- You sell to, or plan to sell to, US mid-market or enterprise buyers.
- An investor, partner, or platform marketplace requires it.
- You handle data on behalf of companies in regulated industries such as fintech, healthtech, or HR tech.
b. You probably don’t need it yet if:
- No customer or prospect has asked, and your buyers are consumers or very small businesses.
- You don’t hold customer data at all.
- Your market expects a different framework first, such as ISO 27001 for European and APAC buyers or HIPAA for US healthcare.
Notice what isn’t on either list: company size. It doesn’t exempt you. Buyers ask two-person startups for SOC 2 reports, and small teams pass all the time. Controls that assume separate people, like segregation of duties or peer code review, get handled through documented scoping and auditor notes rather than heroics.
If you’ve landed on yes, plan for one more thing early: SOC 2 rarely travels alone. The same buyer who wants SOC 2 for your US deals will often want ISO 27001 in Europe, and healthcare buyers will add HIPAA on top of that. Because the controls behind these frameworks overlap heavily, mapping your framework roadmap now costs far less than discovering it one stalled deal at a time.
Once you’ve decided you need SOC 2, two questions remain: which report to get, and how to get there. The report, Type 1 or Type 2, depends on what your buyer expects and how soon they need it, which we covered above. What the path looks like is next.
The SOC 2 compliance journey
You’ll have to move through six stages to get your SOC 2 report: scope, assess, remediate, operate, audit, and maintain.
Let’s explore each in detail.
1. Scope: You start by choosing your Trust Services Criteria and drawing the system boundary, which means deciding exactly which products, infrastructure, repositories, tools, and people the audit will cover.
2. Assess: Run a risk assessment to identify what threatens customer data, then a gap analysis against the criteria. A structured readiness assessment or lighter self-assessment tells you how far you are from audit-ready. In 2026, a credible risk register also documents how you track known-exploited vulnerabilities, how quickly high-risk ones are remediated, and how third-party incidents are evaluated for customer impact, because that’s where breaches actually start nowadays, according to the DBIR report.
3. Remediate: You then close the gaps the assessment surfaced. That work involves implementing the missing controls, finalizing your policies, fixing insecure configurations, and assigning an owner to each control.
4. Operate: Now you run the controls and collect evidence that they worked. For a Type 2 report, this is your observation window, and it is where programs quietly fail, because a control that lapses for even a week, such as a skipped access review or an unapproved merge, becomes an exception in your report. This is exactly what continuous monitoring is for: it catches drift the moment it happens, rather than during audit prep. It is also where automated evidence collection earns its place: a departing employee can trigger a deprovisioning workflow; the system then verifies that access was removed, and the record files itself as evidence.
5. Audit: A licensed CPA firm examines your controls, testing their design for a Type 1 report and their operating effectiveness across the whole window for a Type 2.
6. Maintain: Finally, because SOC 2 renews annually, the controls continue to run, and your next observation window opens as soon as the current one closes.
Buyers will sometimes send a security questionnaire alongside your report, or instead of asking for it, and the same body of evidence answers both.
Of the six stages, the audit is the one teams typically worry about most.
The SOC 2 audit
A SOC 2 audit is an examination of evidence conducted by a licensed CPA firm. The auditor tests each in-scope control, examining design for a Type 1 and sampling evidence across the observation window for a Type 2: access review records, change tickets, incident logs, training completions, and vendor assessments.
Fieldwork usually runs several weeks, with queries going back and forth as the auditor works through the samples, so it helps to know how to prepare for a SOC 2 audit before it starts and to get anyone new to the process through some SOC 2 audit training first.
Two prerequisites catch teams off guard, and both showed up again and again in our conversations with prospects this year:
a. Penetration testing: Not a literal TSC requirement, but in practice most auditors expect a recent pen test as evidence that you validate your security. It costs roughly $1,000–2,500 for a typical SaaS scope, takes one to two weeks, and must be complete before the audit starts. Teams that discover this mid-audit lose weeks. Budget it and schedule it early.
b. Evidence has to exist for the whole window: Raj Viswanathan, CISO at Nium, put it plainly after taking the company through SOC 2 Type 2 with 97% of evidence collection automated: “SOC 2 is an intense, evidence-focused audit. If controls are not automated, it adds more burden to IT teams to ensure we do not miss something. If we miss tracking controls even for a day, it results in control failure, and it will be captured in the report.”
What auditors actually flag, audit after audit:
- Outdated screenshots submitted as current evidence
- Access reviews that skipped a quarter
- Workflow and pipeline changes merged without review
- Hardcoded credentials in repositories
- System descriptions that no longer match the environment
- Integrations everyone assumed were collecting evidence that had silently stopped syncing
That last one deserves a pre-audit check of its own: an integration can show as connected while it has quietly stopped pulling evidence.
None of this happens without an auditor, and choosing one is a real decision.
Choosing your SOC auditor
Only licensed CPA firms can issue a SOC 2 report, which narrows the field but doesn’t make the choice for you. Fees, timelines, and audit experience vary widely, and so does quality.
Three things to check before signing:
- Standing and peer review: CPA firms undergo peer review of their attestation practice. Ask about current peer-review status; a pending or lapsed review on a budget firm is a real risk to how your report is received. After the audit-quality scandals of the past two years, buyers’ security teams have started checking who signed the report, not just that one exists.
- Relevant experience: A firm fluent in SaaS environments samples cloud-native evidence quickly. One that mostly audits banks will be slower and more expensive in yours.
- Process fit: Ask how they gather evidence. Firms that work directly from a compliance platform, or integrate with it, can cut weeks of back-and-forth compared to email-and-spreadsheet fieldwork.
Audit fees are wide: roughly $5,000–$25,000 for a Type 1 and $7,000–$50,000+ for a Type 2, with boutique CPA firms at the lower end, around $12,000–$15,000, and Big 4 firms well above. Cheapest is rarely the answer. If the firm’s standing is shaky, it won’t make for a good impression on your buyers. The report is only as credible as its signer.
With an auditor chosen, the timeline becomes concrete.
How long does SOC 2 take?
The honest answer to the SOC 2 timeline has two parts: how long until you’re audit-ready, and how long until the report is in your hands. Automation compresses the first dramatically. The second you can’t rush, because a Type 2 report can only be issued after your controls have run for a set period.
Most of a Type 2 timeline is the observation window: the stretch, usually 3 to 6 months, during which your controls have to run continuously while the auditor gathers evidence that they held up. It’s the part no tool can shorten, and it’s why a Type 2 takes months longer than a Type 1, which has no window at all.
Here’s how that plays out across the common paths:
| Scenario | Time to report | What drives it |
| Type 1, with automation | 1–2 months | A 2–6 week readiness phase, then a short audit. No observation window. |
| Type 2, with automation | 4–6 months | Readiness, a 3–6 month observation window, then a 1–2 month audit. |
| Type 2, manual or complex scope | up to 12 months | Manual evidence work stretches every phase. |
Because the observation window is fixed, the smart move is to plan backwards from it. If a deal needs your Type 2 report by December and you’re running a six-month window, that window has to open by June, which means your controls need to be live and operating by then.
This is why readiness speed matters even though the window itself won’t budge: the faster you close your gaps, the sooner the clock can start. The internal effort is also lighter than most teams expect, since automation turns setup into a few focused hours a week rather than a dedicated role.
Zeto, a healthcare company, shows how far this compresses in practice with a compliance automation platform like Sprinto. They reached SOC 2 Type 1 readiness in two weeks and completed its audit twenty days later. The payoff came just as fast: Zeto closed a sale the same day it received the report.
Time is one budget. Money is the other.
What does SOC 2 cost?
SOC 2 costs come in a few separate bills, not one: the compliance platform, the external audit, and a penetration test, plus your team’s time. Teams routinely budget for only the platform and get caught by the rest.
| Cost component | Typical range, year 1 | Notes |
| Compliance platform | $5,000–$30,000 / yr | Starts around $8,000 for small teams; scales with headcount and frameworks |
| SOC 2 Type 1 audit | $5,000–$25,000 | Point-in-time; boutique CPA firms around $12,000 |
| SOC 2 Type 2 audit | $7,000–$50,000+ | Across the observation window; boutique firms around $15,000, Big 4 well above |
| Penetration test | $4,000–$15,000 | Expected in practice; a single web app sits at the low end |
| Internal team time | 100–200 hours | The largest hidden cost; automation cuts it to a fraction |
For a small SaaS company doing SOC 2 Type 2 with automation, all-in first-year cost commonly lands around $20,000–$60,000 for a small-to-mid SaaS company, rising toward $150,000 for larger scope or a Big 4 auditor.
Skipping a platform looks cheaper because you avoid the subscription, but it usually costs more once you count your team’s time. A manual cycle takes 100 to 200 internal hours of collecting evidence, chasing screenshots, and updating spreadsheets; automation cuts that to a fraction. The hours you save are worth far more than the subscription you avoided.
Two things are worth doing before you commit a budget. First, ask every vendor to quote all three line items. A headline ‘SOC 2 for $X’ price often covers only the platform and leaves out the audit fee and the pen test, which is the most common reason a budget blows up mid-project. Second, if you expect to need a second framework within the year, such as ISO 27001 or HIPAA, get pricing for both now rather than later. Much of the SOC 2 work carries over, so buying the frameworks together usually costs meaningfully less than adding the second one after the fact.
Fyle, an expense management platform’s, experience shows where the money actually goes. Before moving to Sprinto, the team spent three months with a security consultant and was still stuck at gap analysis, buried in spreadsheets and manual evidence collection. That is a quarter of engineering time gone before a report ever existed, which is exactly the cost that never shows up on a vendor quote.
Also, you should budget for year two. SOC 2 renews annually, so after the first year you’re paying for ongoing monitoring and the renewal audit, which together commonly run to $10,000–$40,000. It should be lower than year one because the setup work is behind you. But remember, buyers will check that your report is current.
Common SOC 2 myths
A handful of SOC 2 myths persist because they sound reasonable. Here are the five that most often lead teams to scope wrong, budget wrong, or overstate what they have.
1. “SOC 2 is a certification”: It’s an attestation. A CPA firm’s opinion in a report, not a certificate. The word “certification” is everywhere, including in URLs on this site, because that’s what people search. Just don’t put “SOC 2 certified” on a slide an enterprise security team will read.
2. “It’s one and done”: Reports cover a defined period and renew annually. The buyers who ask for SOC 2 also check the report date.
3. “Security-only scope is always enough”: Security is the only mandatory criterion, but if you promise uptime or hold confidential data, buyers expect Availability and Confidentiality in scope, and a too-narrow report invites questions.
4. “It’s a paperwork exercise”: Auditors sample operating evidence. Policies without proof of operation produce exceptions, and enough exceptions produce a qualified opinion.
5. “Small companies can’t pass”: They can and do, with scoped controls and documented exceptions where team size makes a control inapplicable.
How Sprinto helps with SOC 2
Sprinto is an autonomous trust and compliance platform that turns SOC 2 from a manual, evidence-chasing project into a mostly automated program you run continuously. Instead of assembling controls, collecting screenshots, and reconciling everything the week before your audit, you work from a pre-built SOC 2 program that monitors itself and flags what needs your attention.
What that looks like for your SOC 2, concretely:
- Pre-mapped controls: The full SOC 2 control set ships ready, mapped to the Trust Services Criteria. Sprinto AI maps controls to framework requirements from the entire control library, including controls you haven’t enabled yet, so you start from a working program instead of a blank register.
- Automated evidence collection: Integrations across your cloud, code repositories, HRIS, MDM, and identity stack pull evidence continuously. The 11pm screenshot hunt stops being part of the job.
- Continuous control monitoring: When a control drifts, an access review lapses, or an integration stops syncing, you find out that day, not during fieldwork. Failing checks come with guided remediation.
- Audit workflows auditors work inside: Your auditor gets a scoped, read-only view of your evidence, and with auditor integrations, requests and evidence can sync directly between Sprinto and the auditor’s own tooling, so nothing gets uploaded twice.
- Trust on display: A Trust Center shares your report and posture with buyers under access controls, and Ask AI answers their security questions from the documents they’re entitled to see, which shortens the questionnaire cycle.
- Multi-framework carryover: SOC 2 controls carry into ISO 27001, HIPAA, and GDPR programs, so the second framework starts far ahead of zero. The overlap is mapped, not asserted.
If you’re comparing options in the SOC 2 software category, you’ll also come across Vanta, Drata, and Secureframe. SOC 2 automation, as a category, has matured to the point where running the program manually is a choice, not a default.
We hold ourselves to the same bar we set for our clients: Sprinto is SOC 2 compliant, and our own report runs on our platform.
You can see the combined effect in how little the audit intrudes once the program runs continuously. When Nium took its SOC 2 Type 2 through Sprinto, only three of its 100-plus controls required hand-collected evidence, and its auditor completed the evidence review in under two meetings. Raj Viswanathan, Nium’s CISO, noted that the engineering team never realized an audit was happening because not a single evidence request reached them.
FAQs
A live walkthrough of SOC 2 inside Sprinto — 30 minutes.
