Change Management
Unit 2: Change Management and Cryptography. Lesson 5 of 54 in SecPlus Academy.
Most outages and many breaches follow an unplanned change. Change management is the process that makes changes deliberate, reviewed, and reversible. The exam tests the pieces of the process and the technical side effects a change can have.
The business process
- Approval process: a change request is submitted, reviewed, and approved by a change advisory board or an owner before anything happens.
- Ownership: one named person is responsible for the change end to end.
- Stakeholders: everyone affected is identified and informed.
- Impact analysis: what could break, who is affected, how long, and what the risk is.
- Test results: the change is tried in a test environment first and the results are attached.
- Backout plan: the exact steps to undo the change if it fails.
- Maintenance window: the scheduled time when the change may run, chosen for least impact.
- Standard operating procedure: routine, low-risk changes follow a pre-approved procedure instead of a full review.
Technical implications
- Allow lists and deny lists: adding software or traffic to an allow list, or blocking it, changes what works.
- Restricted activities: some actions are forbidden during a change, or forbidden entirely without a separate review.
- Downtime: planned unavailability, communicated in advance.
- Service and application restarts: many changes take effect only after a restart, which itself is downtime.
- Legacy applications: old software may break when its platform changes.
- Dependencies: a change to one system can break others that rely on it.
The objective's own words for the restart items are service restart and application restart, and legacy applications and dependencies decide the order.
Documentation and version control
After the change, update diagrams, procedures, and configuration records. Version control keeps every version of configurations and code, records who changed what, and makes rollback a checkout instead of a memory test.
Updating diagrams and updating policies and procedures are the two documentation tasks the exam names.
Change Management, explained slowly
Why a process for changing things
Ask any experienced administrator what caused the last big outage and the answer is usually "a change." A firewall rule, a patch, a new server, a tweak nobody wrote down. Change management is the discipline that turns "just do it" into "request it, review it, test it, schedule it, do it with a way back, write it down." The exam tests both the process pieces and the technical consequences a change can carry.
The process, as a story
The web team wants to move the customer portal to a new database version.
- Change request: they write what, why, and when.
- Ownership: one engineer is named as owner and stays accountable through the end.
- Stakeholders: sales, support, and the database team are identified and told.
- Impact analysis: what breaks if it fails? Customers cannot log in. How long? An hour of downtime. What else depends on it? The reporting system.
- Test results: they run the upgrade in a staging environment and attach the results.
- Backout plan: exact steps to return to the old version if the new one fails, with the time it takes.
- Approval: the change advisory board reviews all of the above and approves.
- Maintenance window: Saturday 2 a.m. to 4 a.m., communicated in advance.
- Implement, test, and document: diagrams, procedures, and the configuration record are updated.
For routine, low-risk changes, a standard operating procedure replaces the full review: the change is pre-approved as long as the procedure is followed.
Technical implications: what a change can break
Allow lists / deny lists adding or blocking software, sites, or traffic changes what works Restricted activities some actions are prohibited during the window or without separate approval Downtime planned unavailability; announce it Service / application restart most changes only take effect after a restart, which is itself downtime Legacy applications old software may not run on the new platform Dependencies changing one system breaks the systems that rely on it
The dependency trap is the exam's favorite: the database upgrade succeeds, but the reporting system that connects to it was never tested against the new version and fails Monday morning. Impact analysis exists to find that before the change.
Documentation and version control
Every change ends with documentation: what changed, why, who approved it, and updated diagrams and procedures. Version control keeps every previous version of configuration files and code, with who changed what and when. Rolling back becomes "restore the previous version" instead of trying to remember the old settings. It is also evidence for audits.
How the exam asks it
- "What must be in place before a change is implemented?" Backout plan, impact analysis, test results, approval.
- "Which element identifies systems that could be affected?" Impact analysis, and the dependency list.
- "How can the team quickly revert to the previous configuration?" Version control.
- "An emergency patch was applied at 3 a.m. What is required afterward?" Documentation through the change process.
What to memorize
- Request, impact analysis, test, backout plan, approve, maintenance window, implement, document.
- Watch dependencies, legacy applications, restarts, downtime, allow and deny lists.
- Version control makes rollback cheap and proves what changed.