CM-5 Access Restrictions for Change
Define, document, approve, enforce physical and logical access restrictions for changes.
system holds itEvidence a system already holds
- Configuration drift detection reports from the CMDB or tooling · Cloud console / configuration management
- Software inventory generated from authoritative discovery tooling · Cloud console / configuration management
periodic reviewEvidence produced at each review
- Change advisory board minutes with risk assessments · Cloud console / configuration management
- Emergency change records with retroactive approvals · Cloud console / configuration management
governing documentDocuments that govern the control
- Control implementation statement for CM-5 citing the system mission and inheritance from common controls · Policy repository / GRC workspace
First move
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-4(2) Impact Analyses | Verification of Controls. After system changes, verify that the impacted controls are implemented correctly, operating as intended, and producing the desired outcome with regard to meeting the security and privacy requirements · CM-5(1) Access Restrictions for Change | Automated Access Enforcement and Audit Records. (a) Enforce access restrictions using [Assignment: organization-defined automated mechanisms]; and (b) Automatically generate audit records of the enforcement actions