SOC 2 is an independent audit report, not a law and not a certificate. For a SaaS company it is the document enterprise buyers ask for during security review, and the one that quietly decides whether a deal moves forward. You pick the Trust Services Criteria that match your promises to customers, an independent CPA firm tests your controls, and you receive a report you can hand to prospects. This guide covers what that means in practice, how Type I and Type II differ, how to scope the work, a readiness checklist, and where your identity layer (Auth0, Amazon Cognito or your own build) fits.
TL;DR
- SOC 2 is a voluntary attestation from an independent CPA firm, but customers can make a current report a condition of doing business.
- Type I looks at control design on one date. Type II tests whether controls worked across a period, and it is the report most buyers want.
- Security is the core criterion. Add Availability, Confidentiality, Processing Integrity or Privacy only when your customer commitments call for them.
- Most of the effort is engineering: access control, change management, logging, vendor tracking and evidence you can produce on demand.
- Decide your identity approach early, because SSO, MFA and audit logs touch almost every control the auditor samples.
Table of Contents
- What SOC 2 means for a SaaS company
- SOC 2 Type 1 vs Type 2
- Which Trust Services Criteria apply to SaaS
- SOC 2 readiness checklist for SaaS teams
- How a SOC 2 audit unfolds
- Identity and access: Auth0 vs Cognito for SOC 2
- Our perspective: build the product so the audit is easy
- Where Requestum can help
- FAQ
- Sources
What SOC 2 means for a SaaS company
SOC 2 is a report in which an independent auditor assesses the controls of a service organization against the AICPA Trust Services Criteria. Palo Alto Networks describes it as designed for service organizations such as cloud providers and SaaS vendors, and as requiring an independent audit of the processes that protect systems and data.
Two words in that description matter. The first is "report". Pulumi's guide calls SOC 2 a voluntary attestation produced by an independent CPA firm, not a certification. You do not "pass" in the way you pass an exam; the auditor gives an opinion, and your buyers read the findings. The second is "independent". Your own team, a consultant or a compliance tool can prepare you, but only a licensed CPA firm can issue the report.
Is SOC 2 legally required?
No. The same Pulumi guide states that no law requires SOC 2 itself, although enterprise customers can make a current report a contractual condition. That is how it becomes mandatory in practice: a security questionnaire arrives, the buyer's procurement team asks for the report, and without it the deal stalls or drops into a longer manual review.
That is also why regulated or sensitive sectors tend to feel the pressure first. If your customers handle financial, health or personal data through your product, expect the request early. If you sell to small teams on credit cards, you may not hear it for a long time.
Why it shows up in sales before it shows up in engineering
A SaaS report works as a trust shortcut. Instead of answering 200 questions per prospect, you share one document that an outside firm has tested. Trust also lives beyond the audit: the way a company handles website security and customer trust shapes how buyers see it before they ever ask for a report. SOC 2 gives that impression something verifiable behind it.
SOC 2 Type 1 vs Type 2
Both report types cover the description of your system and the design of your controls. According to the AICPA comparison published by PwC, Type I assesses them at a specified point in time, while Type II also tests whether the controls operated effectively throughout a defined period and reports the auditor's procedures and results.
| Type I | Type II | |
|---|---|---|
| What is tested | Design of controls | Design and operating effectiveness |
| Time frame | A single date | A period, commonly three to twelve months |
| Evidence | Policies, configurations, a snapshot | Samples across the whole period |
| Buyer reaction | Useful as a first step | The report most enterprise buyers expect |
Pulumi notes that Type II commonly covers three to twelve months, with six- and twelve-month windows frequent, and that it requires multiple control samples across that period. Baker Tilly adds a blunt point: Type I reports give less comfort to readers and are uncommon.
Should you start with Type I?
It depends on the deal in front of you. Type I is optional. Cherry Bekaert states that an organization can go directly from a readiness assessment to Type II. The same firm advises choosing between the two based on what your regulators, business partners or clients expect.
A practical way to decide:
- Ask the prospect or your best three customers which report they will accept. Some accept Type I with a commitment to Type II.
- If a big deal is waiting and you have no report at all, Type I can unblock the conversation while your observation window runs.
- If nobody is pressing, going straight to Type II saves a full audit cycle and its cost.
Whatever you choose, the observation window for Type II starts when your controls are actually running, so the sooner they are built into the product and the team's routine, the sooner the clock starts.
Which Trust Services Criteria apply to SaaS
The AICPA's Trust Services Criteria (2017, with revised points of focus published in 2022) are the standard for evaluating and reporting on controls over systems used to provide products or services. There are five: Security, Availability, Processing Integrity, Confidentiality and Privacy.
Auth0's SaaS guide describes them in terms a product team can use:
- Security: protection against unauthorized access.
- Availability: access to the system as agreed in contracts.
- Processing Integrity: whether data is retrieved as stored and only by authorized people.
- Confidentiality: how data is stored, accessed and shared.
- Privacy: how customer data is collected and used.
The practical rule: scope to what you have promised. If your contract or SLA guarantees uptime, Availability belongs in scope. If customers upload sensitive documents, Confidentiality does. If you run calculations or transactions on customer data, such as billing engines or financial workflows, think about Processing Integrity. Every extra criterion adds controls to design, operate and evidence, so adding all five on the first audit is rarely wise.
If your product also handles European personal data, SOC 2 Privacy does not replace GDPR work. Our GDPR plan for SaaS founders shows how to sequence that in parallel.
SOC 2 readiness checklist for SaaS teams
Start with a readiness or gap assessment, as Cherry Bekaert recommends. It should identify your service commitments and applicable criteria, system boundaries, assets and data classifications, vendor interactions, stakeholders, risks, controls, monitoring, incident response and workforce training. Turn that into work in this order.
1. Define the system boundary
Sprinto's SaaS guide recommends scoping every system that touches customer data: cloud infrastructure, CI/CD, code repositories, HR systems, identity providers and support platforms. A tight, honest boundary keeps the audit manageable. A vague one leads to surprises when the auditor asks about the helpdesk tool where customers paste logs.
2. Write the policies you will actually follow
Cyberbase's 2026 checklist names the foundations: information security, acceptable use, access control, change management, incident response, business continuity, vendor management and data classification policies. Keep them short and true to how you work. An auditor tests what you do against what you wrote, and an ambitious policy you ignore becomes an exception in the report.
3. Put the technical controls in place
The same checklist pairs those policies with SSO, MFA, endpoint protection, centralized logging and vulnerability scanning. For a product team, this is where most of the real work sits. Our web app security checklist breaks security into testable controls with owners and evidence, which maps neatly onto what an auditor asks. Two related pieces deserve their own attention:
- Encryption, key handling and backups: see secure data storage.
- Alerting and incident detection: see application monitoring best practices.
4. Make change management auditable
Auditors sample code changes and ask who reviewed and approved each one before release. Pull requests with required reviews, protected branches and a ticket reference per change produce that evidence automatically. If your releases rely on chat messages and goodwill, fix that before the observation window opens. Our guide to security-first release management covers the pipeline side.
5. Track vendors
Your sub-processors are part of your system story. Keep a list, record why each is used and review their own assurance reports. If you are choosing new tooling, our software vendor selection checks give you a repeatable way to do it.
6. Collect evidence as you go
Common audit evidence, as listed in one open-source SOC 2 toolkit, includes approved policies, configuration screenshots, access and change logs, vulnerability and penetration test reports, backup reports, asset and vendor lists, meeting minutes, training records, firewall and IAM configurations, and encryption settings. Decide who owns each item and where it lives, and capture it on a schedule rather than in a panic the week before fieldwork.
How a SOC 2 audit unfolds
The audit follows a predictable arc: readiness assessment, remediation of gaps, an observation window (for Type II), fieldwork where the auditor samples evidence and interviews owners, then the report. Cherry Bekaert states that the finished report contains the independent auditor's report, management's assertion, management's system description, and the criteria with the auditor's procedures and conclusions. A management response section may be added, but it is optional and not audited.
Two habits make this smoother. First, assign one person to coordinate evidence requests so engineers are not interrupted ad hoc. Second, treat exceptions as information. A missed access review in month two is a reason to fix the process, not to hide it; the report will describe it, and buyers generally care more about how you respond than about perfection.
Plan for the audit to compete with your roadmap. Teams that budget engineering time for it, rather than treating it as a side project for the CTO, finish sooner and with fewer exceptions.
Identity and access: Auth0 vs Cognito for SOC 2
Authentication touches many SOC 2 controls: who can log in, how strongly, who can see what, and what is recorded. That is why the build-or-buy decision for identity matters to your audit, and why developers search for comparisons between Auth0 and Amazon Cognito.
What the sources let us say: Auth0 maintains multiple compliance frameworks and certifications and provides compliance documentation through its Support Center. Its B2B SaaS material says it supports SOC 2 Type II and offers audit logging, credential protection and centralized access controls that can support security reviews. Amazon Cognito is the identity service inside the AWS ecosystem; check AWS's own compliance documentation for its current attestations before you rely on it.
A few points hold for either choice:
- A vendor's report is not your report. Using a compliant identity provider helps you with vendor-management evidence and inherited controls, but you still own how you configure it: MFA enforcement, role design, session settings and offboarding.
- Pick by fit. Teams already deep in AWS often value tight integration with the rest of their stack. Teams selling to enterprises often need SAML or OIDC single sign-on for their customers, organization-level tenancy and flexible login flows, so test each option against your real B2B requirements.
- Logs matter as much as logins. Auditors want to see who accessed what and when. Confirm you can export and retain authentication logs for your whole observation window.
- Role design is the quiet hero. One well-defined role per job function beats dozens of individual permissions. A short read on role-based access controls shows why consolidating access simplifies both daily work and audit sampling.
If you are early and prototyping, a managed identity service is usually the faster route to meeting access-control expectations than writing your own. Building it yourself makes sense only when you have unusual requirements and the capacity to test, patch and evidence it continuously.
Our perspective: build the product so the audit is easy
We are a software development agency, not an audit firm, and we say so plainly: the independent CPA issues the report, and your auditor's judgment is the only one that counts. What we see from the engineering side is that SOC 2 becomes painful when controls are retrofitted onto a product that was never designed to produce evidence.
Three things help most. Make security requirements part of discovery, so access models, tenancy and logging are decided before the first sprint rather than after the first enterprise questionnaire. Build testing into delivery, because regression and security checks that run on every release are exactly the kind of recurring control an auditor wants to sample. And keep the scope honest: a smaller system boundary that you control well beats a sprawling one you cannot explain.
The same logic applies to prioritization. Founders sometimes chase the report before the product has paying customers; others wait until a seven-figure deal is blocked. The better moment is usually when the first enterprise conversations start, because the observation window needs time to run. If you are weighing those trade-offs inside a larger roadmap, our notes on B2B SaaS development and software project risks can help you place compliance work next to everything else competing for engineering hours.
— Dmitry
Where Requestum can help
If your product needs the engineering behind SOC 2, we can help with the parts we deliver: a discovery phase that settles access models, tenancy and logging before build, web development for the product itself, and software testing and quality assurance so changes are verified on every release. Early-stage teams can also look at our software development for startups. Bring your scope and your auditor's expectations, and we will map them to a delivery plan.
FAQ
Is SOC 2 legally required for SaaS companies?
No. No law requires SOC 2 itself. In practice, enterprise customers often make a current report a contractual condition, so it becomes a requirement of the sale rather than of the law.
Is SOC 2 a certification?
No. It is an attestation report issued by an independent CPA firm, which gives an opinion on your controls against the Trust Services Criteria. Buyers read the report itself, including any exceptions, rather than looking for a badge.
How long does a Type II observation period last?
It commonly covers three to twelve months, and six- and twelve-month windows are frequent. Your auditor will sample controls across the whole period, so the controls need to be running before the window opens.
Which criteria should a first-time SaaS company include?
Security is the foundation, and you add others only where your customer commitments require them. Availability suits products with uptime guarantees, and Confidentiality suits products that store sensitive customer content. Confirm the final scope with your auditor.
Can I skip Type I and go straight to Type II?
Yes. Type I is optional, and an organization can move from a readiness assessment directly to Type II. Choose Type I first only if a buyer will accept it and you need something to share while the Type II window runs.
Sources
- What Is SOC 2 Compliance? Palo Alto Networks
- What is SOC 2? Pulumi
- Comparison of SOC 1, SOC 2, and SOC 3, via PwC Viewpoint
- SOC FAQ, Baker Tilly
- SOC 2 Report: Benefits and How to Prepare, Cherry Bekaert
- 2017 Trust Services Criteria with revised points of focus (2022), AICPA
- SOC 2 Compliance and Certification, Auth0 blog
- Auth0 Data Privacy and Compliance, Auth0 Docs
- Auth0 for B2B SaaS
- SOC 2 for SaaS, Sprinto
- SOC 2 Checklist, Cyberbase
- SOC 2 compliance toolkit, GitHub