RMF evidence management
Evidence management is not storage. It is binding — recording which objectives and determinations each artifact supports, where it came from, when, and what was already decided about it, so its relevance is a fact rather than something a person remembers.
Every program has evidence management. It is usually a folder tree on a share drive, organized by control family, with a naming convention that three of the five people follow.
That arrangement stores evidence. What it does not do is record what any of it means, and that gap is where the cost sits.
Storage versus binding
Storage answers: where is the file?
Binding answers: which objectives does this artifact support, which determinations rest on it, where did it come from, when, who judged it, and what did they decide?
The difference shows up the moment somebody other than the original author needs the evidence. A
folder called AC-2 containing eleven files tells you those eleven files are about account
management. It does not tell you which of them supports the specific CCI about disabling inactive
accounts, which are superseded, which was the basis for the current determination, or which one the
assessor already dismissed as a false positive.
That knowledge existed. It lived in a person. When the folder is all that remains, the next assessment re-derives it — and gets a slightly different answer.
Four things every piece of evidence should carry
What it supports. An explicit relationship to the objectives and determinations it bears on. One artifact frequently supports several, and one determination often rests on several artifacts. It is a many-to-many relationship and a folder cannot express it.
Where it came from. Which scanner, which pipeline run, which upload, which person, on what date. Provenance is what lets a reviewer trust the artifact without re-running the thing that produced it.
What was decided about it. The false positive judgment, the risk acceptance, the “this finding is out of boundary” call. These decisions are expensive to make and they are made repeatedly on most programs because nothing retains them.
When it expires. Some evidence has a natural currency — an annual contingency plan test, a quarterly access review, a scan from before the last release. Evidence with no refresh expectation silently becomes historical, and nobody notices until an assessor does.
The re-adjudication tax
If you want one number to justify improving evidence management, this is it.
A vulnerability scan on a moderately complex system returns hundreds of findings. Some are false positives. Some are out of boundary. Some are accepted risks with documented rationale. Working through them takes an assessor days.
Next quarter the scan runs again and returns the same findings, because the underlying conditions have not changed. If nothing preserved last quarter’s judgments, those days are spent again. And the quarter after that.
Preserving adjudication across uploads is not a sophisticated feature. It requires stable finding identity and a stored decision. But it is the single change practitioners notice most, because it removes work that everyone knew was pointless and nobody could avoid.
The same applies to SBOM component findings, STIG rule dispositions, and anything else that arrives repeatedly in a machine-generated pile.
Automated evidence is different from uploaded evidence
Two kinds, and they need different handling.
Uploaded evidence — a policy document, a signed agreement, a screenshot, an interview note. A person put it there, and its provenance is that person and that date. It usually has a long life and a human refresh cycle.
Ingested evidence — a scan result, a pipeline security report, a STIG checklist, an SBOM. It arrives automatically, repeatedly, and in volume. Its provenance is a system and a run. It has a short life and it supersedes itself.
Treating ingested evidence like uploaded evidence produces a folder with four hundred timestamped scan exports and no way to know which is current. Treating uploaded evidence like ingested evidence produces a system that expects a contingency plan test to arrive from a pipeline.
The record needs both shapes, and it needs to know which is which.
Evidence and the architecture version
An artifact describes the system as it was when the artifact was produced. If the system has since changed, the artifact may still be valid or may not — and the difference depends on whether the change touched the thing the artifact was evidence about.
Recording which architecture version evidence was collected against makes that answerable. A scan from before a component moved across a trust boundary is not evidence about the current configuration of that component, and a record that knows both facts can say so.
Without it, evidence currency is judged by date alone, which is a poor proxy. Old evidence about something that has not changed is fine. Recent evidence about something that changed yesterday is not.
What good looks like in practice
- Every determination shows the evidence behind it, and every artifact shows the determinations resting on it. Both directions, both navigable.
- Ingested evidence arrives already attached to the objectives it bears on, rather than landing in an inbox for a person to route.
- A false positive judged in March is still dismissed in September, automatically, with the March rationale attached.
- Expiring evidence is visible before it expires rather than after an assessor finds it.
- The SSP and SAR cite evidence by reference, so “what supports this sentence?” is a click.
The test
One request, in the live product:
Pick any statement in the generated SSP. Trace it to the fact behind it, then to the evidence supporting that fact, then to where the evidence came from and when.
If the chain exists, that takes under a minute. If it does not, no amount of folder discipline will substitute, because the relationships were never recorded — they were remembered, and memory does not survive a personnel change.