Approver not on the list: what the rows show and the clause behind it
The approver recorded is not on the approver list you gave in the preamble. The list of who may approve a production change is what an auditor reads each approval against.
Who is allowed to approve a production change, and where should that be written down?
The entity-level row for SOX carries a board-approved delegation of authority, and COBIT DSS06.03 has levels of authority for approving follow approved job roles. NIST SP 800-53 CM-5 defines and documents who may change the system and CM-9 sets roles in the configuration management plan. Paste your approver list in the preamble and the checker lists every approval by someone not on it; with no list, this finding is not read.
The question the auditor is likely to ask
walkthrough packWas this person authorised to approve production changes on this system at the time, and where is that authority recorded?
The clause behind it
9 clauses in 7 frameworks| Framework | The clause behind it |
|---|---|
| SOX 404 / ICFR | SOX 404 ENT-5 delegation Delegation of Authority · SOX 404 ITGC IT General Controls (ITGC) - Access, Change, Operations |
| PCAOB AS 2201 | AS 2201 ¶39-42 Walkthroughs and the selection of controls to test |
| COBIT 2019 | COBIT DSS06.03 Manage roles, responsibilities, access privileges and levels of authority |
| SOC 2 (Trust Services Criteria) | SOC 2 CC5.1 COSO principle 10: Selects and develops control activities to mitigate risks |
| ISO/IEC 27001:2022 | ISO 27001 5.3 Segregation of duties |
| 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-5 Access restrictions for change · SP 800-53 CM-9 Configuration management plan |
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 ENT-5 delegation Delegation of AuthorityThe clause text
Board-approved delegation of authority matrix defines approval limits for commitments, expenditures, and contracts.
Where it usually falls short: Delegation of authority not reconciled to system approval limits across ERP and banking; Re-delegation in absence of approver not documented or not time-bound
Source: SOX 404 / ICFR
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 ¶39-42 Walkthroughs and the selection of controls to testWhat the external auditor does under this standard (context, not a reading of your rows):
What the auditor does under it
Walkthroughs, selection, design effectiveness. Requirements include (a) perform Walkthroughs of significant transaction flows to confirm understanding of controls, identify control points, (b) Selecting Controls to Test focused on controls that sufficiently address the risk of misstatement to each relevant assertion, (c) evaluate Design Effectiveness via inquiry, observation, walkthrough, inspection, (d) determine whether the company's controls if operating as prescribed by persons possessing necessary authority, competence would satisfy the company's control objectives, (e) document understanding, selection rationale, design conclusions, (f) update design conclusions as controls or processes change.
Source: PCAOB AS 2201
COBIT DSS06.03 Manage roles, responsibilities, access privileges and levels of authorityThe clause text
Business roles, responsibilities, levels of authority and segregation of duties supporting the process objectives are managed, and access to all information assets related to business processes is authorised: roles and responsibilities follow approved job descriptions and process activities; levels of authority for approving transactions, transaction limits and other decisions follow approved job roles; sensitive activities are allocated so that duties are clearly segregated; access rights and privileges are the minimum needed for predefined job roles, removed or revised immediately on role change or termination; regular awareness and training cover roles, responsibilities, the importance of controls and the security, integrity, confidentiality and privacy of information; administrative privileges are secured, tracked and controlled to prevent misuse; and access control definitions, logs and exception reports are periodically reviewed so that privileges remain valid and aligned with current staff and roles.
Where it usually falls short: Transaction limits not enforced in the system; Access accumulated across role changes
Source: COBIT 2019
SOC 2 CC5.1 COSO principle 10: Selects and develops control activities to mitigate risksNamed, not quoted: the criteria text is not held in full here.
Where it usually falls short: Controls listed with no traceability to any risk, so the entity cannot show they mitigate anything identified; Detective controls absent, leaving no means to identify failure of the preventive ones
Source: SOC 2 (Trust Services Criteria)
ISO 27001 5.3 Segregation of dutiesThe clause text
Split conflicting duties so no single person can run a sensitive process end to end unchecked.
Where it usually falls short: Combining conflicting roles in small teams; Lack of documented exceptions
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-5 Access restrictions for changeThe clause text
Requires physical and logical access restrictions on who may make changes to the system to be defined, documented, approved and actually enforced, so that only authorized personnel can alter the system.
Where it usually falls short: Developers hold standing write access to production alongside the pipeline; Restrictions documented but not enforced, so the pipeline can be bypassed manually
Source: NIST SP 800-53 Rev 5
SP 800-53 CM-9 Configuration management planThe clause text
Requires a configuration management plan for the system that sets out roles, responsibilities and processes, establishes how configuration items are identified and managed across the development life cycle, names the configuration items placed under management, is reviewed and approved by defined personnel, and is itself protected from unauthorized disclosure and modification.
Where it usually falls short: Plan describes a process that the delivery teams do not follow; Configuration items never formally identified, so the plan has no subject
Source: NIST SP 800-53 Rev 5