There was a moment during our CMMC Level 2 journey when something that sounded simple turned out to be anything but.
It came up in conversations with vendors, reviewers, and even internally as we mapped controls and evidence:
“Can’t we just inherit that?”
On paper, inheritance sounds like a shortcut. In reality, it is a design decision, one that can either strengthen your compliance posture or quietly undermine it.
This post is about what control inheritance actually means in CMMC, how FedRAMP authorization from a software vendor fits into the picture, and why understanding the limits of inheritance mattered deeply in our own assessment.
What is FedRAMP?
FedRAMP, which stands for the Federal Risk and Authorization Management Program, is a U.S. government initiative that standardizes the security assessment, authorization, and continuous monitoring of cloud products and services. Its primary goal is to ensure that federal data is securely managed by cloud providers through rigorous requirements and regular audits.
You can find a list of vendors and their status on FedRAMP Marketplace
What Control Inheritance Really Means
Control inheritance is the idea that an organization can rely on security controls implemented by an external provider, typically a cloud or SaaS vendor, instead of implementing those controls themselves.
In the CMMC world, inheritance is most commonly discussed alongside FedRAMP authorized platforms. If a vendor has already implemented and been assessed against certain security controls, it is reasonable to ask:
“Can we leverage that work instead of duplicating it?”
The answer is… sometimes, and only in very specific ways.
Requirements for Allowing Control Inheritance
For a control to be inherited in the context of CMMC, several conditions must be met. First, there must be clear evidence that the external provider, such as a FedRAMP authorized vendor, has fully implemented and continuously maintains the relevant control. This includes documented mapping of responsibilities and supporting artifacts like audit reports, contractual language, and system security plans.
Additionally, your organization must be able to demonstrate that the inherited control is applicable to your environment and that any gaps or shared responsibilities are properly addressed. This may require supplementary policies, procedures, or compensating controls to ensure compliance. Ultimately, inheritance is only permitted when objective evidence proves the control is operational, monitored, and relevant to your specific use case.
Where FedRAMP Inheritance Helps
During our journey, working with FedRAMP authorized vendors absolutely helped, when used correctly.
FedRAMP provides assurance that specific system level controls are already implemented, assessed, and monitored by the provider. This can reduce duplication around areas like physical data center security, underlying infrastructure protections, environmental safeguards, and certain infrastructure level monitoring controls.
It’s important to understand the distinctions between FedRAMP “authorized,” “ready,” and “equivalent” when assessing control inheritance options. A FedRAMP authorized provider has completed a rigorous assessment and received an Authority to Operate (ATO), meaning its security controls and processes have been fully validated against FedRAMP requirements. A FedRAMP-ready provider has passed a preliminary review but is not fully authorized, so their controls can’t yet be inherited as certified. “FedRAMP equivalent” refers to providers who claim to meet or exceed FedRAMP requirements through alternative frameworks or self-attestation, but who have not gone through the official FedRAMP authorization process; as a result, objective evidence and federal recognition may be lacking. Understanding these differences is essential to ensure that only eligible controls are considered for inheritance in a CMMC context.
In practical terms, this meant we did not have to reinvent the wheel for controls that were clearly owned and operated by the vendor, and where objective mapping and evidence clearly supported inheritance.
That saved time. It reduced architectural noise. It let us focus our energy where it actually mattered.
Used properly, inheritance lowers burden without lowering standards.
Where Inheritance Breaks Down
Here is the hard lesson we learned, and the one we see customers struggle with most:
You cannot inherit accountability.
FedRAMP authorization does not mean you inherit user provisioning decisions, access approvals, configuration choices, incident response actions, policy enforcement, or evidence ownership.
Even if a vendor implements a control, you are still responsible for how it is used inside your environment.
CMMC assessors do not ask, “Is your vendor compliant?”
They ask, “How is this control implemented, enforced, and evidenced in your environment?”
That distinction matters.
What Cannot Be Inherited No Matter the Vendor
Some controls are non-transferable by design.
You cannot inherit governance decisions, risk acceptance, role definitions, training execution, user behavior, operational discipline, management oversight, or proof that you are doing the thing.
Even with the strongest vendor stack in the world, CMMC still evaluates your organization’s maturity, not the logo list on your architecture diagram.
We saw this play out repeatedly as we mapped assessment objectives.
A control might be supported by a vendor, but the objective level evidence still belonged to us.
Why This Matters More Than People Expect
We have worked with organizations who assumed inheritance meant fewer controls to own, only to discover late in the journey that evidence was missing, responsibilities were unclear, SPRS scores were optimistic, and controls lived in assumptions instead of documentation. Some even thought that 100% of the controls were inherited! And some vendors may have told them that was true, but we digress…
That is where compliance turns reactive.
In our case, being deliberate about what we inherited, what we shared, and what we owned outright made the assessment predictable instead of painful.
Inheritance was not a shortcut. It was a boundary.
The Takeaway from Our Journey
Inheritance is powerful when it is precise. Dangerous when it is vague. Ineffective when it is used as a substitute for ownership.
During our implementation phase, we carefully evaluated vendors against objective requirements such as compliance standards and specific security controls. We found that some vendors, despite their reputation, could not provide the necessary documentation or evidence to demonstrate alignment with these requirements. As a result, including them in our technology stack posed a risk of failing assessment objectives, since evidence supporting compliance with controls was either insufficient or missing. This exclusion was not a reflection on the vendors’ overall quality, but rather a direct consequence of their inability to furnish documented proof and certifications needed for our compliance journey. By ensuring that every vendor met explicit evidence and certification criteria, we strengthened our assessment outcomes and reduced the risk of compliance gaps.
CMMC is not about stacking certifications. It is about being able to clearly explain who owns the control, who operates it, who enforces it, and who proves it.
Certification alone does not guarantee compliance; clear accountability does. Inheritance can support that story, but it can never tell it for you.
Next week, we’ll tackle a question that sparks debate in every compliance discussion: “to enclave or not to enclave?” Stay tuned as we explore the real-world implications, decision factors, and practical strategies for building, or avoiding, enclaves in your environment.
Questions about CMMC certification? Contact Hill Tech Solutions.
