Emergency changes: what the auditor reads in them
An emergency change goes to production first and is authorised after, under a documented emergency procedure, with the access used for it revoked and a post-implementation review. The checker reads the approval against the window you set (five days by default): inside it, the row raises nothing; outside it or missing, the row is listed.
How the checker recognises them
Read from the change type column: emergency, urgent, expedited, break-fix or hotfix.
Findings they raise most often
- Emergency, no approval after: Where is the retrospective approval and the post-implementation review for this emergency change?
- Deployed their own change: How is a developer prevented from promoting their own change to production, and what compensates where they can?
- No test evidence: What testing was done before this change went to production, and where is the record?
The clauses that speak to them
2 clausesCOBIT BAI06.02 Manage emergency changesThe clause text
Emergency changes are carefully managed to minimise further incidents, controlled and made securely, and assessed and authorised appropriately after the change: what constitutes an emergency change is defined; a documented procedure declares, assesses, preliminarily approves, authorises after the change and records emergency changes; all emergency access arrangements for changes are appropriately authorised, documented and revoked after the change is applied; and all emergency changes are monitored with post-implementation reviews involving all concerned parties, considering root causes such as problems with business processes, application development, infrastructure, testing or the environment and initiating corrective action.
Where it usually falls short: Emergency access left in place after the change; Emergencies used as a route around normal change approval
Source: COBIT 2019
SP 800-53 CM-3 Configuration change controlThe clause text
Requires the types of change that fall under configuration control to be defined, proposed changes to be reviewed and approved or rejected with explicit consideration of security and privacy impact, decisions and implemented changes to be documented, change records to be retained for a defined period, and change activity to be monitored and reviewed by the responsible body.
Where it usually falls short: Emergency changes bypass approval and are never retrospectively documented; Impact analysis recorded as a tick box with no security reasoning behind it
Source: NIST SP 800-53 Rev 5