What is SOC 2 Compliance? The Attestation Report Explained for Buyers, Boards, and Deal Teams

What SOC 2 Is

An Attestation Under AICPA Standards

System and Organization Controls reports come in three forms. SOC 1 covers controls relevant to a customer's financial reporting, the successor to SAS 70. SOC 2 covers controls relevant to security, availability, processing integrity, confidentiality, and privacy. SOC 3 is a general-use summary of a SOC 2 without the detail. A SOC 2 engagement is performed under AICPA attestation standards by a CPA firm, and the firm's independence is what gives the report its weight.

The service organization writes a description of its system and asserts that its controls meet the criteria. The auditor examines the description and the controls and issues an opinion on whether the description is fairly presented, whether the controls are suitably designed to meet the criteria, and, for a Type II, whether they operated effectively over the period. The report is restricted-use: it belongs to the service organization, which shares it with customers and prospects under NDA.

Type I and Type II

A Type I report is as of a date. The auditor confirms that on that date the described controls existed and were suitably designed. It answers the question do they have the right controls? and nothing about whether the controls are used.

A Type II report covers a period, typically six to twelve months. The auditor tests whether the controls operated as described throughout the period, using samples: a selection of access reviews, a selection of change tickets, a selection of terminated employees whose access should have been removed. It answers did the controls operate? for the sampled instances. Type II is what enterprise customers and diligence teams want, because design without operation is a policy binder.

The sample is the thing to understand. An auditor testing quarterly access reviews across a twelve-month period examines four reviews. An auditor testing that terminated employees lost access examines a sample of terminations. The opinion is that the controls operated for the sampled items. It is not an assertion that nothing went wrong on any other day.

The Five Trust Services Criteria

Security. The common criteria, present in every SOC 2 report, organized as CC1 through CC9: control environment, communication, risk assessment, monitoring, control activities, logical and physical access (CC6), system operations (CC7), change management (CC8), and risk mitigation (CC9). CC6 and CC7 are where most of the technical security controls live and where most exceptions appear.

Availability. The system is available for operation and use as committed. Capacity, monitoring, backup, recovery, and incident handling relevant to uptime.

Processing Integrity. System processing is complete, valid, accurate, timely, and authorized. Relevant to payment processors, payroll platforms, and anything that transforms customer data.

Confidentiality. Information designated confidential is protected as committed. Classification, encryption, retention, and disposal.

Privacy. Personal information is collected, used, retained, disclosed, and disposed of in conformity with the organization's privacy notice and the AICPA privacy criteria. The most demanding criterion and the least commonly included.

A service organization chooses which criteria to include. Security alone is common for a first report. The choice is itself information: a data processor whose SOC 2 omits Confidentiality has made a decision a diligence team should notice.

How to Read a SOC 2 Report

Most SOC 2 reports are received, confirmed to exist, and filed. Reading one takes an hour and answers questions the cover page does not.

Section 1, the auditor's opinion. Unqualified, qualified, adverse, or disclaimed. Nearly all reports a vendor will share are unqualified. An unqualified opinion can coexist with exceptions in Section 4; the auditor concluded the exceptions did not rise to the level of qualifying the opinion. Read Section 4 anyway.

Section 2, management's assertion. The service organization's statement that the description is accurate and the controls met the criteria. This is the representation the rest of the report tests.

Section 3, the system description. The most important section and the least read. It defines the boundary: which systems, which locations, which services, which infrastructure. Anything not in the description is not covered by the opinion. A SaaS vendor whose description covers the production application but not the corporate Microsoft 365 tenant where customer support tickets and contracts live has a SOC 2 that says nothing about the place a business email compromise would occur. The description also lists subservice organizations, usually the cloud provider, and whether they are carved out (their controls are excluded and the reader is pointed to their own SOC 2) or included.

Section 4, the tests and results. For a Type II, each control, the auditor's test, and the result. Exceptions are recorded here: the access review that was late, the terminated user whose account persisted for thirty days, the change deployed without approval. Exceptions are normal; a report with none may indicate a narrow scope or gentle testing. The pattern of exceptions is what matters. Repeated exceptions in CC6 across two report periods describe an organization that has not fixed its identity process.

Complementary user entity controls. A list of controls the customer must implement for the service organization's controls to be effective: manage your own users, configure MFA on your side, review the access you grant. Customers rarely read this section and rarely do what it says.

The period. A Type II covering a period that ended fourteen months ago describes an environment that has since changed. A bridge letter from management, not the auditor, asserts that nothing material changed. It is an unaudited assertion.

What SOC 2 Does Not Tell You

The report is silent on five things a buyer usually assumes it covers.

Systems outside the description. The corporate tenant, the sales team's laptops, the marketing platform, the acquisition that closed last quarter. If Section 3 does not name it, the opinion does not cover it.

Days between samples. The auditor tested a sample. An intrusion that began and ended between sampled dates, or that occurred in a system the sampled control did not touch, is outside the opinion.

Whether an attacker is present. SOC 2 tests controls. It does not hunt for compromise. A vendor can hold a clean Type II while an attacker holds a session token in the production environment, because no Trust Services Criterion asks the auditor to look.

The quality of the controls chosen. The criteria describe outcomes; the organization chooses the controls. Push-notification MFA and phishing-resistant MFA both satisfy CC6.1. One of them is defeated by adversary-in-the-middle phishing and one is not. The report will not tell you which the vendor uses unless you read the control description.

Anything after the period end. The bridge letter is management's word.

SOC 2 and the Frameworks It Maps To

The AICPA publishes mappings from the Trust Services Criteria to NIST SP 800-53, the NIST Cybersecurity Framework, ISO 27001, and others. CC6, logical and physical access, corresponds to the 800-53 AC, IA, and PE families. CC7, system operations, corresponds to AU, SI, and IR. CC8, change management, to CM. A risk register built on 800-53 control IDs can be expressed in TSC language for a SOC 2 auditor without a second assessment, which is why organizations pursuing SOC 2 for the first time are better served by building the program on 800-53 or the CIS Controls than on the criteria alone. The criteria describe what the auditor will check. The control catalog describes what to build.

ISO 27001 is the closest sibling: an international certification that an information security management system exists and operates, issued by an accredited body rather than a CPA firm. SOC 2 describes controls; ISO 27001 certifies a management system. US enterprise customers ask for the first, international customers for the second, and the control sets overlap enough that many organizations maintain both from one evidence base.

Getting a SOC 2 Report

Scope. Decide which services, systems, and criteria are in scope. Narrow scope is faster and cheaper and produces a report that covers less. The decision should be made with the customers who will read it in mind.

Readiness. A gap assessment against the criteria, then implementation of the controls that are missing. For a mid-market SaaS company, this is usually identity and access governance, change management evidence, vendor management, logging and monitoring, and the policy set. Compliance automation platforms have made evidence collection less painful; they have not made the controls exist.

Type I. Often the first milestone: the auditor confirms design as of a date. Some organizations skip it and go directly to Type II.

Observation period. The controls must operate for the period the Type II will cover, minimum six months in practice, before the auditor can test them. This is the constraint that makes a first Type II a nine-to-fifteen-month project from a standing start.

Audit. The CPA firm examines, interviews, tests samples, and issues the report. Fees for a mid-market Type II typically run $20,000 to $60,000, plus readiness and tooling.

Renewal. Annually, with the observation period rolling. The second report is cheaper and faster than the first if the program was real.

Where Organizations Fail

The exceptions in Section 4 are predictable. Access reviews that were scheduled quarterly and performed twice. Terminated employees whose accounts persisted. Changes deployed without a ticket. Vendor reviews that consisted of collecting the vendor's SOC 2 and filing it. Logging that was enabled and never reviewed. And the failure that does not appear in the report at all: a system description drawn narrowly enough that the environment where the real risk lives, the corporate tenant, the support desk, the finance team's mailboxes, was never in scope.

Executive Implications

For a CFO, SOC 2 is a sales enablement cost with a compliance label. It unlocks enterprise procurement. It should be scoped to what customers will actually read and built on a control framework that will serve other purposes, so the same evidence supports the cyber insurance application and the diligence data room.

For a General Counsel, the report is a set of representations, management's assertion above all, and the system description defines exactly what was represented. Customer contracts that reference SOC 2 should reference the scope. The bridge letter is a management statement, and it should be true.

For a board, a SOC 2 report in the board pack answers the question did the auditor find that the controls we described operated on the days they tested? It does not answer are we secure or are we compromised. A board that has received only the report has been told about the audit, not the environment.

PE Implications

SOC 2 appears in almost every technology data room, and its presence is routinely treated as closing the security workstream. It should open it. Three uses.

Scope as signal. Read Section 3 first. A target whose SOC 2 covers the product and excludes the corporate environment has drawn the boundary where the auditor would find the least. That is a management decision the team should understand.

Exceptions as pattern. Two report periods of CC6 exceptions describe an identity process that has not been fixed. Compare the exceptions to what an independent assessment of the environment finds; the gap between them measures how much the report should be trusted on everything else.

The compromise question. The report does not ask it. A compromise assessment on the actual tenant does, and it is the only way to know whether the diligence team is acquiring an environment or an incident. Clean SOC 2, active compromise is a fact pattern that has reshaped deals.

Post-close, a target's SOC 2 program is an asset to preserve and a scope to widen. The platform benefits from a consistent control framework across portcos, and SOC 2 built on 800-53 or CIS is the version that extends.

Related Reading

• What is ISO 27001?
• What is NIST SP 800-53?
• What are the CIS Benchmarks?
• What is a Compromise Assessment?
• What is a Cyber Insurance Attestation?
• What is Cyber Due Diligence?
• Vendor Risk Management

Real-World Example: A Clean Report and an Occupied Environment

The pattern recurs across Cloudskope's vendor risk and diligence work and across the public breach record. A software company holds a current SOC 2 Type II with an unqualified opinion and few exceptions. The system description covers the production platform hosted on a major cloud provider. The corporate Microsoft 365 tenant, where sales, support, finance, and executive correspondence live, is outside the description.

An adversary-in-the-middle phishing campaign captures a finance employee's session token after MFA is satisfied. The attacker reads invoice threads for weeks, plants inbox rules to hide replies, and redirects a customer payment. No SOC 2 control was violated, because no SOC 2 control covered the tenant. The Type II remains accurate. The company has been breached. The buyer who accepted the report as the security workstream discovers the incident from the customer who did not receive their refund.

The public record contains larger versions of the same story. Organizations with mature SOC 2 programs have disclosed breaches of systems the report described, because the compromise occurred between samples or through a control the criteria did not require. The report was not wrong. It answered the question it was asked. The buyer asked the wrong question.