CCI assessment automation
A CCI is a single testable assertion derived from a control statement, and DoD assessment happens at that level rather than at the control level. Any system storing one status per control forces its nuance into a comment field, which is where reporting goes wrong.
A Control Correlation Identifier is a single testable assertion pulled out of a NIST SP 800-53 control statement. DISA publishes the CCI list, and it is the connective tissue of DoD assessment: STIG rules map to CCIs, CCIs map to control statements, and assessment results are recorded per CCI.
If you have ever wondered why DoD RMF tooling and commercial GRC tooling feel so different, this is the reason. Commercial compliance modeling generally stops at the control. DoD assessment starts below it.
Why the control is the wrong unit
Controls are not atomic. AC-2 — Account Management — contains a set of distinct requirements: identifying account types, assigning managers, establishing conditions for membership, monitoring use, disabling inactive accounts, reviewing accounts on a defined frequency, and more.
Those decompose into separate CCIs, and on a real system they routinely have different answers. Automated account management working. Inactive account disabling not implemented. Review happening but undocumented.
Ask what a single status field for AC-2 should say, and there is no honest answer. What happens in practice is that the assessor picks the worst status and writes the detail into a comment. That comment is now carrying the actual assessment, in prose, in a field nobody can query — which means your reporting is wrong, your POA&M coverage is incomplete, and reassessing the specific thing that failed requires reassessing everything.
Meanwhile the honest answer at CCI level is precise, queryable, and produces exactly one POA&M item against exactly the assertion that failed.
What the mapping chain gives you
CCIs sit in the middle of a chain that makes several useful things possible:
STIG rule → CCI → control statement → control. A STIG finding is not just a configuration issue. It is evidence about a specific assertion under a specific control, and the mapping tells you which.
Walked in each direction, this answers two questions programs ask constantly.
Which STIG findings bear on AC-17? — walk down from the control to its CCIs to the rules mapped to them. This is how a scan result becomes an assessment input rather than a separate pile of work.
This open STIG finding — which controls does it put at risk? — walk up. This is how you know whether a configuration issue is a cosmetic finding or something that undermines a control the AO cares about.
Without the chain stored as data, both questions get answered by a person with a spreadsheet and a good memory, differently each time.
What automation should handle
Import the CCI list and keep it current. It is a published DISA artifact and it revises. Your mappings should come from it rather than from a transcription someone made in 2019.
Map STIG rules to CCIs on ingest. CKL and CKLB files carry the CCI reference per rule. Parse it, store it, and use it. This is the cheapest high-value automation in the whole area and a surprising number of tools discard it.
Roll results up. Report at control level from CCI-level data — control status derived from the CCIs under it, by a stated rule. Never store the control status independently and hope the two agree.
Track per-CCI currency. Which assertions have been assessed recently, against which architecture version, on what evidence. Staleness at CCI level is precise; at control level it is a guess about a group.
Carry findings forward per CCI. A not-satisfied CCI produces a POA&M item scoped to that assertion, not to the whole control. The remediation is specific, the closure criteria are testable, and the reassessment when it closes touches one thing.
The rollup rule needs to be stated
If control status is derived from CCI results, the derivation is a policy decision and it should be written down and inspectable.
The common rule is the pessimistic one: a control is satisfied only if every applicable CCI under it is satisfied. It is defensible and it is what most reviewers expect.
But real assessments have complications the simple rule does not cover. What about a CCI assessed as not applicable — does it count toward the rollup? What about one that is inherited from a common control provider? What about one that is satisfied by a compensating control? What about one that has never been assessed at all, which is a different state from failing?
Whatever your program decides, the decision belongs in the tool as a stated rule rather than in an assessor’s head. Otherwise two people report the same system differently and both are being honest.
What automation must not do
The determination. A CCI is satisfied or not satisfied because an assessor examined evidence and judged it, and that judgment carries their name.
A scanner result is an observation about a CCI. It is not a determination. The distinction sounds pedantic until you have to explain to a reviewer why a control was marked satisfied — and the answer is that a tool inferred it from a passing scan that tested something adjacent to, but not the same as, the actual assertion.
Automation should get the assessor to the point of judgment with everything they need in front of them. Then it should stop.
The practical test for a tool
One request settles whether a product genuinely models CCIs:
Show me AC-2. Show me the CCIs under it. Set one to not satisfied and the rest to satisfied. Now show me the control status, the POA&M item that was created, and which CCI that item is scoped to.
A tool built for DoD assessment does this without comment. A tool that models one status per control will either be unable to do it, or will do it by creating a POA&M item against the whole control — which tells you the granularity is cosmetic.