When Organizations Seeking Certification (OSCs) begin preparing for CMMC, certain terms quickly become a part of everyday conversations. One of the most commonly used (and misunderstood) is inheritance.
But it’s not quite what you’d think when you normally hear inheritance.
Inheritance in CMMC is real. But the way OSCs think about it can create serious gaps when it comes time for an assessment.
Inheritance Is Not a Shortcut
At its core, inheritance refers to leveraging controls implemented by another provider. Most commonly, this applies to Cloud Service Providers (CSPs). If your organization uses a cloud platform, you are not responsible for everything within that environment.
You are not:
- Managing physical data centers
- Replacing failed hardware
- Securing the building itself
Those responsibilities belong to the provider.
But that does not mean you are “off the hook”.
When you rent a house, a landlord handles maintenance. When you own a house, everything becomes your responsibility. Cloud services feel like renting, but with a contract that clearly defines what you still must do yourself.
Inheritance reduces effort. It does not eliminate responsibility.
The Who’s Who in SRMs
Just like in an estate, CMMC inheritance always comes with conditions. These conditions are defined in documentation such as:
- Customer Responsibility Matrices (CRMs)
- Implementation Statements
- System Security Plans (SSPs)
These documents outline a simple yet critical question:
What does the provider do and what do you still have to do?
A common misconception is that using a FedRAMP authorized cloud solution automatically satisfies some larger CMMC requirements. When, in reality, assessors will not accept the broad statement of:
“This is inherited from our provider”.
They are going to ask:
Which controls?
Under what conditions?
What evidence proves your responsibilities are fulfilled?
Inheritance only works when it is clearly defined, properly implemented, and fully documented.
So, What’s the Hold Up?
The biggest challenge with inheritance is not understanding that it exists, but assuming it works automatically.
In order for it to work OSCs must:
- Map provider controls to specific CMMC requirements
- Validate that provider documentation is accurate and current
- Configure their own systems correctly to align with inherited controls
- Prove those configurations during the assessment
Even when a provider handles the majority of a control, there is often a final step required on the OSC’s side.
For example, a provider may support secure configurations by default, but the OSC may still need to enable those specific settings. If those settings are not properly configured, the control is not met, even if the capability exists.
This is where many assumptions are broken down.
The Battle of Inheritance vs Delegation
Another area of confusion comes from External Service Providers (ESPs) like MSPs.
OSCs assume they can inherit controls from these providers in the same way they would from a cloud platform.
But it’s completely different.
With ESPs, the subject isn’t inheritance, it’s delegation of responsibility.
An ESP may perform certain duties on your behalf, but your organization is still accountable for those controls.
In an assessment, you (the OSC) are the one being evaluated, not the provider.
That distinction matters. You cannot just point to a provider’s certification and assume it will satisfy your requirements. You need to demonstrate how responsibilities are defined, executed, and validated within your own environment.
“M” Stands for “Maturity”
CMMC is not static. It is ever-maturing, which means systems, documentation, and processes must evolve over time.
This is especially important with inheritance.
Providers are updating their services frequently. Documentation changes. Features are added, removed, and renamed.
If your organization is relying on outdated documentation, your inherited controls may no longer align with most recent updates.
That is exactly why inheritance must be actively maintained…not just established once.
The Bigger Picture
Inheritance is a valuable part of the CMMC ecosystem. It allows OSCs to use established practices and avoid duplicating work.
But it is not a “get out of jail free” card.
You are still responsible for your compliance even when someone else is doing some of the work.
OSCs that recognize this early (and build their processes around documentation and ownership) are much better positioned for assessments and long-term success.
If you would like to hear more on this, check out our podcast, Climbing Mount CMMC, or feel free to reach out. We’d love to talk.