Approved after it shipped: what the rows show and the clause behind it
The approval time on the row is later than the merge or the deploy. An approval dated after the change was already merged or in production records that someone looked afterwards, not that someone authorised it first. Emergency changes approved inside the window you set are read under the emergency finding instead.
Can a change be approved after it was merged or deployed, and which clause expects the approval first?
COBIT BAI06.01 has changes authorised, planned and scheduled before they are made, and BAI07.06 promotes to production what was accepted. NIST SP 800-53 CM-4 asks for the impact analysis before the change is implemented, and PCI DSS 6.5.4 asks that only reviewed and approved changes are deployed. The emergency route is the one place an approval may follow the change, inside a set window; the checker reads those rows under the emergency finding. Every other row with an approval dated after its merge or deploy is listed.
The question the auditor is likely to ask
walkthrough packWhat authorised this change to go to production at the time it went, given the approval on record is dated after?
The clause behind it
9 clauses in 7 frameworks| Framework | The clause behind it |
|---|---|
| SOX 404 / ICFR | SOX 404 ITGC IT General Controls (ITGC) - Access, Change, Operations |
| PCAOB AS 2201 | AS 2201 ¶44-46 Testing controls across the period: nature, timing and extent |
| COBIT 2019 | COBIT BAI06.01 Evaluate, prioritize and authorize change requests · COBIT BAI07.06 Promote to production and manage releases |
| 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.4 Roles separated between production and pre-production |
| NIST SP 800-53 Rev 5 | SP 800-53 CM-3 Configuration change control · SP 800-53 CM-4 Impact analyses |
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
AS 2201 ¶44-46 Testing controls across the period: nature, timing and extentWhat the external auditor does under this standard (context, not a reading of your rows):
What the auditor does under it
Operating effectiveness. Requirements include (a) test Operating Effectiveness of controls that are sufficiently important to address assertion-level risk, (b) determine Nature of Tests including inquiry, observation, inspection of relevant documentation, reperformance, (c) determine Timing of Tests including interim, roll-forward, period-end procedures, (d) determine Extent of tests including sample size, selection method, considering frequency, control type, reliance on automation, (e) use evidence from other parties including internal audit, management testing where appropriate per AS 2605, (f) document tests, results, conclusions including sample selection, (g) consider IT general controls reliance for automated controls.
Source: PCAOB AS 2201
COBIT BAI06.01 Evaluate, prioritize and authorize change requestsThe clause text
All requests for change are evaluated to determine their impact on business processes and I&T services and to assess whether the change will adversely affect the operational environment and introduce unacceptable risk, and changes are logged, prioritised, categorised, assessed, authorised, planned and scheduled: formal change requests let process owners and IT request changes to processes, infrastructure, systems or applications, with all changes arising only through the change management process and pre-screened for standard changes; requests are categorised (business process, infrastructure, operating systems, networks, applications, packaged software) and related to affected configuration items; they are prioritised on business and technical requirements, resources and legal, regulatory and contractual reasons; each change is formally approved by process owners, service managers and IT technical stakeholders as appropriate, with low-risk frequent changes pre-approved as standard; approved changes are planned and scheduled; every request is evaluated in a structured way with impact analysis on processes, infrastructure, systems, applications, continuity plans and service providers so that all affected components are identified; and the effect of contracted providers on change management is considered, including integration of their processes into the enterprise's.
Where it usually falls short: Changes made outside the process by administrators with direct access; Impact analysis that ignores the continuity plan and outsourced components
Source: COBIT 2019
COBIT BAI07.06 Promote to production and manage releasesThe clause text
The accepted solution is promoted to the business and operations, run as a pilot or in parallel with the old solution for a defined period where appropriate, and where distribution is electronic or physical it is controlled so that it reaches authorised locations intact: transfer of procedures and supporting services, applications and infrastructure from testing to production follows organisational change management and release management standards; the extent of pilot or parallel processing is determined per the implementation plan; process and system documentation, configuration information and contingency plans are updated promptly; media libraries are updated promptly with the transferred version and the existing version and supporting configuration archived; electronic distribution is controlled so that users are notified and distribution occurs only to authorised and correctly identified destinations with completion confirmed; and physical distribution is logged with what was distributed, to whom, where implemented and when updated.
Where it usually falls short: Production updated from a developer's workstation rather than the controlled library
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.4 Roles separated between production and pre-productionRoles and functions are separated between production and pre-production so that only reviewed and approved changes are deployed.
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
SP 800-53 CM-4 Impact analysesThe clause text
Requires changes to the system to be analysed for their potential security and privacy impact before they are implemented, so that the consequences of a change are understood while it can still be stopped or modified.
Where it usually falls short: Analysis performed after deployment as part of a review rather than beforehand; Privacy impact never considered, only availability and security
Source: NIST SP 800-53 Rev 5