TL;DR

Part 1 covered why you probably need a partner. This post is the framework explainer I wish I’d had on day one — what FedRAMP actually is, the three impact levels and how to think about which one applies, the document set that everything revolves around (SSP, SAR, POA&M, ATO), and the live transition from Rev5 to 20x that is reshaping all of the above in 2026. No prerequisites beyond “I’ve heard the word FedRAMP and now I have to do something about it.”

Introduction

In Part 1 I argued the first move is choosing the right advisory partner — and that the 90-day promise is the audit window, not the journey. Several people pinged me with the same follow-up question, in roughly these words: “OK fine, but what is FedRAMP, actually? Not the brochure version — the engineer version.”

This is that post. I’m writing it as the FedRAMP explainer I needed when the federal opportunity first landed on the table, before I’d talked to a single partner. If you’ve done SOC 2 or sat near FIPS work, some of this will feel familiar. A lot of it won’t.

What FedRAMP Is (And What It Isn’t)

FedRAMP — the Federal Risk and Authorization Management Program — is the US government’s framework for authorizing cloud services to handle federal data. It was established in 2011, run jointly by GSA, the Office of Management and Budget, and the federal CIO Council, and it’s the gate any cloud service must pass through to be sold to a US federal agency.

What it is:

  • A standardized authorization model built on NIST SP 800-53 controls
  • A reusable trust signal — one authorization, many agencies (the “do once, use many times” promise)
  • A continuous monitoring program, not just a point-in-time certification
  • A public marketplace of authorized services that any agency can buy from

What it isn’t:

  • A security certification you “pass” and forget about
  • Equivalent to SOC 2 — same family, very different rigor and scope
  • Optional, if you want to sell SaaS to a US federal agency
  • A purely technical exercise — half the work is organizational

The shortest mental model I’ve found: SOC 2 is a trust signal you build for commercial customers. FedRAMP is an authorization regime you operate inside of, indefinitely.

The Three Impact Levels

FedRAMP authorizations come in three flavors — Low, Moderate, and High — each tied to a FIPS 199 categorization of the data your service will handle. The right impact level is the one that matches the highest category across confidentiality, integrity, and availability of the data the agency intends to put into your system.

Low (≈ 125 controls). Public-facing data, low sensitivity. Public websites, low-impact SaaS, services where loss of confidentiality, integrity, or availability would have a “limited adverse effect.” Often the right starting point if your federal use case is light-touch.

Moderate (≈ 325 controls). The default for most commercial SaaS targeting federal customers. CUI (Controlled Unclassified Information) typically lives here. Serious adverse effects from a breach but not catastrophic ones. If your federal customer says “FedRAMP” without specifying, they usually mean Moderate.

High (≈ 425 controls). Law enforcement, emergency services, financial systems, health systems with severe-impact data. Catastrophic adverse effects from a breach. Significantly more rigorous — additional crypto, additional personnel requirements, additional continuous monitoring depth.

A few things that surprise teams:

  • You authorize at one level. You cannot “almost” be at a level. You’re at Low, Moderate, or High. There is no “Moderate-minus.”
  • Going up a level later is a re-authorization, not an upgrade. Don’t pick High aspirationally. Pick the level that matches the agency conversation you actually have.
  • The control counts above are approximate and shift slightly between Rev4 and Rev5. Treat them as orders of magnitude, not exact numbers.

For most non-US ISVs entering the federal market for the first time, Moderate is where the conversation lands.

The Document Set (Where Most of the Work Lives)

If FedRAMP has a beating heart, it’s the document set. Four artifacts do almost all of the work:

System Security Plan (SSP). This is the big one. The SSP is the comprehensive description of your system — boundary, architecture, components, data flows, and most importantly a per-control implementation statement for every applicable 800-53 control. For Moderate, that’s hundreds of “here’s how we satisfy AC-2” paragraphs. It’s the single most expensive document you’ll write, and the one that takes longest. Under 20x, the SSP becomes machine-readable (OSCAL) — but the underlying work doesn’t go away, it just changes format.

Security Assessment Report (SAR). Written by the 3PAO — not by you. After the 3PAO assesses your system against the SSP, the SAR documents what they found: which controls are fully implemented, which are partially implemented, which are not implemented, and the evidence supporting each conclusion. The SAR is what an authorizing official actually reads.

Plan of Action and Milestones (POA&M). The living finding-tracker. Every weakness identified in the SAR — and every weakness found in continuous monitoring afterward — lands in the POA&M with a remediation owner, a target date, and a severity rating. The POA&M is updated monthly. Auditors look at the quality of the POA&M as a signal of how seriously the CSP runs the program.

Authority to Operate (ATO). The actual authorization. Issued by an agency (legacy path) or under the 20x program directly. The ATO is what you can point at when an agency procurement officer asks “are you FedRAMP authorized?” It’s revocable, it’s monitored continuously, and it expires — typically a three-year cycle with continuous monitoring in between.

There are supporting documents too — Privacy Impact Assessment, Incident Response Plan, Information System Contingency Plan, Configuration Management Plan, and a long tail of policy documents. But the four above are the load-bearing artifacts. Everything else exists in service of them.

How Authorization Actually Happens (Legacy Path)

Under the legacy Rev5 path — still the default in early 2026, though that changes by Q3 — there are two routes to an ATO:

Agency ATO. A single federal agency sponsors your authorization. You work with that agency’s CISO and authorizing official, the 3PAO assesses against the SSP, the agency issues the ATO, and the authorization is then reusable by other agencies through reciprocity. This is by far the most common path.

JAB P-ATO (Joint Authorization Board Provisional ATO). The JAB — composed of CIOs from DoD, DHS, and GSA — issues a provisional authorization that any agency can adopt. Higher bar, longer process, more prestigious. Mostly used by the very largest CSPs.

The agency path is more accessible but introduces the agency sponsor problem: you need a US federal agency willing to sponsor your authorization before you can start. That has historically been the single biggest blocker for non-US CSPs. You’re trying to sell to the government, but you can’t get authorized until the government decides to buy.

20x changes this materially.

What 20x Changes (The 2026 Reality)

FedRAMP 20x is the GSA-led program redesign that has been quietly reshaping the entire framework since 2025. The motivation was simple: the legacy program had become too slow, too document-heavy, and too expensive to scale. Authorizations were taking 18-24 months and costing $2-5M per CSP. Federal agencies were buying around the program rather than through it. Something had to give.

The 20x shifts I’m watching closely as a platform engineer:

Machine-readable everything. The SSP, the SAR, the POA&M — all moving to OSCAL (Open Security Controls Assessment Language), a structured XML/JSON/YAML format defined by NIST. Instead of 600-page Word documents, you submit structured data that systems can ingest and validate programmatically. This is the change that makes everything else possible.

KSIs replacing narrative controls. Key Security Indicators are observable, measurable assertions about the state of your system — things like “all production access requires MFA,” “no IAM users in production accounts,” “all images signed and verified.” A KSI is something a machine can check, not a paragraph an auditor reads. Under 20x, your evidence pipeline emits KSIs continuously, and the 3PAO’s job becomes validating that the pipeline measures what it claims to measure.

No agency sponsor required. This is the unlock for non-US CSPs. Under 20x, you can pursue authorization directly without first finding an agency willing to sponsor you. The authorization stands on its own and agencies can adopt it through the marketplace.

Continuous validation, not annual snapshots. Legacy FedRAMP had monthly continuous monitoring layered on top of an annual reassessment. 20x leans harder on the continuous — if your KSIs are emitting and verifiable, the annual reassessment becomes a much smaller event.

The pilot data is encouraging. The first 20x pilot completed authorization in 119 days. Cost estimates are running 70-80% lower than legacy. The default authorization path is expected to become 20x in the second half of 2026.

The catch: 20x assumes you operate the way a 20x CSP needs to operate — heavy IaC, automated evidence emission, OSCAL-native tooling. The teams that benefit most are the ones who built modern platforms in the first place. If you’re carrying a decade of click-ops, 20x is harder, not easier.

Where SOC 2 and FIPS Already Helped You

If you’ve done SOC 2 — the 2026 refresh post covers what’s shifted in the last year — you already have parts of FedRAMP done in spirit, if not in letter:

  • Access control discipline maps directly to the AC family in 800-53
  • Audit logging and monitoring is most of the AU family
  • Change management and configuration discipline lands in CM
  • Risk assessment cadence maps to RA
  • Vendor management maps to SA-9 and the rest of SA

The reciprocity isn’t automatic — FedRAMP demands more depth on most of these — but the muscle memory is real. A good advisory partner will start every engagement by inventorying what you already have evidence for, not by handing you a 325-line spreadsheet to start filling out from zero.

The Building for Compliance series covers the supply-chain side — SBOM, provenance, SLSA, cosign — which lands on the SI, CM, and SA families inside FedRAMP. That’s the bridge I’ll walk in Part 3.

What I’d Tell My Past Self

The trap I almost fell into: treating FedRAMP as a bigger SOC 2. It isn’t. SOC 2 is a trust signal you publish to commercial customers — the report goes out, the deal closes, the controls keep operating. FedRAMP is an operating posture you live inside of, with monthly reporting, quarterly reviews, annual reassessments, and a POA&M that never empties out.

The right way to think about it: you’re not buying a certificate. You’re joining a club whose dues are paid in continuous monitoring evidence, and whose membership terminates the moment your evidence pipeline stops producing.

That reframing changed how I sequenced the platform work. Less “what do we need to pass an audit?” More “what does the steady-state look like, and how do we get our platform to operate that way naturally?”

Conclusion

That’s the framework, end to end. Three impact levels, four core documents, two authorization paths (one legacy, one new), and a transition happening in real time that is rewriting how the whole thing works.

Part 3, going live shortly, picks up where this leaves off: where FIPS-validated crypto lands inside the FedRAMP boundary, how the supply-chain work from the Building for Compliance series maps to specific FedRAMP control families, and what changes when “FIPS-validated” stops being a best practice and becomes a hard requirement of your authorization. Less framework, more code paths.

Further Reading