By Inherited, Shared, or Yours: A Control Inheritance Roadmap for Shared Cloud Tenants
A shared platform's authorization covers the platform, not the program. This roadmap shows how a tenant documents inherited, shared and program-owned controls under NIST SP 800-53, what the ISSO needs at each step, and which decisions stay with the Authorizing Official.
"The platform has an ATO, so we're covered" is the most expensive sentence in shared cloud. The platform's authorization covers the platform. Under the NIST Risk Management Framework, the program's mission system is still its own system, with its own boundary and its own authorization decision. This roadmap is written for the program manager, ISSM, ISSO, or Authorizing Official who has to turn a shared platform's authorization into defensible evidence for one program.
Start With the Position Statement
One sentence belongs in every proposal, status brief, and SSP update for the onboarding:
This effort positions the program to inherit the maximum defensible set of controls (opens in a new tab) from the platform's authorization and documents the remaining mission-owner responsibilities in an assessor-ready Customer Responsibility Matrix reconciliation.
Three phrasings should be rejected on sight: "the environment will be compliant," "the system will be authorized," and "the workbook is the SSP." Each claims an outcome that belongs to the assessor and the AO.
Four Decisions, In Order
Inheritance is only as good as the decisions made before it. Four have to be recorded, in this order, because each constrains the next.
| Step | Decision | Record it in |
|---|---|---|
| 1. Impact level | IL2 or IL4 for DoD under the Cloud Computing SRG; the FedRAMP class the data requires for civilian | Categorization and platform decision record |
| 2. Destination | The shared environment that holds the right authorization at that level | Platform fit assessment |
| 3. Boundary | Where the mission system ends and the platform begins, inside the shared environment | SSP system description and diagrams |
| 4. Inheritance | Which controls are inherited, shared, or program-owned | Control Inheritance Workbook |
Step 3 is where assessors most often push back. Under FISMA, the boundary inside a shared environment has to be drawn explicitly. That means which accounts, networks, and services belong to the program, and which platform services it consumes as a customer. An ambiguous boundary makes every inheritance claim that follows arguable. A useful test is whether the boundary diagram answers three questions without a conversation: which identity store the program's users authenticate against, where the program's logs are stored and who can read them, and which network paths cross from the platform into the program's enclave. If any answer requires a caveat, the boundary is not finished.
Step 2 depends on reading the destination's authorization correctly. Under its 2026 Consolidated Rules, FedRAMP calls a qualifying offering "FedRAMP Certified" and sorts offerings into assurance classes A through D (opens in a new tab). The certification is inherited context. Agencies still authorize their own use, and the program's system still needs its own ATO.
Reading the Customer Responsibility Matrix
Every platform authorization comes with a customer responsibility matrix (CRM). The CRM is written for all tenants at once, so it describes responsibilities in general terms. The program's job is to reconcile it against its own baseline, control by control, and to resolve three kinds of gap:
- Controls the CRM marks as shared without saying where the line falls. The workbook states the tenant's half in concrete terms, such as which logs the program reviews and how often.
- Controls the program's baseline includes but the CRM does not address. These default to program-owned until the platform confirms otherwise in writing.
- Parameters the program must set. Organization-defined values such as review frequencies and session limits have to be set by the program, even when the platform implements the mechanism.
Evidence as code (opens in a new tab) extends the same reconciliation into operations once the tenant is live.
Where Evidence Concentrates
For an IaaS tenant, the positions usually fall into a recognizable pattern. The families below carry most of the workload:
| Family | Typical position | What the program documents |
|---|---|---|
| PE (Physical and Environmental) | Inherited | A reference to the platform authorization; no program action |
| AC (Access Control) | Shared | Program accounts, roles, reviews, and federation to the agency identity provider |
| AU (Audit and Accountability) | Shared | Proof that tenant logs reach the platform or agency SOC, and the program's review cadence |
| IA (Identification and Authentication) | Shared | CAC or PIV federation for program users, and non-person accounts |
| SC (System and Communications Protection) | Shared | Tenant segmentation and allowed flows; the platform provides the perimeter and connection path |
| CM (Configuration Management) | Shared | Program workload settings within platform baselines, under version control |
| IR (Incident Response) | Shared | Program procedures and the handoff to the platform's security operations |
| SI (System and Information Integrity) | Mostly program-owned | Patching and malware protection for the program's own systems |
| CA (Assessment, Authorization, Monitoring) | Program-owned | The mission system's assessment, POA&M, and continuous monitoring |
The shared rows are where inheritance fails in practice. "Shared" with no stated tenant action reads, at assessment, as a control nobody implemented.
What the ISSO Receives
The Control Inheritance Workbook is written for the ISSO and structured so rows move directly into the System Security Plan. For each control it states the position, the CRM line that supports it, the tenant's implementation, the evidence an assessor can check, and the named owner.
Alongside it, the ISSO should expect three supporting artifacts:
- The connectivity and identity design note that backs the SC and IA positions
- The tagging and chargeback standard
- A zero trust map showing which activities the platform delivers and which the tenant owns
The zero trust map matters for DoD programs, which must reach target-level zero trust by the end of FY2027 (opens in a new tab).
What Stays With the Government
The workbook accelerates the RMF Prepare, Categorize, Select, and Implement steps by treating the platform as a common control provider. It does not replace the rest. Three things remain with the government and its assessors:
- The independent assessment of the mission system's controls
- The Authorizing Official's risk acceptance and ATO decision
- Continuous monitoring of the program-owned and shared controls after go-live
Nobody outside the government issues the ATO, the DISA provisional authorization, or the FedRAMP certification, and nobody should promise a timeline for them. Delay has a price, though. What waiting costs when an ATO expires (opens in a new tab) is worth putting in front of the review board, because the inheritance work is what shortens it.
Schedule Risks the Review Board Should See
Most of the onboarding timeline is controlled by the agency and the platform. The plan should name those dependencies and date them:
- Funding document execution. The MIPR or interagency agreement, owned by the funding point of contact.
- Platform intake. Account and enclave requests, owned by the mission-owner sponsor.
- ISSM/ISSO availability. Two to four hours a week to review boundary and inheritance decisions as they are made.
- Network change windows. Connectivity approvals, owned by the network point of contact.
Schedule relief should tie any slip to the missed date. Without it, platform queue time and agency delays land on the onboarding team, and the authorization date moves with no clear cause.
Avalon's Gov-Shared Cloud Services engagement is the execution layer for this roadmap. It produces the platform decision record, the configured tenant, and a Control Inheritance Workbook mapped to NIST SP 800-53 and formatted for your SSP, so the authorization work starts from documented evidence instead of assumptions about what the platform covers.
