Change Management and Configuration Management: Keeping Systems Secure Through Controlled Change
By Heather Lange-Wilson
Technology never stays the same.
Software gets updated. Computers are replaced. Firewall
rules change. New applications are installed. User permissions are modified.
Servers are upgraded. Cloud services are introduced. Security patches are
deployed.
Change is necessary.
But every change can also introduce cybersecurity risk.
A seemingly minor configuration change can accidentally
expose a system to the internet. An untested software update can cause an
important application to stop working. An unnecessary administrator permission
can give someone more access than intended.
This is why change management and configuration
management are important parts of cybersecurity.
The goal is not to prevent change.
The goal is to make sure changes are authorized,
documented, tested, implemented, and reviewed in a controlled manner.
What Is Change Management?
Change management is a structured process for controlling
changes to systems, applications, networks, and other technology.
Instead of someone simply deciding:
“I'm going to change this setting.”
A formal change process asks several questions first.
What is changing?
Why is the change necessary?
What systems could be affected?
What could go wrong?
Has the change been tested?
Who approved it?
When should it be implemented?
How will we know whether it worked?
How can we reverse it if something goes wrong?
These questions may seem excessive for a small change, but
organizations depend on interconnected technology.
A change to one system can unexpectedly affect several
others.
Why Change Creates Security Risk
Imagine that an administrator changes a firewall rule to
troubleshoot an application.
The change fixes the application.
But the firewall rule also unintentionally allows external
access to a sensitive server.
The operational problem was solved, but a cybersecurity
vulnerability was created.
Now imagine that nobody documented the firewall change.
Weeks later, another administrator reviews the firewall and
has no idea why the rule exists.
This illustrates why controlled change matters.
Documentation provides history.
Testing reduces unexpected problems.
Approval establishes accountability.
Review helps verify that the change produced the intended
result without introducing unacceptable risk.
Types of Changes
Organizations may classify changes differently depending on
their processes.
Common categories include:
Standard Changes
A standard change is a routine, well-understood
change that follows an established procedure.
Examples might include regularly approved software updates
or routine account-management activities.
Because the process is already understood and documented, it
may require less individual review.
Normal Changes
A normal change may require additional evaluation, testing,
scheduling, and approval before implementation.
For example, upgrading an important business application
could require coordination between multiple departments.
Emergency Changes
Sometimes organizations cannot wait for the normal
change-management process.
A critical vulnerability may be actively exploited.
A major system may be unavailable.
An emergency security configuration may need to be deployed
immediately.
Emergency change procedures allow organizations to respond
quickly while still maintaining appropriate documentation and accountability.
Emergency does not mean undocumented.
The change should still be recorded and reviewed afterward.
What Is Configuration Management?
Change management focuses on controlling changes.
Configuration management focuses on maintaining
systems in known and approved configurations.
Organizations may establish secure configurations for:
- Workstations
- Laptops
- Servers
- Firewalls
- Routers
- Mobile
devices
- Cloud
systems
- Applications
Instead of configuring every computer differently, the
organization establishes an approved baseline.
Security Baselines
A security baseline defines the minimum approved
security configuration for a system.
A workstation baseline might specify:
- Required
security software
- Firewall
settings
- Password
requirements
- Screen-lock
settings
- Approved
operating-system versions
- Encryption
requirements
- Logging
settings
- Disabled
services
- Patch
requirements
Baselines help create consistency.
If 1,000 computers are configured 1,000 different ways,
protecting and troubleshooting them becomes significantly more difficult.
Standardization reduces unnecessary variation.
Configuration Drift
Even when systems begin with identical configurations, they
can gradually become different.
This is called configuration drift.
For example, someone might disable a security setting while
troubleshooting and forget to turn it back on.
Another person might install unauthorized software.
Someone else might manually change a firewall rule.
Over time, the system no longer matches the approved
baseline.
Organizations may use configuration-management and
monitoring tools to identify these differences.
Hardening Systems
System hardening involves reducing unnecessary
security exposure.
Hardening can include:
- Removing
unnecessary software
- Disabling
unused services
- Closing
unnecessary ports
- Changing
default credentials
- Applying
security patches
- Enabling
encryption
- Restricting
administrative privileges
- Enabling
appropriate logging
A newly installed operating system or application may not
automatically have the most secure configuration for every organization.
Hardening adjusts the system to meet organizational security
requirements.
Testing Changes Before Deployment
Whenever practical, significant changes should be tested
before being deployed broadly.
Testing can identify:
- Application
compatibility problems
- Performance
issues
- Security
problems
- Unexpected
dependencies
- Installation
failures
Organizations may use test environments, pilot groups, or
staged deployments.
For example, instead of deploying an operating-system update
to 5,000 computers simultaneously, an organization might first deploy it to a
smaller group.
If unexpected problems occur, fewer users are affected.
Rollback Plans
Sometimes changes fail.
That possibility should be considered before implementation.
A rollback plan explains how the organization will
return the system to its previous working state.
Rollback might involve:
- Restoring
a previous configuration
- Uninstalling
an update
- Restoring
a backup
- Reverting
a virtual machine snapshot
- Restoring
previous firewall rules
The question should not be:
“What do we do if this fails?”
after the failure occurs.
That question should be answered before the change begins.
Maintenance Windows
Organizations may schedule significant changes during
designated maintenance windows.
A maintenance window is a planned period when systems may be
updated or temporarily unavailable.
Scheduling changes during these periods can reduce
operational disruption.
Employees should pay attention to maintenance notifications.
If IT announces that a system will be unavailable during a
scheduled maintenance period, employees should plan accordingly rather than
attempting unauthorized workarounds.
Unauthorized Changes
Not every technology change is approved.
Employees sometimes install applications, browser
extensions, utilities, or cloud services because they make work easier.
However, unauthorized technology can create security risks.
The software may:
- Contain
vulnerabilities
- Collect
organizational information
- Introduce
malware
- Conflict
with security software
- Store
information outside approved environments
- Create
licensing issues
Employees should follow organizational procedures for
requesting new software or services.
Convenience should not override security.
Documentation Matters
Documentation is one of the most important parts of change
management.
A change record may include:
- Description
of the change
- Business
reason
- Systems
affected
- Risk
assessment
- Testing
results
- Implementation
plan
- Rollback
plan
- Approvals
- Implementation
date
- Final
results
Months later, administrators can review the record and
understand what happened and why.
Without documentation, troubleshooting often becomes
guesswork.
Post-Implementation Review
Completing a change does not necessarily mean the process is
finished.
Organizations may conduct a post-implementation review.
The review asks:
Did the change work?
Did anything unexpected happen?
Were security controls affected?
Should documentation be updated?
What did we learn?
Lessons learned can improve future changes.
Employees Have a Role Too
Change management may sound like something only IT employees
need to understand.
Employees also contribute.
Employees should:
- Avoid
installing unauthorized software
- Follow
application-request procedures
- Report
unexpected system changes
- Pay
attention to maintenance notifications
- Avoid
disabling security controls
- Report
problems after updates
- Follow
instructions during system upgrades
If something suddenly looks different after an update,
reporting it may help identify a larger issue affecting other employees.
The Danger of “Just This Once”
Security problems frequently begin with temporary
exceptions.
“I'll disable the firewall just long enough to test this.”
“I'll give this account administrator access for now.”
“I'll open this port temporarily.”
“I'll install this application and remove it later.”
Temporary changes have a tendency to become permanent when
nobody remembers to reverse them.
Formal change management helps prevent this.
If an exception is necessary, it should be documented,
appropriately approved, and removed when it is no longer required.
Change Is Necessary - Uncontrolled Change Is the Risk
Organizations cannot remain secure by refusing to change.
In fact, refusing to update systems can create even greater
risk.
Security patches need to be installed.
Old technology needs to be replaced.
Configurations need to evolve.
New threats require new protections.
The important distinction is between controlled change
and uncontrolled change.
Controlled changes are evaluated.
They are documented.
They are tested.
They are approved.
They have rollback plans.
And afterward, someone verifies that they accomplished what
they were supposed to accomplish.
That structure allows organizations to improve technology
without unnecessarily sacrificing security or stability.
Knowledge Check
1. What is the primary purpose of change management?
A. Prevent all technology changes
B. Control and document changes to reduce operational and security risk
C. Allow employees to install any application
D. Eliminate system updates
Answer: B
2. What is a security baseline?
A. An approved minimum security configuration
B. A list of employee passwords
C. A disaster-recovery site
D. An incident-response report
Answer: A
3. What is configuration drift?
A. Moving computers between buildings
B. Systems gradually moving away from their approved configurations
C. Installing a new computer
D. Performing a backup
Answer: B
4. Why should significant changes have a rollback plan?
A. To determine how to restore the previous state if the
change fails
B. To eliminate documentation
C. To avoid testing
D. To permanently disable security controls
Answer: A
5. What is system hardening?
A. Making computer hardware physically stronger
B. Reducing unnecessary system exposure and applying secure configurations
C. Preventing all software updates
D. Giving users administrator access
Answer: B
6. What should happen to emergency changes?
A. They should never be documented.
B. They should bypass all security controls permanently.
C. They should still be documented and appropriately reviewed.
D. They should only be performed once per year.
Answer: C
7. An employee needs software that is not currently
approved. What should the employee generally do?
A. Download it from any website
B. Disable endpoint protection before installing it
C. Follow the organization's software request and approval process
D. Install it using another employee's administrator account
Answer: C
Security+ Quick Review
Change Management = Structured control of technology
changes
Configuration Management = Maintaining systems in
known, approved configurations
Security Baseline = Minimum approved security
configuration
Configuration Drift = A system moving away from its
approved configuration over time
System Hardening = Reducing unnecessary attack
surface and applying secure settings
Rollback Plan = Instructions for returning to the
previous state if a change fails
Maintenance Window = Scheduled period for planned
system maintenance or changes
Emergency Change = Urgent change handled through an
expedited but still controlled process
Post-Implementation Review = Verification that a
completed change worked as intended
Final Takeaway
Technology must change to remain useful and secure.
But every change should have a purpose.
Know what is changing.
Understand the risk.
Test when possible.
Document what was done.
Have a way back if it fails.
And verify the result.
Good change management is not about slowing technology down.
It is about making sure that today's solution does not become tomorrow's
cybersecurity incident.
