RMFInsider

Continuous monitoring in eMASS is not a module you turn on. It is a set of recurring actions against the system record you already have: refreshing test results for a rotating subset of controls each year, keeping the POA&M current with real dates and real status, updating the hardware and software lists and artifacts as the system changes, reporting significant changes, and running an annual security review that produces a package the ISSM and, depending on your Component, the AO or AODR sees. The ATO letter tells you the authorization term (commonly three years) and the ConMon strategy, approved with the package, tells you the retest cadence. eMASS is where the evidence of both accumulates.

The gap between the ConMon plan on paper and what happens in eMASS is where systems drift into a bad reauthorization. I have inherited systems where the last test result on any control was dated the week of the original ATO, two and a half years earlier. eMASS did not complain. The AO, on the other hand, had opinions.

What the AO actually expects after the ATO letter

The authorization decision is conditional on the ConMon strategy being executed. In practical terms, the AO or AODR expects to be able to open your system in eMASS at any point in the term and see four things: current scan results feeding the POA&M, control test results that are not all stamped with the original assessment date, POA&M milestones that are being met or honestly updated, and a record that someone reviewed the security posture at least annually. When any of those goes stale, the system is technically still authorized and practically unsupportable, and the reauthorization will feel like a first-time ATO with extra scrutiny.

The ConMon plan you submitted with the package defines the specific commitments. Reread it after the ATO is signed. Teams write ambitious ConMon plans during the package push and forget the contents the day the letter arrives, which means the AO is holding you to a schedule you no longer remember agreeing to.

The control retest cadence: which controls, how often

The retest cadence is usually defined one of two ways. Some Components require a fixed fraction of the baseline reassessed each year (a third per year across a three-year term is common, so every control is retested once per term). Others prioritize by volatility: controls that change frequently or carry high risk (AC-2, CM-6, RA-5, SI-2, IA-5, AU-6) get annual retests, and stable controls (PE, PL, the bulk of the PS family) get retested once per term. Either way, the schedule should be written down and the controls assigned to a calendar year before year one ends.

A practical starting split for a three-year term:

• Annual, every year: AC-2 (account management, tied to your quarterly reviews), CM-6 and CM-7 (STIG compliance, refreshed from new checklists), RA-5 and SI-2 (scanning and flaw remediation, refreshed from ACAS), AU-6 (log review, with evidence the review happened), IA-5 (authenticator management), CP-9 (backup, with a restore test), and any control with an open POA&M item.
• Year one: the remaining AC, AU, and IA controls, plus SC (the boundary and crypto controls, because networks change).
• Year two: CM (baseline, change control, SIA process), CP (plan and exercise), IR (plan and test), SI (the remaining integrity controls).
• Year three: the operational and management families (AT, MA, MP, PE, PL, PS, PM, SA), plus a full walk of inherited controls to confirm every provider authorization is still current.

The year-three inherited-control check is the one that gets skipped and the one that hurts. Providers lose authorizations, change boundaries, and stop offering controls without telling the customers who inherit from them. Confirm each inheritance in eMASS annually at minimum.

Entering retest results in eMASS

Retesting a control in eMASS means entering a new test result against each of its assessment procedures and CCIs, with a new date, a new assessor, a compliance status, and updated test description text describing how you verified it. The walkthrough on entering test results covers the mechanics. Three ConMon-specific points:

• Do not overwrite history. eMASS keeps the test result history per CCI; a new result should be added, not the old one edited. The trend across results is itself evidence that ConMon is happening.
• Attach fresh evidence and associate it with the control. A 2026 test result pointing at a 2024 checklist is a 2024 test result wearing a new date.
• Keep the assessor honest. Self-assessment results entered by the ISSO are fine for ConMon in the Components I have worked with, but the test description should say “ISSO self-assessment” and describe what was actually examined. Do not label your own review as an SCA result.

If a retest finds the control is no longer compliant, mark it non-compliant and open a POA&M item the same day. The temptation to leave it compliant “until we fix it next week” is how packages end up with a compliant status and a contradicting ACAS report sitting in the artifacts tab.

POA&M upkeep: the part the AO reads first

When an AODR opens a system mid-term, the POA&M is the first tab they look at, because it is the fastest read on whether the ISSO is paying attention. The ConMon standard for POA&M items is straightforward and rarely met:

• Every open item has a scheduled completion date in the future, or a documented slip with a new date and a reason. A past-due item with no update is the single loudest signal of a neglected system.
• Milestones are updated at least monthly, with status text that changes. “In progress” for eleven consecutive months is not a status.
• New vulnerabilities from ACAS and new STIG findings are added within the timeframe your Component defines (often 30 days from discovery for CAT II and III, faster for CAT I).
• Closed items have evidence attached: the rescan showing the plugin no longer fires, the updated checklist, the CCB record for the configuration change.
• Risk-accepted items have the acceptance memo attached and a review date, because accepted risk is supposed to be re-examined, not forgotten.

Monthly is the right cadence for a POA&M pass. It fits the ACAS cycle, it is short enough that nothing slips far, and it is the interval the daily, weekly, and monthly ConMon checklist is built around.

Keeping the system record true: assets, artifacts, and changes

ConMon also covers the boring fields. The hardware and software lists should match the ACAS asset list and the actual rack. When a server is added or retired, the list changes that week. The boundary diagram gets a new version when the boundary changes. The SSP gets a revision entry whenever a control implementation changes materially. And any change that could affect the security posture (new interconnection, new data type, major software upgrade, a move to a new hosting environment) goes through the security impact analysis process and, if significant, gets reported to the AO through your Component’s significant change procedure rather than discovered at reauthorization.

The test I apply: if the AODR opened eMASS today and compared it to the system as it exists today, would anything surprise them? Surprises are what turn a routine annual review into a directed reassessment.

The annual security review: what goes in the package

The annual review is the formal checkpoint. Its exact form varies by Component (some call it the Annual Security Review, some fold it into an Annual Assessment, some require an ISSM memo), but the content the AO expects is consistent:

• A summary memo, signed by the ISSM, stating the review was conducted, the period covered, the overall posture, and any significant changes during the year.
• The retest results for that year’s scheduled controls, entered in eMASS with evidence attached.
• A current POA&M export, with a short narrative on items closed, items added, items slipped and why, and items risk-accepted.
• Current ACAS scan summary showing credentialed coverage across the hardware list and the CAT I, II, and III counts with trend against last year.
• Current STIG compliance summary per STIG applied, from fresh checklists.
• Updated hardware list, software list, boundary diagram, and any revised plans (CP, IR, CM) with the exercise or test records for CP-4 and IR-3.
• Confirmation that inherited controls were verified and the providers’ authorizations remain current.
• Confirmation that the ConMon strategy itself is still appropriate, or a proposed revision.

Assemble it in eMASS as an artifact bundle with a consistent naming convention (ASR-FY26_ prefix on every file), then route it through whatever workflow your Component uses. Where the PAC is used for annual reviews, the personnel and role check from your original submission applies again; a review stuck in a workflow because the AODR account went inactive counts, in the AO’s eyes, as a review not done.

The mistakes that turn ConMon into a reauthorization crisis

• Letting all control test results carry the original assessment date for the entire term. This is the most visible ConMon failure and the easiest to avoid.
• Running ACAS faithfully and never moving the results into the POA&M. Scanning is data collection; ConMon is what you do with it.
• Treating the annual review as a memo instead of a package. A memo with no retest results and no POA&M narrative behind it says the review was a signature, not a review.
• Skipping the inherited-control verification and discovering at reauthorization that the enclave provider’s ATO expired 14 months ago.
• Failing to report a significant change and letting the AO learn about the new cloud interconnection from the SCA.
• One person owning all of it with no alternate. ConMon is a three-year commitment; plan for leave, PCS moves, and contract turnover.

Why this matters beyond the checkbox

The purpose of continuous monitoring is that the AO’s risk decision stays informed for the life of the authorization rather than being accurate for one afternoon. The lessons from ConMon done badly are consistent: the systems that got breached or lost their authorization were rarely the ones with a weak initial package. They were the ones nobody looked at again. A disciplined monthly POA&M pass and a real annual review in eMASS are how you avoid being that system, and if you want the tracker I use to keep milestones, evidence, and slip history in one place between eMASS updates, the POA&M Tracker is the tool I built for exactly that monthly ritual.