Evidence reuse in RMF, and why most programs cannot do it
Evidence reuse depends on two facts most programs never record — which controls an artifact supports, and whether it still describes the current system. Without them, every assessment cycle rebuilds evidence that never changed.
Every RMF program has an evidence repository. Almost none of them can reuse evidence, and the reason is not discipline. It is that the two facts reuse depends on are never written down.
Fact one: what does this artifact support?
An evidence folder tells you a file exists and roughly when it arrived. It does not tell you which controls it supports, or who decided that it did.
So at the next assessment, somebody opens the folder and re-derives the mapping from the filename and their own memory. That derivation is not recorded either, so it happens again next time. Three cycles in, the person who made the original judgment has moved to another program and the reasoning is gone.
The fix is unglamorous: bind the artifact to the controls and assessments it supports at the moment it arrives, while the person uploading it still knows why they are uploading it. Relevance recorded beats relevance reconstructed, every time.
Fact two: does it still describe the system?
The second question is harder and matters more. An artifact that was accurate evidence for SC-7 eighteen months ago may now describe a boundary configuration that no longer exists.
Answering it requires knowing what changed in the system since the artifact was captured — which means the system’s state has to be versioned, and the artifact has to be locatable in that history. If the architecture is an uploaded Visio file, there is no history to locate anything in.
With versioned architecture and per-artifact binding, the question becomes mechanical: this evidence supports these controls; these controls are in the scope affected by the change between version 6 and version 7; therefore this evidence needs re-examination and the rest does not.
The reuse that actually pays
Once both facts exist, the expensive part of an assessment cycle collapses. You are no longer asking “what evidence do we have for the baseline?” — you are asking “what changed, and what evidence does that change put in question?”
For a moderate baseline, a typical architecture change puts a handful of controls in scope. The other several hundred keep the evidence, determinations and assessment context already built.
That is the difference between reassessing the delta and rebuilding the package.
Practical rules
- Bind on arrival, not at review time.
- Compute hashes server-side. A hash the uploader asserted is a claim, not an integrity control.
- Track continuity actively. Evidence going stale should surface before a review, not during one.
- Keep decisions that survive re-upload. A false-positive judgment stored on a row that the next scan recreates dies with the row, and the finding silently comes back unflagged.
- Record dismissals as decisions. A STIG that does not apply should be recorded as not-applicable with a reason and an author, not filtered out of a view.