CMMC Control Inheritance: What You Can Inherit, What You Still Own, and How to Prove It

What we actually verified for this page

We don’t ask you to take our word for it. Here’s what we read directly, and when.

• The ESP definition and the CUI/Security Protection Data threshold — read in 32 CFR § 170.4 on July 1, 2026.
• The requirement to document the ESP relationship and CRM in your SSP — 32 CFR § 170.19(c)(2) for Level 2 (the Level 3 parallel sits in § 170.19(d)(2)).
• The inheritance rule and the findings model — the CMMC Assessment Guide – Level 2, Version 2.13 and 32 CFR § 170.24 (MET / NOT MET / NOT APPLICABLE).
• The six-year evidence-retention rule — codified in 32 CFR § 170.17.
• The FedRAMP Moderate bar for cloud providers — DFARS 252.204-7012 and the December 21, 2023 DoD CIO FedRAMP equivalency memorandum.
• Phase 1 and Phase 2 timing — the 48 CFR DFARS acquisition rule (90 FR 43560, effective November 10, 2025) and the DoD CIO CMMC site.
• The AWS inheritance breakdown cited below — AWS’s own Prescriptive Guidance for CMMC Level 2, labeled as an AWS-specific example, not a universal rule.

Regulatory facts on this page are dated because phases and rules change. If you’re reading this well after July 2026, re-check the primary sources linked throughout and at the bottom.

What is CMMC control inheritance?

CMMC control inheritance is the documented use of another party’s implemented security responsibility as part of your own CMMC environment. It doesn’t transfer your overall compliance accountability — it only changes who performs and proves specific responsibilities. Per the CMMC Assessment Guide – Level 2, an inherited objective is met only when you provide adequate evidence that the other entity performs it and that it applies to your in-scope assets.

Let’s ground that in the actual rule, because this is where the whole topic lives or dies. The CMMC Assessment Guide – Level 2 (Version 2.13)says a contractor can inherit requirement objectives, and it sets the standard plainly: a requirement is met when adequate evidence shows that the enterprise or another entity — such as an External Service Provider (ESP), which can include cloud service providers, managed service providers, and managed security service providers — implements the objective. The key phrase is “adequate evidence.” The outcome bar doesn’t move. The source of the proof does.

Read that last part twice. Inheritance is not a discount on the outcome. It’s a different source of proof for the same outcome.

You inherit objectives — not controls, and not certifications

Here’s the nuance almost every competing page glosses over. CMMC Level 2 is built on the 110 security requirements in NIST SP 800-171 Revision 2, organized into 14 control families. But those 110 requirements break down into 320 assessment objectives in NIST SP 800-171A — the smaller “determination statements” an assessor actually checks. Inheritance happens at the objective level, not at the control or family level.

That means a single NIST requirement can split three ways: some objectives inherited from your cloud provider, some shared with your MSP, and some entirely yours. A provider being certified, or a cloud being FedRAMP authorized, gives you evidence you can point to for specific objectives. It never gives you a certification you can wear. You still get assessed. You still get certified as you.

Inherited vs. shared vs. customer-owned — the distinction that saves assessments

The whole game is knowing which bucket each objective falls into for your environment — and being able to hand an assessor the paper trail for each one.

Why CMMC control inheritance matters right now

CMMC stopped being a future problem.The 48 CFR DFARS acquisition rule took effect November 10, 2025, opening Phase 1 (November 10, 2025 through November 9, 2026), which centers on Level 1 and Level 2 self-assessments. Phase 2 begins November 10, 2026, when DoD intends to include Level 2 certification-assessment requirements — the kind performed by a Certified Third-Party Assessment Organization (C3PAO) — in applicable solicitations and contracts. Inheritance claims made without a CRM and evidence package won’t survive a C3PAO assessment. Here’s the timeline, dated to the primary sources we checked:

Sources: 32 CFR Part 170; DFARS final rule, 90 FR 43560 (effective Nov. 10, 2025); DoD CIO CMMC site.

The temptation, when a prime flows a clause down or a solicitation lands with a CMMC requirement, is to buy your way out — grab a compliant cloud, sign an MSP, and assume the controls come with it. That instinct is exactly what this page exists to check. The right CMMC provider isn’t the same for every contractor — the category you need depends on your required CMMC level, whether you handle FCI or CUI, your assessment type, your cloud and IT environment, and your contract timeline. The contract clause sets your level, not a checklist.

Disclosure: The Defense Compliance Report is an independent trade publication on CMMC 2.0 and DIB compliance. We may receive compensation for qualified introductions, sponsorships, or partner referrals when disclosed. Compensation does not control our regulatory analysis, provider-category recommendations, or Cyber AB status verification.

Does FedRAMP authorization or your provider’s certification satisfy your controls?

No. A cloud provider’s FedRAMP authorization and an ESP’s own CMMC status can supply evidence for specific inherited objectives — but neither one certifies you, and neither one is automatic. Inheritance is determined by where your assessment boundary sits, and it requires your CRM and SSP to document the split. When your assessor arrives, they assess your environment, not your provider’s.

FedRAMP (the Federal Risk and Authorization Management Program) authorizes a cloud service at a specific impact level for a specific system boundary. That authorization covers the provider’s slice of the stack — the physical data center, the hypervisor, the core infrastructure. It does not cover how youconfigured your tenant, provisioned your users, set your access policies, or produced your evidence. “The cloud is FedRAMP” answers a question about the provider. Your assessment answers a question about you.

FedRAMP Authorized vs. FedRAMP Moderate Equivalent — know which one you have

For Level 2, if a cloud service processes, stores, or transmits your CUI, DFARS 252.204-7012 requires you to require and ensure that the provider meets security requirements equivalent to the FedRAMP Moderate baseline. The CMMC Program Rule (32 CFR Part 170) is where the “authorized orequivalent” framing comes from: a Level 2 CSP handling CUI must be FedRAMP Moderate (or higher) authorized, or meet FedRAMP Moderate equivalency. Those two paths are not the same, and confusing them creates real risk.

Sources: DoD CIO FedRAMP equivalency memorandum (Dec. 21, 2023); DFARS 252.204-7012; 32 CFR Part 170.

Two things worth sitting with. First, the equivalency bar is arguably stricter than a standard FedRAMP authorization, because equivalency allows no open control POA&Ms. Second, the equivalency burden lands on you, the contractor — you have to obtain, review, and be ready to hand over the provider’s Body of Evidence. That’s a very different day than pointing at a Marketplace listing.

A couple of real-world markers, sourced carefully:

• Company-stated example: PreVeil, an end-to-end encrypted email and file-sharing provider, states it achieved DoD FedRAMP Moderate Equivalency and cites a public comment by The Cyber AB’s CEO at the 2025 CMMC Summit. The Defense Compliance Report has not independently confirmed a current DIBCAC determination for this page — verify any provider’s current status and evidence directly before you rely on it.
• Verify on the Marketplace: Microsoft’s GCC High is listed on the FedRAMP Marketplace at the High impact level, which exceeds the Moderate bar. As with any provider, confirm the current listing yourself before relying on it. See our GCC High for CMMC guide.

The “fully inherited controls” pitch

You will hear vendors say their enclave delivers “fully inherited controls.” Treat that phrase as a prompt to ask for the CRM, not as a conclusion. FedRAMP authorization applies to one system boundary — not to everything a provider builds on top of it. When a managed provider stands up an enclave on a FedRAMP-authorized cloud, they introduce new configurations, access controls, and monitoring that the underlying cloud’s authorization does not cover. That new layer has to be documented and evidenced on its own. “Fully inherited” almost never survives contact with an assessor.

What can you inherit from each provider type?

What you can inherit depends entirely on the provider type and the role it plays. A FedRAMP-authorized CSP typically covers infrastructure-layer physical and platform controls. A non-CSP MSP or MSSP can cover the services it operates — logging, patching, monitoring — where you can evidence it. A GRC platform, by itself, is a documentation aid, not an inheritance source. A prime’s virtual desktop can take your access endpoint out of scope under narrow conditions. The matrix below maps each, with what stays yours and what to request before you rely on it.

Sources: 32 CFR §§ 170.4, 170.19 (eCFR); DFARS 252.204-7012; CMMC Scoping Guide L2 (DoD CIO); DoD CIO FedRAMP equivalency memo (Dec. 21, 2023).

A source-checked example: what AWS says you can inherit

Numbers make this concrete. In AWS’s own published Prescriptive Guidance for CMMC Level 2, AWS states that for its Landing Zone Accelerator reference architecture, 21 of the 110 requirements are fully inheritable, 79 are partially inheritable, and 10 are customer-only. The 21 fully inheritable ones break down as all 6 Physical Protection (PE) practices, 8 of the 9 Media Protection (MP) practices, 5 Maintenance (MA) practices, and 2 Access Control (AC) practices — documented in your SSP with the AWS CMMC Customer Package (from AWS Artifact) as evidence.

Notice what that tells you. Even in a well-architected cloud, 79 requirements are only partially inheritable and 10 are entirely yours.Treat that “21 / 79 / 10” as an AWS-specific example, not a universal law — your real split depends on your architecture, your CRM, your data flow, and your configuration. But it’s a useful reality check against any pitch that implies the cloud does most of the work.

The one honest caveat we’ll give you plainly

Here’s the part vendors don’t lead with: inheritance almost always covers less than it sounds like it will, and it never reduces your accountability. Even in a best-case stack — a FedRAMP-authorized government cloud tenant plus an MSSP that holds a valid, relevant CMMC Level 2 Certificate of CMMC Status for the services you intend to rely on — a large share of the 320 assessment objectives stay fully or partly yours, and “our provider handles it” without a CRM is a direct path to a NOT MET finding.

That’s not a reason to avoid inheritance. Used well, it genuinely lowers what you have to build and operate. It’s the reason to map it precisely, in writing, before you build your SSP or pay for anything.The contractors who breeze through assessments aren’t the ones with the longest logo list on their architecture diagram — they’re the ones who can say, for every objective, who owns it, who operates it, and where the evidence lives.

Can an MSP or MSSP provide inherited CMMC controls?

Yes — but only where the MSP or MSSP’s responsibility is documented in a CRM, supported by evidence, and inside your assessment scope when it processes, stores, or transmits your CUI or Security Protection Data. A managed provider can perform real security work you rely on; it cannot make you compliant, and “our MSP handles CMMC” is not, by itself, evidence of anything.

Three things decide whether that reliance actually helps you at assessment time:

• Is it in scope? Under 32 CFR § 170.4, a provider is an ESP for CMMC purposes when your CUI or Security Protection Data live on its assets. When that’s true, § 170.19(c)(2) requires the relationship, the services, and the CRM to be documented in your SSP, and the ESP’s services are assessed as part of your assessment.
• Can you prove it? The assessor evaluates the ESP’s CRM and uses the examine, interview, and test methods to confirm the objective is actually met in your environment. A provider performing a function is only half the story; the other half is the evidence — configurations, logs, tickets, access reviews — and your staff being able to speak to how it works.
• Does a provider certificate help? It can. The CMMC Assessment Process (CAP) v2.0 allows an assessment team to accept a lower level of effort for a non-CSP ESP that has voluntarily earned a Level 2 or Level 3 Certificate of CMMC Status — but you still have to ensure the inherited requirements are maintained in your environment and be ready to show it. A provider’s certificate reduces friction; it does not close your file.

The failure mode is always the same: a strong MSP relationship with no CRM, no service description, and no committed evidence support. If your provider can’t tell you which of the 320 objectives it implements, which it shares with you, and which are entirely yours — and can’t commit to supporting your assessment — you’re carrying risk you probably don’t know about.

Which CMMC controls can’t be inherited?

Some objectives can’t realistically be inherited as complete outcomes — they depend on your people, your risk decisions, your policies, and your records. Governance and human-driven families — Awareness and Training, Personnel Security, Risk Assessment and risk acceptance, and Security Assessment (your SSP and POA&M ownership) — stay with you no matter how strong your provider stack is. There is no universal “inherited controls list”; inheritance depends on your boundary, service model, CRM, data flow, and configuration.

The table below is a starting map of where inheritance is realistic across the 14 NIST SP 800-171 Rev. 2 families. The high/partial/low ratings are our editorial read of common environments — confirm every objective against your own CRM.

Source: Editorial application of NIST SP 800-171 Rev. 2 family structure; 32 CFR Part 170; CMMC Assessment Guide L2 v2.13. Confirm every objective against your own CRM.

The principle underneath all of it: you can inherit a mechanism, but you cannot inherit a decision. Nobody can accept your risk for you, own your policies for you, run your training for you, or prove your maturity for you. Even the strongest vendor stack still leaves CMMC evaluating your organization.

What documents prove inherited CMMC controls?

Inherited controls are proved with a traceable paper trail, not a vendor’s word. At minimum, expect: SSP references, a Customer Responsibility Matrix, provider service descriptions, FedRAMP authorization or equivalency evidence where applicable, and objective evidence showing your customer-side responsibilities are actually implemented. Under 32 CFR § 170.19(c)(2), the ESP relationship and services must be documented in your SSP and described in the ESP’s service description and CRM.

Your minimum evidence stack

Source: 32 CFR § 170.19(c)(2); CMMC Assessment Guide L2 v2.13; editorial application of assessment evidence requirements.

SSP language that holds up (a template you can copy)

For each inherited or shared objective, write it so an assessor can trace it end to end. A defensible pattern looks like this:

For requirement [NIST SP 800-171 requirement ID], [Provider] performs [specific responsibility] within [service boundary]. [Your organization] remains responsible for [customer-owned responsibility]. The inherited/shared responsibility is documented in [CRM section/table], supported by [evidence artifact], and reflected in the network diagram and asset inventory.

What NOT to write in your SSP

These are the phrases that get controls marked NOT MET. If your SSP reads like this, fix it before an assessor sees it:

• ✗"Handled by our MSP."
• ✗"Inherited from Microsoft."
• ✗"Covered by FedRAMP."
• ✗"In the enclave."
• ✗"Not applicable because cloud."

Every one of those skips the requirement ID, the specific responsibility, your remaining responsibility, the evidence, and the boundary. A good narrative names all five.

CRM vs. SRM — they’re related, not identical

You’ll see two terms. A Shared Responsibility Matrix (SRM) is the big-picture strategy — how responsibilities split between you and your providers, often published or shared as a framework. A Customer Responsibility Matrix (CRM) is the contract-specific, per-objective document from your provider that says exactly who owns what. For CMMC documentation, lean on the rule-aligned term — CRM— and remember the point of both is the same: traceability of provider responsibility, customer responsibility, evidence, and boundary.

“My MSP or cloud provider won’t give me a CRM”

This is the friction point that quietly sinks readiness timelines. If a provider performs a responsibility but won’t give you a CRM, a service description, evidence exports, or assessment support, that provider is a bottleneck, not a shortcut— and the responsibility reverts to unproven. Missing documentation is itself a compliance risk. Your options: press for the CRM (and put it in the contract), change your architecture, or replace the provider before you rely on them in an assessment. Don’t discover this the week before your C3PAO shows up.

How much detail do inherited controls need in the SSP?

Enough for an assessor to trace each inherited or shared responsibility to a provider boundary, a CRM entry, your remaining responsibility, and an evidence artifact. A short reference is fine only when the linked CRM and evidence are specific enough to fully support the requirement. When in doubt, more detail — especially for services that touch CUI or Security Protection Data.

Use this quick self-test on every inherited or shared objective. If you can’t answer all seven, you’re not ready:

1. Which CMMC/NIST requirement is affected?
2. Which provider performs which part?
3. What do you still own?
4. Where is the CRM reference?
5. What objective evidence proves it?
6. Is CUI or Security Protection Data involved?
7. Will the provider support assessor evidence requests?

Source: Editorial application of 32 CFR §§ 170.19, 170.24; CMMC Assessment Guide L2 v2.13.

How do C3PAO and DIBCAC assessors evaluate inherited controls?

An assessor never accepts “inherited” as a conclusion. Using the three CMMC assessment methods — examine, interview, and test — they trace scope, responsibility, implementation, and evidence through your SSP, CRM, service descriptions, and artifacts. All three methods are aimed at you, not at your cloud provider or MSP. An inherited objective is marked MET only with adequate evidence that the entity performs it and that it applies to your in-scope assets; inadequate evidence yields NOT MET.

How objective-level findings roll up

Every one of the 110 requirements gets a finding of MET, NOT MET, or NOT APPLICABLE (defined in 32 CFR § 170.24). For a requirement to score MET, every applicable objective within it must be MET or NOT APPLICABLE— and an objective assessed as N/A counts the same as MET for scoring. One unproven inherited objective can drag an otherwise-solid requirement into NOT MET, and for a Final Level 2 (C3PAO) status, all 110 requirements must land at MET or N/A. That’s why the CRM’s objective-by-objective granularity matters so much: it maps to how the finding is actually calculated.

If a requirement comes back NOT MET, 32 CFR § 170.17(c)(2)allows re-evaluation during the active assessment and for 10 business days after it — but only if you already have additional evidence, it doesn’t weaken an already-MET requirement, and the findings report hasn’t been delivered. It is not a window to go build something you never had.

When the assessor evaluates your provider

Even with a strong CRM in place, the assessment team evaluates the ESP’s CRM and can require ESP participation and evidence during the assessment to confirm the objective is met in yourenvironment. “Our MSSP monitors logs” isn’t the finish line. The assessor wants to see the configuration, the review cadence, the records, and — often — hear your own staff explain the process. Structure your provider contracts so the ESP is available and willing to provide evidence; if a contract prohibits sharing evidence with assessors, you have a problem to solve before assessment day.

If you have a gap: temporary deficiency, enduring exception, and POA&M

The rule builds in some flexibility, and it’s worth knowing. A temporary deficiency (defined in 32 CFR § 170.4) is a condition where a fix is known and in process, documented in an operational plan of action — it arises after implementation, not as a stand-in for never having implemented something. An enduring exception covers a situation that can’t be fully remediated and must be documented in your SSP. And for Levels 2 and 3, a conditional CMMC status may be available for up to 180 days to close out remaining POA&M items; you earn Final status only if the POA&M is successfully closed, and if it isn’t closed within 180 days, the conditional status expires (32 CFR § 170.17). None of these let you skip proving what you claim to inherit — they govern how a gap is handled, not how inheritance is evidenced.

Does GCC High, AWS GovCloud, or a CUI enclave make you CMMC compliant?

No platform makes you compliant by itself. GCC High, AWS GovCloud, and CUI enclaves can reduce or clarify your scope and give you strong inheritance evidence — but you still own configuration duties, customer-side objectives, evidence, and the scope decisions. A compliant platform supports a CMMC strategy; it is not the same thing as a compliant contractor.

We already showed the AWS numbers: 21 fully inheritable, 79 partially inheritable, 10 customer-only in AWS’s published Level 2 reference architecture — an AWS-specific example, not a universal rule. The lesson generalizes: a compliant cloud can carry a meaningful share of the technical load, but the provider will tell you (as Microsoft and AWS both do) that you must still determine and document what you’re responsible for. Treat any “X of 110 inherited” figure as a starting hypothesis to confirm against the provider’s actual CRM, not a number to put in your SSP on faith.

Enclaves deserve one extra note, and the rule is precise here. The clear out-of-scope fact pattern in 32 CFR § 170.19is narrow: an endpoint hosting a virtual desktop (VDI) client configured so that it allows no processing, storage, or transmission of CUI beyond the keyboard, video, and mouse signals sent to the VDI client is considered out of scope. That’s a specific design — not a blanket “the enclave keeps us out of scope.” For any other enclave endpoint design, validate the actual data flow and endpoint behavior. The moment CUI lands on a workstation outside the enclave, that endpoint is back in scope. The assessor follows the data, not the diagram’s label.

What mistakes cause inherited controls to fail?

Inherited controls fail when a contractor treats inheritance as a vendor claim instead of an evidence chain. The most common failures: missing CRM detail, misclassifying the provider, unclear CUI flow, unmanaged customer-owned responsibilities, and no provider support during the assessment.

Source: Editorial analysis of 32 CFR Part 170; CMMC Assessment Guide L2 v2.13; DFARS 252.204-7012.

What should you ask before relying on inherited controls?

Ask for documents and commitments, not assurances. The right questions reveal whether a provider can actually support your SSP, CRM, evidence package, and assessment — before you’re depending on them. Keep this list; it doubles as your evidence-request checklist.

Put these to any provider whose controls you plan to lean on:

1. For this engagement, are you a CSP, ESP, MSP/MSSP, enclave provider, GRC platform, RPO, or C3PAO?
2. Will you process, store, or transmit our CUI?
3. Will you process our Security Protection Data (logs, configurations, security telemetry)?
4. Can you provide a Customer Responsibility Matrix?
5. Can you provide a service description mapped to CMMC responsibilities?
6. If you’re a CSP: what’s your FedRAMP authorization or equivalency basis, and can we see the Body of Evidence?
7. Will you support evidence requests during readiness and during a C3PAO or DIBCAC assessment?
8. Which responsibilities remain customer-owned?
9. What evidence can we export and retain?
10. Do your terms allow sharing evidence with assessors?
11. Do you keep implementation and assessment roles separate to avoid a conflict of interest?

Do not submit CUI, drawings, technical data, export-controlled information, contract-sensitive details, credentials, or security artifacts through any web form— ours or a provider’s intake form. Use general descriptions only.

How to build your control inheritance map before requesting quotes

Start with your data flow, not vendor names. A useful map identifies where FCI, CUI, and Security Protection Data live; which provider touches each layer; which objectives are inherited, shared, or customer-owned; and what evidence you still need. Build that first, and every provider conversation gets sharper — and cheaper.

The seven steps:

1. Determine whether the contract involves FCI, CUI, or both.
2. Identify the required CMMC level and assessment type from the contract clause.
3. Map every system that processes, stores, or transmits FCI/CUI.
4. Map every provider that touches CUI or Security Protection Data.
5. Classify each provider — CSP, ESP, MSP/MSSP, enclave, GRC, readiness, or assessment.
6. Request the CRM, service description, and FedRAMP or equivalency evidence where applicable.
7. Mark each requirement as inherited, shared, customer-owned, or unresolved.

That last column — “unresolved” — is the one that tells you exactly what to buy and who to hire. This is the logic behind The CMMC Path Framework: it maps your required level, your FCI vs. CUI handling, your assessment type, your IT/cloud environment, and your contract timeline to the provider categoryyou need. It routes to a category, not a named provider, and it’s not a score, a ranking, or compliance advice.

Which provider category do you need if control inheritance is your problem?

The right category depends on the gap. Documentation gaps point to an RPO/RP or readiness consultant. Operational gaps point to an MSP/MSSP. Boundary problems point to a CUI enclave or CSP architecture. Scattered evidence points to a GRC platform as a supporting layer. Formal certification points to a C3PAO — but only once you’re assessment-ready, and never as your remediation provider for the same engagement.

Source: Editorial analysis of 32 CFR Part 170; CMMC Assessment Process (CAP) v2.0 (The Cyber AB).

One boundary worth stating clearly, because it’s a real rule, not a preference: your readiness/remediation help and your formal assessment must stay conflict-clean. The CMMC Assessment Process (CAP) v2.0requires C3PAOs to manage impartiality and conflicts of interest, and it prohibits assessment personnel from giving implementation advice that would conflict them from resuming the same assessment. If a single vendor offers to “get you ready and then certify you,” ask exactly how they separate those roles.

If you’re notthe right reader for a matching form — say you’re a researcher, a prime evaluating a sub, or someone who already has a mature GRC program and just wanted the mechanics — you don’t need us to route you anywhere. Take the matrix, take the SSP template, and go build. That’s the honest answer, and the right reader trusts us more for giving it.

Inheritance vs. reciprocity vs. shared responsibility — clearing up the terms

These get used interchangeably, but they aren’t the same. Inheritance means you rely on another entity to perform an objective, evidenced in your CRM. Shared responsibility describes the split model itself. Reciprocity — accepting one program’s assessment wholesale in place of another’s — is not a formally defined, guaranteed CMMC mechanism today, so don’t build your compliance plan around it.

The practical takeaway: a FedRAMP authorization or a provider’s own CMMC status gives you evidencetoward specific objectives (inheritance). It does not automatically satisfy CMMC by cross-recognition (reciprocity). Plan your evidence around what you can actually document, not around a shortcut that isn’t guaranteed to exist.

Methodology — what we verified, and what we don’t claim

This guide was built by reading the primary CMMC rule text, the DFARS cloud and CMMC acquisition language, the CMMC Assessment Guide, DoD FedRAMP equivalency guidance, DoD CMMC implementation timing, and authoritative cloud-inheritance documentation. Provider-category recommendations are editorial judgments drawn from those verified facts.

What we verified on July 1, 2026:

• 32 CFR Part 170 text for scope, CSP/ESP definitions, Security Protection Data, Level 2/Level 3 scoping, findings, and evidence retention (§§ 170.4, 170.17, 170.19, 170.24).
• The CMMC Assessment Guide – Level 2 (Version 2.13) inheritance and findings language, and CAP v2.0 conflict-of-interest and ESP-participation procedures.
• DFARS 252.204-7012 cloud-service language and the December 21, 2023 DoD CIO FedRAMP Moderate equivalency memorandum.
• The 48 CFR DFARS acquisition rule (90 FR 43560) and Phase 1/Phase 2 timing.
• AWS’s published CMMC Level 2 inheritance breakdown (21 / 79 / 10) as an AWS-specific example.

What this page does not claim:

• It does not guarantee CMMC certification.
• It does not provide legal, contractual, or compliance advice.
• It does not rank named providers or publish “best provider” awards.
• It does not claim affiliation with the Cyber AB, DoD, DCMA DIBCAC, NIST, or any government agency.
• It does not say a checklist determines your CMMC level — your contract clause and CUI handling do.
• It does not say inherited controls eliminate your proof obligations.

Frequently asked questions about CMMC control inheritance