Change management is a structured process for controlling how modifications are made to IT systems, software, and policies. Without it, changes become unpredictable, undocumented, and potentially destructive.

[Change Request]
       |
       v
[Review & Approval]
       |
       v
[Testing]
       |
       v
[Implementation]
       |
       v
[Documentation]

1. Version Control

Version control tracks changes across software, configurations, and patches over time.

Benefits:

• See what software is currently installed
• Track what changed between versions
• Identify when a change was made
• Roll back to a previous stable version if the latest causes issues

v1.0 --> v1.1 --> v1.2 (broken)
                    |
               Roll back to v1.1

Use cases:

• Software releases
• Configuration files
• Firewall rule sets
• OS patches

2. Documentation

Every change must be documented before and after implementation.

What to record:

+ Who made the change
+ What was changed
+ When the change was made
+ Why the change was made
+ Who authorized it

Why it matters:

Documentation protects both the organization and the individual who made the change. If something goes wrong later, you can trace back: who approved it, what was tested, and what the expected outcome was.

"Why did you change that?"
        |
        v
"Here's the approval, test results, and ticket."

Never make undocumented changes in a production environment.

3. Diagrams

Keep network and process diagrams up to date whenever technology changes.

Types of diagrams to maintain:

• Network topology diagrams
• Data flow diagrams
• Process flow diagrams
• System architecture diagrams

Outdated diagrams cause confusion and slow down incident response. A diagram showing removed systems or missing new ones is worse than no diagram at all.

Old diagram: Server A --> Server B --> DB
Reality:     Server A --> Load Balancer --> Server B, C --> DB

4. Policies and Procedures

Policies must stay synchronized with actual technology and processes.

Common failure:

Policy Step 3:  [obsolete - skip]
Policy Step 7:  [obsolete - skip]
Policy Step 13: [obsolete - skip]

If staff are told to skip steps, the policy loses authority. You cannot hold someone accountable for not following a policy that has undocumented exceptions.

Rules:

• Remove outdated steps entirely
• Update policy documents when processes change
• Communicate all policy updates to affected staff

5. Business Impact Analysis

Before implementing any change, evaluate the business impact.

Questions to answer:

+ Who will be affected?
+ How long will services be unavailable?
+ What is the acceptable downtime window?
+ What is the cost of downtime vs. cost of the change?

Goals:

• Minimize downtime
• Prevent work stoppages
• Avoid productivity loss

[Change Plan]
      |
      v
[Impact Assessment]
      |
      +--> Low impact --> Proceed with approval
      +--> High impact --> Schedule maintenance window

6. Maintenance Windows

A maintenance window is a pre-scheduled period when changes are applied to systems.

Purpose:

• Users know in advance when services will be unavailable
• Staff can prepare and wrap up work
• Support teams can apply changes with minimal disruption

"System will be unavailable Saturday 2:00 AM - 4:00 AM"

Best practices:

• Choose low-traffic periods (nights, weekends)
• Communicate the window in advance
• Define a clear restore target time
• Have support staff available during and after

Real example: Applying a VoIP patch during business hours without a maintenance window caused dropped calls across the organization. Calls were not recovered because customers moved on. After that incident, all potentially disruptive changes were scheduled after 5 PM local time.

7. Approval Process and Workflow

Changes should not be applied without authorization.

Standard workflow:

[Request] --> [Review] --> [Test] --> [Approve] --> [Implement] --> [Document]

Approval checklist:

• Was the change tested?
• Are test results available for review?
• Who is authorizing the change?
• Is a backout plan in place?

No change should reach production without a sign-off from an authorized individual.

8. Backout Plan

A backout plan is a predefined rollback procedure in case a change fails.

Think of it like saving a game before a boss fight. Before the change:

Snapshot / Backup / Restore Point
           |
           v
Apply change
           |
     Change fails?
           |
           v
Roll back to restore point

What to prepare:

• Configuration backups
• System snapshots
• Database backups
• Known-good firmware versions

Critical infrastructure (routers, firewalls, core servers) must always have a tested backout plan before changes are applied.

9. Knock-On Effects

Changes in one area of a system can unexpectedly affect other areas.

Examples:

Before any change:

Ask: "What else depends on this?"

Map dependencies before modifying allow lists, deny lists, firewall rules, or access controls.

10. Legacy Applications

Legacy = old software still in use for business reasons.

Why legacy applications stay around:

• Already paid for
• Specific users depend on them
• Migration is expensive or complex
• Integrated into existing workflows

The challenge:

New security requirements may be incompatible with legacy systems. Simply patching around a legacy app is not always possible.

New security policy
        |
        v
Breaks legacy application
        |
        +--> Migrate user to new system
        +--> Customize new system to reduce learning curve
        +--> Retire legacy app with proper planning

Before making changes that touch legacy systems, identify all applications and users that depend on them.

11. Stakeholder Communication

Before taking any system offline, notify the right people.

Who to notify:

+ System owners
+ Application owners (e.g., webmaster before taking down web server)
+ End users
+ Customers (if external services are affected)
+ Management / leadership

Steps:

1. Identify who will be impacted
2. Communicate the planned change and timing
3. Confirm the expected duration
4. Provide status updates during the window
5. Confirm restoration when complete

Change Management Summary

Version Control      --> Track what changed, roll back if needed
Documentation        --> Record who, what, when, why, and who approved
Diagrams             --> Keep them current with actual infrastructure
Policies             --> Remove outdated steps, communicate updates
Business Impact      --> Evaluate downtime cost before proceeding
Maintenance Windows  --> Schedule changes during low-impact periods
Approval Process     --> No change without sign-off and test results
Backout Plan         --> Always have a rollback path ready
Knock-On Effects     --> Identify dependencies before making changes
Legacy Applications  --> Assess compatibility before major updates
Stakeholders         --> Communicate before, during, and after

Quick Reference