Change and Configuration Management: Keeping Security Controls Stable When Everything Keeps Changing

🎯 CISSP Lens

Pick answers that align business risk, governance intent, and practical control execution.

Change management and configuration management work together to answer two questions:

• How do we make changes safely?
• How do we keep systems in a known good state over time?

Security operations must be tightly connected to both.

Purpose of change management in security operations

Change management ensures that modifications to systems, networks, and applications are:

• Reviewed for risk and impact before implementation
• Approved by appropriate stakeholders
• Implemented in a controlled, documented way
• Verified after the change to confirm expected results

From a security perspective, unmanaged change is a major source of vulnerabilities and outages. A formal change process reduces surprises.

Configuration baselines and hardened builds

Configuration management focuses on the state of systems after changes.

A configuration baseline is a documented, approved set of settings for a particular type of system, for example a domain controller or web server. Hardened builds incorporate security best practices such as:

• Disabling unnecessary services and ports
• Enforcing secure protocols
• Configuring logging, auditing, and time synchronization
• Applying standard security policies and group settings

Security operations should work with infrastructure teams to develop and maintain these baselines.

Change advisory boards and security participation

Many organizations use a change advisory board to review and approve significant changes. Security representation in the board helps ensure that:

• Proposed changes do not introduce obvious weaknesses
• Compensating controls are considered when risks cannot be fully eliminated
• High risk changes are scheduled with appropriate safeguards and monitoring

Security input should be practical and risk based, not simply rejecting changes without alternatives.

Emergency changes

Sometimes changes must be made quickly to resolve outages or close critical vulnerabilities. Emergency changes are acceptable, but they should not bypass control entirely.

Good practice for emergency changes includes:

• A defined emergency change path with limited approvers
• Documentation of what changed, when, and why
• Post change review at the next CAB meeting to validate the decision and update baselines if needed

Without review, emergency changes accumulate and create configuration drift.

Detecting and correcting configuration drift

Configuration drift occurs when systems slowly deviate from baselines due to ad hoc fixes, manual tweaks, or untracked changes.

Security operations can help control drift by:

• Using configuration management tools or infrastructure as code to enforce baselines
• Running periodic configuration audits against known good templates
• Investigating deviations to understand whether they were intentional and approved

Reducing drift makes it easier to investigate incidents and reduces the chance that a forgotten change weakens security.

📋 Domain cross-reference

📋 Domain cross-reference

CISSP Domain 7 looks at how changes are controlled in daily operations.

Exam relevant ideas include:

• Unmanaged change is a major source of operational risk and security incidents.
• Security must be represented in change approval processes and should review changes for security impact.
• Separation of duties applies to change management. The person who requests a change should not be the only person who approves and implements it.
• Configuration baselines support integrity by providing a known reference state.

When answering exam questions, favor approaches that strengthen processes and documentation, not quick technical fixes without governance.

A developer needs to troubleshoot a remote desktop issue on a test system. To move quickly, they open the RDP port on a production firewall rule and expose a server directly to the internet, promising themselves that they will close it later.

The change is not documented. No ticket is created. Weeks pass and the open RDP port remains.

Attackers scanning the internet find the exposed service and eventually brute force the weak administrator password. They use the compromised server as a foothold to move deeper into the environment.

In the post incident review, the organization identifies failures in:

• Change management, because the firewall rule change bypassed standard approvals.
• Configuration management, because there was no baseline for firewall rules and no monitoring for deviations.

They respond by:

• Requiring change tickets for all production firewall changes, including those requested by developers.
• Implementing configuration management for firewalls so rule sets are version controlled and audited.
• Setting up alerts for high risk changes such as exposing administrative ports to the internet.

Over time, emergency fixes and ad hoc changes are replaced by planned, reviewed modifications.

⚠️ Watch for this mistake: Treating change management as pure bureaucracy and bypassing it for urgent or small changes.

⚠️ Watch for this mistake: Failing to document secure configuration baselines for critical platforms.

⚠️ Watch for this mistake: Allowing direct changes on production systems without peer review or testing.

⚠️ Watch for this mistake: Not monitoring for configuration drift, so systems slowly become inconsistent and less secure.

⚠️ Watch for this mistake: Handling emergency changes as exceptions that are never reviewed afterward.

• ✅ ✅ Document secure configuration baselines for your most critical systems and services, such as domain controllers, firewalls, and key application servers.
• ✅ ✅ Ensure security representation on the change advisory board or equivalent group.
• ✅ ✅ Require formal change tickets for all production changes, including security tooling and configuration adjustments.
• ✅ ✅ Use configuration management tools or infrastructure as code to define and enforce standard builds where possible.
• ✅ ✅ Implement alerts or regular reports for high risk configuration changes, such as changes to firewall rules or exposure of administrative interfaces.
• ✅ ✅ Conduct periodic configuration audits to compare running systems against baselines and correct drift.

• 💡 💡 Controlled change reduces both security incidents and outages.
• 💡 💡 Configuration baselines and hardened builds give you a known good starting point and a target for audits.
• 💡 💡 Security must be integrated into change governance, not operate as a side channel that people avoid.
• 💡 💡 Emergency changes are sometimes necessary, but they still require documentation and post change review.
• 💡 💡 CISSP Domain 7 expects you to favor documented processes and separation of duties over one off shortcuts.

📝 Exam practice

📝 Exam practice

Question: A system administrator makes a configuration change directly on a production server without a change ticket. The change causes a key security control to fail. Which control process was bypassed?

Answer: Formal change management. The administrator should have submitted a change request, obtained required approvals including security review, and documented the change. Bypassing the change process increases the risk of outages and security regressions.