Inherited on Paper Only
Fourteen agency systems are consolidating into a shared datacenter. The datacenter team publishes a common control catalog claiming 62 controls - physical access, boundary protection, malware defense, backup. The owner of a Moderate-impact system plans to mark all 62 as inherited and assess only the remaining 160 controls. During a pre-assessment spot check, the ISSO finds the datacenter's malware agent is not deployed on two hypervisor clusters that host this system's virtual machines, and the datacenter's supporting assessment is a self-attestation signed 20 months ago with no test results attached. The datacenter team says the catalog is authoritative and should be taken as given.
1. Can the system owner mark all 62 controls as inherited? Explain the test you would apply control by control.
Read the worked answer
No. Inheritance is a claim about implementation and evidence, and each of the 62 has to pass three questions:
- Is the control actually implemented by the provider, rather than merely listed?
- Does the implementation cover the components this system depends on?
- Is there current, credible assessment evidence at a rigor appropriate to a Moderate system?
The 20-month-old self-attestation with no test results fails question 3 for the whole set - a self-attestation is an assertion, not an assessment. The hypervisor clusters fail question 2 for at least the malware defense control: if the platform hosting this system's virtual machines lacks the agent, then for this system the control is not in place, and 'inherited' is simply false.
A realistic outcome is a split: some controls genuinely inherited with current evidence, some hybrid, and some reclassified as system-specific or not implemented, with the system owner responsible for closing the gap.
2. How should the SSP and POA&M record the outcome?
Read the worked answer
The SSP's inheritance section should, per control, name the providing organization, identify the control as common, hybrid, or system-specific, cite the specific evidence artifact and its date, and state the portion implemented at the system level for hybrids.
For the malware defense gap, the SSP should show the control as not satisfied at the platform layer, describe what the system owner will do instead (for example host-based protection on each VM plus a documented risk acknowledgement for the hypervisor layer), and cross-reference a POA&M entry with an owner, milestone, and target date. The datacenter team should carry its own POA&M item for the missing deployment, because the provider is the party that can fix it.
Marking a control implemented on the strength of the catalog alone - with no evidence reference - is exactly the condition an assessor will flag, and it is hard to defend once the underlying attestation is 20 months old.
3. The datacenter argues the catalog is authoritative. How do you respond?
Read the worked answer
Authority is not assurance. A catalog is a statement of intent; the AO is being asked to accept risk on a claim, and claims require evidence proportionate to the impact level.
An effective response is procedural rather than confrontational: ask the provider for the assessment scope, the testing method, the sample, the date, and the open remediation items behind each control. If those exist, the catalog becomes usable and the inheritance is defensible. If they do not, the honest classification is 'unverified,' and the system owner must either obtain evidence or assess the control at the system level.
The underlying governance point is that common control providers should themselves be assessed and their results shared on a schedule - otherwise every consuming system inherits an unexamined promise.