A routine, non-urgent configuration change on a hospital ward switch turns into an emergency fix after hours because a device suddenly loses connectivity and the technician has to act immediately, without time for the normal approval process. What should happen once service is restored?

Emergency changes are a recognized exception within change-control practice precisely because some situations demand immediate action before formal approval can be obtained, but the exception applies to the timing of approval, not to the requirement for documentation — after service is restored, the technician records what was changed, why the normal process couldn't be followed in time, and what the outcome was, so the change is traceable just like any planned one. Treating the incident as fully closed once connectivity returns skips that documentation step and leaves an undocumented gap in the network's change history, which becomes a real problem the next time someone troubleshoots that switch and doesn't know an unplanned change happened. Deliberately leaving the change undocumented to avoid paperwork defeats the entire purpose of change control and creates exactly the kind of invisible, untracked modification that audits and root-cause investigations depend on not existing. Undoing a fix that successfully restored connectivity, purely to route it through normal approval afterward, needlessly reintroduces the very outage that was just resolved, for a process step that can be satisfied through after-the-fact documentation instead. A caveat: many organizations set a short deadline — same day or next business day — for retroactively documenting an emergency change, so the record doesn't get lost or forgotten. As an operational check, confirm the emergency change entry includes the same core details as a planned one: what changed, why, who acted, and the verified outcome.