APP-009 Change Management
Description
All changes to production systems, applications, infrastructure and configuration are subject to a formal change management process. Changes are documented, risk-assessed, tested and approved before deployment. The body that approves changes includes a security representative and a privacy representative, named by role. Emergency changes follow an expedited but documented process. Changes are logged with the initiator, the approver and a timestamp, and rollback procedures are defined. After a change, the controls the impact analysis identified as affected are verified to be implemented correctly and operating as intended, and the verification result is recorded against the change.
Rationale
Uncontrolled changes are a primary cause of outages and security incidents, and formal change management makes changes reviewable for impact and traceable to authorised individuals. Naming who approves, and not only that approval happened, keeps security and privacy from being represented by whoever is nearest. Post-change verification closes the other half: testing that the change works is not testing that the controls it touched still do, and a change that quietly disables logging on a subsystem passes every test written for the change itself.
Applicability (9 profiles)
Framework Mappings (25)
| CCC-01 | Change Management Policy and Procedures | full |
| CCC-02 | Quality Testing | partial |
| CCC-03 | Change Management Technology | full |
| CCC-04 | Unauthorized Change Protection | full |
| CCC-08 | Exception Management | full |
| CCC-09 | Change Restoration | full |
| CCC-01 | Change Management Policy and Procedures | full |
| CCC-02 | Quality Testing | partial |
| CCC-03 | Change Management Technology | full |
| CCC-04 | Unauthorized Change Protection | full |
| CCC-08 | Exception Management | full |
| CCC-09 | Change Restoration | full |
| 8.32 | Change management | full |
| NIS2-CIR-6.3 | Configuration Management | informative |
| NIS2-CIR-6.4 | Change Management, Repairs and Maintenance | partial |
| NIS2-CIR-6.6 | Security Patch Management | informative |
| CM-1 | Policy and Procedures | partial |
| CM-3 | Configuration Change Control | full |
| CM-3(2) | Configuration Change Control | Testing, Validation, and Documentation of Changes | full |
| CM-3(4) | Configuration Change Control | Security and Privacy Representatives | full |
| CM-4 | Impact Analyses | full |
| CM-4(2) | Impact Analyses | Verification of Controls | full |
| CM-9 | Configuration Management Plan | partial |
| CC5.2 | COSO Principle 11: Selects and Develops General Controls Over Technology | partial |
| CC8.1 | Change Management | full |
Evidence (3)
Change request and approval records for recent production changes, showing that each change was documented, risk-assessed, and approved before deployment.
Example: ServiceNow, Jira, or equivalent change management ticket export for production changes in the last 30 days, each showing: change description, risk assessment, approver(s), approval timestamp, deployment timestamp, and rollback plan.
Test: Request a 30-day sample of production change records, aiming for at least 10 tickets. For each change verify: (1) a change request exists before the deployment timestamp, (2) an approver distinct from the initiator approved it, (3) a risk assessment or impact analysis is present, (4) a rollback procedure is documented, (5) emergency changes carry an expedited approval record rather than none, (6) the approval body for a change touching a security or privacy control included the security and privacy representatives named by role.
Deployment pipeline and infrastructure audit logs confirming that production changes were made only through approved, traceable change paths.
Example: AWS CloudTrail, GitHub deployment event log, or CI/CD platform deployment history for the last 30 days showing each production deployment with the initiating actor, pipeline run ID, and timestamp. Any out-of-band changes (direct console access) should appear in CloudTrail with an explanation.
Test: Cross-reference the deployment and infrastructure audit log against the change record list for the last 30 days. Verify: (1) every production deployment in the log has a corresponding approved change record, (2) no production change appears in the log without a change record, an emergency change record included, (3) the initiating actor for each deployment resolves to a named individual, (4) changes made outside the deployment pipeline appear in the infrastructure audit log rather than only in the pipeline log.
Post-change control verification records for a sample of changes that touched a security or privacy control.
Example: Change verification records, CHG-2026-0388 to CHG-2026-0431
Test: Select changes whose impact analysis named an affected control. Verify: (1) the change record names the controls the impact analysis identified, (2) a verification result is recorded for each of those controls after deployment, (3) the verification tests the control's operation rather than restating that the deployment succeeded, (4) a failed verification during the period led to a rollback or to a recorded remediation with an owner and a date, (5) the verification was carried out by someone other than the person who made the change.
Questions (3)
Are all changes to production systems, applications, infrastructure and configuration subject to a formal change management process?
Every production change, including infrastructure and configuration changes, must have a traceable record. Emergency changes require an expedited but still documented approval, not zero oversight.
How are production changes authorised and deployed in your organisation?
Every production deployment should be traceable to an approved change record. The ability to audit who approved what change, and when, is a key audit expectation.
Which of the following are part of your change approval and post-change process?
Options run from the most commonly in place to the least. Naming who approves keeps security and privacy from being represented by whoever is nearest. Testing that a change works is not testing that the controls it touched still do: a change that quietly disables logging on a subsystem passes every test written for the change itself.