CM-3 Configuration Change Control
Determine, document, and approve changes; track, review, audit; CAB or equivalent; analyze security impact.
5
artefacts
1
held by a system
1
at each review
hard
to go live
Policy repository / GRC workspace
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
- Configuration drift detection reports from the CMDB or tooling · Cloud console / configuration management
periodic reviewEvidence produced at each review
- Change advisory board minutes with risk assessments · Cloud console / configuration management
governing documentDocuments that govern the control
- Control implementation statement for CM-3 citing the system mission and inheritance from common controls · Policy repository / GRC workspace
- Configuration management policy and change control procedure · Policy repository / GRC workspace
- Approved baseline configurations for each platform family · Policy repository / GRC workspace
First move
Mostly documents and reviews. Pull the 1 system-held artefact from your Cloud console / configuration management on a schedule; put the documents under version control with an owner and review date, and log each review as a dated record with a named reviewer.
Common gaps auditors find
- Baselines exist on paper but production hosts drift without alerting
- Emergency changes bypass CAB and lack retrospective review
- Unauthorised software present on endpoints not flagged by tooling
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetCM-2(7) Configure Systems and Components for High-Risk Areas · CM-3(2) Testing, Validation, and Documentation of Changes