Inherited
The platform implements and operates the control for your boundary. You document the relationship and reference the platform's description instead of writing your own.
Control inheritance
Inheritable FedRAMP Controls
Key takeaway: Inheritance lets a service built on a FedRAMP Certified platform document which controls it relies on, which it shares with the platform and which it owns. Cybertorch is a FedRAMP Certified Class D (High) managed detection and response platform on Azure Government, and the controls a customer can inherit are the ones in its responsibility documentation. Inheritance reduces what you implement and defend. It does not remove your own certification work, and it does not move a FedRAMP date.
This page explains how inheritance works, the control families a security operations platform typically contributes, what inheritance does not cover, where it saves the most work and how to claim it. Related: certification classes, Significant Change Notices and OSCAL automation.
3inheritance statuses: inherited, shared, owned
Dec 7, 2026VDR and VER take effect for your own service
Jan 1, 2027SCN ruleset applies to your own changes
800+NIST SP 800-53 Rev 5 controls mapped by NISTcompliance.ai
Dates checked against fedramp.gov on October 14, 2026.
How it works
A design principle, not a shortcut
Three statuses, recorded control by control.
Every cloud service runs on infrastructure it does not fully control. A SaaS provider runs on a cloud platform, and the platform runs on physical data centers. At each layer, some security controls belong to that layer and some belong to the layer beneath. FedRAMP control inheritance records that relationship: the service documents which controls it inherits from the platform, which it shares and which it implements itself.
Inheritance is a design principle of the program, not a workaround. Done correctly it removes duplicate work across the federal cloud ecosystem and lets each layer focus on the controls it actually owns.
Shared
You and the platform each implement a part. Configuration management, identification and authentication for human users and access control are common examples. The split must be written down.
Owned
The control is entirely yours, whatever sits underneath. Application-layer controls such as input validation, business-logic access control, application keys and application user identity stay here.
What Cybertorch covers
Control families a security operations platform contributes
Audit, incident response and continuous monitoring are the heaviest operational families.
Cybertorch is FedRAMP Certified Class D on Azure Government, authorized for DoD IL-4. Customers whose workloads are monitored by Cybertorch can document inheritance for portions of the families that cover security operations, continuous monitoring, incident response and audit.
| Family | Example controls | What Cybertorch contributes | Typical status |
|---|---|---|---|
| Audit and Accountability (AU) | AU-2, AU-3, AU-6, AU-9, AU-11, AU-12 | Centralized log collection, SIEM, log retention and continuous event analysis across the protected boundary. | Inherited |
| Incident Response (IR) | IR-4, IR-5, IR-6, IR-7, IR-8 | 24/7 incident response by U.S. citizen analysts, response playbooks aligned to federal reporting requirements and incident monitoring. | Inherited |
| Continuous monitoring (CA and SI) | CA-7, SI-4, SI-5 | Continuous security monitoring and alerting telemetry across the protected boundary. | Inherited |
| System and Information Integrity (SI) extensions | SI-3, SI-7, SI-10 | Contributes malicious code protection for monitored endpoints, integrity through configuration monitoring and input validation signals through application telemetry. | Contributes |
| Risk Assessment (RA) | RA-5 | Vulnerability scanning and threat intelligence for the monitored boundary. Your own RA-5 and VDR work still applies. See VDR and VER. | Contributes |
| Configuration Management (CM) | CM-2, CM-3, CM-6, CM-8 | Configuration drift detection for the monitored boundary. An overlap, not full inheritance. Your application-layer configuration stays yours. | Shared |
This table shows how these families usually divide. It is illustrative, not a commitment. Cybertorch's responsibility documentation and your service agreement define the controls you can inherit, and your independent assessor decides whether each one satisfies the requirement for your boundary. Confirm each control with Quzara before you plan around it.
What it does not cover
Boundary precision
The inheritance matrix is where the boundary between inherited and owned controls is written down.
What inheritance does not cover
Application-layer controls. Input validation, business-logic access control, application-specific encryption keys and application user identity management remain yours.
Controls the platform does not operate. A provider cannot inherit a control the platform does not run for its boundary.
Your own configuration. Configuration management and access control are shared. The platform covers its part, and you document and run yours.
What you still do
Document the relationship. Record the status of every control in the inheritance matrix and reference the platform's description for the inherited ones.
Operate and maintain. Keep the documentation current as the platform's inherited controls or your relationship with the platform change.
Be assessed. Your independent assessor reviews the inheritance and whether the relationship is operationally real, and tests your owned and shared controls.
Inheritance narrows scope. It does not remove it.
How much a service gains depends on its architecture and on how deeply it uses the platform's security operations. Quzara does not quote a control-count reduction before reviewing your boundary.
Where it saves work
Where inheritance saves the most work
The inherited controls are usually the operationally heaviest ones.
Avoids a SOC build
Standing up a 24/7 security operations capability means hiring and vetting U.S. citizen analysts, deploying a SIEM, instrumenting log collection and writing response playbooks. Inheriting it replaces that build with documentation.
Avoids 24/7 staffing
Round-the-clock coverage needs several shifts with backup on every tier, through every holiday. Inheritance moves that staffing burden to the platform.
Narrows assessment
Inherited controls are documented and referenced, and your assessor concentrates on the owned and shared controls and on whether the inheritance is real.
Higher-class implementations
A control the platform implements to the Class D baseline is documented against your own class. Your assessor decides whether it satisfies the requirement for your boundary.
Reuse across frameworks
The same inheritance documentation supports FedRAMP, CMMC Level 2 and FISMA Moderate packages from one evidence base.
Machine-readable matrix
The inheritance matrix lives in the same structured package as the rest of your documentation instead of a separate spreadsheet.
Dates still apply
Inheritance does not move your CR26 dates
VDR and VER take effect on December 7, 2026 and the Significant Change Notification ruleset applies from January 1, 2027, for your service as well as for the platform. Confirm in the responsibility documentation which parts of vulnerability reporting and change notification are shared before you plan around the platform. Quzara does not promise a certification date, and neither does FedRAMP.
Primary sources CR26 Rev5 deadlines, Notice NTC-0014, SCN rules, Rev5.
How to claim it
From service agreement to certification package
Claiming inheritance is a documentation discipline with six steps.
Establish the relationship
Your in-scope systems are monitored by the platform, with log collection, SIEM analysis and incident response covering your boundary. A responsibility matrix and a service agreement record it.
Obtain the platform's documentation
Get Cybertorch's responsibility documentation for the controls it provides. Reference it from your package instead of restating it.
Mark each control
For every control in your target baseline, record inherited, shared or owned. Describe your part of every shared control in full.
Build the inheritance matrix
List each control, its status and the responsible party. NISTcompliance.ai generates the matrix from the platform's documentation and your implementations.
Maintain it
Update the documentation when inherited controls or your relationship change. A change to inheritance may be a significant change, so classify it under the SCN ruleset.
Validate with your assessor
Your independent assessor reviews the inheritance and confirms you actually receive the controls you claim.
How NISTcompliance.ai handles the workflow
NISTcompliance.ai ingests the platform's responsibility documentation, in OSCAL where it is published, generates the inheritance matrix, populates the inherited sections of your package, maintains them as the relationship changes and produces the cross-references your assessor reviews. It maps the same inheritance documentation across FedRAMP, CMMC Level 2 and FISMA Moderate. AI drafts, and your team and your assessor decide.
Common questions about FedRAMP control inheritance
What does FedRAMP control inheritance mean?
A service operating on a FedRAMP Certified platform documents which of its controls it inherits from the platform, which it shares and which it owns. For inherited controls it references the platform's implementation instead of implementing the control itself.
Is inheritance a shortcut?
No. It is a design principle of the program that removes duplicate work. Each layer still owns and documents the controls it actually runs.
What does Cybertorch make inheritable?
Portions of the Audit and Accountability, Incident Response and continuous monitoring families, with contributions to others. The table above shows typical examples. Cybertorch's responsibility documentation defines the controls that apply to your boundary.
What does inheritance not cover?
Application-layer controls such as input validation, business-logic access control, application-specific keys and application user identity management. They stay with the service whatever platform sits underneath.
What is the inheritance matrix?
A record of which controls you inherit, which you share with the platform and which you own, and who is responsible for each. Traditionally a spreadsheet, it can live in the same structured package as the rest of your documentation.
What is a component definition?
An OSCAL document describing a reusable component and the controls it satisfies. Where a platform publishes one, customers reference it in their own packages instead of restating the inherited controls.
How much does inheritance reduce my control count?
It depends on your architecture and how deeply you use the platform's security operations. Quzara does not quote a percentage before reviewing your boundary.
Does inheriting from a Class D platform help a Class C service?
A control the platform implements to the Class D baseline is documented against your own class, and your independent assessor decides whether it satisfies the requirement for your boundary.
How does the assessor validate inheritance?
The assessor reviews the inheritance documentation and checks that you actually receive the inherited controls. The assessment concentrates on your owned and shared controls and on whether the relationship is real.
What happens if my inheritance relationship changes?
A change to inheritance may be a significant change. Classify it under the Significant Change Notification ruleset, which applies from January 1, 2027. See the SCN guide.
Can I inherit from multiple platforms?
Yes. A service can inherit different controls from different platforms, for example identity from one provider, infrastructure from another and detection and response from a third. Reference each platform's documentation separately.
How does NISTcompliance.ai handle inheritance?
It ingests the platform's responsibility documentation, generates the inheritance matrix, populates the inherited sections of your package and keeps them current through continuous monitoring.
Building on a FedRAMP Certified Class D platform?
Cybertorch supplies security operations your service can document as inherited, and NISTcompliance.ai builds the inheritance matrix and keeps it current. Engage Quzara through our GSA HACS vehicle or directly to map your inheritance scope.