RMFInsider

A continuous monitoring plan DoD ISSO teams actually follow doesn’t look like the diagram in NIST SP 800-137. It looks like a rotating set of obligations — scans to review, findings to triage, POA&Ms to update, evidence to stage — that never fully stops between one authorization decision and the next. If you’re new to the role, or you’ve inherited a ConMon program that’s more theory than practice, here’s what it actually looks like on the ground.

What a Continuous Monitoring Plan for a DoD ISSO Is Actually For

NIST SP 800-137 defines the Information Security Continuous Monitoring (ISCM) program as providing ongoing assurance that security controls remain effective over time, rather than assuming a point-in-time authorization stays accurate forever. That’s the whole premise: an ATO is a snapshot, and ConMon is the process that keeps the snapshot honest as the system, the threat landscape, and the environment keep changing underneath it.

In practice, that means your ConMon plan is the document — and the daily habit — that ties together scanning, patching, findings management, and reauthorization evidence into one continuous thread instead of a once-a-year scramble.

Some ISSOs inherit a ConMon plan as a static document that sits in eMASS untouched between reauthorizations, treated as paperwork rather than practice. That’s the version of ConMon that fails audits and, worse, misses real risk. The version that works is the one where the plan describes what your team is actually doing week to week, and the evidence in eMASS reflects that reality rather than a best-case description written once and forgotten.

The Cadence: What Actually Happens, and How Often

I’ll be direct about something here: there’s no single published DoD-wide document that mandates one universal scan cadence for every system, and I’m not going to pretend there is. What I can tell you is how this has worked in practice on the programs I’ve supported, which is the more useful answer anyway since your local policy and AO expectations will ultimately govern your actual schedule.

Activity	Typical Rhythm I’ve Seen	What Drives It
Vulnerability scanning (ACAS)	Regular, recurring scans — set by local policy, not a single DoD-wide mandate	Scan Asset Manager and site-level ACAS policy; see my ACAS scanning breakdown for how results actually get worked
POA&M review and update	Regular cadence tied to milestone due dates and finding severity	Local ISSM/AO reporting requirements and CM-4 security impact analysis on any change
Control assessment / reassessment	Ongoing throughout the authorization period, concentrated ahead of reauthorization	ISCM program design and the system’s authorization timeline
Full reauthorization	Tied to your system’s ATO expiration and risk posture	AO decision, informed by the accumulated ConMon evidence

The honest takeaway: don’t build your ConMon plan around a cadence you read somewhere online. Build it around what your local ACAS policy, your ISSM, and your AO actually require, and document that cadence explicitly in your plan so there’s no ambiguity when an assessor asks you to justify it.

Who Owns What: ISSO vs ISSM vs SCA in the ConMon Process

ConMon is one of the areas where role confusion causes the most dropped balls, because the three roles touch the same evidence at different points in the cycle. I’ve written a full breakdown of ISSO vs ISSM vs ISSE if you want the complete picture, but here’s how it plays out specifically in continuous monitoring:

• ISSO — owns the day-to-day: reviewing scan results, updating POA&M entries, coordinating remediation with system administrators, and staging evidence for assessment.
• ISSM — owns the program-level view across multiple systems, sets local ConMon policy, and reports status up to the AO.
• SCA (Security Control Assessor) — independently validates that the controls you’re monitoring are actually operating as documented, typically at reassessment milestones rather than daily.

If your ConMon plan doesn’t spell out who does what in this chain, that ambiguity is exactly where findings sit unaddressed until someone notices at the worst possible time — right before a reassessment.

Where Security Impact Analysis Fits In

NIST SP 800-53’s CM-4 control requires a security impact analysis on changes to the system — patches, configuration changes, and fixes all trigger it. This is the piece of ConMon that catches people off guard most often: it’s not just about scanning what’s already there, it’s about evaluating the security impact of anything you’re about to change before you change it. A ConMon plan that only covers scanning and ignores CM-4 obligations is incomplete, and it’s usually the gap an assessor finds first.

Building Your Actual ConMon Plan: The Core Sections

Whether you’re writing one from scratch or inheriting one that needs an overhaul, these are the sections I make sure exist:

• Scanning tools in use and how results feed into your POA&M — this connects directly to how you’re actually working ACAS output day to day. If you haven’t built this workflow yet, my walkthrough on how to enter a POA&M in eMASS covers the mechanics.
• Roles and responsibilities across ISSO, ISSM, and SCA for each ConMon activity.
• Security impact analysis process for any proposed change, per CM-4.
• Evidence retention — where artifacts live in eMASS and how they map to specific controls.
• Escalation path for findings that miss remediation deadlines.
• Reauthorization trigger — what accumulated evidence gets reviewed, and when, ahead of ATO expiration.

Every one of those sections should point back to a specific process, not a vague statement of intent. “We review findings regularly” isn’t a plan. “ISSO reviews new ACAS findings against the POA&M within the timeframe set by local policy, escalates anything past due to the ISSM” is.

From Evidence to Reauthorization

The entire point of doing ConMon well is that reauthorization stops being a fire drill. If you’ve been maintaining accurate POA&M entries, documenting security impact analyses on every change, and keeping eMASS artifacts current throughout the authorization period, your reauthorization package is mostly already written — you’re assembling evidence that already exists rather than reconstructing a year of activity from memory in the final two weeks.

This also happens to be one of the clearest connections back to the bigger DoD framework conversation right now: if your program is starting to talk in CSRMC phase language, your Operations-phase activity is essentially your ConMon program under a new name. Good ConMon discipline now is direct preparation for however that terminology evolves.

What Assessors Actually Want to See

When an SCA or an AO’s staff sits down with your ConMon evidence, they’re not looking for a narrative about how diligent your team has been. They’re looking for a trail they can follow without asking follow-up questions: a finding was identified on a specific date, it was entered into the POA&M with a realistic remediation date, it was tracked through to closure or formally accepted as risk, and any change made along the way had a documented security impact analysis behind it.

The gap I see most often isn’t a lack of effort — it’s a lack of a clean trail. Work gets done, but it doesn’t get documented in a way that reconstructs cleanly months later. If your eMASS artifacts and your POA&M entries tell a consistent, dated story on their own, without you needing to explain the gaps verbally, your ConMon evidence is doing its job.

Frequently Asked Questions

How often should ACAS scans run?

There’s no single public DoD-wide mandate specifying one cadence for every system. Your local ACAS policy and your AO’s expectations set the actual schedule — document whatever cadence applies to your system explicitly in your ConMon plan rather than assuming a generic industry number applies.

Who is responsible for closing POA&M findings?

The ISSO typically drives day-to-day remediation coordination and status updates, while the ISSM owns program-level reporting and the AO makes the final risk acceptance or closure decision. The specific split should be spelled out in your ConMon plan so there’s no ambiguity when a finding is overdue.

Does a security impact analysis apply to every change?

NIST SP 800-53’s CM-4 control requires a security impact analysis on changes to the system, including patches and fixes. Treat this as the default expectation for any change, and document why an analysis was or wasn’t warranted rather than skipping the step silently.

Common ConMon Mistakes I See

• Treating POA&M entries as a compliance checkbox instead of a living risk record — entries go stale, dates slip, and nobody notices until an assessor does.
• Skipping security impact analysis on “minor” changes that turn out not to be minor at all.
• Letting scan results pile up unreviewed because there’s no defined owner for triage.
• Writing a ConMon plan once and never updating it as the system, the team, or local policy changes.

None of these are exotic problems — they’re the same handful of failure modes that show up on program after program, and every one of them traces back to the plan not assigning clear ownership or not getting revisited as things change. A ConMon plan that was accurate when it was written but never touched again after the initial ATO is, functionally, no plan at all by the time reauthorization rolls around.

Every one of these is fixable with a plan that assigns clear ownership and gets revisited, not filed away. If you want a working structure for keeping POA&M entries current and tied to actual remediation deadlines instead of a spreadsheet that quietly rots, my POA&M Tracker is built around exactly that workflow.