SOC 2
SOC 2 is an AICPA attestation standard where an independent auditor examines how a service organization protects customer data against the Trust Services Criteria.
SOC 2 is an attestation standard from the AICPA where an independent auditor examines how a service organization protects customer data, against the Trust Services Criteria: security, availability, processing integrity, confidentiality and privacy. For SaaS companies it has become the de facto ticket to enterprise deals: no report, no procurement approval.
Key facts:
- SOC 2 is an auditor's attestation report, not a certificate: the deliverable is a detailed report on your controls, shared with customers under NDA.
- Type I assesses control design at a point in time; Type II tests whether controls operated effectively over a period (typically 3 to 12 months). Enterprise buyers usually require Type II.
- Only the Security criteria (the Common Criteria) are mandatory; the other four categories are added by choice depending on the service.
- SOC 2 is voluntary and market-driven, unlike NIS2 and DORA which are law, but the control substance overlaps heavily.
The Trust Services Criteria
| Criteria | What it covers | Mandatory? |
|---|---|---|
| Security (Common Criteria) | Access control, threat detection, incident response, change management, risk assessment, vendor management | Yes |
| Availability | Uptime, capacity, disaster recovery | Optional |
| Processing integrity | Complete, accurate, timely processing | Optional |
| Confidentiality | Protection of confidential business data | Optional |
| Privacy | Handling of personal information | Optional |
Type I vs Type II
Type I answers "are the right controls designed and in place today?" and can be produced quickly. Type II answers "did those controls actually operate for the whole audit period?" and is what serious buyers ask for, because it proves operation, not intention. The practical consequence: Type II requires continuous evidence (logs, alerts, reviews, incident records) collected throughout the period. Point-in-time screenshots do not survive a Type II audit; continuously monitored controls do.
The audit process
A typical path: choose scope (criteria and systems), run a readiness assessment against the Common Criteria, remediate gaps (this is where tooling, policies and processes get built), operate the controls while collecting evidence, then undergo the audit with an accredited CPA firm. Most first-timers go Type I then Type II, or straight to Type II with a shorter initial period.
Where email security fits, honestly
No product makes an organization SOC 2 attested; the audit covers your whole control environment. But several Common Criteria run straight through the mailbox, and this is where an email security layer carries real audit weight:
| SOC 2 control area | What Sentaro contributes | What remains yours |
|---|---|---|
| Threat detection & monitoring (CC7) | Continuous AI-native detection of phishing, business email compromise and malicious OAuth apps, with alerting | The monitoring program, triage and ownership |
| Incident detection & response chain | Detection triggers the incident process and supplies who/what/when evidence for incident records and customer notifications | The incident response plan, decisions, communication and post-mortems |
| Logical access (CC6) | Visibility into third-party OAuth grants and scopes on mail, files and calendars; flags unsanctioned access | Access policies, reviews, provisioning and revocation decisions |
| Vendor & third-party management (CC9) | A live picture of which SaaS and AI services actually touch company data, including shadow IT and shadow AI adoption | Vendor assessments, contracts and risk acceptance |
| Audit evidence for Type II | Continuously generated logs and reports covering the audit period | Mapping evidence to controls with your auditor |
The incident chain deserves emphasis: auditors test not only that incidents are handled but that they are detected and documented in the first place. Detection you can show, with timestamps, scope and disposition, is the difference between an incident narrative and an incident record.
This page is general guidance, not legal or audit advice. Scope and evidence requirements are set with your auditor.
Frequently asked questions
What does SOC 2 stand for?
System and Organization Controls 2, an AICPA attestation standard for service organizations' controls over security, availability, processing integrity, confidentiality and privacy.
What is the difference between SOC 2 Type I and Type II?
Type I assesses whether controls are suitably designed at a point in time. Type II tests whether they operated effectively over a period, usually 3 to 12 months, and is what most enterprise customers require.
Is SOC 2 a legal requirement?
No, it is voluntary and market-driven, typically demanded by customers in procurement. Legal frameworks like NIS2 and DORA are separate, though the underlying controls overlap substantially.
How long does SOC 2 take?
Commonly several months of readiness and remediation, plus the Type II observation period of 3 to 12 months. Timelines depend on scope and how much of the control environment already exists.
Does email security help with SOC 2?
Yes, concretely: threat detection and monitoring, the incident detection and evidence chain, OAuth/access visibility and third-party insight map to the Common Criteria, and continuous logs serve as Type II evidence. But the attestation covers your full control environment; no single tool delivers it.