FedRAMP RFC-0010: FedRAMP Scope Interpretation Technical Assistance (CLOSED)

[rpalmer-gsa]

RFC-0010 FedRAMP Scope Interpretation Technical Assistance

• Status: Open
• Created By: FedRAMP PMO
• Start Date: 2025-05-15
• Closing Date: 2025-06-15
• Short Name: rfc-0010-scope-technical assistance

Where to Comment

• Discussion Forum: https://github.com/FedRAMP/rfcs/discussions/31
• Public Comment Form: https://forms.gle/MkHUDacjLmXQswYf9
• Email: pete@fedramp.gov with the subject "RFC-0010 Feedback"

FedRAMP Guidance Types

• Standards are base requirements that can be applied in any environment and will change rarely
• Best Practices support standards with methods, techniques, or examples and may change often
• Technical Assistance supports standards with additional technical nuance to support decision making and may change often

Summary

This Request for Comment (RFC) seeks public input on draft interpretive technical assistance for OMB Memorandum M-24-15, Section 3, "Modernizing the Federal Risk and Authorization Management Program (FedRAMP)." This technical assistance provides additional technical nuance to support agency decision-making regarding the categories of cloud services excluded from FedRAMP requirements. The draft document offers interpretive guidance with illustrative examples for each of the five exclusion categories defined in M-24-15, along with a summary table to aid consistent application across federal agencies.

Motivation

OMB Memorandum M-24-15 updated FedRAMP's scope and mandated the publication of clarifying guidance to aid agencies in interpreting the defined exclusion categories. Section 3 of M-24-15 states: "FedRAMP, in consultation with OMB, will publish guidelines for interpreting the categories above, with supporting examples that clearly illustrate what types of services are in and out of scope."

This draft technical assistance has been developed to fulfill that requirement by providing the necessary technical nuance to help agencies navigate and make consistent determinations about FedRAMP applicability.

To ensure maximum reusability of this technical assistance across agencies and encourage thoughtful implementation, the guidance provides key criteria that agencies can apply when evaluating cloud services. This approach allows agencies to focus resources on services that genuinely require FedRAMP authorization while avoiding unnecessary burden for services that fall outside the scope of FedRAMP.

Explanation

The full draft technical assistance is approximately 5 pages and is available for review in the following formats:

• Basic web formatting on fedramp.gov
• Basic text markdown on GitHub (below)
• PDF file: rfc-0010-scope-interpretation-technical-assistance.pdf
• Word file: rfc-0010-scope-interpretation-technical-assistance.docx

Discussion Requested

FedRAMP is seeking feedback on all aspects of this draft technical guidance. We encourage specific comments on, but not limited to, the following areas:

• Are exclusion explanations clear, concise, and easy for a non-technical reader to understand?
• Are the sections "When FedRAMP Doesn’t Apply" and "Key Tests" accurate and provide practical guidance for making determinations?
• Is the distinction between "Out of Scope" and "In Scope" clearly illustrated with relatable examples for various cloud service models?
• Does the guidance offer sufficient clarity on how to handle hybrid scenarios or situations where only a portion of a service falls under FedRAMP requirements?
• Are there any terms used that could be interpreted differently across agencies, and if so, are definitions or further explanations needed?
• Are there areas involving AI or other emerging technologies that require additional information to inform agency evaluation of FedRAMP scope applicability?

---

RFC-0010 FedRAMP Scope Interpretation Technical Assistance

Thursday, May 15th, 2025

---

Background

OMB Memorandum M-24-15 "Modernizing the Federal Risk and Authorization Management Program (FedRAMP) updated FedRAMP's scope, defining categories of services excluded from its requirements. To ensure consistent application of these exclusions across agencies, the memorandum requires the publication of clarifying guidance, stating in section 3 “FedRAMP, in consultation with OMB, will publish guidelines for interpreting the categories above, with supporting examples that clearly illustrate what types of services are in and out of scope.”

The information is provided for public awareness. Reference to any commercial product does not constitute endorsement by GSA. For more information, please see FedRAMP Disclaimers.

Introduction

M-24-15 "Modernizing the Federal Risk and Authorization Management Program (FedRAMP) establishes that agencies must apply FedRAMP when acquiring cloud services to create, collect, process, store, or maintain Federal information on behalf of a Federal agency, unless the service meets specific exclusion criteria outlined in the policy. This requirement enables standardized security assessment reuse and consistent monitoring across the federal government, promoting efficiency and enhancing security posture.

FedRAMP does not apply to all internet-based services used by agencies. M-24-15 Section 3 clearly defines specific categories of cloud services that are out of scope. Furthermore, agencies may use the same service offering differently based on mission needs, and each agency must determine FedRAMP applicability based on their specific implementation, use case, and risk profile.

This technical assistance clarifies the initial step of determining if FedRAMP requirements apply to a cloud service, based on the agency's specific use and the out-of-scope categories defined in M-24-15. While M-24-15 includes various processes and flexibilities for services requiring authorization, this guidance focuses solely on interpreting the scope exclusions.

Best practices and technical assistance MUST NOT be used as a checklist. All examples are for discussion purposes ONLY. This technical assistance is designed for reasonable people to have reasonable discussions about FedRAMP applicability based on their specific use of a cloud service.

This Technical Assistance document will be continuously updated to reflect evolving interpretive needs based on M-24-15's scope requirements. This includes updates to reflect any additional excluded categories identified by the FedRAMP Board with Federal CIO concurrence, or exceptions made by the FedRAMP Director with OMB approval.

Determining FedRAMP Scope

This guidance provides practical examples to help agencies navigate FedRAMP applicability decisions to ensure consistent implementation of M-24-15 across the federal government. The examples below illustrate how to interpret each of the out-of-scope categories defined in Section 3 of the OMB Memorandum. This guidance is not intended to be a complete listing of all possible examples or exclusions. Agencies must perform their own analysis and may find that some use cases may fall into multiple exemption categories outlined below

Information systems that are only used for a single agency’s operations, hosted on cloud infrastructure or platform, and are not offered as a shared service or do not operate with a shared responsibility model;

When FedRAMP Doesn’t Apply: The service is exclusively for a single agency's operations and not intended for reuse or reconfiguration by other agencies.

Key Tests:

• Single agency operational and configuration responsibility
• No assessment to reuse

Examples:

• Agency custom applications deployed to FedRAMP authorized IaaS
• Agency deployed instances of an app from a FedRAMP authorized PaaS vendors App Storefront
• Agency mission systems operated by a single agency with no shared operation or configuration responsibility

Out of Scope Detailed Example - Data.gov: GSA operates data.gov, a cloud hosted platform which allows agencies to share open datasets. While multiple agencies can contribute datasets, GSA maintains full responsibility for the systems configuration, operations, and authority to operate.

Analysis: Single operator; no shared platform responsibility.

In Scope Detailed Example - USDA AgCloud Managed Platform Services (AMPS): AMPS is a fully-managed DISC platform designed to give customers a supported and secure way to cloud computing. AMPS includes security services, patching services, administration services, and inheritable Authority to Operate (ATO) security controls for these managed services. Simply stated, AMPS provides the infrastructure on which customers may deploy their applications.AMPS provides a standardized, secure cloud platform that allows agencies to quickly deploy applications without managing the underlying IT infrastructure. By offering a shared, pre-configured environment with consistent security standards, AMPS assumes responsibility for the underlying platform, while customer agencies manage their applications.

Analysis: Reusable platform; shared responsibility model.

Social media and communications platforms used in accordance with agency social media policies

When FedRAMP Doesn’t Apply: The service is not an authoritative repository for federal information, and its unavailability would not result in the loss of federal information.

Key Tests:

• Used in accordance with agency social media policies including compliance with Federal Records Act
• Primary purpose is external communication
• Not used as an authoritative source for federal information
• All federal information in the communication platform is intended for public use

Examples:

• Agency social media accounts (e.g., X, Facebook/Meta) including platform AI features (like content suggestions, public analytics, and sentiment analysis) that do not respond on behalf of the agency
• Scientific collaboration platforms (protocols.io)

Out of Scope Detailed Example - Scientific Collaboration: Agency researchers use protocols.io to communicate with the scientific community and share information. If protocols.io went away, the agency wouldn’t lose any federal information so the platform isn’t within the scope of FedRAMP.

Analysis: External communication using public information; not an authoritative source.

In Scope Detailed Example - Government Collaboration: Agency teams use collaboration platforms (e.g., Slack, Teams) for internal and cross-agency work, processing and storing sensitive, non-public federal information. Handling this information on behalf of agencies necessitates FedRAMP authorization.

Analysis: Handles internal, non-public federal information.

Search Engines

When FedRAMP Doesn’t Apply: The search engine is used primarily for public information discovery and does not store, index, or maintain internal federal information on behalf of the government.

Key Tests:

• Primary function is public information discovery
• Does not collect or maintain federal information for agencies
• Users instructed not to input sensitive federal information

Examples:

• Public web search engines (e.g., Google, Bing, Lycos) using only public or non-sensitive federal information
• Public AI Chatbots (e.g., ChatGPT, Claude, Grok) using only public or non-sensitive federal information

Out of Scope Detailed Example - AI search chatbot: An agency uses a public AI Chatbot search to troubleshoot technical issues with a video conferencing system. Search queries of public or non-sensitive federal information may be logged by the vendor, but not FOR the agency. Because no internal data is accessed or trained on, FedRAMP doesn’t apply.

Analysis: Searches public information; does not collect or maintain internal federal information for the agency.

In Scope Detailed Example - Internal Data Search: An agency uses a shared cloud service to index and search internal repositories containing non-public federal information (e.g., documents, emails, databases). Because the service collects, processes, and maintains internal federal information on behalf of the agency, FedRAMP authorization is required.

Analysis: Collects, processes, and maintains internal agency data for the agency.

Widely available services that provide commercially available information to agencies, but do not collect Federal information

When FedRAMP Doesn’t Apply: The commercial information service does not collect or maintain federal information on behalf of the government.

Key Tests:

• Provides commercial services to agencies and the general public
• May temporarily process federal information (such as an address) to provide a response, and may maintain records of past requests, but does not collect or maintain federal information for the government
  • The agency does not require the service to retain or provide access to this information after the transaction or service delivery is complete
• Risk of unexpected exposure of federal information is accepted because the positive impact on the agency’s mission is greater than the impact of the government’s use of the system being exposed

Examples:

• Map services
• Public Certificate Authorities (e.g., Let's Encrypt, DigiCert) and DNS Resolvers
• Document and Address verification services
• Non-IT service providers such as airline ticketing or ride sharing systems

Out of Scope Detailed Example - Janitorial Services Scheduling: An agency sends building information and access information to a cloud scheduling portal used by their janitorial service company. The company uses the information to ensure that buildings are serviced and that janitors can access the building.

Analysis: Acquired non-IT service; cloud tool use is incidental; does not maintain federal information for the agency.

Out of Scope Detailed Example - Verification Services: An agency uses an address-validation service API which returns a true/false “match” and then discards the data. The service doesn’t retain the federal information and there is little risk as the service is authoritative for the information provided (addresses), making it a service that falls outside the FedRAMP scope.

Analysis: Provides commercial data; temporarily processes federal information; does not maintain federal information for the agency.

In Scope Detailed Example - Verification Services (Identity): An agency uses a cloud Identity Verification service requiring users to submit PII. The service collects, processes, and stores this sensitive federal information (PII) on behalf of the agency to perform identity proofing and for later review. Maintaining federal PII for an agency function necessitates FedRAMP authorization.

Analysis: Collects and stores sensitive federal PII on behalf of the agency.

Ancillary services whose compromise would pose a negligible risk to Federal information or information systems, such as systems that make external measurements or only ingest information from other publicly available services

When FedRAMP Doesn’t Apply: The agency determines, through a specific risk analysis, that the compromise or failure of the ancillary service would pose a negligible risk to federal information or information systems based on the agency's specific use. This determination may vary by agency and use case.

Key Tests:

• Makes external measurements or ingests only public information
• Doesn’t control or have privileged access to agency systems
• A failure or compromise would not compromise the delivery of agency services

Examples:

• Basic upstream traffic filtering/DDoS (no decryption, negligible availability requirements)
• Basic CAPTCHA services on public facing non-sensitive sites and forms
• Public web analytics and uptime monitoring (Pingdom, StatusPage)
• Unauthenticated vulnerability and code scanning tools for public facing components or code

Out of Scope Detailed Example - Public Monitoring Tool: An agency uses an external service to monitor its non-critical public website/API availability via pings, logging uptime, and sending alerts.

Analysis: Externally measures public endpoints; does not ingest or store sensitive federal data.

In Scope Detailed Example - Integrated Monitoring System: An agency integrates an Application Performance Monitoring (APM) service into its internal applications. This service collects sensitive federal data like distributed traces and detailed logs from internal sources, often via installed agents or privileged API access to other internal systems.

Analysis: Handles internal, non-public federal information; possesses privileged access to internal systems.

Summary Table

Exclusion Category (from M-24-15, Sec 3)	When FedRAMP Doesn't Apply (Core Condition)	Key Tests / Considerations
1. Single Agency Systems: Info systems for only one agency's operations, hosted on cloud, not offered as a shared service or using a shared responsibility model	The service is exclusively for a single agency's operations and not intended for reuse or reconfiguration by other agencies	• Single agency has full operational & configuration responsibility • No assessment intended for reuse by others
2. Social Media & Communications Services: Used according to agency social media policies	The service is not an authoritative repository for federal information, and its unavailability would not result in the loss of federal information	• Used per agency policy (incl. Records Act) • Primary purpose: external communication • Not authoritative source for federal info • All federal info within is intended for public use
3. Search Engines	The search engine is used primarily for public information discovery and does not store, index, or maintain internal federal information on behalf of the government	• Primary function: public info discovery • Does not collect/maintain federal info for agencies • Users instructed not to input sensitive federal info
4. Widely Available Commercial Information Services: Provide commercially available info to agencies; do not collect federal info (on behalf of the government)	The commercial information service does not collect or maintain federal information on behalf of the government	• Provides commercial services • May temporarily process fed info (e.g., address) but doesn't collect/maintain for the government • Agency never needs its info back from the service • Risk of exposure accepted (mission impact > exposure risk)
5. Ancillary Services (Negligible Risk): Compromise poses negligible risk to federal info/systems (e.g., external measurement, public info ingestion)	The agency determines through risk analysis that the failure or compromise of the ancillary service poses negligible risk to federal info and systems. Risk assessment is agency-specific	• Makes external measurements or ingests only public info • Doesn't control or have privileged access to agency systems •A failure or compromise would not compromise the delivery of agency services

[jsantore-cgc]

First off, kudos. This is one of the cleanest, clearest guidance docs I have seen from FedRAMP. Thank you. Please use this as a model.

There are a few issues worth considering:
a- an agency customer (so the business users, not their security group) thinks 'must be FedRAMPed' even though by the above guidance FedRAMP wouldn't apply. This is the disconnect between a well meaning consumer treating FedRAMP as a hard requirement even when FedRAMP does not apply. I have, in the past, to alleviate concerns with government customers who aren't savvy enough to understand, provided an attestation of 'non-applicability of FedRAMP' (particularly for COTS products that would be installed in the agency customer's own cloud environment.) An on-prem solution does not require FedRAMP. Any way to educate agencies, especially in the sales/procurement cycle about when FedRAMP doesn't apply, would be much appreciated.

b- Add-on components that may be cloud native. Consider an agency on prem solution (either physically on prem, or in agency cloud environment), but there's a new mobile device connector allowing tablets to somehow integrate with that that solution. I assume the add-on and associated supporting infrastructure would not itself require FedRAMP authorization, even if it's cloud hosted.

c- It is worth explicitly calling out the 'rolodex exception' on contact information so it is not deemed Federal Data requiring protection. By
Rolodex exception, I mean names and contact information. This is more PII specific, but worth addressing.

2.3 Exception of Business Rolodex Information OMB M-07-16, Footnote 6, establishes the flexibility for an organization to determine the sensitivity of its PII in context using a best judgment standard. The example provided in footnote 6 addresses an office rolodex and recognizes the low sensitivity of business contact information used in the limited context of contacting an individual through the normal course of a business interaction. The Privacy Overlays refers to this example from OMB M-07-16, Footnote 6, as the “Rolodex Exception.” PII meeting the “Rolodex Exception” typically presents a very low risk to privacy for the individual or the organization and will not trigger implementation of the low, moderate, or high Privacy Overlays for a system containing only this type of information. Consistent with NIST and CNSS tailoring guidance, the “Rolodex Exception” is a scoping decision that, when applicable, helps organizations avoid unnecessary expenditures of resources based on a risk determination for this limited subset of PII. `

For the purposes of implementing the low, moderate, and high Privacy Overlays, PII that may be included in this “Rolodex Exception” is limited to the following business contact information:
• Name (full or partial)
• Business street address
• Business phone numbers, including fax
• Business e-mail addresses
• Business organization `

An example of an information system which may meet the parameters of the Rolodex Exception include office rosters that contain only business contact information. Before choosing to apply the Rolodex Exception, an organization must consider the sensitivity of the PII based on the complete context in which it appears. Business contact information alone can be sensitive under certain circumstances, such as in association with a tax return or on a list of individuals under investigation for fraud, waste, and abuse. Consider, also, whether the contact information includes a blend of business and personal information (e.g., a business phone number may be a personal device, or a business address may be a residential address of a home office). If, after exploring contextual considerations, the organization determines that a system’s use of the business contact information is limited to business contact purposes, then the organization may apply the Rolodex Exception.
(https://www.commerce.gov/sites/default/files/opog/privacy_overlays_entire_document.pdf)
(There may be a better canonical source than this, but you get the idea. This was the first one I found)

[rgutwein]

1. Clarify “Shared Responsibility Model” Language in Category 1
The distinction between a single-agency system and a shared responsibility model is a critical scope determinant. However, the current phrasing may be ambiguous for hybrid deployments.

Suggestion: Include an example where a system is deployed by one agency but leverages reusable modules or containerized services that may later be shared. Clarify whether intent for reuse triggers “shared responsibility” considerations even if only one agency is currently using the system.

2. Address FedRAMP Scope for AI Services Consuming Public vs. Internal Data
The guidance on search engines and AI chatbots is a strong start, but the rapid adoption of AI services (especially LLMs and foundation models) warrants further elaboration.

Suggestion: Include examples for AI services integrated into agency workflows (e.g., classification, summarization, or autonomous action-taking) and how FedRAMP scope applies when these services:

1. Process public-only prompts
2. Train on or store internal agency data
3. Act autonomously on agency systems

3. Encourage Structured Boundary Documentation via OSCAL or Machine-Readable Format
To support consistent application and encourage reuse across agencies, the interpretation guidance should endorse structured documentation formats such as OSCAL.

Suggestion: Reference OSCAL system and component definition models for documenting out-of-scope exclusions and scope logic (e.g., metadata flags such as "out-of-scope": true with justification). This supports future FedRAMP automation and assessment reusability.

4. Expand on “Negligible Risk” and Risk Analysis Requirements for Ancillary Services
The ancillary services section leaves discretion to agency-specific risk determinations, but there is a risk of inconsistent application.

Suggestion: Recommend using a basic impact analysis or checklist aligned to FIPS-199 categorization for evaluating whether a service poses negligible, moderate, or elevated risk to confidentiality, integrity, or availability. This adds structure while preserving flexibility.

5. Clarify the Scope Interaction with Non-FedRAMP CDNs and Edge Services
Many CSPs rely on third-party CDNs or edge compute platforms (e.g., Fastly, Cloudflare) to accelerate delivery of agency applications. It's unclear how these should be categorized when they do not store federal data but handle encrypted or sensitive traffic.

Suggestion: Include explicit examples of:

1. A non-FedRAMP CDN acting as a pass-through with no decryption → out of scope

2. A CDN performing TLS termination, WAF rules, or caching sensitive responses → in scope

This guidance will greatly aid CSPs, 3PAOs, and agencies in scoping FedRAMP efforts appropriately, reducing unnecessary burden while maintaining high assurance levels. The decision trees, test questions, and illustrative examples strike a pragmatic balance.

I support formalizing this guidance as dynamic Technical Assistance under FedRAMP and encourage ongoing updates as new cloud patterns and technologies evolve.

Thank you again for the opportunity to provide feedback and for FedRAMP’s commitment to modernizing cloud security and compliance in alignment with M-24-15.

[rpalmer-gsa]

Thanks so much for the feedback!

Regarding your first point on clarifying the "Shared Responsibility Model": To ensure we understand correctly, could you provide a bit more detail about the specific scenarios you envision? For instance, are you thinking more about shared infrastructure services an agency might use internally and then offer to other agencies? Or are you speaking about the sharable nature of the software modules/containers themselves? What parts of the assessment would be reusable?

Across the other questions and scenarios you outline, we have worked to define "Key Tests" as a way to help agencies navigate situations and scenarios that aren't explicitly outlined. Do you find that the "Key Tests" offer a solid foundation for making determinations based on the scenarios you outline in items 2,4, and 5? Are there ways we can improve the concept of "Key Tests," or outline additional tests that may be missing?

Finally, do you have thoughts on what might be needed to clarify the interaction between the Scope of FedRAMP Technical Assistance (this) and the Minimum Assessment Scope RFC-0005.

[rgutwein]

@rpalmer-gsa

Regarding the Shared Responsibility Model clarification: Yes, the intent was to encourage clearer delineation of when reuse or multi-agency consumption transitions a system into FedRAMP scope, particularly in modular or containerized architectures. For example, an application may be developed by one agency for exclusive use today, but designed with reusable microservices or containerized components (e.g., Docker images, Terraform modules) that another agency could eventually leverage. It would be helpful to confirm whether intent to reuse or potential for reuse (even if unrealized) influences the scoping determination, especially if those components are already decoupled for broader adoption.

On Key Tests, I do think they offer a strong initial framework, and I support their expansion. It might help to anchor each test in structured logic, potentially aligning to OSCAL fields (e.g., authorization-boundary, information-type, out-of-scope: true, etc.) to support automation and reproducibility across agencies and tooling. This could also support consistent reuse in hybrid use cases.

As for the interaction between this guidance and the Minimum Assessment Scope RFC-0005, a helpful clarification could involve scoping boundaries for third-party services (e.g., CDNs, AI tools) that may not store federal data, but impact confidentiality or availability due to privileged positioning (e.g., TLS termination, traffic analysis, WAF enforcement). This may sit at the intersection of both guidance documents and would benefit from further harmonization.

Thanks again for the opportunity to contribute.

[wisecryptic]

interesting discussion. AI seems fairly easy to classify today but I would be interested to see how that may evolve, especially when when AI talks to another AI

[Christcpd]

Great document. Lots of excellent examples. "Agency teams use collaboration platforms (e.g., Slack, Teams)" More of these types of examples. The more the better. As @jsantore-cgc pointed out, I too have had to have deep discussions with people around FedRAMPing their environment because they didn't understand and the examples were lacking. I would suggest expanding this document or including an appendix that highlights other out of scope examples.

As for AI, I would approach that as a completely separate item from Search Engines. It is so widespread and quickly becoming ubiquitous, it really is a different animal than a search engine. AWS has a Generative AI Security Scoping Matrix that breaks the AI use cases to 5 different scopes (1-5). You can see it here: https://aws.amazon.com/ai/generative-ai/security/scoping-matrix/ Scope 1-3 all use public of pre-trained models. 4-5 train or augment on your data.

In this AI section, calling out the use of Federal Data in prompts will be paramount to proper scoping as well. Example: Worker uploads a Word document to ChatGPT asking it to create an executive summary. In Scope? Out of Scope? That document is now stored in the AI for use by that user in the future. It doesn't train the model but the model can reflect on it for future responses.

Circling back, the use of everyday examples is awesome. AI could use lots of examples all on its own.

[wisecryptic]

great document. Thanks for including AMPS as an example.
concerning social media platforms, I have some food for thought on hybrid social platforms - places like telegram, locals, whatsapp etc. these are unique in that sometimes communications are broadcast to the public, sometimes to distinct public groups, sometimes to a single end user that is external to normal agency communications. These are special cases where PII or other sensitive data may be appropriate to release, but it doesn’t make sense to in-scope the entire service, only to understand and implement certain protections around the communication, particularly in policy and encryption areas. As described in the guidance, Agency-to-Agency communications or Agency-to-partner communications should be classified differently than these agency-to-external communications.

[austinsonger]

1. The “Single Agency Systems” section needs clarification for IaaS-based multi-tenant deployments that are logically isolated but technically reside on shared infrastructure.

   • Suggested Language: Clarify whether “not offered as a shared service” refers to logical or physical isolation, and whether reuse of templates or architecture invalidates exclusion.

2. AI model platforms often allow users to input sensitive data to tune or retrain models.

   • Suggestion: Add a scenario around MaaS offerings that include persistent storage of model weights updated using federal data.

3. The phrase “authoritative repository for federal information” is used across multiple sections.

   • Suggestion: Include a glossary or consistent definition for “authoritative source” vs. “transient processor” to avoid misinterpretation across agencies.

4. Agencies increasingly use external cloud services for inference-only workloads (e.g., ML model execution on Fed data without training).

   • Request: Add clarification on whether FedRAMP is required when a CSP model runs inference on internal data, even if the model itself isn’t fine-tuned or retained.

5. Several observability or scanning tools use installed agents or API tokens to monitor systems.

   • Recommendation: Clarify that agent-based integrations or privilege elevation would disqualify a tool from being treated as “negligible risk” or ancillary, even if used passively.

6. Commercial Info Services – Address Temporarily Stored PII

   • Clarify whether temporary retention of PII (e.g., email, address, name) by commercial services like ride-share APIs, for billing or fraud prevention, crosses the FedRAMP applicability threshold.

7. Add a Flowchart for Determining FedRAMP Applicability

   • The current “Key Tests” sections are helpful but verbose. A simple decision flowchart or matrix would make it easier for agencies to operationalize this guidance, especially during ATO onboarding or acquisition reviews.

[vedigaurav]

Great Document !! Please expand scope to address below areas as well, if possible for more clarity.

1. Clarify SaaS vs PaaS vs IaaS Applicability
   The RFC would benefit from explicit guidance distinguishing FedRAMP applicability across SaaS, PaaS, and IaaS service models. In practice, vendors frequently misinterpret whether hosting on a FedRAMP-authorized PaaS or IaaS is sufficient for compliance. Including examples for each model, especially in shared responsibility contexts, would help CSPs and agencies align expectations during procurement and authorization planning.
   Suggestion: Expand the guidance with examples of how FedRAMP scope differs for SaaS vs PaaS vs IaaS services. Many vendors struggle to understand when their platform or integration points bring them into scope based on service model responsibilities.

2. Address Bring Your Own License (BYOL) Use Cases
   Please consider addressing BYOL scenarios, where an agency deploys a COTS product in its own FedRAMP'ed cloud environment, using licenses from a vendor. These cases often create confusion over whether the vendor must pursue a FedRAMP authorization even though the software is not hosted or managed by them. Clear guidance would help vendors respond appropriately to procurement inquiries and prevent misapplication of FedRAMP requirements.
   Suggestion: Clarify how FedRAMP applies when agencies procure software through BYOL and deploy it in their own cloud environments. Vendors are often asked to “FedRAMP” these cases even when they don’t host or manage the service.

3. Add Clarification for Use of Cloud APIs
   It would be helpful to provide guidance on systems that interface with cloud services solely through APIs. If an agency system transmits limited federal data through public APIs—such as for metadata lookups, analytics, or messaging—does that constitute processing that falls under FedRAMP scope? Adding examples and risk-tiered thresholds for API use would clarify applicability.
   Suggestion: Address scenarios where an agency system makes API calls to a cloud service that processes limited federal data. Is occasional data transit via public APIs enough to require FedRAMP authorization?

4. Provide Examples for Temporary or Non-Persistent Use
   Please consider clarifying how FedRAMP applies to short-term or non-persistent uses of cloud services, such as in pilot projects, proof-of-concept deployments, or internal innovation sprints. Agencies and vendors are uncertain whether brief use with limited federal data triggers FedRAMP requirements. Explicit exemptions or scoping guidelines for such ephemeral deployments would be helpful.
   Suggestion: Include guidance for services used briefly or in pilot form (e.g., beta testing, Non-Prod environments, mock testing). Agencies and CSPs often debate if temporary usage triggers FedRAMP.

5. Clarify Responsibilities for Federal Integrators
   More clarity is needed around system integrators who build and manage custom workloads for agencies on top of FedRAMP-authorized infrastructure (e.g., AWS, Azure). What responsibilities fall to the integrator vs. the infrastructure provider regarding FedRAMP scope and controls? This is especially relevant for tailored government solutions that reuse platform services.
   Suggestion: System integrators often host agency workloads on FedRAMP-authorized infrastructure but provide custom components. More clarity is needed on how their services are scoped and assessed.

6. Address Use of AI Assistants Integrated with FedRAMP'ed Tools
   As AI-powered assistants such as MS Copilot, Google Gemini, ChatGPT may become integrated into FedRAMP-authorized tools, it's increasingly important to clarify whether their data access, inferencing, or autonomous actions introduce new scope boundaries. These assistants may handle prompts containing sensitive federal data or act within an application environment, raising concerns aligned with Executive Order 14110 (Safe, Secure, and Trustworthy AI) and OMB M-24-10 (Advancing Governance, Innovation, and Risk Management for Agency Use of AI).
   I recommend this guidance explicitly reference above EO and OMB memorandums to ensure that embedding AI assistants in authorized tools does not create inadvertent compliance or data privacy issues. Practical examples involving AI summarization, document processing, or task automation within federal environments would help agencies and vendors apply FedRAMP in line with emerging AI governance frameworks.
   Additionally, alignment between FedRAMP scope definitions and evolving AI use case categorization frameworks (e.g., those from NIST and DHS) could improve consistency in oversight, especially when AI features interact with sensitive data or execute decisions.
   Suggestion: As AI assistants such as MS Copilot, Google Gemini, ChatGPT get integrated into FedRAMP-approved productivity suites, guidance should clarify whether their data access or actions change the compliance boundary.

[pete-gov]

comments received via email from Microsoft:

Current Language/ Section	Proposed Language/Comment
Social media and communications platforms used in accordance with agency social media policies	We propose including communication policies alongside with social media policies.
This technical assistance is designed for reasonable people to have reasonable discussions about FedRAMP applicability based on their specific use of a cloud service.	We propose updating this to: The technical assistance provided here cannot address all potential scenarios and represents only a subset of examples to foster meaningful discussion around applicability. It remains the agency responsibility to identify all relevant issues that they must consider in making their decisions regarding applicability.
When FedRAMP Doesn’t Apply: The service is not an authoritative repository for federal information, and its unavailability would not result in the loss of federal information.	if this statement is also true for data.gov it should be referenced there as well for clarity i.e., data.gov is not the authoritative source of datasets shared; nor would its unavailability result in the loss of federal information. That type of confluence will help readers see the similarities between examples.
Out of Scope Detailed Example - AI search chatbot: An agency uses a public AI Chatbot search to troubleshoot technical issues with a video conferencing system. Search queries of public or non-sensitive federal information may be logged by the vendor, but not FOR the agency. Because no internal data is accessed or trained on, FedRAMP doesn’t apply	Agencies will need to ask thoughtful questions here to understand how internal data may (and may not) be used in combination with AI queries. As such, we propose updating this to: In scenarios where no internal agency data is accessed or otherwise utilized by the AI chatbot FedRAMP doesn't apply.

[pete-gov]

comments received via email from Schellman:

Comment #	Section	Quote	Comment	Recommendation
1	Search Engines	Public web search engines (e.g., Google, Bing, Lycos) using only public or non-sensitive federal information Public AI Chatbots (e.g., ChatGPT, Claude, Grok) using only public or non-sensitive federal information	The draft uses the term "non-sensitive federal information". It's not clear how this would relate to 800-60 / the security categorization process. In addition, the Minimum Assessment Scope (MAS) just refers to "federal information" in the context of OMB Circular A-130 and does not distinguish between "sensitive" or "non-sensitive".	The PMO should clarify what is meant by "non-sensitive federal information" when it comes to the applicability of FedRAMP.
2	Ancillary services whose compromise would pose a negligible risk to Federal information or information systems, such as systems that make external measurements or only ingest information from other publicly available services	When FedRAMP Doesn’t Apply: The agency determines, through a specific risk analysis, that the compromise or failure of the ancillary service would pose a negligible risk to federal information or information systems based on the agency’s specific use. This determination may vary by agency and use case.	The draft notes that the agency would make this determination through a "specific risk analysis". Would this be the sponsoring / partnering agency that would make this determination or would all agencies with a valid ATO on file have input? Agencies have different use cases / risk appetites so this may pose challenges if there is no central oversight.	The PMO should clarify what should be included in a "specific risk analysis" and set expectations for CSOs that are being used by multiple agencies / have multiple valid ATOs on file.

[pete-gov]

comments received via public comment form:

Timestamp	Agency/Organization	Primary Stakeholder Community	Public Comment	Section Number
5/23/2025 13:15:13	Salesforce	Cloud Service Provider (CSP)	Section: Information systems that are only used for a single agency’s operations, hosted on cloud infrastructure or platform, and are not offered as a shared service or do not operate with a shared responsibility mode Text: "The service is exclusively for a single agency's operations and not intended for reuse or reconfiguration by other agencies." Comment: Does this include SaaS? If so, how can a CSP and agency know ahead of time if a SaaS will forever only be used by a single agency? Proposing that we add guidance here that states that, if a platform does intent to become multi-tenant in the future, then it must get FedRAMP Authorized, even if it didn't need to during single use.
5/23/2025 13:15:42	Salesforce	Cloud Service Provider (CSP)	Section: RFC-0010: FedRAMP Scope Interpretation Technical Assistance Text: - Comment: In general, this technical assistance seems more focused on helping aspring providers figure out if they need to be FedRAMP Authorized or not, rather than helping existing CSPs figure out what is and isn't in scope. We would like to see guidance clarifying federal information types and what might impact the CIA of federal information vs. what we have here.
5/25/2025 20:21:56	Public	Private Sector - Other	None.	None.
6/2/2025 7:33:09	CSP-AB	Cloud Service Provider (CSP)	Introduction - "This technical assistance is designed for reasonable people to have reasonable discussions about FedRAMP applicability based on their specific use of a cloud service. " Comment: suggest rewording to " The technical assistance provided here cannot address all potential scenarios and represents only a subset of examples to foster meaningful discussion around applicability. It remains the agency responsibility to identify all relevant issues that they must consider in making their decisions regarding applicability." Social media and communications platforms used in accordance with agency social media policies. Comment: We propose including communication policies alongside with social media policies. Social media and communications platforms used in accordance with agency social media policies - "When FedRAMP Doesn’t Apply: The service is not an authoritative repository for federal information, and its unavailability would not result in the loss of federal information." Comment: If this statement is also true for data.gov it should be referenced there as well for clarity i.e., data.gov is not the authoritative source of datasets shared; nor would its unavailability result in the loss of federal information. That type of confluence will help readers see the similarities between examples. Search engines - out of scope detailed example - "Because no internal data is accessed or trained on, FedRAMP doesn’t apply." Comment: Agencies will need to ask smart questions here to understand how internal data may (and may not) be used in combination with AI queries. As such, we propose updating this to: In scenarios where no internal agency data is accessed or otherwise utilized by the AI chatbot FedRAMP doesn't apply.	Included above
6/13/2025 14:26:38	Cloudflare	Cloud Service Provider (CSP)	-This is a great technical assistance doc; however, additional scope examples could be useful for more of the grey areas that CSPs often face (especially in hybrid scenarios). Also, the "When FR doesn't apply" sections are incredibly helpful in making these determinations and should continue to be used in future technical assistance docs. -Define "negligible risk" as described as the basis for scope determination for ancillary services -AI is mentioned under the search engine example; however, AI is rapidly expanding and growing into something much bigger than a search engine and should be treated as such. FedRAMP is notoriously behind in regulating emerging technologies and this is a great opportunity to expand on examples where AI should be considered in/out of scope.