RMF Authorization Decision for a SaaS System with Unclear Boundary and Inherited Controls

Boundary

A system boundary follows data flows and management authority, not contractual labels. The API connection to the legacy eligibility system is part of the agency system because agency data crosses it, the agency controls the legacy endpoint, and a failure or compromise there affects the authorized system. Calling it 'external' hides an interconnection that needs an ISA/MOU, data-flow documentation, and controls at both ends. The boundary should include the SaaS tenant as configured for the agency, the API gateway, the legacy eligibility system, agency identity providers, and the agency's endpoint access paths.

Inheritance

Inheritance is control-specific, not package-wide. The agency may inherit only controls that are: (1) within the FedRAMP authorization boundary, (2) implemented by the vendor as described in the package, and (3) not dependent on agency configuration or operation. From the customer responsibility matrix, classify each control as inherited, shared, or customer-owned. For shared controls, the agency must document and assess its half. For example, the vendor may provide encryption at rest, but the agency may own key management, account provisioning, logging retention, and contingency testing.

What cannot be assumed

A FedRAMP Moderate authorization does not automatically cover the agency's API integration, agency-configured workflows, or the legacy system. The three stale high-risk POA&Ms also weaken the inheritance claim for any affected control. The agency still needs a system security plan, a security assessment report or assessment of agency-owned controls, and a POA&M. Skipping a separate assessment is not defensible; the agency can leverage the vendor package to reduce scope, but it must assess the agency boundary and shared responsibilities.

Decision

A full authorization to operate is not defensible today. The boundary is misstated, the agency has not assessed its own controls, three high-risk POA&Ms are 14 months old, the contingency plan is untested, and continuous monitoring is an annual questionnaire. The 30-day deadline and the legacy support deadline create schedule pressure, but they do not cure those gaps.

A defensible path is a time-limited authorization with conditions, or an interim authorization to test if the mission can tolerate it. If the AO accepts risk in writing, the decision should state the specific risks, the compensating controls, the expiration date, and the evidence required for full authorization.

Conditions

1. Correct the boundary and document the API interconnection with an ISA, data-flow diagram, and security controls at both ends.
2. Complete the customer responsibility matrix review and assess all agency-owned and shared controls within 60 days.
3. Require the vendor to provide a current POA&M with remediation dates for the three high-risk items; independently validate closure for at least one.
4. Test the SaaS contingency plan, including restoration of a sample dataset, before full authorization.
5. Establish continuous monitoring: monthly vulnerability and POA&M updates, incident notification within 24 hours, annual assessment, and a SaaS log feed or compensating review.
6. Implement compensating controls now: restrict API access, enforce MFA, monitor legacy eligibility access, and encrypt CUI in transit and at rest.

Reasoning

The AO can authorize with conditions when risk is understood and accepted. Here the risk is not yet understood because the boundary and shared controls are unresolved. A short-term conditional authorization aligned to the legacy transition protects the mission while forcing evidence. Full authorization should wait until the high-risk POA&Ms and contingency test are resolved.

Continuous monitoring design

Continuous monitoring should be risk-based and tied to the controls that matter most: boundary changes, identity and access, vulnerability remediation, incident response, contingency, and supplier performance. A practical package includes:

• Monthly vulnerability scan summaries and remediation status for the agency boundary.
• Monthly review of the vendor's POA&M and significant change notifications.
• Quarterly access reviews for privileged accounts and API credentials.
• Annual control assessment of agency-owned controls, with sampling.
• Annual contingency test, plus a tabletop after major changes.
• Incident reporting with a 24-hour initial notification and defined follow-up.
• A log review process, either through a SIEM feed or documented compensating sampling if no feed exists.

Stale POA&Ms

The three high-risk POA&Ms cannot be carried forward indefinitely. Assign an agency owner and require the vendor to provide a root-cause statement, remediation plan, and independent evidence. If the vendor cannot close them, the agency must either apply compensating controls, restrict the data or functionality affected, or escalate to the AO for a risk decision. Set a hard deadline, for example 90 days, and make contract renewal or expansion contingent on closure.

Governance

Report monitoring results to the AO quarterly using a small set of metrics: open high-risk findings, mean time to remediate, access review completion, contingency test result, and significant changes. The AO should re-authorize or adjust the authorization when risk changes materially. The program office should not treat the initial authorization as permanent permission; it is a risk decision with an ongoing evidence obligation.