Automated author, no human approval: what the rows show and the clause behind it
The author is a bot or AI coding agent account, and no person distinct from that account, and from whoever set it to work, approved the change. When an agent writes the change, the person who prompted it cannot be its only approver.
Who has to approve a change written by a bot or an AI coding agent under SOX?
No clause names a bot. The clauses name the change: COBIT BAI06.01 has every change authorised through the change process, BAI03.08 has testing by people independent of the solution team, PCI DSS 6.2.3 asks for review by someone other than the originating developer, and NIST SP 800-53 SA-10 has the developer implement only approved changes. When the developer is an automated account, the approval has to come from a person who is neither the account nor the person who set it to work. The checker marks bot and AI coding agent accounts from the author name and lists the changes with no such person as approver.
The question the auditor is likely to ask
walkthrough packWhich person reviewed and approved this change written by an automated account, and were they independent of whoever started the job?
The clause behind it
9 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.01 Evaluate, prioritize and authorize change requests · COBIT BAI03.08 Execute solution testing |
| SOC 2 (Trust Services Criteria) | SOC 2 CC8.1 Change management processes are in place |
| ISO/IEC 27001:2022 | ISO 27001 8.25 Secure development life cycle · ISO 27001 8.4 Access to source code |
| PCI DSS v4.0 | PCI DSS 6.2.3 Custom software reviewed prior to production |
| NIST SP 800-53 Rev 5 | SP 800-53 SA-10 Developer configuration management · 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.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 BAI03.08 Execute solution testingThe clause text
During development, testing including control testing is executed continually according to the test plan and development practices in the appropriate environment, engaging business process owners and end users in the test team: solutions and components are tested per the plan with testers independent from the solution team and representative process owners and end users, and results are recorded in a test log; clearly defined test instructions are used with an appropriate balance of automated scripted tests and interactive user testing; all tests cover the integration of business processes and IT components and non-functional requirements such as security, privacy, interoperability and performance; errors are identified, logged and classified (minor, significant, mission-critical) and tests repeated until all significant errors are resolved, with an audit trail of results; and outcomes are recorded and communicated to stakeholders per the plan.
Where it usually falls short: Testing done only by the developers; Significant errors accepted to meet a date
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.25 Secure development life cycleThe clause text
Establish and apply rules for secure development of software and systems.
Where it usually falls short: Policy exists but not enforced; Threat models not updated for new features
Source: ISO/IEC 27001:2022
ISO 27001 8.4 Access to source codeThe clause text
Appropriately manage read and write access to source code, development tools and libraries.
Where it usually falls short: Shared accounts used for source code repositories; Permissions not reviewed on a regular basis
Source: ISO/IEC 27001:2022
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 SA-10 Developer configuration managementThe clause text
Requires the developer of the system, component or service to perform configuration management during defined life cycle stages, to document and control the integrity of changes to defined configuration items, to implement only organization-approved changes, to document approved changes with their potential security and privacy impacts, and to track security flaws and their resolution and report findings to defined personnel.
Where it usually falls short: Obligations assumed from the developer's own process with nothing in the contract; No visibility of developer changes, so approval is nominal
Source: NIST SP 800-53 Rev 5
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