FedRAMP Boundary Policy

• Status: Open
• Created By: FedRAMP
• Start Date: 2024-01-16
• Closing Date: 2024-02-17
• Short Name: rfc0004-boundary-policy

Where to Comment

• Discussion Forum: https://github.com/FedRAMP/rfc0004-boundary-policy/discussions
• Public Comment Spreadsheet: https://app.smartsheetgov.com/b/form/00503546a1c444528a6073cb52f84d33
• Email: pete@fedramp.gov with the subject “RFC 0004 Feedback”

Summary

This draft policy opens discussion on clarifications for the documentation and assessment of the FedRAMP boundary and the reuse of FedRAMP authorized cloud service offerings by cloud service providers.

Draft guidance released in the FedRAMP Request for Comment (RFC) process should not be considered formal or finalized. The initial public comment period for this draft will be 30 days. Depending on the outcome of this comment period, there may be further rounds of public comment after additional edits. Once public comment is concluded, FedRAMP’s goal will be to finalize this policy with the FedRAMP Board within two months.

This draft policy indicates that the FedRAMP boundary must include all services that:

1. handle federal information; and/or
2. directly impact the confidentiality, integrity, or availability of federal information

Services not meeting the above criteria should be excluded from the FedRAMP boundary with appropriate justification and risk-based review. Ancillary services whose compromise would pose negligible risk to federal information or federal information systems are explicitly outside the scope of FedRAMP.

Motivation

The assessment of cloud service offerings under FedRAMP should be limited, wherever possible and appropriate, to systems and services whose compromise would pose a risk to the security of federal information. The inclusion of ancillary services with negligible impact on federal information in the FedRAMP boundary creates an unnecessary burden on cloud service providers, third party assessment organizations, and government agencies during the initial authorization and ongoing monitoring of cloud service offerings. This increased burden may result in reduced effective security as effort is spread across disparate systems that pose negligible risk; effort should instead be focused explicitly on the aspects of a cloud service offering that pose meaningful risk.

External services that pose meaningful risk to federal information must be included in the FedRAMP boundary, but the reuse of FedRAMP authorized external services should be incentivized to reduce duplication of effort. Only documentation and assessment of the configuration or customer implementation (as defined in the Customer Responsibility Matrix) of a FedRAMP authorized external service should be required. Agency review teams should separately review the underlying security of external cloud services with FedRAMP authorizations for a complete risk picture when making an authorization decision.

Explanation

The full draft policy is approximately six pages and is available for review as follows:

• Basic web formatting on fedramp.gov (below)
• Basic text markdown on GitHub
• PDF file: 0004-boundary-policy.pdf
• Word file: 0004-boundary-policy.docx

This draft policy does not include examples; updates and clarifications are expected in the public comment and agency review process. There will be multiple iterations on this policy during this process, with examples to be provided once an initial version is adopted as formal policy.

Discussion Requested

FedRAMP stakeholders will be impacted differently by separate areas of this proposed update to how cloud service offering boundaries should be determined and assessed. These changes are intended to decrease the burden of FedRAMP authorization while increasing the focus on the security of the highest risk aspects of cloud services.

FedRAMP seeks to understand how these changes would impact varying sets of stakeholders and what additional changes and clarifications would be recommended to find the right balance between security, cost, and complexity for all parties.

FedRAMP also encourages the public to provide example scenarios during public comment periods to clearly highlight where and how this guidance can be clarified in future knowledge base articles.

Editorial Comments

1. This policy explicitly limits the FedRAMP boundary to a subset of the full traditional authorization boundary. If a SaaS offering runs on a FedRAMP authorized PaaS then both the SaaS offering and the aspects of the PaaS used by the SaaS offering would be inside the agency Authorization to Operate boundary but the FedRAMP authorization will only include the SaaS offering and its configuration of the PaaS. This is difficult to convey effectively in general due to the many dimensions of reuse. Examples are recommended, but how can this be standardized clearly without examples?_

   Ex: Control MP-06 (Media Protection, Media Sanitization) requires that media be sanitized prior to disposal. A SaaS CSO does not need to address the implementation of MP-06 by the FedRAMP authorized PaaS it is leveraging, but may need to address MP-06 implementations for laptops used by site reliability engineers managing the SaaS CSO. Agencies issuing an ATO for the SaaS CSO would need to review the full MP-06 implementation from the underlying PaaS to make an appropriate risk assessment for transferring data into the SaaS CSO, however.

2. This draft introduces the plain language idea of “handling” federal information as inherently inclusive of everything one can do with information without continuously providing a long list of verbs (“create, collect, process, store, transmit, access, maintain, use, disseminate, disclose, dispose, etc.”). Is this sufficiently clear?

3. FRR211: This rule is intended to convey that restrictions on external connections may not be used by a cloud service provider to deny access to the owner of federal information in a cloud service offering. A cloud service offering may allow agency authorized services to interconnect with the cloud service offering and only needs to document the relevant mechanisms within the cloud service offering. For example, if a cloud service offering allows authenticated API access to information, then any system used by the agency to access that information is outside the FedRAMP boundary but not prevented under this rule. This is a difficult process rule to communicate. Providing comment on improving clarity here would be appreciated.

---

FedRAMP Boundary Policy Working DRAFT

APPLICABILITY

This policy defines requirements and recommendations related to FedRAMP boundaries for the following parties:

• Cloud service providers (CSPs) who participate or want to participate in the FedRAMP marketplace
• Independent assessors (IAs) who perform third-party cybersecurity assessments for cloud service offerings (CSOs) through their FedRAMP packages. IAs conduct both initial and periodic evaluations of CSOs to ensure they comply with federal security requirements. IAs are also known as third-party assessment organizations (3PAOs).
• Package reviewers from FedRAMP designated leads, who are federal agencies responsible for sponsoring CSPs for FedRAMP authorization. A designated lead can be:
  • An authorizing official at a federal agency; or
  • The FedRAMP Director at GSA in the case of a program-sponsored authorization.

The purpose of this guidance is to establish greater consistency and a shared interpretation of which systems and data fall within a FedRAMP authorized boundary, and which do not, across all FedRAMP authorization pathways.

This guidance is normative and applies to all FedRAMP authorizations, and is required to be followed by all cloud service providers (CSPs) and all federal sponsors of FedRAMP authorizations (individual agencies, multi-agency constructs, and FedRAMP itself in the case of program authorizations).

CSPs and IAs must adhere to this version of the policy by MONTH DD, 2025. Package reviewers from FedRAMP designated leads must adhere to this version of the policy starting on MONTH DD, 2025.

TABLE OF CONTENTS

1. Policy Overview 4

1.1 Reuse of FedRAMP Authorized Cloud Service Offerings 4

1.2 Operations Outside the FedRAMP Boundary 4

2. Requirements and Recommendations 5

2.1 Cloud Service Providers 5

2.1.1 FedRAMP Boundary Definition 5

2.1.2 FedRAMP Boundary Protection of Information 6

2.1.3 FedRAMP Boundary Restrictions on Inbound and Outbound Connections 6

2.2 Independent Assessors (IAs) 6

1. Policy Overview

The FedRAMP boundary defines the scope of a Cloud Service Offering (CSO) that must be assessed for FedRAMP authorization.

The FedRAMP boundary includes all aspects of the CSO, including external services, that:

1. handle[^1] federal information; and/or
2. directly impact the confidentiality, integrity, or availability of federal information

This includes all services to be consumed by tenants/customers and the underlying components, infrastructure, and services (including external services), that handle federal information as part of the CSO and the related organizational users operating the service. It also includes privileged security tooling, authentication systems, management/orchestration, and keying material and secrets.

Cloud Service Providers (CSPs) and Independent Assessors (IAs) are encouraged to engage FedRAMP when navigating complex scenarios about when services should be inside the boundary or not. FedRAMP will create and maintain a knowledge base of examples with specific guidance where appropriate to help CSPs and IAs navigate this.

[^1]: inclusive of any possible use of information, including creation, collection, processing, storing, transmitting, accessing, disposing, etc.

1.1 Reuse of FedRAMP Authorized Cloud Service Offerings

CSPs can leverage existing FedRAMP authorized cloud service offerings as part of their CSO to streamline their engineering and authorization process. Reusing a FedRAMP authorized cloud service offering will allow the CSO to inherit the existing implementation, assessment, and testing of services from those cloud service offerings without including the entirety of those offerings inside the FedRAMP boundary.

The relevant inherited controls from leveraged FedRAMP authorized cloud service providers should be reviewed during reuse or agency assessment for an Authorization to Operate but should not be duplicated in the FedRAMP boundary or assessment for the CSO. Documentation and assessment of leveraged FedRAMP authorized cloud service offerings used by the CSO should be limited to the configuration of leveraged services following guidelines in the leveraged service’s Customer Responsibility Matrix (CRM) and remaining in compliance with CISA BOD 25-01: Implementation Guidance for Implementing Secure Practices for Cloud Services.

1.2 Operations Outside the FedRAMP Boundary

Ancillary services that support the CSP or CSO but pose negligible[^2] or no direct risk to federal information should remain outside the FedRAMP boundary. These systems may be documented in the SSP front matter and other diagrams as appropriate to demonstrate operations of the CSO. Interactions with such systems will be reviewed by the IA to affirm that they pose the low level of risk as documented, but systems that pose this low risk will not be tested by the IA.

Examples of ancillary services that may be outside the FedRAMP boundary include corporate email services, development environments, and customer service systems where a loss of confidentiality, integrity, or availability is not likely to directly affect federal information within the CSO.

[^2]: so small that it is not worth considering; any foreseeable risk would be merely an inconvenience

2. Requirements and Recommendations

This section defines requirements and recommendations related to FedRAMP boundaries for three types of stakeholders: CSPs, IAs, and package reviewers from FedRAMP designated leads.

Each requirement and recommendation has an identifier that is unique across FedRAMP policies. This identification approach enables referencing specific requirements and recommendations in this and other resources.

2.1 Cloud Service Providers

CSPs are responsible for defining the FedRAMP boundary for each of their CSOs, protecting information and components within each boundary, and safeguarding the environments of operation. The following requirements and recommendations apply to all FedRAMP authorized CSOs unless otherwise stated.

2.1.1 FedRAMP Boundary Definition

• FRR201: CSPs shall include all CSO services and their underlying components, infrastructure, and services (including external services) that:

  • handle federal information; and/or

  • directly impact the confidentiality, integrity, or availability of federal information.

• FRR202: CSPs shall include any components required to be installed or run on a tenant system in order to use the CSO and may include additional optional components if they are included in the SSP.

• FRR203: CSPs shall document all components, their relationships, data flows, types, encryption employed, access and policy enforcement points, security components, and ports/protocols/services used in the SSP.

• FRR204: CSPs shall address only the customer responsibilities for any FedRAMP authorized cloud service offerings that they wish to inherit controls from. Configurations must comply with CISA BOD 25-01: Implementation Guidance for Implementing Secure Practices for Cloud Services.

• FRR205: CSPs shall update boundary documentation as architectures evolve and as protections or data flows change. CSPs shall reflect such updates promptly in SSPs, continuous monitoring reports, and in the POA\&M where they deviate from these requirements.

2.1.2 FedRAMP Boundary Protection of Information

• FRR206: CSPs shall designate a System Owner for the CSO who has sufficient organizational authority to enforce all policies, procedures, and control implementations which affect the FedRAMP boundary, including contractual obligations with third parties.

• FRR207: CSPs shall not reuse federal information for shared purposes unless the government tenant specifically opts in to such sharing or grants access to the information. CSPs shall ensure that external services that handle federal information are configured to meet this requirement. This requirement applies to machine learning models trained on federal information.

• FRR208: CSPs shall ensure that security and administrative configuration, secrets, key material, and agents are managed within the FedRAMP boundary and are documented within the SSP.

• FRR209: CSPs shall document and maintain information exchange agreements for all external systems within the FedRAMP boundary. This shall include the information types, encryption employed, ports/protocols/services used, access levels, and the requirement to meet FedRAMP security requirements.

• FRR210: CSPs shall ensure that federal information sent to public or commercial services used to support the function of a CSO is limited to information approved by the owner of the federal information.

2.1.3 FedRAMP Boundary Restrictions on Inbound and Outbound Connections

• FRR211: CSPs shall not permit any systems outside the FedRAMP boundary to directly access federal information or to make changes to the security of the FedRAMP boundary except when approved by the owners of the federal information.

• FRR212: CSPs shall document all connections established between the FedRAMP boundary and systems in the environment of operations, including the data types, encryption employed, ports/protocols/services used, the level of access, and the service or component involved.

2.2 Independent Assessors (IAs)

• FRR216: IAs shall test all components within the FedRAMP boundary and shall review and evaluate connections to systems outside the FedRAMP boundary as documented by the CSP following FRR201-212.

• FRR217: IAs shall review data flows between the FedRAMP boundary and the environment of operations, and shall validate the impact categorization of the data in those services, the presence of appropriate certifications, and ensure they have no direct security impact or privileged access to the federal information.

• FRR219: IAs shall document deviations from this guidance within the SAR, POA\&M, and other materials.