Tenancy and Inheritance Boundary

Control Statement

For every element hosted in a shared or authorized service, the overlay shall record which controls are inherited from the provider and which remain the organization's responsibility.

Purpose. To ensure that the customer half of a shared responsibility model is owned by someone, so that inherited controls do not become nobody's job.

Discussion

The customer responsibility matrix is the most reliably unread document in federal cloud adoption. The provider states that a control is the customer's responsibility; the customer assumes that a FedRAMP-authorized service handles it; and the control is implemented by neither while appearing satisfied to both. That gap is invisible on any inventory and visible on this overlay, because an unassigned customer responsibility appears as an element with an inheritance claim and no owner. This control and CG-5 are the same discipline applied at different scopes — CG-5 verifies inheritance from a control baseline, FO-3 verifies it from a service provider.

Goals and Metrics

A metric that cannot come out badly is not a metric. Each of these is capable of reporting that the control is not working.

Accountability

Exactly one role is accountable, and every other role carries at least Informed — no control in the published catalog leaves a role with zero relationship to it. That is a stated property of how these were authored, not a coincidence, and not a claim that every role's work is worth equal attention here.

Inputs and Outputs

Activities

1. L2Record the hosting provider for every element in a shared or authorized service.
2. L2Record which controls are inherited and which remain the organization's responsibility.
3. L2Report unassigned customer responsibilities as gaps.
4. L3Derive the split from the provider's authorization package and customer responsibility matrix rather than from assumption.
5. L3Assign an owner and an implementing maneuver to each customer responsibility, reconciled against terrain ownership (TM-7).
6. L3Re-verify the split when the provider changes its offering, its authorization status, or its responsibility matrix.
7. L3Record where a provider's authorization does not extend to the way the agency is actually using the service, since inheritance does not apply outside the authorized scope.
8. L4Measure the proportion of customer responsibilities carrying both an owner and an operational move, since an owned but unimplemented responsibility is a gap that reports as assigned.
9. L4Trend the count of unassigned responsibilities across cycles.
10. L5Feed recurring inheritance gaps into acquisition, so that the responsibility split is evaluated before a service is adopted rather than after.

Measurement

Evidence and Assessment

Related Guidance

Where This Control Is Used

Derived, in every case, from the declaration at the other end: the forms whose techniques name this control, the artifacts whose producing and consuming controls include it, the layers whose control lists name it, and the roles its own accountability chart puts to work. Nothing here is authored on this page, so the sheet cannot claim an edge the other end does not.