Building on how findings become evidence? Start with How ACAS Findings Become Remediation Evidence.

Most people who have worked an ACAS scan or a STIG checklist have watched a finding turn into a POA&M item without ever seeing the step that got it there. The finding shows up red in a report, and a few days later there is a line item in eMASS with a control number attached to it. Nobody walks through how that connection actually got made.

So what links a scan result to a security control, and where does that mapping happen?

The Piece Nobody Explains: CCI

Every STIG check carries a Control Correlation Identifier – CCI – built into the checklist itself. The CCI is the translation layer between a technical requirement (disable SSHv1, enforce a password history of 24, log privileged command execution) and the NIST SP 800-53 control that requirement supports. You do not assign the CCI yourself. It ships with the STIG, and it is what eMASS reads to figure out which control a given finding belongs to.

SysAdmin translation: A STIG finding like V-220734 – SSH idle timeout not configured – carries a CCI that maps to AC-12, Session Termination. When you import that CKL into eMASS Assets, the system reads the CCI and matches the finding to AC-12 in your control set. You never type in a control number by hand.

What an AP Actually Tests

The Assessment Procedure – AP – is the testable requirement sitting underneath a control. A single control can carry several APs, and each one gets its own Compliant or Non-Compliant call in eMASS. This is why two systems can both show AC-2 as “Implemented” and still have very different risk pictures – the control passed at the level eMASS tracks, but the individual APs underneath it tell the real story of what was tested and what was not.

When an AP comes back Non-Compliant, that is one of the direct triggers for a POA&M item – not the control as a whole, the specific AP. That granularity matters when you are writing the vulnerability description later, because “AC-2 failed” is not useful to an assessor. “AP AC-2(1) failed because inactive accounts were not disabled within 30 days” is.

eMASS Does the Mapping For You – Mostly

Once scan results and STIG checklists land in the Assets Module, the Prioritized Actions Queue takes over. It reads the CCI on each finding, maps it to the associated control automatically, and surfaces the highest-priority items at the top so remediation decisions do not require manually cross-referencing a spreadsheet. From that queue you can open a new POA&M item, attach a finding to an existing one, flag a false positive, or work through what is overdue.

The part worth knowing before it surprises you: any finding eMASS cannot map to a specific control gets dropped into CM-6 by default. That is not a judgment call about severity – it is a catch-all. If you never go back and check the Findings tab, filtered by Controls, you can end up with a stack of unrelated technical issues all parked under Configuration Settings Management, none of which actually belong there.

Why the CM-6 Bucket Deserves a Second Look

This is the step that gets skipped most often, and it is also the one an IV&V validator will notice first. A finding that auto-mapped to CM-6 because eMASS could not correlate its CCI might actually belong under IA-5 for a credential issue, or SI-2 for a patching gap. Leaving it under CM-6 does not make the finding go away, but it does make your control posture harder to read and your POA&M harder to defend during review. Working the Findings tab by Controls, Devices, and Benchmarks periodically is how you catch these before an assessor does.

The Practical Takeaway

A technical finding does not become a POA&M item randomly – it travels through a specific chain, from CCI to AP to control, and eMASS automates most of that chain for you as long as you know where to check its work.

Trust the CCI, but verify the landing spot. After every scan import, spend five minutes in the Findings tab sorted by Controls before you move on to remediation planning.

Write POA&M descriptions at the AP level, not the control level. An assessor is testing the AP, and your documentation should speak the same language the assessment does.

Treat CM-6 as a queue, not a home. A finding sitting under CM-6 with no obvious configuration-management connection is a mapping gap waiting for someone to notice it, and better that someone is you.

The systems that sail through IV&V are not the ones with zero findings – they are the ones where every finding already sits under the control it actually belongs to.