FedRAMP in 12 weeks: a readiness calendar, and what it cannot promise

Twelve weeks is enough to get a cloud service FedRAMP ready: choose the path, fix the boundary, close the biggest technical gaps and automate evidence. It is not enough to promise authorization or certification, because FedRAMP and independent assessors set review timing and the program is changing. Treat this as a readiness sprint.

What is the state of the program?

FedRAMP's 20x page says full rules for 20x Certification are finalised for Class A, Class B and Class C, with Class B aimed at lighter, small-scale services and Class C at common enterprise services used across an agency, and that Class D is planned. The page states that the 20x approach is built on goals, continuous measurement and automatic validation. The home page lists traditionally certified services as well as 20x certified ones, and its changelog shows draft requirements still being published as of mid October 2026.

I did not find a sourced duration for any path, so this calendar does not predict one. Ask your assessor and read the current FedRAMP documents before committing a date to a customer.

What does each sprint deliver?

Sprint 1, weeks 1 to 3: decide and draw

• Week 1: confirm which agencies or customers need FedRAMP, which impact level they expect, and which FedRAMP path and class fits. Read the current requirements. Name an executive sponsor and a program owner.
• Week 2: draw the boundary. Components, data stores, admin paths, external services, personnel. Fewer components means less to prove, so challenge every inclusion.
• Week 3: build the inventory and data flows, and pick an assessor to talk to. Exit criteria: path chosen, boundary signed off, inventory complete.

Sprint 2, weeks 4 to 6: gap assessment

• Week 4: map your current controls to the requirements for your path, with an owner for each.
• Week 5: test the claims. Sample five systems for patch level, five accounts for MFA, one change from request to deployment.
• Week 6: rank gaps by effort and risk. Decide what to fix, what to change in the architecture, and what to descope. Exit criteria: gap list with owners and dates, architecture decisions made.

Sprint 3, weeks 7 to 9: fix the hard things

• Week 7: identity: strong MFA for administrators, role based access, separate admin accounts, access review.
• Week 8: cryptography and data protection: inventory of modules and key management. FedRAMP is publishing updates on cryptographic module use, so confirm current text.
• Week 9: logging, monitoring, vulnerability management and incident response, including a tabletop. Exit criteria: top gaps closed with evidence.

Sprint 4, weeks 10 to 12: automate, rehearse, engage

• Week 10: turn evidence into automated feeds with timestamps and history: inventory, configuration state, scan results, access state. FedRAMP's materials emphasise automatic validation and continuous evidence.
• Week 11: write the service description for an agency reader, the control entries and the failure criteria. Run a dry run with an outsider.
• Week 12: readiness review with your assessor, fix list, and a submission plan with realistic dates from the assessor, not from this article. Exit criteria: evidence flowing, dry run done, plan agreed.

Which things derail the plan?

• Boundary changes mid-sprint. Freeze it after week 3 except for deliberate decisions.
• Inherited services. Cloud providers, identity services and monitoring tools each bring their own status and responsibilities. Map who does what.
• Cryptography surprises. Discovering late that a component does not meet module requirements forces rework.
• Assuming a tool does it for you. Tools collect evidence. People still decide scope, risk and exceptions.
• No engineering time. FedRAMP's own lessons say cloud providers need deep engagement from engineering teams.
• Promising dates to customers. Review timing is not yours to set.

Who does what?

Executive sponsor: priorities and budget. Program owner: schedule, gap tracker, assessor liaison. Platform lead: boundary, inventory, configuration. Security lead: identity, logging, incident response, vulnerability program. Engineering: pipeline evidence and fixes. Legal or contracts: customer commitments and flow down.

What to do

1. Confirm the path and class from fedramp.gov before anything else.
2. Fix the boundary in week 3 and hold it.
3. Book assessor time early.
4. Put evidence collection in pipelines from sprint 3.
5. Run the dry run with someone who has not seen the system.
6. Share dates with customers after your assessor confirms them.

Quick check

How Safeguard helps automate this

Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously, which saves the team time in sprint 4 and afterwards. Technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Safeguard's 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 the approval level. Safeguard helps prepare and keep evidence ready. FedRAMP and independent assessors decide outcomes. Book a call.

Sources

• FedRAMP 20x
• FedRAMP home page and changelog

Fetched 18 October 2026. Baseline and rules pages returned errors when I tried them, so confirm current requirements directly.

Last reviewed: 18 October 2026.