SOX Change Log Checker
Change type

AI-authored changes: what the auditor reads in them

An AI coding agent writes the change and opens the pull request; a person set it to work. That person cannot be its only approver, because then nobody independent of the author reviewed it. The checker lists the agent-authored changes whose only approver is the agent, another automated account, or the person who prompted it.

How the checker recognises them

Read from the author name: an agent or AI marker in the account name, with or without a bot suffix. A requested-by column names who set it to work.

Findings they raise most often

The clauses that speak to them

4 clauses
COBIT BAI03.08 Execute solution testing
The 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.

Evidence an auditor expects: Test logs with independent testers and business participation; error classification and resolution records; communicated results
Where it usually falls short: Testing done only by the developers; Significant errors accepted to meet a date
Source: COBIT 2019
ISO 27001 8.4 Access to source code
The clause text

Appropriately manage read and write access to source code, development tools and libraries.

Evidence an auditor expects: Repository access controls; Development tool access; Library dependency controls; Change approval records
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 production

Bespoke 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.

Evidence an auditor expects: Pull request review evidence with reviewer name; SAST scan results per release; Code review checklist; Issue tracker showing remediation; Approval gate before deployment
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 management
The 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.

Evidence an auditor expects: Contract or agreement clauses imposing developer configuration management duties; Developer change records showing approval before implementation; Documented configuration items under developer configuration management; Flaw tracking records and reports received from the developer
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

Other change types

Run the specimen Check your own change log