SOC 2: explained for the teams who have to earn the report.

An attestation, not a regulation

SOC 2 is not a law and not a certification — it is an attestation. An independent CPA firm examines your controls, compares what it finds against the AICPA Trust Services Criteria, and issues a written opinion. The opinion is the report: a document your customers and prospects read to decide whether to trust you with their data.

The key architectural difference from ISO 27001 or a regulation like DORA is that there is no accreditation body, no statutory scope, and no enforcement mechanism. There are no penalties for not having a SOC 2 report and no regulator who can compel one. You pursue SOC 2 because the market requires it — specifically, because enterprise procurement teams routinely demand a Type II report before signing a contract with a cloud or SaaS vendor. That market pressure is real and growing, but it is commercial, not legal. The decision to pursue SOC 2 and which Trust Services Criteria to scope in is yours to make based on what your buyers need to see.

The five Trust Services Criteria

The TSC are the measuring stick the auditor uses. Security (the Common Criteria, CC) is the only mandatory category — every SOC 2 report covers it. The other four are optional add-ons, included where relevant to the services you provide and to what your customers care about.

Most SaaS companies scope Security as the baseline and add Availability when uptime commitments matter to buyers, Confidentiality when enterprise data handling is a selling point, Privacy when personal data processing is central to the service, and Processing Integrity for transactional or financial processing services.

CC1 through CC9: what the auditor samples

The Common Criteria are the detailed control requirements behind the Security category. They are organized into nine groups, CC1 through CC9, each covering a distinct control domain. CC6, Logical and Physical Access Controls, is the most operationally intensive for most organizations: it covers access provisioning, authentication, role-based access, and periodic access review. CC7 covers systems operations and monitoring. CC9 covers risk management and vendor risk, including CC9.2, which specifically requires monitoring of third-party providers and the controls they operate on your behalf.

Understanding the CC-series structure matters because auditors sample evidence at control level. Knowing which CC criterion a control satisfies is how you build an audit-ready evidence map rather than a pile of documents. An access review that exists in a spreadsheet but cannot be tied to CC6.1 and a named control owner is harder to defend than one that is documented, assigned, and recurring.

The CC-series maps closely to ISO 27001 Annex A: CC6 aligns with A.5.15–A.5.18 (access management); CC7 with A.8.x (operations); CC9.2 with A.5.19–A.5.23 (supplier security). Organizations running both frameworks reuse this evidence rather than maintaining separate control sets.

Type I and Type II: what the difference means in practice

SOC 2 Type I examines whether your controls are suitably designed at a single point in time. An auditor visits, reviews your control documentation, and forms a view on whether the design is adequate. Type II examines whether those controls operated effectively over a defined period — the observation period, typically six to twelve months, with a minimum of six months.

Enterprise buyers almost universally require a Type II report because it demonstrates sustained operation, not just the existence of a policy. A Type I says your controls look right on paper on a given day. A Type II says they actually ran for six or twelve months without material gaps. That is the artifact that closes deals in enterprise procurement.

Some organizations use a Type I as a milestone — a way to get a report into customers' hands faster while the Type II observation period accumulates. That is a legitimate tactic, but enterprise security teams know what Type I means, and a Type II replaces it as the standard ask.

Why the audit window is the hard part

The observation period is the hardest part of SOC 2 for most organizations — not because the controls are unknown but because the evidence must be continuous. If access reviews are supposed to run quarterly and one quarter was missed, the auditor finds it. If a change-management process was documented in January but the evidence trail shows it was not followed in March, that is a deviation. The report will note it.

The practical implication is that SOC 2 compliance is not a project you finish and file — it is an operational cadence you sustain, and the audit is the annual check that the cadence held. This is structurally different from ISO 27001, where a certification body audits a snapshot and reaudits at surveillance intervals. The SOC 2 observation period is continuous: every month of the window counts, and every gap in recurring controls is visible.

This is why tools built for SOC 2 focus on evidence collection and recurring task management during the observation period, not just control documentation at the start. The goal is to walk into the audit with twelve months of evidence already organized, not to reconstruct it under deadline.

What a SOC 2 report is and who reads it

A SOC 2 report is a private document. Unlike an ISO 27001 certificate, which is publicly verifiable, a SOC 2 report is distributed under NDA to enterprise customers and prospects who request it during vendor due diligence. It is not filed with a regulator. It is not posted on your website. It is given, under confidentiality, to the procurement and security teams of your enterprise buyers.

What those teams look at: first, the auditor's opinion — whether it is unqualified (clean) or qualified (contains exceptions). An unqualified opinion means the auditor found that controls met the criteria without material exceptions. Second, the system description — which services and systems were in scope. A narrow scope ("the billing module only") may not satisfy a buyer whose data flows through systems that were not covered. Third, the exceptions table — any controls that failed or deviated during the audit period, and management's response.

A Type II report with a clean opinion, appropriate scope, and no material exceptions is the artifact that closes enterprise deals where a vendor security questionnaire alone would not suffice. The report is typically renewed annually, which is why the observation period cadence is ongoing rather than one-time.

SOC 2 and ISO 27001: the controls map, the decision does not

SOC 2 and ISO 27001 address overlapping control territory — which is why organizations running both can reuse significant evidence. The structural difference is the output: ISO 27001 produces a certificate (three-year, globally recognized, publicly verifiable, issued by an accredited certification body); SOC 2 produces a report (privately distributed, annually renewed, issued by a licensed CPA firm, standard in US enterprise markets).

For organizations selling into both US and EU enterprise markets, both are common and the controls overlap is a practical advantage: map once, satisfy both. For organizations choosing one to start, the question is where your buyers are. ISO 27001 is the expectation in EU enterprise and global markets. SOC 2 is the US market standard and is frequently a mandatory checkbox in US enterprise procurement. See the full SOC 2 vs ISO 27001 comparison for a control-by-control breakdown.

SOC 2 as a running programme, not an annual sprint

Acuna structures SOC 2 across its four panes so the work happens continuously rather than in a crunch before the CPA firm arrives.

In Comply, you select the Trust Services Criteria in scope, define the system description, and map each CC criterion to controls with owners. Cross-framework mapping runs automatically: a CC6 access-control set built for SOC 2 maps to ISO 27001 A.5.15–A.5.18 without rebuilding it.

In Implement, each control carries a CC criterion reference, an owner, an implementation status, and an evidence requirement. The audit trail is built into the control record, not reconstructed from email threads.

In Operate, recurring tasks keep the observation period clean: quarterly access reviews, monthly control attestations, vendor assessment cycles under CC9.2, and change-management logs. A task that slips shows as overdue before the auditor sees it as a gap.

In Assure, the audit pack builds itself from the evidence that accumulated during the observation period. Auditor requests for specific controls or evidence items are handled as an evidence view rather than a search-and-assemble exercise. See how Acuna supports SOC 2 audit readiness.