RMFInsider

To enter test results in eMASS, open the control, go to its Assessment Procedures (AP) or Test Results view, and for each CCI record a result (Compliant, Non-Compliant, or Not Applicable), the date tested, who tested it, and a result narrative describing what was checked and what was found. eMASS rolls the CCI results up into the control’s compliance status. That roll-up is the reason a control can look Compliant on the dashboard while a validator marks it a finding: the status was set by hand, but the CCIs underneath it have no test results, or worse, contradictory ones.

Controls, assessment procedures, and CCIs: the three layers

NIST 800-53 gives you the control (AC-2, Account Management). NIST 800-53A gives you the assessment procedures for that control: the specific things an assessor examines, interviews about, or tests. DISA’s Control Correlation Identifiers break each control requirement into atomic, testable statements with an ID (CCI-000015, CCI-000016, and so on). eMASS is organized around the CCIs because that is the level at which a validator can say yes or no without ambiguity.

Practical consequence: AC-2 in a Moderate baseline can have a dozen or more CCIs. “AC-2 is compliant” means every applicable CCI has a compliant test result. Anything less is a partial, and partials are findings.

NIST 800-53 controls explained covers the control layer; this post lives at the CCI layer.

Step by step: recording a test result

• Open the system, then the Controls tab, then the control.
• Open the Assessment Procedures (some instances say Test Results or CCI Details). You see each CCI with its text, its current result, and history.
• For each CCI, click Add Test Result.
• Set the result: Compliant, Non-Compliant, or Not Applicable.
• Set the test date (the date the check was actually performed) and the tester.
• Write the result narrative: what you examined, what setting or evidence you saw, and the artifact name that holds the proof.
• Save. Repeat for every CCI. Then confirm the control’s rolled-up status changed the way you expected.

If the artifact you are citing is not uploaded and attached yet, do that first; uploading and associating artifacts in eMASS is the companion procedure.

Writing a result narrative that survives validation

Weak: “Verified compliant.” That is a status, not a test.

Strong: “Examined the Default Domain Policy on DC01 on 2026-08-14. Account lockout threshold is set to 3 invalid attempts, lockout duration 15 minutes, observation window 15 minutes, meeting the CCI requirement. Screenshot in artifact AC-7 – Lockout Policy GPO – 2026-08.”

The strong version names the method (examine), the object (a specific GPO on a specific host), the observed value, the requirement it meets, and the evidence. A validator can retest it in two minutes. That is the whole point.

Recording a Non-Compliant result honestly

A Non-Compliant CCI result should create or link to a POA&M item. In eMASS, non-compliant results typically prompt for that linkage. Write the narrative the same way (what you checked, what you found, what the gap is), then reference the POA&M ID. Systems with a few honest Non-Compliant results and matching POA&M items look mature. Systems with 100% Compliant results and a 40-item POA&M look like someone did not connect the two, and validators notice. Entering a POA&M in eMASS covers the other half of that linkage.

Not Applicable: the result that needs the best justification

N/A is legitimate when the CCI describes something the system does not have (wireless CCIs on a system with no wireless, for example). It is not legitimate as a way to avoid testing something inconvenient. Every N/A needs a narrative that states the architectural fact making it inapplicable and points to evidence of that fact, such as the boundary diagram or the hardware/software list. Validators sample N/A results specifically because they are the easiest place to hide a gap. The eMASS hardware and software baseline is usually the evidence that supports a good N/A.

Bulk importing test results

Where your instance supports it, STIG checklist (.ckl or .cklb) and SCAP results can be imported and mapped to CCIs automatically, populating hundreds of test results at once. Evaluate-STIG and STIG Viewer both produce compatible output. Two cautions from experience: import to a test system or a single control first, and review the mapping report afterward, because a checklist for the wrong STIG version will cheerfully populate results against CCIs that no longer exist in your baseline. How to apply STIGs covers producing the checklists in the first place.

What validators actually check

• Does every applicable CCI have a result, with a date inside the assessment window?
• Does the narrative describe a real test, and does the cited artifact show what the narrative says?
• Do Non-Compliant results have POA&M items, and do POA&M items have corresponding Non-Compliant results?
• Are N/A justifications consistent with the boundary diagram and hardware/software list?
• On a sample of controls, does the observed configuration still match the recorded result? This is the retest, and it is where stale results die.

The SCA-V preparation guide walks the assessment from the validator’s side of the table.

Keeping results current during ConMon

Test results age. A result dated three years ago on a control that changed with the last STIG release is, functionally, no result. Build a retest cadence into continuous monitoring: high-volatility controls (CM, SI, AC) quarterly, stable controls annually, and everything after a significant change. eMASS keeps result history, so each retest adds a new entry rather than overwriting, and that history is itself evidence that CA-7 is happening. The continuous monitoring plan post has a cadence table you can adopt.

For the ordered task list across the Assess and Monitor steps, including when to retest and when to refresh results before reauthorization, the RMF Checklist has it in sequence.