CMMC vs. SOC 2: Type I, Type II, and What a SOC 2 Report Does Not Cover

SOC 2 is a report, not a universal certificate

SOC 2 reports are issued by independent CPA firms using AICPA attestation standards and Trust Services Criteria. The criteria cover Security, Availability, Processing Integrity, Confidentiality, and Privacy. The report describes the service organization, selected criteria, controls, and auditor’s opinion. A Type II report also includes the tests of controls and their results, as shown in AICPA’s illustrative report description.

The first useful correction is linguistic. A company can obtain a SOC 2 report. Calling the company “SOC 2 certified” often hides the report’s scope, period, and criteria. A prospective customer should read those details instead of treating a logo as a complete answer.

Type I versus Type II

A Type II report gives a buyer evidence about operating effectiveness. It isn’t automatically broader in every respect. The scope still depends on the service, system boundary, criteria selected, exceptions, and report period. AICPA’s SOC 2 overview describes the report context.

Why a SOC 2 report does not satisfy a CUI obligation

DFARS 252.204-7012 requires adequate security for covered contractor information systems and points to NIST SP 800-171. The requirement comes from the contract and the information system. A SOC 2 report doesn’t change that governing obligation.

There can be real overlap. Access administration, logging, incident response, change management, and vendor oversight may produce evidence useful in both programs. The difference is that a CUI program must test the applicable 800-171 requirements within its defined boundary. A SOC 2 report’s criteria and scope are chosen for a different attestation purpose.

The gap becomes clear in the artifacts. A SOC 2 report may show that an auditor tested a control. A CUI readiness record still needs to show how the contractor meets the applicable 800-171 requirement, where CUI flows, and which party owns each part of a shared service.

Read the exceptions and customer responsibilities

A report’s conclusion needs its context. Check which service and period the report covers, the criteria selected, and any exceptions described. Then examine the customer responsibilities relevant to the planned use. A report for one service or period doesn’t answer every question about another deployment.

Suppose a hypothetical supplier presents a Type II report covering January through June. The customer plans an August deployment in a newly offered environment. Three separate questions now matter:

A clean opinion for the stated period does not, by itself, answer those later-deployment questions. Our recommendation is to preserve the report’s scope and period in the shared responsibility record, rather than reducing the review to a yes/no “SOC 2” field.

Use one evidence library, keep two decisions separate

The workable approach is to inventory existing SOC 2 controls and evidence, then map them to the applicable 800-171 requirements. Mark each mapping full, partial, or absent. Preserve the reason for partial matches. An access-review artifact may support both programs, while CUI scoping or a customer responsibility matrix may still require separate work.

In Deep Fathom’s view, the value of SOC 2 is not that it lets a defense supplier skip CMMC work. It gives the team a tested evidence base and an honest starting point for the work that remains. Use CUI boundary scoping, the SSP guide, and the DFARS 7012 guide to define the remaining work.