Scoping FedRAMP means deciding exactly which cloud service offering you are putting forward, what federal data it will hold, what impact level that implies and where the boundary sits. Do it with a prospective agency in the room. Choose your path at the same time: FedRAMP is moving from the Rev5 process to a program it calls 20x.
Why is the path itself part of scoping?
FedRAMP's 20x page, fetched 18 October 2026, describes a new approach to cloud security assessment and authorization. It says the rules for 20x Certification are finalised for Class A, Class B and Class C, which it describes as available now, with Class D planned for a later phase. In its roadmap, Class B maps to Low impact and Class C to Moderate, and Class D to High. The page also says FedRAMP plans to stop accepting new Rev5 certifications on 11 June 2027, with a transition path for existing ones.
Those are FedRAMP's stated plans, and dates move. Before you scope, read the current program pages, since the right path for your service depends on the impact level, the agency and the timing.
Note also what the page says about philosophy: security should be continuously enforced, monitored and reported rather than staged for a point in time audit, and automatic validation is preferred where possible. That affects how you design evidence from day one.
What goes into the scope decision?
The service offering. One cloud service, defined as a product: what it does, who uses it, what components deliver it. If you have several products, start with one. A narrow, clean boundary is faster to document, test and defend.
The data. What federal information will the service process, store or transmit? What are the confidentiality, integrity and availability consequences of a loss? This sets the impact level. A service that handles only public information is a different conversation from one holding sensitive agency records.
The impact level. Low, Moderate or High. The level drives the number and strictness of requirements. Choose it from the data and the agency's needs, not from what you would like to build.
The boundary. Everything that processes federal data or supports the service in a way that affects its security: production infrastructure, management and monitoring tools, build and deployment pipelines, identity systems, administrative access paths and support staff access. Draw it as a diagram with data flows, then list the components in a table.
External services. Each cloud or third party service inside your design is either inside your boundary or an external dependency with its own authorization status. Write down which, and why.
People and locations. Staff who can reach the environment, and where they sit. This is often where scope surprises appear.
How do you test the boundary?
Walk five scenarios and see whether your diagram holds: a developer pushing code, an administrator logging in to production, a support engineer debugging a customer issue, a vendor updating a component and a backup restoring after failure. Wherever a path leaves the boundary or bypasses a control, either the boundary is wrong or the design is.
Who needs to be involved?
An agency sponsor or customer, your engineering lead, your security lead, whoever owns infrastructure and an assessor or advisor if you use one. Federal customers decide how much assurance they need, and the assessment is carried out by independent parties, not by you.
What mistakes recur?
- Starting the paperwork before an agency customer exists.
- Drawing the boundary around production only and forgetting build tools and admin paths.
- Choosing an impact level to fit a convenient design.
- Several products in the first boundary.
- Treating a cloud provider's authorization as covering your own configuration.
- Ignoring the shift in programs and building for a process that is closing to new entrants.
What to do
- Name the single service offering and write a one paragraph description.
- Identify the federal data types and the impact level with the agency.
- Check the current FedRAMP program pages and decide Rev5 or 20x with your sponsor.
- Draw the boundary diagram with data flows and list every component.
- Classify every external service as inside or outside, with its authorization status.
- Walk the five scenarios and fix gaps.
- Freeze the scope document and review it whenever the architecture changes.
Quick check
Does FedRAMP have more than one path now?
According to FedRAMP's 20x page fetched on 18 October 2026, it offers 20x Certification classes alongside the existing Rev5 process, and plans to stop accepting new Rev5 certifications on 11 June 2027. Check current notices.
Can we scope several products at once?
You can, but a first boundary around one service is easier to define, test and explain. Add products later.
Sources
- FedRAMP, FedRAMP 20x, fetched 18 October 2026.
How Safeguard helps automate this
FedRAMP's own direction favours continuous evidence over staged paperwork, and that is where Safeguard fits. Its compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code rather than screenshots, and monitoring runs between assessments. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability inside the boundary you define. The remediation agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and set the approval level. Safeguard does not authorize or certify you, and independent assessors and agencies make those decisions. Book a call.
Last reviewed: 18 October 2026.
