SOC 2 (Service Organization Control 2) is an attestation engagement in which an independent CPA firm reports on a service organization's controls relevant to one or more Trust Services Criteria, most commonly Security, and often Availability, Confidentiality, Processing Integrity, or Privacy.
In security and compliance programs, SOC 2 is how many SaaS and cloud vendors demonstrate to customers that controls around systems and data were designed (and, for Type 2, operated) over a defined window. The report is produced by a licensed auditor under AICPA attestation standards. It is not a government license, not a product certification badge your company awards itself, and not the same as ISO 27001 certification.
In simple terms, SOC 2 answers:
- Which Trust Services Criteria are in scope for this system?
- What controls did management design to meet those criteria?
- For Type 2, did those controls operate effectively over the audit period?
This page is the umbrella definition. For deeper comparisons and walkthroughs, see SOC 2 Type 1 vs Type 2, SOC 2 Trust Services Criteria Explained, What Is SOC 2 Evidence?, and how to prepare for a SOC 2 audit. Related glossary themes include audit evidence, continuous compliance, a control, and ISO 27001.
Why SOC 2 Matters
Buyers, diligence teams, and enterprise security questionnaires routinely ask for a current SOC 2 report before sharing production data or signing larger contracts.
SOC 2 matters because:
- It packages control design and (for Type 2) operating evidence into a standardized report customers recognize.
- It forces clarity on system boundaries, risks, and control owners.
- Gaps surface as exceptions or qualified opinions, which creates pressure to remediate rather than paper over issues.
- Ongoing readiness reduces the last-minute scramble that control drift creates mid-period.
- Pairing SOC 2 work with continuous evidence habits supports faster renewals and fewer emergency engineering interrupts.
SOC 2 is a report about your controls. It is not a guarantee that nothing will go wrong, and it does not replace customer due diligence.
SOC 2 vs Type 1 vs Type 2 vs ISO 27001 vs "Certification"
Keep labels precise.
| Concept | Primary job | How it relates to SOC 2 |
|---|---|---|
| SOC 2 | Attestation report on TSC-relevant controls | The umbrella report family this page defines |
| SOC 2 Type 1 | Opinion on control design at a point in time | A SOC 2 report subtype focused on design |
| SOC 2 Type 2 | Opinion on design and operating effectiveness over a period | The subtype most enterprise buyers prefer |
| Trust Services Criteria (TSC) | Criteria categories (Security, Availability, and others) | The criteria set SOC 2 reports map controls against |
| ISO 27001 | Management system certification against an ISO standard | Different scheme; often mapped alongside SOC 2 via control mapping |
| Self-attested "SOC 2 certified" badge | Marketing language | Misleading; SOC 2 is an auditor attestation, not a self-issued cert |
Saying "we are SOC 2 certified" usually oversimplifies. Prefer "we have a SOC 2 Type 2 report" with criteria and period stated. See SOC 2 Type 1 vs Type 2 and ISO 27001.
How a SOC 2 Engagement Typically Works
Teams usually move through readiness, fieldwork, and report issuance:
- Define scope. System description, in-scope services, locations, and which Trust Services Criteria apply. Security is nearly always included.
- Identify risks and controls. Map risks to control activities. Assign owners. Document policies and procedures.
- Collect evidence. Prefer continuous evidence collection over end-of-period screenshot hunts. See What Is SOC 2 Evidence?.
- Choose Type 1 or Type 2. Type 1 evaluates design at a point in time. Type 2 evaluates design and operation over an audit period.
- Engage a CPA firm. Auditors plan, request populations, sample, interview owners, and test controls.
- Remediate findings. Address exceptions through remediation and exception management before or as the report finalizes.
- Issue and share the report. Distribute under NDA or portal controls to customers and prospects who need it.
Concrete good vs poor examples:
- Good: Type 2 period with dated access review packets, change tickets, and training completion exports covering the full window.
- Poor: a Type 1 design narrative with no plan for how the same controls will leave evidence next quarter.
- Good: clear system description that matches what sales promises customers.
- Poor: marketing claims that every product line is "in the SOC 2" when only one service is scoped.
Evidence Themes Auditors May Expect
Illustrative themes. Exact samples depend on your controls and criteria:
| Theme | Example evidence areas |
|---|---|
| Logical access | Provisioning, MFA, reviews, privileged access (access control, logical access) |
| Change management | Tickets, approvals, deployments (change management) |
| Risk | Assessment packets and register maintenance (risk assessment) |
| Vendors | Due diligence and monitoring for critical processors |
| People | Training and policy acknowledgement |
| Monitoring and incidents | Alerts, tickets, post-incident notes (monitoring, incident management) |
| Availability (if in scope) | Backups, DR tests, capacity notes |
Evidence quality improves when artifacts are dated, attributable, and mapped to controls. See audit evidence and continuous compliance.
Framework Notes
Trust Services Criteria
Security is the foundational category. Availability, Confidentiality, Processing Integrity, and Privacy may be added based on customer commitments and system risks. See SOC 2 Trust Services Criteria Explained.
Relationship to ISO 27001 and other programs
Many organizations map SOC 2 controls to ISO 27001 Annex A and other frameworks to reduce duplicate work. Mapping is reuse of evidence themes, not automatic equivalence. See mapping controls across SOC 2 and ISO 27001.
Customer and contractual use
Customers treat SOC 2 reports as diligence artifacts. Report period, criteria, carve-outs, and exceptions all matter. Sharing stale or incomplete reports creates trust risk.
Common Failures and Misconceptions
Watch for these patterns:
- Calling SOC 2 a "certification" you award yourself
- Treating Type 1 as permanently equivalent to Type 2 for enterprise buyers
- Scoping the report so narrowly that sales claims do not match the system description
- Collecting evidence only in the last two weeks of the period
- Ignoring control drift when tools, owners, or cloud accounts change
- Confusing a clean report with continuous monitoring or incident-free operations
- Assuming ISO 27001 certification automatically satisfies every SOC 2 sample request without mapped evidence
These misconceptions create diligence friction and weak renewal cycles.
Continuous Compliance Bridge
Passing one audit is a milestone. Staying ready is the operating model. Continuous compliance means you keep control operation and evidence current throughout the period so the next Type 2 renewal is routine. See AuditFlo's continuous compliance resource and how to prepare for a SOC 2 audit.
How AuditFlo Helps
AuditFlo (auditflo.co) helps teams retain continuous evidence collection and audit-period history for control artifacts when those records are stored or linked through connected systems and workflows your team already uses.
The focus is organizing dated proof so SOC 2 readiness claims can be shown with history instead of last-minute screenshots. AuditFlo is positioned here as evidence and readiness support for the control program your organization defines. It does not issue SOC 2 reports, does not perform attestations, does not certify compliance, does not guarantee a clean opinion, and does not replace auditors or your CPA firm.
To see the workflow for your stack, request a demo.
Key Takeaway
SOC 2 is an independent attestation on controls relevant to the Trust Services Criteria. Type 1 addresses design at a point in time; Type 2 addresses design and operating effectiveness over a period. Treat it as auditor-issued reporting, not a self-certification badge, and keep continuous evidence habits so renewals stay boring in the best way.