Topics in this domain
- Enterprise Architecture and IT Risk
- Change Management Risk
- Assets, Configuration and Dependencies
- Incident and Problem Management Oversight
- Project Governance and IT Risk
- Governing the Secure SDLC
- DevOps, CI/CD and Agile Delivery Risk
- Testing, Release and Deployment Risk
- Data Classification, Ownership and Handling
- Data Lifecycle: Integrity, Retention and Disposal
- Business Continuity Planning and Governance
- Disaster Recovery and Testing Recovery Capability
- Emerging Technology Risk: Cloud, IoT and OT
- AI and Machine Learning Risk
- Setting Risk Boundaries for Innovation
- Core Security Concepts: CIA, IAM, Cryptography and Network Security
- Security Frameworks and Control Standards
- Security Awareness Culture and Measuring Training
- Privacy Governance and Data Protection Principles
- Developing a Data Protection Control Strategy
Change Management Risk
The change process
Many outages and security gaps are caused by changes. Change management assesses the risk of each change before it goes live.
Scaling to risk
Emergency changes
Example. A firm found that 40% of its changes were labelled “emergency” to skip the CAB. The practitioner reported it as a KRI; the CIO added weekly emergency-change reviews, and the rate fell to 5%.
Risk indicators for change
- Changes causing incidents (the change failure rate).
- Share of emergency changes.
- Unauthorised changes detected.
- Changes without rollback plans.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| GREATEST change management risk | Unauthorised or untested changes reaching production |
| Emergency change made without approval | Document, test and approve it afterwards |
| BEST way to detect unauthorised changes | Compare production with approved changes |
| Who should migrate code to production | Someone other than the developer, or the pipeline |
In short
- Many outages and security gaps are caused by changes; change management assesses risk before changes go live.
- Changes are requested, assessed, approved, built and tested, migrated by someone other than the developer, and reviewed.
- Scale the process to risk: standard, normal, major and emergency changes.
- Emergency changes can skip prior approval but must be documented, tested and approved afterwards.
- Unauthorised changes are detected by comparing production with approved change records.
Exam traps
- Developers moving their own code to production.
- Emergency changes never reviewed afterwards.
- Treating every change the same regardless of risk.
- Relying on change tickets to find unauthorised changes.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The change process
Scaling to risk
Emergency changes
ExampleA firm found that 40% of its changes were labelled 'emergency' to skip the CAB. The practitioner reported it as a KRI; the CIO added weekly emergency-change reviews, and the rate fell to 5%.
1 / 8