7.9 Change Management

Key Takeaways

CISSP 7.9 focuses on understanding and participating in Change Management processes.

The central purpose is to ensure that changes to controlled environments are understood, authorised, tested, implemented, validated and recorded.

Change Management does not prevent change. It prevents uncontrolled change.

Change introduces risk because even beneficial modifications can produce unintended consequences.

A security patch can create an outage.

A firewall rule can create excessive exposure.

An IAM change can create excessive privilege.

A logging change can create a monitoring blind spot.

The change-management lifecycle can be remembered as:

Request → Assess → Approve → Test → Implement → Validate → Record.

A change request should explain what will change and why.

Impact assessment considers which systems, users, services and dependencies could be affected.

Security impact analysis specifically considers how the proposed change affects confidentiality, integrity, availability and security controls.

Functional success ≠ security success.

An application may continue functioning while logging, EDR, segmentation or access controls have been weakened.

Configuration Management and Change Management are related but different.

Configuration Management establishes and maintains the authorised configuration state.

Change Management controls how that state may be modified.

Configuration = what should it look like? Change = how may we alter it?

A successfully implemented permanent change may require the authorised configuration baseline to be updated.

Patch Management is also closely connected to Change Management.

A patch may reduce security exposure while simultaneously creating operational change risk.

Security urgency should therefore be balanced with appropriate testing, approval, deployment and recovery controls.

Change records should provide enough information to understand the purpose, scope, risk, implementation method and expected result.

Useful information includes affected assets, dependencies, testing, implementation steps, approvals, schedule, validation and rollback.

Organisations commonly use different change categories according to risk and urgency.

A standard or pre-authorised change is commonly a repeatable, well-understood lower-risk activity using an established procedure.

Pre-authorised ≠ undocumented.

Planned or normal changes generally require individual assessment and approval.

Emergency changes use an accelerated process because waiting creates unacceptable risk.

Emergency = accelerated governance. Emergency ≠ no governance.

Emergency changes should still receive appropriate approval, available testing, validation and documentation.

Retrospective review can confirm whether emergency procedures were used appropriately and whether additional follow-up is required.

Excessive use of emergency changes may indicate that normal processes are ineffective or routinely bypassed.

Change approval should reflect the risk and significance of the proposed change.

Low-risk repeatable activity does not necessarily require the same governance as a major production architecture change.

Some organisations use a Change Advisory Board or similar governance mechanism for significant changes.

A CAB can bring together operations, security, application, infrastructure and business perspectives.

However:

CAB ≠ mandatory committee approval for every tiny change.

Separation of duties can reduce the possibility that one person requests, approves and implements a high-risk change without oversight.

Where perfect separation is impractical, compensating controls can include independent review, logging and monitoring.

Changes should be appropriately tested before production.

Testing may consider functionality, security, compatibility, performance, monitoring and recovery.

Test environments should represent important production characteristics sufficiently well to provide useful assurance.

Staged deployment can reduce the blast radius of an unsuccessful change.

A change may first be tested in non-production, then deployed to a small pilot population before broader deployment.

Implementation plans should describe the exact steps required to perform the change.

They should also define expected results and the conditions under which implementation should stop or rollback should occur.

Maintenance windows help ensure that important changes occur when technical staff, monitoring and recovery capabilities are available.

Change freezes can reduce avoidable production risk during particularly sensitive business periods.

A change freeze does not necessarily prohibit critical authorised emergency changes.

Rollback planning asks how the organisation will recover if the change fails.

Possible approaches include restoring previous configuration, reverting software, restoring snapshots, failing over or redeploying a known-good version.

"We can rollback" should be a capability, not an assumption.

Some changes cannot simply be reversed.

Database migrations and other stateful changes may require a carefully designed recovery or roll-forward strategy instead.

Post-implementation validation confirms that the intended result actually occurred.

Validation should consider both business functionality and security controls.

Implemented ≠ validated.

Successful permanent changes should also be reflected in relevant documentation.

Configuration baselines, diagrams, runbooks, recovery plans and monitoring documentation may need updating.

Unauthorised change should be treated seriously.

It may result from administrator error, poor process discipline, configuration drift or attacker activity.

Unexpected creation of an administrator account, disabling of logging or modification of a firewall rule may therefore warrant security investigation.

Configuration monitoring, file-integrity monitoring, cloud audit logs, SIEM and baseline comparison can help identify unexpected changes.

Infrastructure as Code does not eliminate Change Management.

Instead, change controls can be embedded into version control, peer review, automated testing and deployment pipelines.

Automated change ≠ uncontrolled change.

Version control provides traceability showing what changed, when, by whom and often why.

Automation can strengthen Change Management by making tests, policy checks, approvals and deployments more consistent.

Automation also increases the potential speed and scale of mistakes.

A bad manual configuration may affect one server.

A bad automated configuration can affect thousands in seconds.

DevOps and continuous delivery therefore do not require abandoning Change Management.

Instead, controls can become faster, automated and integrated directly into delivery workflows.

Security-sensitive changes deserve particular attention.

Firewall, IAM, logging, encryption, endpoint protection and cloud network changes can alter risk immediately.

Temporary security changes should include an explicit expiry or restoration mechanism.

Temporary ≠ self-reversing.

Post-implementation review can help organisations learn from important or unsuccessful changes.

Useful metrics can include successful change rate, failed changes, emergency-change volume, unauthorised changes, rollback frequency and change-related incidents.

The central CISSP principle is:

understand the proposed change, assess its security and business impact, obtain appropriate authorisation, test it, implement it in a controlled way, have a recovery strategy, validate the result and preserve a traceable record of the new authorised state.