Concept
Operational RMF is the layer nobody named, so nobody funded it.
RMF has a well-understood project — produce the package — and a well-understood repository — the system of record. Between them is the continuous work of keeping the authorization true, and it has been running on spreadsheets because it never had a name.
- Continuous, not periodic
- One boundary, not a portfolio
- Upstream of the AO
- Ref
- O-01
- Kind
- Definition
- Scope
- one authorization boundary
The definition.
Operational RMF is the continuous work of keeping a system authorization true as the system changes — as distinct from the periodic project of producing an authorization package.
The distinction is between a record and a deliverable. A deliverable is produced, reviewed and finished. A record is maintained, and the deliverables are generated from it whenever somebody needs one. Most RMF tooling is built for the deliverable, which is why so many programs can produce a beautiful package and cannot tell you whether it is still accurate six weeks later.
- Ref
- O-02
- Kind
- Model
- Layers
- three
- Failure
- cadence mismatch
Three layers, two of which already have tools.
| Layer | What it holds | Cadence |
|---|---|---|
| Engineering | The system as it actually is — code, pipelines, hosts, dependencies, scan results, architecture decisions. | Continuous. Changes many times a week. |
| Operational RMF | The authorization record. Categorization, baseline, implementation, architecture versions, evidence, assessments, determinations, findings, POA&M. | Continuous. Moves when engineering moves. |
| System of record | The submitted authorization data and the AO decision. eMASS on most DoD programs. | Periodic. Moves at submission and review. |
Engineering has excellent tooling. The system of record exists and is generally mandated. The middle layer is where the authorization actually lives, and on most programs it has no system at all — it has a share drive, a control tracker, and one person who remembers why AC-17 was tailored.
The package does not go stale because anyone was careless. It goes stale because the layer that would have kept it current was never given a place to exist.
- Ref
- O-03
- Kind
- Vocabulary
The four terms this depends on.
Precise words, because the imprecise ones — "compliance platform", "AI-powered", "single pane of glass" — describe nothing and commit to nothing.
- Operational RMF
- The continuous work of keeping a system authorization true as the system changes — as distinct from the periodic project of producing an authorization package.
- Authorization record
- The structured set of facts that constitute a system authorization: categorization, baseline, implementation, architecture, evidence, assessments, determinations, findings and POA&M. The artifacts are renderings of it.
- Evidence-grounded generation
- Producing an authorization artifact such that every statement in it traces to a fact in the record and, where applicable, to the evidence behind that fact.
- Reassess the delta
- Deriving reassessment scope from a computed change between two immutable architecture versions, instead of rebuilding the package because something moved.
- Ref
- O-04
- Kind
- Consequence
What follows from taking the layer seriously.
The definition is not decoration. If you accept that the record is the artifact and the documents are renderings, four things stop being optional.
Regeneration must be lossless.
If regenerating the SSP destroys work, the document has become the record and the record has become a draft. That is the failure the whole model exists to prevent.
Every statement needs a source.
A generated sentence you cannot trace back to a fact is a sentence nobody can defend under assessment. Evidence-grounded generation →
Change must be computable.
If reassessment scope cannot be derived, the safe default is to reassess everything — which makes security the reason engineering cannot improve the system. Reassess the delta →
Machines must not write facts.
A record whose contents may have been authored by a model without anyone noticing is not a record. Human-governed AI →
- Ref
- O-05
- Kind
- Lifecycle
One record, from categorization through continuous monitoring.
The RMF steps are not phases the record passes through and leaves behind. They are views of the same record at different moments.
-
Categorize
FIPS 199 impact levels, the high-water mark, and the system narratives that describe what is being authorized.
-
Select
NIST SP 800-53 Rev 5 baselines seeded from the NIST OSCAL catalog, tailored into a per-system control set.
-
Implement
Implementation statements, evidence, STIG applicability and the engineering data behind each control.
-
Assess
Assessment procedures, per-CCI results, determinations and findings, each bound to what it was assessed against.
-
Authorize
SSP, SAR, POA&M and the authorization package, generated from the record rather than assembled beside it.
-
Monitor
Architecture change, inventory drift, evidence continuity and the reassessment scope each of them creates.
- Ref
- O-06
- Kind
- Boundaries
What operational RMF is not.
- Not a system of record. It sits upstream of eMASS and exports to it. Replacing the repository your AO reads is not on the table and no vendor should pretend otherwise.
- Not GRC. GRC is organizational and multi-framework. This is one authorization boundary, anchored to the engineering reality of that boundary.
- Not a document generator. Document generation is an output of the layer, not the layer. A generator with no record behind it produces a correct document once.
- Not configuration compliance. Hardening a fleet to a STIG baseline is a different job, producing evidence that the authorization record consumes.
- Not an AI product. AI reduces practitioner workload inside the layer. It is not the layer, and it does not get to make determinations.
Next step