During an outage, an on-call DBA added an index to a production table to relieve severe blocking. Performance recovered, but no change ticket was raised and the index exists only in production. What should happen next?

Change management usually includes an emergency change path for situations where waiting for normal approval would prolong an outage. The trade-off is that the change must be documented and reviewed afterward: a change record describing what was done and why, retroactive approval from the change authority, and incorporation of the change into version control and deployment scripts so other environments and future deployments include it. Without that, the next deployment from source control may silently remove the index, or test environments will no longer match production. Leaving the change undocumented creates configuration drift and an unexplained object that future administrators may remove or duplicate, and it bypasses the review that might reveal a better long-term fix. Dropping the index immediately because it lacked prior approval would likely bring back the blocking and the outage; the control objective is documentation and review, not reversing a beneficial fix by reflex. Banning emergency changes outright would leave teams unable to respond to incidents and would encourage undocumented workarounds. Exam caveat: the post-change review may still decide to modify or replace the emergency fix, but that decision is made through change control. Operational check: open the emergency change record, capture the index definition, add it to the migration scripts, deploy it to lower environments, and confirm it appears in the next schema comparison.