No independent approval: what the rows show and the clause behind it
The row records no approver, or the approver recorded is the person who wrote the change. An auditor testing change management starts from this column: every change in the population should carry an approval by someone other than its author.
Does SOX require an independent approval for every production change, and which clause says so?
Section 404 asks management to assess internal control over financial reporting; the statute itself lists no change-management steps. The change detail an auditor tests sits in the IT general controls and is written down in COBIT BAI06.01: changes are logged, assessed, authorised, planned and scheduled, and arise only through the change management process. SOC 2 CC8.1, ISO/IEC 27001 8.32, PCI DSS 6.5.1 (with 6.2.3 asking for a reviewer other than the developer) and NIST SP 800-53 CM-3 carry the same expectation in their own terms. The checker lists the rows with no approver, or with the author as approver.
The question the auditor is likely to ask
walkthrough packWho approved this change before it reached production, and where is that approval recorded by someone other than the author?
The clause behind it
8 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 |
| 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 · PCI DSS 6.2.3 Custom software reviewed prior to 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
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
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
PCI DSS 6.2.3 Custom software reviewed prior to productionBespoke and custom software is reviewed before release to production by someone other than the developer who wrote it, using manual and automated methods.
A one-line statement; the standard's own text is not quoted here.
Where it usually falls short: Self-approval of pull requests; SAST not blocking on findings
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