CMMC, MSPs, and GCC High: Getting Your Scoping Decisions Right

The pattern I see repeatedly with federal contractors pursuing CMMC: they treat managed service providers and GCC High migration as procurement decisions, then discover mid-assessment that they've just shaped their entire security boundary. By the time they're sitting across from a C3PAO, the scope is essentially locked. The decisions you made six months ago about email hosting, ticketing systems, and backup platforms now determine whether you're defending 15 systems or 150.

This isn't about vendor selection. It's about understanding how CMMC's assessment boundary rules interact with shared-responsibility models, and why "our MSP handles that" often creates more scope problems than it solves.

The MSP Shared-Responsibility Model Breaks CMMC's Assessment Logic

CMMC borrowed its scoping model from NIST 800-171, which defines boundaries based on where Controlled Unclassified Information (CUI) lives and flows. The assumption baked into that model is that you control your security perimeter. Managed service providers disrupt that assumption completely.

When you engage an MSP for infrastructure, monitoring, or application management, you're creating a shared-responsibility environment. The MSP operates components of your security boundary. They patch systems. They monitor logs. They respond to alerts. They have privileged access to systems that store, process, or transmit CUI.

Here's where contractors get caught: CMMC requires that all systems in scope meet the relevant maturity level controls. If your MSP's infrastructure, tools, or personnel touch CUI or systems that handle it, those components are now part of your assessment boundary. The C3PAO doesn't care that you don't directly operate those systems. They care whether those systems meet CMMC requirements.

The shared-responsibility trap works like this: you assume that because the MSP "owns" the infrastructure, they're responsible for its CMMC compliance. The MSP assumes they provide a secure platform, but compliance against specific frameworks is your responsibility. Nobody realizes the misalignment until the gap analysis reveals that half your scope sits in the MSP's environment, which was never architected to CMMC standards.

What Actually Gets Inherited vs What You Still Own

I've seen too many contractors believe that moving to a managed security service automatically satisfies CMMC controls. It doesn't work that way. Even with a fully managed SIEM, EDR platform, or backup solution, you still own:

• Defining what gets monitored and logged
• Setting alert thresholds and response procedures
• Ensuring logs meet CMMC retention and protection requirements
• Verifying that incident response actually happens within required timeframes
• Maintaining evidence that controls operate effectively

The MSP might provide the tooling and staff to operate these controls, but the responsibility for compliance is non-delegable. A C3PAO will expect to see evidence that you've verified the MSP's implementation meets your requirements. If you can't produce that evidence, the control fails—even if the MSP's platform is technically capable.

GCC High: The Migration That Defines Your Boundary

Microsoft's Government Community Cloud High (GCC High) is positioned as the solution for contractors handling CUI. It's FedRAMP High authorized, includes components that meet NIST 800-171 and CMMC requirements, and theoretically takes a large chunk of your IT infrastructure out of scope for direct assessment. That's the value proposition.

The reality is more nuanced. GCC High does provide a defensible environment for email, collaboration, file storage, and several other Microsoft 365 services. If you're currently managing Exchange servers, SharePoint farms, and file shares on-premises or in commercial cloud environments, migrating to GCC High legitimately reduces your assessment burden. You inherit Microsoft's FedRAMP authorization for those services, which C3PAOs generally accept as meeting baseline requirements.

But GCC High doesn't eliminate scope. It shifts it. You still own identity and access management, conditional access policies, data loss prevention configurations, and audit logging. Those configurations must meet CMMC requirements. If you misconfigure Azure AD, fail to enable MFA correctly, or don't set up logging to capture the right events, the control fails. The C3PAO will test your implementation, not just verify that you purchased GCC High licenses.

What GCC High Actually Covers (And What It Doesn't)

I've worked with contractors who assumed that subscribing to GCC High meant their entire Microsoft ecosystem was compliant. That's not how FedRAMP inheritance works. GCC High's authorization covers Microsoft's operation of the underlying infrastructure and platform services. It doesn't cover:

• Your tenant configuration and security policies
• Third-party applications integrated with your Microsoft environment
• Custom-developed applications hosted in Azure Government
• Hybrid environments where you're synchronizing with on-premises systems
• External MSP tools that connect to your tenant for management or monitoring

The last point is where contractors trip up most often. You migrate to GCC High to reduce scope, then connect a commercial-tier MSP tool for backup, endpoint management, or SIEM aggregation. That connection just pulled part of your CUI environment back out of the protected boundary. The C3PAO will correctly identify that as a scope expansion and expect you to demonstrate how that external system meets CMMC requirements.

The Questions You Should Have Asked Your MSP Before Assessment

Most contractors select MSPs based on cost, feature checklists, and references. Then they discover mid-assessment that the MSP can't produce documentation that maps their services to CMMC controls, operates from a non-compliant environment, or requires you to attest to security measures you can't actually verify.

Before you sign an MSP contract—or at minimum, before you schedule a CMMC assessment—you need specific answers to specific questions. These aren't theoretical. They're the questions C3PAOs will effectively ask during your assessment, and "I'll have to check with our provider" isn't an acceptable answer when you're under audit.

Environment and Infrastructure Questions

Where does the MSP's infrastructure reside? If they're operating from commercial AWS, Azure Commercial, or other non-FedRAMP environments, any CUI that touches their infrastructure creates a compliance gap. You need an MSP operating from FedRAMP-authorized environments (AWS GovCloud, Azure Government, GCC High) or an on-premises infrastructure that you've validated meets requirements.

What access do MSP personnel have to your systems and data? CMMC requires personnel security controls, background checks, and access management for anyone with privileged access to CUI systems. If MSP technicians have admin rights to your environment, you need to verify they meet personnel security requirements and that their access is logged, monitored, and regularly reviewed. Many MSPs operate with shared admin accounts or offshore support teams that can't meet federal background check requirements.

How does the MSP handle role-based access? Generic "admin" access doesn't cut it under CMMC Level 2. You need to see documented evidence of least-privilege access, role separation, and regular access reviews within the MSP's environment and their access to yours. If their support model is "everyone on the team has admin rights," you have a problem.

Documentation and Evidence Questions

Can the MSP provide a System Security Plan (SSP) or equivalent documentation? You're going to need to reference the MSP's security controls in your own SSP. If they can't provide detailed documentation of their security architecture, control implementations, and risk management processes, you're going to struggle to demonstrate that systems they manage meet CMMC requirements. For more on what a proper SSP looks like, see the guide to System Security Plans that hold up under audit.

What evidence can the MSP produce for continuous monitoring and incident response? CMMC requires evidence that controls operate effectively over time. That means logs, monitoring reports, incident records, and response documentation. If the MSP can't provide regular evidence packages, you have no way to demonstrate continuous compliance. This is especially critical if you're planning to use POA&Ms for any controls the MSP operates—you'll need ongoing evidence of remediation progress.

How does the MSP handle configuration management and change control? CMMC requires baseline configurations, change documentation, and security impact analysis for system modifications. If your MSP operates with ad-hoc change processes or can't provide change logs, you're missing evidence for multiple controls. And if they push updates or configuration changes without your approval or documentation, you've lost control of your security boundary.

Boundary and Scope Questions

What other clients or systems share infrastructure with your environment? Multi-tenant MSP environments create complex scope questions. If the MSP operates shared infrastructure, you need to understand how tenant isolation works, whether CUI environments are logically or physically separated from other clients, and how the MSP prevents cross-tenant data exposure. Some C3PAOs will require dedicated infrastructure for CUI environments; at minimum, you need documented evidence of effective isolation controls.

What external services does the MSP use that connect to your environment? MSPs typically use multiple third-party tools for monitoring, ticketing, backup, and management. Each external connection is a potential scope expansion. You need an inventory of every external service that touches your CUI environment and documentation of how each meets security requirements. If the MSP's backup solution stores your data in a commercial cloud region, you have a CUI boundary violation.

The CMMC and Managed Service Provider Scoping Decision Tree

The decision about how to handle MSPs in your CMMC scope isn't binary. You have options, but each carries specific implications for cost, timeline, and assessment complexity. I've seen contractors successfully navigate this with several different approaches, but only when they made intentional decisions early.

Option 1: Full In-Scope Integration. You treat the MSP's environment and services as part of your assessment boundary. The C3PAO evaluates controls within the MSP's infrastructure the same way they evaluate your internal systems. This works when the MSP operates from a compliant environment, provides full documentation, and agrees to participate in assessment activities. It typically requires that the MSP has prior CMMC experience and has structured their services to support client assessments. The advantage is clean scope definition. The disadvantage is that MSP assessment participation often comes with significant cost.

Option 2: FedRAMP Inheritance Model. You select an MSP that operates from a FedRAMP High (or comparable) authorized environment and structure your services so you're only using components covered by their authorization. This is the GCC High model: inherit infrastructure controls from the FedRAMP authorization, demonstrate your configuration and use of those services meets requirements. This works well for commodity services like email and file storage. It falls apart when you need custom configurations or integration with non-FedRAMP services. The key is understanding exactly which controls you inherit vs. which you still own.

Option 3: Out-of-Scope Boundary. You architect your environment so the MSP only manages systems that don't store, process, or transmit CUI. They handle your commercial IT, your public website, your marketing systems—anything outside the CUI boundary. All CUI systems remain fully under your control within a separate, bounded environment. This is the cleanest scope approach, but it requires discipline. You need strict network segmentation, clear data handling procedures, and controls to prevent CUI from leaking into MSP-managed systems. It's also the most expensive from an operational standpoint, since you're essentially running two parallel IT environments.

Option 4: Hybrid with Documented Interfaces. You use the MSP for specific functions with carefully controlled interfaces to your CUI environment. For example, the MSP manages a logging aggregation platform that receives log data from CUI systems but doesn't have direct access to those systems. Or they provide monitoring services through read-only access that's tightly scoped and logged. This model requires precise documentation of every connection point, data flow, and access path. It's complex from a documentation standpoint but can be cost-effective if implemented properly.

The Real Cost Drivers Most Contractors Miss

When contractors evaluate MSP costs for CMMC, they typically focus on service fees. The real cost drivers are elsewhere. Here's what actually drives expense:

Assessment preparation and documentation. Whether the MSP is in-scope or you're documenting interfaces and inheritance, you need comprehensive documentation packages. Most MSPs don't provide this as part of standard service agreements. Expect to pay for custom documentation, artifact generation, and evidence collection specifically structured for your CMMC assessment. For context on realistic cost and timeline expectations, see the breakdown of what CMMC compliance actually costs.

Configuration changes to meet specific controls. Your MSP's standard service delivery model probably doesn't meet all CMMC Level 2 requirements. You'll need custom logging, enhanced monitoring, modified access controls, and potentially infrastructure changes. These aren't included in base service pricing and often require escalation to engineering teams or specialized security staff. Get a statement of work that explicitly addresses CMMC requirements before you're locked in.

Ongoing evidence generation and validation. CMMC isn't a point-in-time certification. You need continuous evidence that controls remain effective. If your MSP provides quarterly reports but CMMC requires evidence of monthly monitoring reviews, you're either paying for custom reporting or manually generating evidence from raw logs. Factor this into your recurring costs, not just your initial assessment budget.

When GCC High Creates More Problems Than It Solves

I'm going to take a position that Microsoft partners don't like: GCC High migration isn't always the right answer for CMMC, and I've seen it create expensive scope expansion for contractors who pursued it without understanding their actual architecture.

GCC High makes sense for contractors whose CUI workload is primarily email, file collaboration, and standard Microsoft 365 applications. If you're a services firm doing engineering work for DoD and your primary CUI handling is document exchange and project collaboration, GCC High legitimately simplifies your environment.

It makes less sense when you have significant on-premises infrastructure, custom applications, or hybrid architectures. Here's why: GCC High migration requires moving your entire identity infrastructure, typically through Azure AD Connect or equivalent synchronization. Once you start syncing on-premises Active Directory with GCC High, you've created a hybrid environment. That hybrid architecture now includes connection points, synchronization infrastructure, and identity management systems that span both environments. The C3PAO will evaluate all of it.

I've worked with contractors who spent six months and significant budget migrating to GCC High, then discovered during assessment preparation that their hybrid architecture actually expanded their scope compared to their previous on-premises environment. The synchronization servers, the VPN concentrators for hybrid connectivity, the certificate authorities, the multi-factor authentication infrastructure—all of it came into scope because it supports the hybrid environment that handles CUI.

The GCC High Break-Even Calculation Nobody Does

Before you commit to GCC High migration, do this calculation: map every system currently in your CUI boundary, then map what your boundary looks like post-migration including all hybrid components. Count systems, not just licenses. Include:

• All synchronization and integration infrastructure
• VPN and network connectivity for hybrid access
• On-premises systems that will remain because they can't migrate (legacy applications, specialized engineering tools, manufacturing systems)
• Third-party applications that integrate with Microsoft 365 that may not support GCC High
• Monitoring and security tools that need to span both environments

If your post-migration boundary is larger or more complex than your current state, GCC High isn't simplifying your assessment—it's adding cost and complexity. This isn't a theoretical concern. I've reviewed assessments where the GCC High migration added 20+ systems to scope through hybrid architecture requirements.

The alternative that contractors often overlook: keep your on-premises environment, architect it properly for CMMC, and use GCC High only for components that genuinely benefit from cloud migration. You don't have to be all-in on Microsoft's cloud to satisfy CMMC. A well-architected on-premises environment with proper segmentation, access controls, and monitoring can be simpler and cheaper to assess than a hybrid architecture that tries to do everything in the cloud.

The MSP Contract Clauses That Actually Matter for CMMC

Standard MSP contracts aren't written with CMMC in mind. Most focus on uptime, response times, and generic security commitments. You need specific language that addresses assessment, evidence, and compliance responsibilities. These clauses should be negotiated before contract signature, not after you're already dependent on the MSP's infrastructure.

Right to audit and assessment participation. Your contract should explicitly grant you (and your C3PAO) the right to audit the MSP's relevant controls and review documentation. This isn't about financial audits—it's about technical security validation. The MSP should commit to participating in assessment activities, responding to C3PAO inquiries, and providing evidence packages on defined timelines. Without this language, you're dependent on the MSP's goodwill when assessment deadlines hit.

Specific security control commitments. Don't accept generic "industry-standard security" language. Your contract should reference NIST 800-171 or CMMC explicitly and include schedules or appendices that map MSP services to specific control families. The MSP should commit to maintaining controls at the required maturity level for the duration of the contract. If they can't commit to specific controls, they're not ready to support your CMMC assessment.

Evidence generation and delivery requirements. Define what evidence the MSP will provide, in what format, and on what schedule. This should include log exports, configuration baselines, change records, incident reports, vulnerability scan results, and any other artifacts you'll need for assessment or continuous monitoring. Specify data formats and retention periods. "We'll work with you on evidence" isn't enforceable when you're three weeks from assessment and need specific artifacts.

Incident response and breach notification. CMMC requires incident response capabilities and specific timelines for reporting. Your MSP contract should define what constitutes an incident affecting your environment, notification timelines, and the MSP's role in containment and remediation. If a security event occurs in the MSP's infrastructure that impacts your CUI, you need to know immediately, not when they get around to mentioning it in a quarterly report.

Exit rights and data portability. If the MSP can't support your CMMC requirements, or if they lose their own compliance status, you need the right to terminate and migrate without penalty. Include explicit data extraction rights, format requirements, and transition support commitments. I've seen contractors locked into non-compliant MSP arrangements because the exit costs and data migration complexity made it cheaper to fail assessment and remediate than to switch providers.

What Good Looks Like: The MSP-CMMC Integration Pattern That Works

After working with contractors through multiple assessments involving managed service providers, I've seen a pattern that consistently works. It's not the cheapest option, and it's not the fastest to implement, but it's the approach that gets through C3PAO assessments without significant findings related to MSP scope.

First, the contractor maintains a small, bounded CUI environment under direct control. This includes identity management, core security infrastructure, and any systems that absolutely must handle CUI. This environment is typically on-premises or in a FedRAMP High cloud enclave. It's architected specifically for CMMC from the ground up: proper segmentation, comprehensive logging, centralized authentication, documented baselines. It's not large—often 10-30 systems depending on the organization—but it's clean.

Second, the MSP manages peripheral infrastructure and provides specific security services into the CUI environment. They handle the broader corporate IT, run the SOC, operate the vulnerability management program, manage endpoint protection deployment. But their access to the CUI environment itself is limited to defined interfaces: they receive logs through one-way data flows, they have read-only access for monitoring, they execute approved changes through a documented change control process. The contractor maintains control of the CUI boundary; the MSP provides depth of security expertise and operational capacity around that boundary.

Third, there's comprehensive interface documentation. Every connection between the MSP-managed environment and the CUI environment is documented: network diagrams, data flow diagrams, access paths, authentication mechanisms. The C3PAO can see exactly where the boundary is, what crosses it, and how it's protected. This documentation becomes part of the System Security Plan and is maintained as a living document, not a point-in-time deliverable. When I review contractor SSPs, I can immediately tell whether they've thought through MSP integration by looking at the network architecture and data flow sections—either it's comprehensive with clear boundaries, or it's vague and hand-wavy. The former passes assessment; the latter generates findings.

Fourth, the MSP operates from a compliant environment for any shared infrastructure. If the MSP provides services that multiple clients use (backup, SIEM, ticketing), that infrastructure is either FedRAMP authorized or the contractor has validated it meets CMMC requirements through direct audit. There's no assumption that "the MSP is secure"—there's documentation proving it.

This model requires more upfront planning than just signing an MSP contract and assuming they'll figure out CMMC requirements. But it creates a defensible scope, supports evidence generation, and most importantly, gives you actual control over your compliance posture rather than dependence on the MSP's capability and willingness to support your assessment.

The Strategic Decision: Control vs. Convenience

The fundamental tension in CMMC scoping with managed service providers is between operational convenience and compliance control. MSPs offer the convenience of outsourced management, specialized expertise, and often better security tooling than you could deploy internally. But that convenience comes at the cost of direct control over your compliance evidence, scope boundaries, and assessment process.

This tension isn't unique to CMMC—it exists across every regulatory compliance program I've worked with. But CMMC makes it more acute because the assessment model is prescriptive, the C3PAOs don't have flexibility to accept alternative implementations, and the stakes are your ability to bid on and maintain DoD contracts.

The contractors who navigate this successfully make intentional choices about where they need control and where they can accept dependence. Core CUI handling, identity management, and access control—these typically stay under direct control because they're fundamental to demonstrating compliance. Security monitoring, vulnerability management, and incident response—these often move to MSPs because the expertise and tooling requirements make internal operation expensive or impractical for mid-sized contractors.

But the decision has to be made consciously, with full understanding of the assessment implications. "Our MSP handles that" can't be the answer to C3PAO questions about security controls. Either you've documented how the MSP's implementation meets requirements and maintained evidence of its effectiveness, or you haven't outsourced the function—you've just created a compliance gap with vendor letterhead on it.

For broader context on how self-assessment compares to third-party assessment and what level of rigor C3PAOs actually apply, see the comparison of CMMC self-assessment versus third-party assessment processes.

The Questions Your Leadership Should Be Asking Now

If you're a federal contractor heading toward CMMC assessment with MSP relationships or considering GCC High migration, these are the questions your leadership team should be asking your IT and compliance staff today, not three months before your assessment date:

Can we produce a current, accurate diagram showing every system in our CUI boundary and every connection to MSP-managed infrastructure? If the answer is no or if there's hesitation, your scope isn't defined well enough to start assessment planning. The time to discover scope ambiguity is now, not during the C3PAO's initial scoping workshop.

For every MSP service we use, can we document which specific CMMC controls that service addresses and what evidence the MSP will provide? This should be a written mapping, not a verbal assurance from your account manager. If you're paying for managed security services but can't articulate what controls they satisfy, you're not getting compliance value from that spend.

If our primary MSP notified us tomorrow that they can no longer support CMMC requirements, how long would it take us to migrate to an alternative? This is a business continuity question as much as a compliance question. MSP dependencies can create single points of failure for your ability to maintain certification. Understanding your migration timeline and alternative options is risk management.

What percentage of our IT budget is going toward CMMC-specific requirements vs. general security improvement? This matters because CMMC compliance has ongoing costs: evidence generation, assessment preparation, continuous monitoring, MSP premium services for compliance support. If you haven't budgeted for sustained compliance operations, your initial assessment success won't be maintainable. CMMC isn't a project—it's a program that needs sustained funding and attention.

For more on building realistic CMMC budgets and understanding what sustained compliance actually costs, the CMMC compliance article series covers both tactical implementation and strategic program development.

The contractors who succeed with CMMC treat it as a strategic infrastructure decision, not a checkbox compliance exercise. They make intentional choices about MSP integration, understand the scope implications of those choices, and maintain direct control over the elements that matter most for demonstrating compliance. The ones who struggle treat MSPs and cloud platforms as black boxes, assume vendor assurances are equivalent to documented evidence, and only confront scope complexity when the C3PAO starts asking detailed questions.

Which pattern you follow will determine whether your CMMC assessment is a manageable validation of your security posture or a painful discovery process that reveals how little control you actually have over your own infrastructure.