What Your Assessor Will Actually Test: A CR26 Blueprint for FedRAMP 20x and Rev5

FedRAMP is rebuilding how cloud services get assessed. The Consolidated Rules for 2026 (CR26) replace the System Security Plan with a machine-readable Security Decision Record. FedRAMP 20x moves certification from documented plans to measured outcomes through Key Security Indicators. And FedRAMP’s new assessor guidance tells independent assessors to examine “both the security capability and the machinery that produces the reported result.”

Agencies haven’t all moved with it. Many still want a traditional Rev5 package, with the SSP, SAP and SAR their authorizing officials know how to review, and FedRAMP will keep accepting Agency sponsored Certification applications until June 11, 2027. Defense contractors face a third expectation: FedRAMP Moderate equivalency for cloud services that handle CUI under DFARS 252.204-7012, which is still measured against the Rev5 Moderate baseline.

That leaves providers building for two or three audiences at once, and it is tempting to treat 20x and CR26 as a problem for later. That is the expensive choice. What CR26 asks assessors to look for, including reproducible evidence, an inventory that can be trusted, automation that can be tested, and findings that sit unedited in the provider’s own record, applies to both 20x and Rev5 under the new rules, and it is exactly what makes an equivalency or legacy Rev5 package hold up under scrutiny.

The way ahead is to build the evidence once, as measured, machine-readable output, and present it in whatever package the customer needs. This post is a blueprint for doing that: what the rules require on each path, what FedRAMP now tells assessors to look for, and what an assessor will actually ask to see. The checklist near the end pulls it onto one page.

First, Which Rules Are You Actually Under?

CR26 is one rulebook with two certification types. Rev5 “follows a legacy approach based primarily on documented plans while 20x follows a modern approach based primarily on measured outcomes” (FRD-CTY), and you pick one per offering (FRC-CSO-POP).

Two nuances catch people. First, 20x Class A is built on a framework you already hold (a prior Rev5 authorization, SOC 2 Type II or GovRAMP within the past 12 months, per FRC-CLA-ASF), and independent assessment is optional for it. Second, 20x Class D isn’t finished. SDR-CSX-KMT leaves its specifics “to be set during the 20x Phase 4 Pilot.” FedRAMP has since proposed pilot requirements (RFC-0036), but only providers that already hold 20x Class C can join the pilot, and FedRAMP plans to fold the final Class D rules into the Consolidated Rules for 2027. If you need the highest class of assurance on a near-term timeline, Rev5 Class D is the path that exists today.

Rev5 then forks again on how you arrive. For a Rev5 Program Certification, FedRAMP’s Rev5 assessor guidance says the legacy SAP and SAR are “not necessary”; the assessment lands in the SDR and Certification Package Overview. For a sponsored Agency Certification, the assessor still delivers the legacy package to the agency, and “A modern assessment is also required!”

What the IVV Rules Actually Say

The Independent Verification and Validation (IVV) rules apply to both types and split the work cleanly. The part that changes the relationship most is where the assessor’s findings end up: inside your own record, next to your words, where agencies read them.

Two details are worth knowing. The rules file notes that “inappropriate modification” means “changing the underlying intent” of the assessor’s content; you can reformat the assessor’s summary, but you can’t soften it. And the 20x guidance says provider and assessor “may work in the same platform,” but “their records must remain distinct.” If your SDR lives in a GRC tool or a Git repository, give assessor findings their own fields or files with their own write permissions, so the history shows who wrote what.

On independence, CR26 lets you ask your assessor for advice and lets the assessor give it, “UNLESS doing so is likely to compromise the objectivity and integrity” of the assessment (IVV-CSO-RAA, IVV-IAS-SHA), and bars an assessor from assessing an offering within two years of advising it (REC-IAS-SEP). An assessor can tell you your denominator comes from the wrong place. An assessor can’t build your reconciliation job and then grade it.

What the SDR Looks Like on Each Path

Both types use the Security Decision Record, in human-readable form and as JSON that validates against FedRAMP’s schema. The unit of the record is what differs.

One metric nuance matters for planning. FedRAMP’s October 8 update removed FRC-CSX-MOT, which had asked Class C applicants for six months of persistent validation history. What remains is SDR-CSX-KMT: a Class C SDR carries up to a year of daily metric data “including status of persistent validation,” and the Class B version is now a SHOULD. A new offering without that history isn’t locked out; the rule’s note asks for the mechanisms to be in place and an agreement to meet the requirement. The history only starts when the measure does. Also note the SDR metadata field for “source of update” (SDR-CSO-MTD): if a job wrote the update, the record should name the job.

The Machine-Readable Output Assessors Look For

FRC-CSO-JSN requires JSON that is “valid against the corresponding JSON schema” whenever a rule names one, and the SDR rule does. FedRAMP’s Security Decision Record schema (dated 2026-06-24) is one file for both certification types: FedRAMP rules for everyone, KSIs for 20x, controls and parameter values for Rev5, plus ports and protocols.

Here is roughly what an assessment-ready 20x KSI entry could look like. The field names come from the schema; the values are illustrative.

{
  "ksiId": "KSI-IAM-AAM",
  "ksiImplementationStatus": "Implemented",
  "ksiImplementation": [
    "Every identity source provisioned from the HR feed via the IdP pipeline."
  ],
  "ksiValidation": [
    "Daily iam-lifecycle-recon compares every identity source to HR events.",
    "Quarterly canary account outside the pipeline must be flagged in one cycle."
  ],
  "ksiAssessment": [],
  "ksiTests": ["iam-lifecycle-recon@v3.4.1", "iam-canary-selftest@v1.2.0"],
  "ksiEvidence": [{
    "evidenceType": "Log",
    "evidenceDescription": "1,284 accounts, 0 exceptions, canary flagged.",
    "evidenceLocation": "https://evidence.example.com/iam-aam/2026-09-23",
    "lastUpdated": "2026-09-23"
  }]
}

What an assessor checks in that entry: the ksiTests values point to versioned jobs that can be rerun, not prose. The evidence is a Log or Configuration record with a location the assessor can open, not a Screenshot, which the schema allows but which gives an assessor the least to validate. The lastUpdated date matches the cycle the summary claims. And ksiAssessment is empty, because the assessor writes it; the schema makes it required, so it gets filled when the assessor’s summary lands under IVV-IAS-SUM.

On Rev5, the same file carries each control with its parameter values:

{
  "controlId": "AC-11",
  "parameterValues": [
    { "parameterId": "ac-11_odp.02", "parameterValue": "15 minutes" }
  ],
  "controlImplementationStatus": "Implemented",
  "controlImplementationDescription": "Enforced by IdP policy lock-15 ..."
}

This is the entry an assessor diffs against live configuration. If the identity provider’s policy says 30 minutes, the JSON is wrong, and so is your SDR. Because the schema makes that comparison mechanical, providers should run it themselves before the assessor does. The same goes for portsAndProtocols: every exposed port in the boundary should appear, with its encryption stated.

Two gaps are worth knowing about. The schema’s status values are Implemented, Not Implemented and Partially Implemented, while SDR-CSF-CTF also lists Planned, Alternative Implementation and Not Applicable. And there is no dedicated field for the historical metrics SDR-CSX-KMT requires. Until FedRAMP reconciles those, say what you mean in the description fields and point to the metric history from ksiEvidence, so neither the assessor nor an agency has to guess.

How Much Automation Is Enough?

On 20x, FRC-CSX-VVK sets a floor on automated methods to persistently verify and validate each KSI, rising by class. The rules don’t define what a separate “method” is. A practical test: two methods should be able to disagree.

How Assessors Test a KSI Measure

FedRAMP’s 20x guidance tells assessors to “examine both the security capability and the machinery that produces the reported result,” and lists seven questions for tracing a validation end to end. It also says, in a line worth printing out, “Automation is not proof by itself.” At the keyboard, those seven fold into four working questions.

Population. Every denominator gets traced back to your authoritative inventory (KSI-PIY-GIV), scoped to the Minimum Assessment Scope you defined under MAS-CSO-IIR. In practice that means the cloud provider’s resource APIs (an AWS Config aggregator, Azure Resource Graph, Google Cloud Asset Inventory) across every account, subscription or project in the boundary, reconciled against IaC state. FedRAMP’s guidance says it directly: “Do not stop at the dashboard. A green status can hide missing accounts, incomplete inventory, faulty integrations, or a manual step that never happened.”

For log coverage, that means reconciling against the list KSI-MLA-LET requires you to maintain, not the SIEM’s own source list.

expected = inventory.resources(scope="MAS") & logging_policy.required_sources
observed = siem.sources(last_seen_within="24h")
silent   = expected - observed   # should log, did not
unknown  = observed - expected   # logging, not inventoried: scope gap
coverage = len(expected & observed) / len(expected)

Reproduction. Your engineer reruns the measure live, from a query pinned in version control, with the raw row counts behind the percentage. FedRAMP tells assessors to prefer “live demonstrations, direct queries, machine-readable results, and historical trends,” and for automated measures they almost always win over a saved export.

Known bad. With your team driving, a condition the measure should flag gets planted in a safe corner of the boundary: a canary account created in the console instead of the pipeline (KSI-IAM-AAM), a security group rule changed by hand (KSI-SVC-ACM), a stopped log forwarder on a non-production host (KSI-MLA-OSM). Then everyone waits a cycle. Cleanup goes in the change log, because KSI-CMT-LMC applies to the test too.

History. A missed run is fine if it shows up as a missed run; FRD-PER only requires that “the status of persistent activities will always be known.” A missed run that shows up as a clean day is a finding. The best histories are append-only, with run ID, timestamps, query version, row counts and result written to storage with object lock or equivalent retention.

What a Strong KSI Summary Should Actually Look Like

The 20x guidance tells assessors to explain, for each KSI, “what was tested, how it was tested, what the evidence showed, and where risk or uncertainty remains.” The assessor’s summary can only be as specific as yours. Here is the difference for KSI-IAM-AAM:

At Class C, the strong version would also name its second automated method, such as the daily iam-lifecycle-recon job from the JSON entry earlier, which reconciles every identity source’s accounts against the HR feed and catches a pipeline that silently stopped processing terminations.

The Rev5 Side of the Table

Rev5 providers don’t escape any of this. The Rev5 SDR asks for the verification and validation in place for every control, and where that evidence comes from automation, the same four questions apply. Two Rev5 risks come up most. The first is parameter drift: FRC-CSF-ACP requires every organization-defined parameter recorded in the SDR, so when the SDR says a 15-minute session timeout and the identity provider says 30, that is a verification failure you could have caught by diffing the JSON against live configuration. The second is leaning on the annual subset. IVV-CSF-ACF carries every negative finding into the next assessment, and IVV-CSF-PCA says you SHOULD include all applicable controls each time.

Your Readiness Blueprint

Here is everything above on one page, organized by what an assessor will ask for on each path. If you can hand over what is in your column, the assessment moves quickly and the assessor’s summary in your SDR says what you want an agency to read.

The Practical Takeaway

• Confirm your type, class and dates. If you were planning around 20x Class D, its requirements are still waiting on Phase 4.
• On 20x, run the four tests on your five most important KSIs. Trace the denominator, rerun from a pinned query, plant a known bad, and read the history for filled gaps.
• Count your automated methods against FRC-CSX-VVK and check that each pair can disagree.
• Validate your SDR JSON against the schema and make sure every evidence location opens.
• Start the history early. A Class C SDR carries up to a year of daily metrics with validation status, and that year only fills from the day collection starts.
• On Rev5, diff SDR parameters against live configuration and get last year’s findings ready for this year’s scope. On the agency path, budget for both deliverable sets.

For a long time, an assessor’s skepticism was aimed at the control. CR26 moves it down a layer, onto the systems that tell everyone the controls are working. 20x does that explicitly, with automation minimums and metric history. Rev5 does it more quietly, through an SDR that expects verification and validation for every control.

Either way, agencies will read your measures as fact. So test them first. When the assessor sits down to rerun your numbers, the best outcome for everyone is that you already have.

If you are planning a 20x or Rev5 assessment under CR26 and want to talk through scope, timing, class and what the assessment will need from you, Lunarline’s Independent Assessment team is happy to walk through it.