What is RMF automation, and what is it actually automating?

“RMF automation” has become a category label rather than a description, which makes it nearly useless when you are trying to work out what a tool will do for your program. It is worth separating into three capabilities that have almost nothing to do with each other.

1. Evidence ingest

Taking the output that engineering and security tooling already produces — STIG checklists, ACAS and Nessus scans, SBOMs, CI pipeline results, ticket state — and pulling it into the authorization record without anyone re-keying it.

This is the most commonly automated of the three and the easiest to verify. Ask a vendor which formats they parse, and whether a clean scan is recorded as a clean scan or discarded. That second question sounds pedantic. It is not: if a clean run is thrown away as a suspected schema error, the last dirty scan stays the newest data point forever and previously-open findings never show as resolved.

2. Impact derivation

Given that something in the system changed, working out what that change means for the authorization: which controls are now in scope for reassessment, which evidence no longer describes anything real, which assessments were performed against a state the system is no longer in.

This is the capability that is almost never automated, and it is the one that determines whether a package stays current. It is also the hardest, because it requires the tool to hold the system’s architecture as structured facts rather than as an uploaded diagram — you cannot derive the control impact of a change from a picture.

3. Artifact generation

Producing the SSP, SAR, POA&M and authorization package.

Every vendor in this market now claims this, and most of them can do it. The distinction worth drawing is whether the document is generated from an authorization record or assembled beside one. If it is assembled beside one, generation is a one-time act and every subsequent change is a manual edit to a Word file. If it is generated from the record, regenerating after a change is a routine operation — which is the entire difference between a package that stays current and one that does not.

The question that separates them

Ask what happens six months after the first SSP is generated, when a component has moved and two new STIGs apply.

A tool that automates ingest and generation gives you a fast way to produce a fresh document that nobody has checked. A tool that also derives impact tells you which parts of it need to be re-examined, and lets you preserve the rest.

That is the difference between automating the typing and automating the thinking about what changed.

What to ask a vendor

• Which scan and checklist formats do you parse, and what happens to a clean run?
• Do you hold the system architecture as structured facts, or as an uploaded image?
• When the architecture changes, what tells me which controls are affected?
• Is an assessment recorded against a specific system state, or just a date?
• Can you regenerate the SSP, or only generate it once?
• What can your AI change without a human accepting it?

The last one matters more than it looks. If the honest answer is “anything it extracts”, then what you have automated is the introduction of unverified claims into an authorization package.