🔒 Closed beta: four products · 📉 Corrections record: AI mistakes, counted by class and fed back into the next run · 📢 New post: FedRAMP Release 2026.10.13.01 Added 279 Control Mappings and Has No Changelog Entry · 📝 Also fresh: Atlassian CVE-2026-21589 Added to KEV; CVE Record Rejected the Next Day · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 KSI Quick Check: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPComplianceConMon

FedRAMP Security Decision Record: No Assessor-Populated Fields

On September 8 someone opened a question in FedRAMP's community discussions with a screenshot of a Security Decision Record field layout and a reasonable ask: which of these attributes is the independent assessor supposed to populate, and is the Owner column on them right?

It is a good question because it is the question every provider coming out of Rev5 will ask. Under the old shape there was a document the 3PAO wrote and handed to you. You put it in the package. The authorship was obvious because the artifact had a cover page with a company name on it.

A FedRAMP maintainer answered the same day, and the answer was that the provider is responsible for all Security Decision Record content — including the independent verification and validation results from its assessor. The assessor supplies a summary of its process and findings, and then verifies that what it supplied made it in without inappropriate modification. Every field in the screenshot, the reply said, gets populated by the provider.

That is one person's answer in a discussion thread, which is exactly the kind of thing the ticket that sent me here says to check rather than repeat. So I went and read the rules. They say the same thing, and they say it more bluntly.

The rules put every obligation on one side

SDR-CSO-FRR is the rule that creates the record at all. Providers MUST supply a Security Decision Record, in human-readable and JSON formats, covering seven things for each applicable FedRAMP rule. Here is the list, because the shape of it is the whole story:

  • an explanation of how the rule is followed, or why it isn't and what that costs customers
  • verification that the implementation is appropriate for the rule
  • validation that the implementation is in place and working as intended
  • independent verification
  • independent validation
  • any responses or clarifications to the comments in the independent verification or validation
  • rule-specific artifacts, where they apply

Items four and five describe work the provider cannot do. They are still the provider's items. The rule does not say "the assessor supplies independent verification" — it says the provider must supply a record that includes it. The assessor's work is an input to an obligation that never leaves the provider's side of the table.

The matching rule on the assessor's side is IVV-IAS-SUM, and it is short. Assessors MUST supply the provider with a high-level summary of their assessment process and findings for each FedRAMP Practice, "this summary will be included by the provider in the FedRAMP Security Decision Record." Attached to it is the note that reframes the whole arrangement:

FedRAMP does not require a separate Security Assessment Plan or Security Assessment Report for FedRAMP 20x or FedRAMP Rev5 Certifications; this information is expected to be included in the Security Decision Record by the cloud service provider.

There is no SAR anymore. Not a renamed SAR, not a SAR with a JSON wrapper — the deliverable with the assessor's name on the cover is gone, and what replaces it is text the assessor hands over for the provider to carry. The parallel rule IVV-IAS-OSA does the same for the overall summary, which lands in the Certification Package Overview instead, and notes that FedRAMP supplies no template for it.

Two rules then guard the handoff from either end. IVV-CSO-ICP says the provider MUST include assessment results "without inappropriate modification," with inappropriate meaning a change to the underlying intent — reformatting for presentation is fine. IVV-IAS-VIP says the assessor MUST verify that what it supplied actually appears in the package unmodified. The assessor's authorship was not replaced by nothing. It was replaced by a right of inspection.

FedRAMP has already had to say this out loud once. CPO-CSO-OSA carries a changelog entry dated June 25, 2026 — the day after the Consolidated Rules launched — reading "added after official launch to clarify that the provider is required to supply this artifact." The confusion in that discussion thread is not an outlier. It is the default reading, and the program patched the rules against it within twenty-four hours of publishing them.

The schema is where it stops being a matter of interpretation

Prose can be argued with. A JSON Schema cannot, and the Security Decision Record schema settles the question in a way worth looking at directly.

The assessor's entire footprint in that file is two properties. frrAssessment on each FedRAMP requirement and ksiAssessment on each Key Security Indicator, both arrays of a single shared definition:

assessmentStatement — Description of how the control/requirement/ksi is assessed by an independent validator.

Type: string. That is the whole definition. No author. No date. No assessor identifier. Nothing pointing back to the engagement it came from. The independent assessment of a requirement is a paragraph of Markdown sitting in an array, structurally indistinguishable from frrImplementation, which the provider writes about itself.

The word owner does not appear anywhere in the schema. The only attribution field in the entire document is metadata.updateSource — "source of the update (e.g., person, team, or automated process)" — and there is exactly one of those, for the record as a whole.

The assessor does appear by name in the machine-readable package, exactly once, and in the other file. The Certification Package Overview schema has an assessor object with two required properties: a name, and a six-digit FedRAMP-assigned assessorID. An identity, registered at the package level. Not an authorship claim on anything inside it.

And the "Owner" the original question was looking for does exist — it is just somewhere else entirely. CPO-CSO-MTD requires the name, title, and contact information of the official who is responsible and accountable for the Certification Package. One accountable human, named once, at the top. Not a per-field attribute, and not an assessor.

The thread's follow-up question was whether the provider should expect its assessor to hand over the tests it ran and the artifacts it reviewed. In schema terms those are ksiTests and ksiEvidence, and both are required on every Key Security Indicator entry alongside ksiImplementation, ksiValidation, and ksiAssessment. ksiTests is an array of bare strings. ksiEvidence is an array of evidence objects, each with a type drawn from a fixed list — Log, Report, Screenshot, Configuration, Policy, Procedure, Audit Record — plus a description, a URI, optional inline text, and a last-updated date. The maintainer's answer was that the provider populates both, and the assessor verifies that the provider's tests and evidence produce the expected results. The schema agrees: there is nowhere in either field for an assessor to put anything.

One wrinkle worth noticing if you are about to build against this. The schema's top-level required list names only certificationPackageOverviewUri and fedRampRequirements. keySecurityIndicators is not on it, and neither is metadata — both of which the rules make MUST. Validating clean against the schema is not the same as satisfying SDR-CSO-FRR. The schema is the floor of the file format; the ruleset is the actual bar.

What this costs you in practice

The useful reframe here is that the Security Decision Record is not a document you assemble at assessment time. It is a system you operate, and the assessor's output is an input stream into it.

A few things follow from that, and they are the kind that are cheap to build now and expensive to retrofit.

Budget for ingest, not for filing. Your assessor will hand you prose, per FedRAMP Practice, with no template behind it. That text has to land in frrAssessment and ksiAssessment entries in a file that also has to stay current — CPO-CSX-CPM requires Class B providers to maintain the Certification Package at least monthly, with the expectation that automation does it as changes occur. The assessor's words will age inside a record that keeps moving around them.

Keep the original, because the "unmodified" rule is two-sided. You are allowed to reformat for presentation. Your assessor is required to come back and check that you did not change the intent. Keeping the as-received text next to the as-published text makes IVV-IAS-VIP a diff instead of a conversation, which is a kindness to both of you and considerably faster.

The schema will not hold your provenance, so hold it yourself. If you want to know which engagement a given ksiAssessment string came from, or which version of the measure it was written against, none of that survives into the published record. That is not a gap you can file a bug about — it is what the field is. Track it on your side and treat the SDR as a rendering.

Evidence type and assessment depth are different questions. evidenceType accepts "Screenshot" as a perfectly legal value for your own evidence. IVV-IAS-VIM and IVV-IAS-VEF both tell assessors that verification and validation require "reviewing the actual measures themselves at a technical level, such as reviewing underlying code as appropriate; don't simply review documentation or screenshots." Those rules govern different acts and do not conflict, but the practical read is clear enough: a screenshot can be a row in your record and still not be a basis for anyone's conclusion about it.

As for when any of this bites — the Security Decision Record and Independent Verification and Validation rulesets carry identical dates. Optional adoption opened 2026-07-04. Obtaining an initial certification has required them since 2026-07-04. Maintaining an ongoing certification requires them from 2027-01-01, with the grace period ending on the first FedRAMP independent assessment started after that date. Both rulesets apply to Class B and Class C, not to Class A.

One rule moved after the thread closed

Here is the part you only find by re-reading the rules rather than the discussion about them.

Read the Security Decision Record ruleset for Class B and Class C side by side and they differ in exactly one place: SDR-CSX-KMT, the historical-metrics rule. Everything else is word for word. The Independent Verification and Validation ruleset is word-for-word identical between the two classes, down to the notes.

And on October 8, 2026, a month after that discussion closed, SDR-CSX-KMT changed. The Consolidated Rules changelog records it: MUST became SHOULD for Class B, and the rule was clarified to state that persistent validation status is one of the metrics to include. The same release removed FRC-CSX-MOT as duplicative with it.

So today, Class B should include a summary of each metric over the past 30 days and up to the past year where available. Class C still MUST, and carries an additional line Class B does not: all daily metric data, including the status of persistent validation, up to the past year.

That is the sole structural difference between the two classes in this record, and it moved five weeks after a thread about this record was marked answered. Which is the quiet argument for reading rule changelogs on a cadence rather than catching up through commentary — including this post's.

Where this lands for what we build

We've written before about how little separates Class B from Class C once you diff the rulesets, and this is the same finding from a different angle: the program keeps moving work from "produce a document when asked" toward "operate a record continuously."

That shift is most of why NAICOM looks the way it does. It is the orchestration layer our own engineering runs on, and its useful property here is that the record is a byproduct rather than a deliverable. Every dispatch writes a row carrying its issue key, role, verdict, and reason. Every correction to an agent's claim is stored as a class alongside what was claimed and what turned out to be true. None of that exists to satisfy SDR-CSX-KMT. It exists because the work produced it — which is the only way you end up with a year of daily metric data on the day someone asks whether you have a year of daily metric data.

The ingest problem is the same shape. Text arrives from outside the system, has to land in a specific field of a record that is otherwise machine-maintained, and has to still be provably the same text months later when someone checks. That is a pipeline, and the providers who treat it as one will have a much duller January than the providers who treat it as a mail merge.

The question worth carrying

If your assessor vanished tomorrow and left you only the text it had already sent, could you still produce a complete, current Security Decision Record from your own systems?

Under these rules that is not a hypothetical about assessor availability. It is just a description of what you are already required to be able to do.

Reference