1.3 Explain the importance of change management processes and the impact to security

From class: Change management → get approval before you do a change ("think of the reboot video"). Software change management → obtain permission before installing software. Version control was listed as an integrity control (Day 1) — it proves what changed and lets you roll back.

Why the exam cares

Uncontrolled change is one of the biggest sources of outages and security holes (a firewall rule "temporarily" opened, a patch that breaks logging, a rushed config that disables TLS). Change management is a managerial/operational control that makes change deliberate, reviewed, tested, reversible, and documented.

Breakdown 1 — The business process side

Element	What it means	Why it matters for security
Approval process	Changes go through a request → review → approve flow, usually a Change Advisory Board (CAB)	Prevents unauthorized changes; creates accountability
Ownership	One named person is responsible for the change end to end	Someone to answer for scope, testing, and rollback
Stakeholders	Everyone affected (app owners, security, help desk, business units) is consulted	Security gets a seat before the change, not after
Impact analysis	What could break, what's the risk, who's affected, what's the security impact	Identifies dependencies and new attack surface
Test results	Proof the change works in a non-production environment	Reduces surprises; catches security regressions
Backout plan	Documented steps to undo the change if it fails	Limits downtime and exposure when things go wrong
Maintenance window	Agreed low-impact time period for implementing changes	Predictable, monitored, staff available
Standard operating procedure (SOP)	Step-by-step instructions for routine changes	Consistency; low-risk changes can be pre-approved ("standard changes")

Emergency changes still get reviewed — just after the fact.

Breakdown 2 — Technical implications

Implication	Example	Security angle
Allow lists / deny lists	New app needs to be added to the application allow list; new IP to a firewall ACL	Forgetting the list update = outage; over-broad update = exposure
Restricted activities	Some actions are off-limits during a change (e.g., no schema changes during business hours)	Limits blast radius
Downtime	The service is unavailable during the change	Availability impact; schedule in the maintenance window; communicate
Service restart	Restarting a daemon to load new config	Sessions drop; monitoring may alert; verify it came back with the right settings
Application restart	Restarting the app tier	Same as above; watch for cached credentials/tokens
Legacy applications	Old apps with no vendor support or hard-coded dependencies	Can't be patched normally → compensating controls, isolation
Dependencies	Change A requires B, C to be updated first (libraries, certificates, DNS, firewall rules)	Missed dependencies cause cascading failures

Breakdown 3 — Documentation and version control

• Updating diagrams — network/architecture diagrams must reflect the new state; stale diagrams hide attack paths and slow incident response.
• Updating policies/procedures — if the change alters how something is done, the SOP/runbook changes with it.
• Version control — every config, script, IaC template, and policy document has a history: who changed what, when, and why. Enables rollback (backout), diffing, peer review, and audit evidence. Git is the canonical example; also applies to firewall configs, GPOs, and documents.

Breakdown 4 — Typical change flow (memorize the order)

1. Request the change (RFC — request for change) with owner, scope, justification.
2. Impact analysis and risk assessment; identify stakeholders and dependencies.
3. Test in a non-production environment; capture results.
4. Approval (CAB / change authority) including security sign-off; write the backout plan.
5. Schedule in a maintenance window; notify stakeholders.
6. Implement following the SOP; monitor.
7. Verify and close, or back out if it fails.
8. Document: update diagrams, policies, CMDB, version control.

Exam tip: Questions like "the change was implemented and broke authentication; what was MISSING?" usually key test results or impact analysis. "Team can't restore the previous state" → backout plan. "Nobody knows the current network layout after the change" → updating diagrams. "Who is responsible for the change?" → ownership.

Quick self-check

• What's the difference between a maintenance window and downtime? (Window = the scheduled slot; downtime = the actual unavailability during it.)
• Why does version control matter for security, not just developers? (Rollback, audit trail, detect unauthorized change.)
• Name two technical implications of changing a firewall policy. (Allow/deny list updates, dependencies on other rules/services.)

From class (Day 5) — testing and implementing changes: rolling updates (a few instances at a time), blue/green (two environments, flip traffic, instant rollback), canary (sample test — a small slice of users first); regression testing during the maintenance window proves the change didn't break what already worked. Detail in 4.7.