CM-1 Policy and procedures
What the standard requires
a. Develop, document, and disseminate to [organization-defined personnel or roles]: 1. [organization-level | mission/business process-level | system-level] configuration management policy that: (a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and (b) Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and 2. Procedures to facilitate the implementation of the configuration management policy and the associated configuration management controls; b. Designate an [official] to manage the development, documentation, and dissemination of the configuration management policy and procedures; and c. Review and update the current configuration management: 1. Policy [frequency] and following [events] ; and 2. Procedures [frequency] and following [events].
Quoted verbatim from NIST SP 800-53 Rev 5 (OSCAL catalog), which is in the public domain.
Cross-framework mappings
No cross-framework mapping is seeded for this control. That is stated rather than filled in: a mapping nobody authored is worse than a gap you can see.
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.