RMFInsider

To run a report in eMASS, open your system and go to the Reports tab (on some instances it sits under System Details or in the left navigation), pick the report type, set any filters, and export to Excel or PDF. The reports you will actually use as an ISSO are the Control Status report for compliance percentages, the POA&M export for open findings and milestones, the System Report for the one-page summary leadership wants, and the Package reports when a submission is in flight. Everything else is occasionally useful and mostly noise.

Here is which report answers which question, how to read the columns, and the two ways ISSOs misread them in front of their ISSM.

The Control Status report

This is the report behind the number everyone quotes: “we’re at 87% compliant.” It lists every control in the baseline with its compliance status (Compliant, Non-Compliant, Not Applicable), its implementation status, its approval stage in the CAC, whether it is inherited, and the count of associated artifacts and test results.

How to run it

• Reports tab, choose Control Status (sometimes labeled Control Compliance or Control Summary).
• Filter by control family if you are answering a family-specific question, otherwise leave it unfiltered.
• Export to Excel. The on-screen view is fine for a glance; the export is what you will pivot.

How to read it

The compliance percentage eMASS displays by default counts Not Applicable controls as satisfied. That is legitimate if the N/A justifications are real, and it is how a system with weak evidence still shows a pretty number. Before you repeat the percentage upward, filter to N/A and read the justifications. A system with 60 controls marked N/A because “the system does not use wireless” when it has a wireless controller in the boundary is a finding waiting to be written.

Second thing to check: controls marked Compliant with zero artifacts and zero test results. Sort by the artifact count column. Those controls will not survive the CAC, and the compliance number is overstated by exactly that many. How the approval chains work explains what happens to them next.

The POA&M export

The POA&M report lists every open and closed weakness with its severity (CAT I, II, III or Very High through Low depending on your instance), the source (ACAS scan, STIG, SCA finding, self-assessment), the responsible role, scheduled completion date, milestones, and current status. It is the report your ISSM will ask for on a Friday afternoon and the one the AO’s staff reads most carefully.

Columns that matter

• Scheduled completion date versus today’s date. Overdue items with no milestone update are the first thing a reviewer circles.
• Milestones with dates. An item with a completion date and no interim milestones reads as “we have not started.”
• Risk acceptance / mitigation fields. If an item is being accepted rather than fixed, the justification and the accepting authority have to be filled in, or it is just an open finding with a nicer label.
• Source and identifier. Findings from ACAS carry the plugin ID; STIG findings carry the vuln ID. Reviewers cross-check these against the scan and checklist artifacts. Mismatches are how a POA&M loses credibility.

If the POA&M itself needs work, how to write a POA&M and POA&M management cover the writing and the tracking.

The System Report

This is the one-page-ish summary: system name and acronym, categorization (confidentiality, integrity, availability impact levels), authorization status and expiration date, the ISSO, ISSM, and AO of record, boundary summary, and compliance rollup. It is what you hand a program manager who asks “where are we on the ATO” and does not want the 300-row spreadsheet. Run it as a PDF, check the authorization termination date on it against your own calendar, and keep the current version in your working folder. When leadership asks a question at 4:55 pm, this report is the answer nine times out of ten.

Package reports

Once a package is created, eMASS can generate the package summary, the control set included in the package, and (depending on your instance and role) the SAR view with the SCA’s findings and risk determinations. Use these when a package is in the PAC and someone asks what exactly was submitted. The package snapshot is frozen at submission, so if you have updated controls since, the live Control Status report and the package report will disagree, and that difference is not a bug. It is the answer to “why does the SCA still see the old value.”

Two ways ISSOs misread reports in front of the ISSM

Quoting the compliance percentage without the validation percentage

Compliant means you said so. Validated means someone checked. A system at 95% compliant and 40% validated is a system that is 40% done. Report both numbers, every time, and nobody gets surprised during assessment.

Reading the POA&M count instead of the POA&M age

Twelve open items that were opened last month and have milestones is a healthy system. Twelve open items from two years ago with no updates is a system the AO will ask hard questions about. The count is the same; the story is not. Add an “age in days” column to your export and sort by it. The continuous monitoring checklist builds that review into a monthly rhythm.

A weekly report routine that takes fifteen minutes

• Monday: export Control Status. Note compliant, validated, and the count of Compliant-with-no-artifact controls. Fix three of those this week.
• Monday: export POA&M. Flag anything due in the next 30 days and anything overdue. Send owners a one-line reminder.
• Friday: run the System Report as a PDF and file it with the date. Twelve months later, you have a paper trail that shows continuous monitoring actually happened, which is a control in itself.

If you would rather track open findings in a spreadsheet built for this workflow, the ISSO’s POA&M Tracker is the one I use alongside the eMASS export.