Emergency, no approval after: what the rows show and the clause behind it
An emergency change with no approval recorded inside the window after its deploy. An emergency route lets a change go first and be authorised after; this row shows no after, or an after outside the window you set.
How long after an emergency change does the approval have to be recorded?
No clause in the frameworks here fixes a number of days. COBIT BAI06.02 has emergency changes assessed and authorised after the change, under a documented procedure, with a post-implementation review. The window is yours to set: it is the number of days your own emergency procedure allows, five by default. The checker lists every emergency change with no approval inside that window.
The question the auditor is likely to ask
walkthrough packWhere is the retrospective approval and the post-implementation review for this emergency change?
The clause behind it
6 clauses in 6 frameworks| Framework | The clause behind it |
|---|---|
| SOX 404 / ICFR | SOX 404 ITGC IT General Controls (ITGC) - Access, Change, Operations |
| COBIT 2019 | COBIT BAI06.02 Manage emergency changes |
| SOC 2 (Trust Services Criteria) | SOC 2 CC8.1 Change management processes are in place |
| ISO/IEC 27001:2022 | ISO 27001 8.32 Change management |
| PCI DSS v4.0 | PCI DSS 6.5.1 Change control procedures in production |
| NIST SP 800-53 Rev 5 | SP 800-53 CM-3 Configuration change control |
A result shows the frameworks you tick; SOX 404 brings COBIT and AS 2201 with it. PCI DSS clauses show on the cardholder systems only.
SOX 404 ITGC IT General Controls (ITGC) - Access, Change, OperationsThe clause text
ITGC including access management, change management, computer operations, program development, backup, recovery.
Source: SOX 404 / ICFR
COBIT 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
SOC 2 CC8.1 Change management processes are in placeNamed, not quoted: the criteria text is not held in full here.
Where it usually falls short: Emergency changes used routinely, with retrospective approval that is never withheld; Approval and implementation performed by the same person, so the approval is not independent
Source: SOC 2 (Trust Services Criteria)
ISO 27001 8.32 Change managementThe clause text
Put changes to facilities and systems through change management procedures.
Where it usually falls short: Missing formal approval; No rollback plan documented
Source: ISO/IEC 27001:2022
PCI DSS 6.5.1 Change control procedures in productionChanges to system components in production follow a set procedure that records the reason for the change, its security impact, a documented approval, testing and a way back.
A one-line statement; the standard's own text is not quoted here.
Source: PCI DSS v4.0
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