An emergency firewall change stops an active attack on a courts case-management VPN. What must still happen afterward, and what should normal changes require?

Change management distinguishes emergency fixes from normal changes without abandoning control. Emergency changes may proceed under expedited authority to restore critical municipal services, but they still require post-implementation review so the city documents what changed, why, who approved the emergency path, and whether follow-up hardening or formal CAB ratification is needed. Normal changes require approval before production to reduce outages, security gaps, and undocumented configuration drift across citizen-facing and internal systems. The dual requirement preserves agility in crisis while preventing “emergency” from becoming the everyday bypass.

Claiming emergency changes need no record and normal changes may skip approval to go faster removes both the audit trail and the preventive control. Making all changes—including emergencies—undocumented in production forever guarantees unrecoverable snowflake systems and failed investigations. Always applying normal changes first in production before any test environment inverts safe practice and turns citizens into unwitting beta testers. Exam caveat: CISSP expects recognition that emergencies are controlled exceptions with after-the-fact accountability, not uncontrolled free-for-alls. Operationally, define emergency change criteria, auto-create post-implementation review tasks, and measure how often emergencies recur for the same system as a signal of underlying instability.