📢 New post: Is It Even in Your Boundary? CVE-2026-0257 and the Question a KEV Clock Asks First · 📝 Also fresh: 20x Is Permanent Now: The Rehearsal's Over, the Rules Land in June · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPComplianceGRC

Before the Submission: What FedRAMP 20x Prep Actually Looks Like

The FedRAMP 20x Phase One pilot draft submission window opens today, May 19, and runs through May 26. Formal submissions begin May 30. The program is using the draft window to evaluate format and delivery — packages don't have to be finalized, can carry placeholder or anonymized data, and draft submissions won't influence the final authorization decision. It's a process rehearsal, on purpose.

That setup is genuinely useful. It also makes today a reasonable moment to talk about what 20x prep looks like from inside a CSP that hasn't started yet, because the most common question we hear is some version of "if the documentation burden drops 80% and authorizations happen in weeks, how hard can the prep be?"

Harder than the headline numbers suggest. Not impossibly hard — the pilot participants who've come through Phase One Low and the Phase 2 Moderate cohorts have demonstrated the path works — but the work that's left after the templates go away is the work that was always load-bearing, and it's now more visible rather than less.

A few of the areas we've seen teams underestimate.

Machine-readable packages are a different artifact

The headline 20x change is the move from Word-and-Excel templates to structured machine-readable submissions. The package is JSON, validated against the program's schema, with human-readable summaries layered on top. That shift sounds like a serialization change. Operationally it isn't, because the structured package has to be generated from somewhere — and "somewhere" is usually the part of the program that doesn't exist yet.

A team whose SSP currently lives as a Word document maintained by a compliance lead doesn't have a generator. They have a document. The path from document to structured package is either a one-time transcription (which leaves you with two artifacts that drift) or a pipeline that reads infrastructure state and emits the structured package as output (which is the destination the program is pointing at, but which takes weeks to stand up).

The Phase One draft window's "placeholder or anonymized data" allowance is a real gift here. Teams can submit a structurally valid package well before the underlying generator is fully wired up. That's worth using.

KSIs and the evidence behind them

The Key Security Indicators are the structural backbone of a 20x package. They are technical attestations — short, declarative, machine-readable — about how specific security capabilities are implemented. Each KSI is meant to be supported by evidence that a 3PAO can validate.

The translation work between "we have a control" and "here is the KSI value and the evidence behind it" is where teams spend more time than expected. The control implementation may be entirely real and entirely adequate; expressing it as a KSI with a citation that points to verifiable infrastructure state is its own task. KSI catalogs have evolved through the Phase One and Phase 2 pilots and continue to settle — keeping current with the active version, and writing the generator against the right schema, is part of the prep.

Continuous Validation Reports change the cadence

20x leans hard on continuous validation. The CVR is the artifact that carries that — periodic, machine-readable, generated from the live system rather than assembled from a quarterly evidence drive.

For teams whose current ConMon program is "run the monthly scan, deliver a PDF" the CVR cadence is a process shift before it is a tooling shift. The scans don't change. What changes is whether the evidence is continuously produced as an operational byproduct, or whether it's manually packaged at the moment a report is due. The first one works at 20x cadence. The second one doesn't, even with good tooling, because the assembly step is where teams lose days.

Existing commercial certifications can carry weight

One of the more pragmatic aspects of Phase One Low is that existing commercial certifications — SOC 2, ISO 27001, others — can support specific KSI attestations rather than requiring duplicated evidence. This is genuinely useful for teams already operating mature compliance programs in the commercial market.

The catch is that "support" isn't "substitute." The 3PAO still needs to validate that the commercial assessment scope actually covers the KSI's domain, and that the controls under the commercial framework map cleanly to the FedRAMP capability. A SOC 2 report from a year ago, performed against a scope that didn't include the specific system going for FedRAMP, doesn't do the work. Inventorying which commercial certs apply, where their scope lands, and what evidence carries across is prep that pays off — but it's prep, not free credit.

3PAO selection and the kind of engagement that fits 20x

20x assessments are technical, structured, and faster. Not every 3PAO is positioned for that kind of engagement yet. The assessor relationships that work well for traditional Rev 5 — extended documentation review, lots of interview time, narrative-heavy reporting — don't always translate to structured-package validation against machine-readable rules.

The 3PAO community is adapting, and the firms with strong Phase One Low experience are the obvious starting point. Worth scoping early; assessor availability has been one of the recurring constraints reported by Phase 2 cohort participants.

The thing that doesn't compress

Underneath all of this is the part of the work that the timeline genuinely can't shrink: knowing the system. What runs where, what it talks to, how it's configured, who has access, how changes flow. A FedRAMP authorization at any tier is an attestation about a real running system, and the attestation can only be as honest as the team's understanding of the system itself.

The teams we've worked with who moved through 20x quickly weren't the ones who had the best templates. They were the ones whose engineering teams had a clear mental model of the boundary and the data flows, and whose compliance and engineering functions were close enough that the questions answered themselves the first time. Where there's a gap between those two functions, the prep that closes it is more valuable than any tooling investment.

What today's draft window is good for

If you're a CSP that has been waiting to start, the draft submission window is a low-stakes opportunity to test what the structured submission path actually feels like. Even an obviously incomplete package, with anonymized data, exercises the generator pipeline, the schema validation, the delivery mechanism — and surfaces the gaps that would otherwise show up under formal-submission pressure on May 30.

We've been working with teams on the infrastructure-native side of this — inventory, evidence collection, KSI generation pipelines — and the pattern that's held up is to treat the early submissions as engineering iterations rather than compliance deliverables. The program seems to be inviting that posture, which is the right invitation.

Reference