How DISA STIGs map to RMF controls
A STIG rule maps to a CCI, and the CCI maps to a specific statement within an 800-53 control. The mapping is published rather than inferred, it is many-to-many, and a passing STIG rule is evidence about a control rather than a determination on it.
STIGs and RMF controls come from different places and serve different purposes, which is why the relationship between them confuses people so consistently.
A STIG is a configuration standard: specific, technology-bound, testable, published by DISA per product. An 800-53 control is a security requirement: general, technology-agnostic, published by NIST.
Neither maps to the other directly. The connection runs through a third thing.
The chain
STIG rule → CCI → control statement → control
The Control Correlation Identifier is the joint. A CCI is a single testable assertion derived from an 800-53 control statement, published by DISA, and it is what makes the whole apparatus work.
A STIG rule references the CCI or CCIs it addresses. That reference is in the STIG content itself and in the CKL and CKLB files your scans produce — it is published data, not something you infer.
The CCI in turn belongs to a specific statement within a control. Not the control generally: the particular assertion.
Losing the middle link is the common failure. A tool that maps STIG rules straight to controls has thrown away the granularity that makes the mapping useful, and it will be unable to tell you which part of AC-2 a finding actually bears on.
The relationship is many-to-many, in both directions
One STIG rule can address multiple CCIs. A single configuration setting can satisfy assertions under more than one control. A rule about audit record content may bear on several distinct audit requirements.
One CCI is addressed by many STIG rules. A CCI about session termination is addressed by a rule in the Windows STIG, a different rule in the RHEL STIG, another in the web server STIG. Same assertion, different technologies.
This is why a control’s STIG coverage is not a single number and why “we are STIG compliant” does not translate cleanly into a control status. The coverage is a set, and the set differs per technology in your boundary.
Walking the chain in both directions
The mapping earns its keep because it answers two questions programs ask constantly.
Downward: which STIG findings bear on this control? Start at the control, get its CCIs, get the STIG rules mapped to those CCIs, get the results for those rules across your assets. This is how a pile of scan output becomes assessment input rather than a parallel workstream.
Upward: which controls does this open finding put at risk? Start at the failing rule, get its CCIs, get the control statements those CCIs belong to. This is how you tell whether a configuration finding is cosmetic or whether it undermines something the AO cares about.
Both are trivial with the mapping stored as data and laborious without it. Without it, they get answered by a person with a spreadsheet and a good memory — differently each time, and not at all after that person leaves.
Where STIGs cover controls, and where they do not
STIG coverage across an 800-53 baseline is real and uneven, and it is worth knowing the shape.
Heavy coverage: configuration management, access control at the technical level, identification and authentication, audit and accountability, system and communications protection. These families are largely about how systems are configured, which is exactly what STIGs specify.
Partial coverage: system and information integrity, media protection. Some assertions are configuration; others are procedural.
Essentially no coverage: planning, program management, personnel security, awareness and training, contingency planning at the organizational level, risk assessment, supply chain risk management. Nothing in a STIG tells you whether you tested your contingency plan.
The practical consequence: a fully STIG-compliant system has strong evidence for a specific slice of its control set and none at all for a large remainder. Programs that equate STIG compliance with control compliance discover this during assessment, and the discovery is expensive.
A passing rule is evidence, not a determination
The distinction matters more than it sounds.
A STIG rule passing means a configuration setting has an expected value on a scanned asset. It is an observation about a CCI.
A determination that the CCI is satisfied is a judgment — made by an assessor, considering whether the observation actually addresses the assertion, whether it covers all relevant assets, and whether anything else bears on it.
Those come apart routinely. A rule passes on the ninety hosts that were scanned and says nothing about the four that were not. A rule addresses one aspect of a CCI that also requires something the STIG does not test. The technology in question is not covered by any STIG in your set.
A system that automatically marks CCIs satisfied from passing rules has made assessment judgments without an assessor. The results look great and cannot be defended.
What to require from tooling
- Parse the CCI reference on ingest. It is in the CKL and CKLB file. Discarding it is a choice, and a bad one.
- Store the mapping as data, sourced from the published DISA CCI list, refreshed when it revises.
- Navigate both directions, control to findings and finding to controls.
- Keep rule results as observations distinct from CCI determinations.
- Show coverage honestly. Which CCIs under this control have STIG coverage in my technology stack, and which have none? The second set is where the assessment work actually is.