SOC 2 for Government Contractors (2026 Guide)

Agencies and prime contractors want proof that their supply chain is secure. For government contractors, a SOC 2 report is one form of that proof: an independent attestation from a licensed CPA firm about whether your security controls work.

SOC 2 is not a federal mandate like CMMC. A prime or an agency can still ask for it as evidence of your internal security program, and prime contractors flow security requirements down to subcontractors. If a procurement team asks for a SOC 2 Type 2 report and you can’t hand over a clean one, you may not make the short list.

This guide explains how SOC 2 works in government contracting: how it maps to CMMC and NIST 800-171, how to scope your audit, and how to build a roadmap that avoids duplicate effort. For auditor selection, the SOC 2 auditor directory can be filtered by industry.

What SOC 2 Means for Government Contractors

SOC 2 is not a certification. It is an attestation: a CPA firm examines your controls and issues an opinion on whether they are designed and operating effectively. The AICPA defines the standard. The report covers one or more of five Trust Services Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy.

In the federal space you are often handling Controlled Unclassified Information (CUI), and your prime contractor has its own compliance obligations. A SOC 2 report addresses the prime’s concern about weak links in the supply chain. It tells the prime: “An independent auditor examined this vendor’s controls. Here is what they found.”

A Type 1 captures control design at a point in time. A Type 2 covers operating effectiveness over an observation period (the AICPA sets no fixed minimum; we suggest planning for six months or more). For federal work a Type 2 is the better fit, because it shows your controls are not just written down but run continuously.

SOC 2 vs. CMMC vs. FedRAMP: Where Each Framework Fits

Government contractors frequently deal with three frameworks: SOC 2, CMMC, and FedRAMP. They are not interchangeable, and they are not redundant.

Which of the two you need depends on who is asking. DoD contracts that include DFARS 252.204-7012 require NIST SP 800-171 safeguards, and a solicitation may add a CMMC self-assessment. A SOC 2 request usually comes from a prime contractor or a commercial customer. A Defense Industrial Base (DIB) contractor that handles CUI and also sells to customers who ask for independent assurance typically needs both. One that sells only to DoD may never be asked for SOC 2. If you need both, build them together rather than as separate projects, as covered below.

FedRAMP is a narrower obligation. You only need it if you are selling a cloud service directly to federal agencies. If you are a subcontractor delivering services to a prime, FedRAMP likely does not apply to you. Read more in our SOC 2 vs. FedRAMP guide. A SaaS vendor selling to agencies should also read SOC 2 for SaaS companies for how scoping works for a hosted product.

The CMMC final rule was published on September 10, 2025, and took effect on November 10, 2025. That started Phase 1, in which applicable DoD solicitations require a CMMC Level 1 or Level 2 self-assessment as a condition of award. Phase 2 was due on November 10, 2026, when DoD planned to start requiring Level 2 certification assessments by an authorized third-party assessor (C3PAO). On July 13, 2026, DoD suspended Phase 2 and held all later rollout milestones while it reviews the program.

Until DoD issues further guidance, a solicitation can call for only a Level 1 or Level 2 self-assessment. The implementing memo also bars C3PAO and Level 3 assessment requirements during the suspension and directs that any already in active solicitations or existing contracts be removed. The security work has not gone away. If your DoD contracts include DFARS 252.204-7012, you still have to protect covered defense information under NIST SP 800-171 and report cyber incidents within 72 hours, and DoD says it will enforce 800-171 through self-assessments and selected government-led assessments. Plan on implementing 800-171 now and treat the timing of any C3PAO certification as open. Our SOC 2 vs CMMC comparison tracks the current program status.

What the DoD Clause Requires, and Where SOC 2 Appears

The clause that sets the security duty for DoD contractors who handle covered defense information is DFARS 252.204-7012. DoD’s current text is in class deviation 2026-O0025, Revision 3, signed September 3, 2026, whose Attachment 1 reproduces the clause (dated June 2026) on pages 37 to 39 of 71. These are the paragraphs that bear on a SOC 2 decision:

The 71-page deviation does not mention SOC 2, the AICPA or attestation reports anywhere. No paragraph of the clause requires a SOC 2 report. When a prime or an agency asks for one, the request comes from the contract or the vendor-review process. What the clause requires is the 800-171 safeguards, FedRAMP Moderate-equivalent cloud providers for covered defense information, and a report to DoD within 72 hours. A SOC 2 report can show that related controls operate, but the clause does not name it as a way to meet any of those duties.

Source: DoD class deviation 2026-O0025, Revision 3, Attachment 1 (revised DFARS part 240), DFARS 252.204-7012 (JUN 2026), pages 37 to 39 of 71. Read October 21, 2026.

The Five Trust Services Criteria for Government Work

Nearly every SOC 2 report starts with Security. The other four TSCs are optional. Use this framework to scope them:

SecurityAlmost always included

Its Common Criteria apply to every SOC 2 report. They cover access, change management, risk assessment, and monitoring.

ConfidentialityAdd if you handle CUI or confidential data

Protects CUI and any data your government client designates as confidential.

AvailabilityAdd if your contract has an uptime SLA

Tests capacity planning, backup, and disaster recovery controls.

Processing IntegrityConsider for financial or data processing services

Relevant if you provide data processing, financial transactions, or critical calculations.

PrivacyConsider if you collect or process PII

Applies when the contract involves personnel data, healthcare, or benefits administration.

What each TSC means for federal work:

• Security: The foundation. Its Common Criteria apply to every SOC 2 report and include logical access (CC6.1), change management (CC8.1), risk assessment (CC3.2), and monitoring (CC7.2). This is where most of your CMMC overlap lives.
• Confidentiality: Required if you handle CUI, contract data, or any information your government client designates as confidential. C1.1 covers identifying and maintaining confidential information, and C1.2 covers disposing of it when it is no longer needed.
• Availability: Required if your contract includes SLA commitments. It tests your capacity planning, backup, and disaster recovery controls.
• Processing Integrity: Relevant if you provide data processing, financial transactions, or critical calculations.
• Privacy: Applies if you collect or process PII. Required when your contract involves personnel data, healthcare, or benefits administration.

How SOC 2 Maps to CMMC and NIST 800-171

A unified compliance program saves the most work here. SOC 2 and CMMC Level 2 cover many of the same security areas, so evidence you collect for your SOC 2 audit can satisfy the corresponding CMMC practices. You do not need two separate evidence libraries.

The overlap works because CMMC Level 2 is built on NIST SP 800-171, which covers 14 control families. The SOC 2 Common Criteria address many of the same security domains: access control, risk assessment, system monitoring, incident response. The frameworks use different vocabulary, but the underlying controls often test the same things.

How much carries over is not a fixed percentage. The Trust Services Criteria are outcome-based: you design your own controls, and the auditor tests whether they meet each criterion. CMMC Level 2 assesses each of the 110 NIST SP 800-171 requirements individually. A SOC 2 control set written with 800-171 in mind covers more of CMMC than one written only for commercial customers, so treat any single overlap figure you see quoted as an estimate.

To measure your own overlap, map your controls requirement by requirement. NIST SP 800-171 Revision 2, the version CMMC Level 2 is assessed against, maps each requirement to NIST SP 800-53 controls in its Appendix D. The AICPA publishes a Trust Services Criteria to NIST SP 800-53 mapping (free account required). Joined through 800-53, the two give you a first-pass crosswalk to review with your auditor.

See our guide to the SOC 2 common criteria and SOC 2 controls overview for deeper coverage of individual control requirements.

Control Mapping Reference

The Overlap Visualized

SharedCollect evidence once

Access control, risk assessment, system monitoring, and incident response. The control mapping table above pairs the specific requirements.

CMMC Level 2 onlyExtra work for CMMC

Prescriptive requirements SOC 2 leaves to your own control design, such as FIPS-validated encryption for CUI, CUI media marking, a System Security Plan, and session lock.

SOC 2 onlyExtra work for SOC 2

Areas NIST SP 800-171 leaves out, such as the recovery and continuity planning tested under Availability, plus the Processing Integrity and Privacy criteria.

The controls that do not overlap are where you need to do extra work. CMMC Level 2 prescribes specifics that SOC 2 leaves to your own control design, such as FIPS-validated encryption for CUI (3.13.11), CUI markings on media (3.8.4), a System Security Plan (3.12.4), session lock (3.1.10), and visitor escorts (3.10.3). In the other direction, NIST SP 800-171 leaves contingency planning out of scope, so the recovery and continuity planning tested under SOC 2’s Availability criteria has no CMMC counterpart, and the Processing Integrity and Privacy criteria fall outside CMMC’s focus on protecting CUI. Build your unified control library around the overlap, then layer in what each framework uniquely requires.

Scoping Your Audit for Federal Contracts

Define scope too narrowly and your report won’t cover the systems your government client actually cares about. Define it too broadly and you pay to audit systems that don’t matter and extend your timeline unnecessarily.

Your SOC 2 “system” is the complete set of components that deliver your contracted service. For a government contractor, that boundary must capture everything that touches sensitive government data.

What Belongs in Scope

Work through each component category:

• Infrastructure: Cloud environments (including AWS GovCloud if applicable), data centers, networks, VPNs, and endpoints that touch the service
• Software: Applications, databases, APIs, and code repositories used to deliver the service
• People: Roles with administrative access, engineers who deploy to production, security operations staff, and customer support with data access
• Data: Explicitly identify CUI, PII, contract-sensitive data, and any data types your government client designates as requiring protection
• Processes: Change management, incident response, vulnerability management, access reviews, and vendor risk management

Scoping Checklist for Government Contractors

• Document every system component that processes or stores CUI
• Map data flows from government client to your systems and back
• Identify all third-party subprocessors that touch in-scope data (your cloud provider, monitoring tools, ticketing systems)
• Confirm which TSCs your contract obligations require
• Review your System Security Plan (SSP) if you have one; it should inform your SOC 2 system description
• Validate your scope with your auditor before starting evidence collection

The shared responsibility model is a common scoping trap. Your cloud provider (AWS, Azure, GCP) maintains its own compliance certifications. Those do not cover your configurations. You are responsible for everything you build and configure on top of their platform. Document that boundary clearly in your system description. Contractors that run IT for other organizations carry a wider privileged-access boundary; SOC 2 for MSPs walks through scoping it.

For practical guidance on gathering evidence within your defined scope, see our SOC 2 evidence request list and risk assessment template.

Government Contractor Compliance Roadmap

Plan about 6–12 months or more for a first SOC 2 Type 2, measured from the start of control implementation. If you already have NIST 800-171 controls in place, the preparation phase can be shorter because much of the groundwork is done.

Phase 1Plan and scope

Gap analysis, policy development, scope definition, and auditor selection.

Phase 2Build and run controls

Control implementation, evidence collection, staff training, and vendor assessments.

Phase 3SOC 2 Type 1

Type 1 audit, remediation of findings, and the start of the Type 2 observation period.

Phase 4SOC 2 Type 2

Type 2 audit and issued report, then the start of CMMC-specific control layering.

Phase 5CMMC assessment prep

Layer CMMC-specific controls onto your SOC 2 foundation, complete the System Security Plan, run the Level 2 self-assessment your solicitation calls for and enter the result in DoD's Supplier Performance Risk System (SPRS), and reuse SOC 2 evidence for overlapping practices. C3PAO assessments wait on DoD's program review.

A few notes on timing:

• We suggest a Type 2 observation period of at least six months (the AICPA sets no fixed minimum), or longer if your contract or prime specifies one. Start your controls running on day one; do not wait until the audit begins.
• If you have an active contract pursuit that requires SOC 2, a Type 1 report can demonstrate design-level compliance while your Type 2 observation period runs.
• You do not have to wait for the Type 2 report to start Phase 5. CMMC-specific controls can be layered in while the observation period runs, and an existing SSP with documented NIST 800-171 controls shortens that work.

Common Mistakes That Delay Government Contractor Audits

Four common mistakes delay or derail SOC 2 audits for government contractors.

1. Misreading the shared responsibility model

Contractors assume their cloud provider’s FedRAMP authorization or SOC 2 report covers them. It does not. AWS, Azure, and GCP are responsible for the security of the cloud. You are responsible for security in the cloud: your configurations, your identity management, your encryption settings. Document your responsibilities explicitly. Your auditor will test them.

2. Generic policies that ignore federal context

Off-the-shelf policy templates fail in two ways. First, they often lack the specificity auditors need to test controls. Second, they ignore federal obligations. Your incident response plan, for example, must address the 72-hour reporting requirement under DFARS 252.204-7012. Your risk assessment must explicitly consider threats related to CUI handling and DIB operations. See our SOC 2 security controls guide for what auditors look for in incident response.

3. Weak evidence collection

Auditors require proof that controls operated over time, not just that policies exist. Common evidence failures:

• Log reviews documented only in emails rather than a ticketing system
• Vulnerability scan reports without remediation tracking
• Access reviews completed but not formally signed off by a manager
• Security training completion records that can’t be filtered by role

Build your evidence library continuously from the start of the observation period. Do not attempt to reconstruct it at audit time. Our SOC 2 evidence request list covers what each control typically requires.

4. Ignoring DFARS incident reporting timelines

DFARS 252.204-7012 requires contractors to report cyber incidents to DoD within 72 hours. Your incident response plan and your SOC 2 evidence must reflect this. Auditors testing CC7.4 will ask to see your IR plan and evidence of tabletop exercises. If the plan is silent on DFARS timelines, that is a gap, both for the audit and for your contract compliance. See our encryption requirements guide for related technical control requirements.

How to Choose an Auditor for Government Work

Not every CPA firm that performs SOC 2 audits has experience in the Defense Industrial Base. Federal contracts add complexity (CUI handling, DFARS obligations, CMMC alignment) that a generalist auditor may not know how to address.

When evaluating firms, focus on three things:

Federal framework fluency: Ask them to explain their approach to controls that satisfy both SOC 2 and NIST SP 800-171. A knowledgeable firm will describe specific evidence requests and explain how they document dual-purpose testing.

DIB client experience: Ask for anonymized examples of government contractor audits they have completed. Ask specifically whether those clients had CMMC obligations and how the firm addressed the overlap.

Integrated audit methodology: Look for a firm whose testing generates evidence that works for both SOC 2 and CMMC. This saves you from running two separate audit programs with two separate evidence libraries.

A useful interview question: “How would you test CC6.1 in a way that also produces evidence for CMMC practice AC.L2-3.1.2?” A strong answer describes specific artifacts (RBAC configuration exports, user access review sign-offs, provisioning/deprovisioning logs) and explains how those artifacts satisfy both frameworks simultaneously.

Browse auditors with federal compliance experience in the SOC 2 auditors for government contractors directory. If your contract names a formal federal credential, use the narrower FedRAMP 3PAO + SOC 2 overlap list or CMMC C3PAO + SOC 2 overlap list before shortlisting. Our directory lists 21 firms that issue SOC 2 and are authorized CMMC C3PAOs, and 17 that issue SOC 2 and appear on the FedRAMP Marketplace list of 3PAOs.

Frequently Asked Questions

Is SOC 2 legally required for government contractors?

SOC 2 is not a direct federal mandate. No regulation requires it by name. But a prime contractor or federal agency can require it as a contractual condition for vendors handling sensitive data. If you work in the DIB, it may reach you as a flow-down requirement. For DoD contracts involving CUI, the requirements come from DFARS 252.204-7012, which calls for NIST SP 800-171 safeguards, and from a CMMC Level 2 self-assessment when the solicitation requires one. DoD suspended third-party CMMC certification requirements in July 2026 while it reviews the program. A SOC 2 report can sit alongside those requirements as independent evidence that your controls operate.

What is the difference between SOC 2 and FedRAMP?

SOC 2 is a voluntary attestation from a CPA firm covering five Trust Services Criteria. FedRAMP is a mandatory federal authorization program for cloud service providers selling to government agencies. SOC 2 evaluates your internal security controls. FedRAMP authorizes a specific cloud product for federal use. Many DIB contractors are asked for SOC 2 for supply chain trust and do not need FedRAMP unless they provide a cloud service directly to federal agencies. Read the full breakdown in our SOC 2 vs. FedRAMP guide.

How long does it take a government contractor to get SOC 2 compliant?

Plan about 3–6 months for SOC 2 Type 1 and 6–12 months or more for a first Type 2, measured from the start of control implementation. With a six-month observation period, the Type 2 report typically arrives about 7–9 months after your controls are running. If you already have NIST 800-171 controls documented for CMMC, preparation goes faster because the shared areas (access control, risk assessment, incident response, system monitoring) are already built. The observation period itself does not get shorter. Our SOC 2 audit timeline guide breaks down each phase.

What are the 5 Trust Services Criteria in SOC 2?

The five Trust Services Criteria are Security (in nearly every SOC 2 report), Availability, Processing Integrity, Confidentiality, and Privacy. Government contractors add Confidentiality when they handle CUI and Availability when the contract carries SLA commitments. Processing Integrity applies if you provide data processing or financial services. Privacy applies if you handle PII. You select the TSCs that reflect your actual contractual commitments.

Can SOC 2 help with CMMC compliance?

Yes. SOC 2 and CMMC Level 2 cover many of the same security areas. Evidence collected for SOC 2 controls in access control, risk assessment, incident response, and system monitoring can be reused to satisfy the corresponding NIST SP 800-171 requirements that underpin CMMC. CMMC then adds prescriptive requirements SOC 2 does not specify, such as FIPS-validated encryption for CUI, CUI media marking, and a System Security Plan. How much carries over depends on how your SOC 2 controls are written, so no single overlap percentage fits every company. A unified compliance program (one control library, one evidence repository) lets you collect the shared evidence once, though each framework still adds its own requirements. The overlap table in the mapping section above shows specific control-to-control relationships.

---

The government contractor auditor directory lists CPA firms whose profiles show government or defense work, or a FedRAMP or CMMC assessor listing. The narrower overlap pages help when you need formal 3PAO or C3PAO authority.