Inherited Controls and Customer-Managed Keys in a SaaS Deployment
An agency is deploying a commercial SaaS case-management platform to process 250,000 active cases at the Moderate impact level. The provider holds a FedRAMP Moderate authorization and supplies an SSP, SAR, and customer responsibility matrix. The agency plans two changes: it will use customer-managed encryption keys held in its own HSM, and it will connect the SaaS to an on-premises HR system through a new API that passes employee identifiers and case assignments. The provider SSP states that customer-managed keys are outside its authorization boundary and that the API is a customer responsibility. The system owner argues that because the SaaS is already FedRAMP Moderate, the agency can inherit all controls and skip a separate assessment. The AO wants a recommendation before signing the ATO letter, and the project has a 60-day launch window.
1. How should the agency treat the provider FedRAMP authorization? Can it inherit all controls and skip assessment?
Read the worked answer
Leveraged authorization is not a blanket inheritance. The provider FedRAMP Moderate package can support the agency assessment, but the agency must review the SSP, SAR, POA&M, and customer responsibility matrix, confirm the service authorization boundary, and map each inherited control to the agency requirements. Customer-managed keys held in the agency HSM are outside the provider boundary and are a customer responsibility; key management, access, rotation, and logging must be assessed. The new API is also a customer responsibility and an interconnection. The agency still needs its own authorization package and AO decision; it cannot skip assessment of the customer-controlled portions. The 60-day launch window is a schedule risk, not a basis for skipping. If the agency cannot assess the added components in time, it should reduce scope, delay, or issue a time-limited authorization with conditions.
2. What should the interconnection and boundary documentation include for the HR system API?
Read the worked answer
The API interconnection needs an ISA between the agency system owner and the HR system owner. Document the data elements, direction of flow, authentication and authorization, encryption in transit, logging, availability expectations, and incident notification. Confirm the HR system own authorization and whether the data is PII; if so, update the PIA and SSP. Define the boundary: the SaaS is an external service, the HR system is a separate system, and the API is a connection that the agency controls. The agency SSP should show inherited controls from the provider and supplemental controls for the connection. The data-flow diagram must show where identifiers are stored and who can query them. The AO should see the interconnection risk before signing the authorization.
3. What continuous monitoring responsibilities remain with the agency after authorization?
Read the worked answer
Use the provider FedRAMP continuous monitoring deliverables as inherited evidence, but do not assume they cover agency responsibilities. The agency must maintain its own ISCM: configuration baselines for the API and key-management components, vulnerability scanning, log review, and POA&M tracking. Confirm the provider incident response and notification timelines, and integrate them into the agency incident plan. Define how provider POA&M items are reviewed and escalated, and how changes to the service are communicated. Because customer-managed keys change the encryption architecture, include them in ongoing authorization metrics. The agency should also verify that the provider ConMon package is current and that the service authorization has not lapsed or been downgraded. If the provider authorization changes, reassess reliance.