Requirement ID: MAS-CSO-IIR
The requirement
Providers MUST identify a set of information resources to assess for FedRAMP Certification that includes all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering; this set of information resources is the cloud service offering. (force: MUST)
What does this mean?
Before you can assess a cloud service for FedRAMP Certification, you first have to define exactly what you are assessing. This requirement asks providers to draw that boundary.
This requirement is about scoping and it puts that responsibility on the provider. Rather than being handed a boundary, the provider has to define one, anchored to a single reference point: federal customer data. Anything that touches that data, or could affect how secure it is, falls inside the line; anything genuinely disconnected stays out.
Two deliberately broad words do the work. “Handle” captures the full data lifecycle, not just one moment, and “information resource” captures the whole operation, not only technology, but the people and processes running it. That breadth keeps the boundary from being drawn artificially small. And the set the provider identifies doesn’t just describe the offering. it is the offering, which is why getting it right matters: it defines what gets assessed and certified, and what doesn’t.
This article is also a LinkedIn newsletter. If you would like to receive it straight to your inbox, subscribe here.
Why does this matter?
The assessment scope determines what gets tested and what does not. If a resource that touches federal customer data is left out of the identified set, it never gets assessed, and a real risk to that data can go unexamined.
An incomplete or overly narrow boundary can create a false sense of assurance. An agency may authorize a service believing the full data path is covered, when in reality a component that processes or stores their data was excluded. That gap could later surface as an unassessed vulnerability, a data exposure, or an availability failure in a part of the system no one reviewed.
Getting this identification right is the foundation for everything that follows in the certification.
What could implementation look like?
There is no single mandated method for identifying the set. One approach could involve mapping the full lifecycle of federal customer data, from the point it enters the service to the point it is disposed of.
Teams might start by tracing where federal customer data is uploaded, processed, stored, and transmitted. From there, they could identify the technical resources along that path, such as compute, storage, networking, and code, and then the supporting resources that could affect confidentiality, integrity, or availability, such as identity systems, monitoring tools, and backup services.
Because information resources include non-technical elements, the set may also include relevant policies, procedures, and the personnel responsible for operating the offering. Reviewing the draft boundary with engineering, security, and product stakeholders could help catch resources that are easy to overlook.
Example scenario
A fictional provider offers a managed document collaboration service used by federal agencies. Agencies upload documents, which are the federal customer data.
The provider traces the data path and identifies the application tier, the object storage service, the database holding document metadata linked to customer content, and the load balancers in front of the application. They also recognize that their identity provider, though it does not store documents, controls access and therefore is likely to impact confidentiality. It is included.
A logging pipeline that captures only provider-generated telemetry and no federal customer data is reviewed and determined not to handle that data, but the team documents the reasoning so the decision is traceable. The final identified set becomes the cloud service offering they submit for assessment.
What evidence could demonstrate implementation?
Examples may include:
- A data flow diagram tracing federal customer data through the offering
- An inventory of information resources included in the identified set, technical and non-technical
- Documentation explaining why specific resources were included or excluded
- Records of stakeholder reviews used to validate the boundary
- A defined description of the cloud service offering derived from the identified set
Common pitfall
A frequent misunderstanding is treating the boundary as only the machine-based components. Because information resources include personnel, policies, and procedures, a scope limited to infrastructure and code can miss managerial resources that are part of the offering. Another common weakness is excluding a component that does not store data but still controls access to it, such as an identity or key management system, which is likely to impact confidentiality or integrity.
Question for your team
Can we trace every place federal customer data flows through our service and confirm that each resource along that path, including access-control and supporting systems, is in our identified set?
Key takeaway
The scope of a FedRAMP assessment is only as trustworthy as the boundary that defines it, so every resource likely to touch federal customer data or affect its security belongs in the identified set.
Related requirements
None listed in the source data.
Have a question about putting this requirement into practice?
38North Security can help you turn the requirements into an operating model that works in practice. Talk to us →
The quoted requirement above is from the provided FedRAMP CR-26 JSON for requirement MAS-CSO-IIR. The implementation ideas, example scenario, and evidence examples are general guidance for educational purposes and should be validated against official FedRAMP guidance.
About the Authors
