CM-3 Configuration change control
What the standard requires
a. Determine and document the types of changes to the system that are configuration-controlled; b. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses; c. Document configuration change decisions associated with the system; d. Implement approved configuration-controlled changes to the system; e. Retain records of configuration-controlled changes to the system for [time period]; f. Monitor and review activities associated with configuration-controlled changes to the system; and g. Coordinate and provide oversight for configuration change control activities through [configuration change control element] that convenes [[frequency] | when [configuration change conditions] ].
Quoted verbatim from NIST SP 800-53 Rev 5 (OSCAL catalog), which is in the public domain.
Maps to 4 controls in 3 other frameworks
Mappings are CMDash’s own, seeded with the product and shown on both frameworks they connect. In the product they mean evidence you attach here also counts against the controls listed above.
Integrations that carry evidence for this family
These connectors produce data relevant to FedRAMP Moderate’s Configuration Management family, which is the granularity CMDash publishes — there is no pre-built per-control mapping, and claiming one would be inventing it. You decide which evidence answers which control.
In CMDash this control is a row with an owner, a status, uploaded evidence kept with its full history, and an export an assessor can read.