RMF continuous monitoring software
Scan monitoring is the part everyone already does. The three that quietly erode an authorization are inventory drift, STIG applicability drift and evidence expiry — because each one changes what is true without producing an alert.
Continuous monitoring is an RMF step every authorized system owes, and the software sold for it is mostly a dashboard over vulnerability scan results.
Scan results matter. They are also the thing your program is already watching, because scanners are loud and findings have severities and somebody chases them. The failures that actually erode an authorization are quieter, and they share a property: nothing generates an alert when they happen.
Four things to monitor
1. Findings. Vulnerabilities, STIG rule failures, code and dependency issues. Loud, well-tooled, already happening on most programs. Necessary and insufficient.
2. Inventory drift. What the record says is in the boundary versus what is actually running. A host added and never recorded. A container image quietly replaced. A service decommissioned but still in the SSP. Nothing alerts on this. It is discovered during an assessment, usually embarrassingly.
3. Applicability drift. DISA publishes new STIGs and revises existing ones. Your technology stack changes. The intersection — which STIGs apply to what you actually run — moves for two independent reasons and moves silently in both cases. A program assessing against a STIG set decided eighteen months ago is assessing against a fiction.
4. Evidence expiry. The annual contingency plan test that is now fourteen months old. The access review from two quarters ago. The scan that predates the last release. Determinations resting on expired evidence are not wrong exactly — they are unsupported, which is worse under assessment because it looks like nobody was paying attention.
Items 2, 3 and 4 have no natural alarm. They require someone or something to go looking, and that is what continuous monitoring software should be for.
Inventory drift, concretely
Two pictures of the same system: the architecture model in the authorization record, and the assets actually present according to scanners, cloud inventory and pipeline deployments.
Continuous monitoring means comparing them and reporting the delta. Present but not modeled. Modeled but absent. Present with different properties than recorded.
Each of those is a question rather than a violation. A host present but not modeled might be a legitimate addition nobody documented, or something outside the boundary that a scanner reached anyway, or a real problem. The software’s job is to surface it as a question and let a practitioner answer. Reporting the drift and letting the practitioner classify it is the correct division of labour.
What the software must not do is silently update the model to match reality. That would resolve the discrepancy by discarding the fact that a discrepancy existed, which is exactly the information you needed.
Applicability drift, concretely
STIG applicability is the intersection of two moving sets: the DISA catalog and your technology stack.
The catalog moves when DISA publishes or revises. Your stack moves when engineering upgrades a database, replaces a web server, adds a container platform. Neither event notifies your authorization record.
Continuous monitoring here means: sync the catalog, re-evaluate applicability against the current technology inventory, and report what changed. A newly applicable STIG that nobody has assessed. A revised STIG whose existing checklist needs merging. A STIG that no longer applies because the technology is gone.
The merge case is the one that costs most. A new revision of a STIG you already assessed should merge into the existing checklist, preserving the review comments and dispositions already recorded against unchanged rules. Tools that discard that work force a complete re-review on every release, which is why so many programs simply do not update their checklists.
Evidence expiry, concretely
Evidence has a natural currency and most systems never record it.
Set a refresh expectation per evidence type — annual for a contingency plan test, quarterly for access reviews, per-release for scans — and the record can tell you what is about to lapse before it lapses.
Then add the sharper version, which is not about dates at all: which determinations rest on evidence collected against an architecture version the system has since moved past? That question catches things dates cannot. Recent evidence about something that changed yesterday is stale. Old evidence about something that has not moved in three years is fine.
What the output should be
Not a compliance score. A score averages a missing contingency plan test against a missing comment field and tells you neither.
The output should be a set of named, actionable questions:
- These four assets are present and not in the model.
- This STIG became applicable when the database was upgraded, and has not been assessed.
- These eleven determinations were made against architecture version 24; the system is on 27, and these three of the eleven are affected by changes in between.
- This evidence expires in three weeks.
Each is specific, each has an owner, and each can be closed. That is a monitoring report a program can run its cadence on.
The relationship to the ATO
Continuous monitoring is not paperwork you do to keep an authorization. It is the mechanism by which the authorization stays true.
An ATO is a statement that a specific system, in a specific configuration, with specific controls, presents acceptable risk. Every one of those specifics can change. Monitoring is how the program knows whether the statement still holds.
That framing also explains why a dashboard over scan results is not enough. Scan findings tell you about a category of risk. They tell you nothing about whether the system you are authorized for is still the system you are running.