SOX Change Log Checker
For whoever hands the auditor the change population

Paste your change log. See every production change without an independent approval.

SOX Change Log Checker reads the change or pull-request export you paste and marks each production change the way an auditor will test it. Paste your change or pull-request export, and optionally the deployment log. Get every production change with no independent approval, approvals recorded after the merge or the deploy, changes authored by a bot or AI coding agent with no human approval, people who approved or deployed their own change, emergency changes with no approval after the fact, deployments with no matching change, each with the SOX, SOC 2, ISO 27001, PCI DSS or NIST clause behind it, quoted and cited.

What it readsIt checks the export you paste, in your browser. It cannot see your systems, so paste the deployment log beside the change tickets and it reconciles the two.
What it givesIt lists the rows that need a look, with the clause behind each. It gives no pass or fail and no audit opinion.
Check your own change logEight changes free, no account, nothing leaves your browser until you save.
Specimen: an invented listed software company4 of 60 changes
  1. 29NL-2129normalRefactor invoice rounding helper
    authored bycode-agent[bot]AI coding agent, set to work by t.nakamura
    approved byt.nakamura14 Jul 06:17set the agent to work
    deployed bysvc-release-pipeline14 Jul 11:17
    automated author, no human approval
  2. 19NL-2119normalUsage chart on the account page
    authored bys.patelmerged 29 Jun 15:07
    approved byp.alvarez29 Jun 20:073 h after the deploy
    deployed bysvc-release-pipeline29 Jun 17:07
    approved after it shipped
  3. 50NL-2150normalCapacity reservation for close week
    authored byk.oseimerged 14 Aug 10:50in all three roles
    approved byk.osei14 Aug 07:50is the author
    deployed byk.osei14 Aug 12:50is the author
    no independent approvaldeployed their own changeone person, three roles
  4. 7NL-2107normalSession length for idle users
    authored byj.ruizmerged 11 Jun 11:31
    approved bynone recorded no approver
    deployed byj.ruiz11 Jun 13:31is the author
    no independent approvaldeployed their own changeno ticket reference
60 changes, 20 need a look before the auditor asks. 58 deployments reconciled: 56 matched, 2 with no matching change, 4 changes never deployed. The full run is below the paste boxes.
Two colleagues at a desk going through work on a screen beside a stack of binders
Hand the auditor a change population you have already read: every exception named, the deployments reconciled, and the clause behind each ready for the walkthrough. It works from the export you already have, in your browser, with no connection into your code host or your pipelines to approve first.
01

Paste the population and the log

The change or pull-request export for the period, header row and all, in the first box; the deployment log in the second. Column names are read from a published dictionary of 215 aliases, times in ISO, US or UK formats, with the time zone and the date order stated on the result.

02

Read each change as a custody record

Who wrote it, who approved it and who put it into production, in that order, with the times. A field that breaks the chain is struck and the finding ticked: ten findings in a fixed order, a change under every one it raises, the clause behind each.

03

Take the pack into the walkthrough

The exceptions CSV is the population an auditor samples from. The reconciliation sheet ties every deployment to a change. The walkthrough pack gives, per finding, the rows, the clause and the question the auditor is likely to ask.

Why read the log before the auditor does

The auditor asks for the change population, samples it, and tests each change for an approval by someone other than its author, dated before it shipped. When an agent writes the change, the person who prompted it cannot be its only approver, and the change log is where that shows first. Reading the whole population first turns the sample into rows you have already explained.

The dictionary is ours and published in full: every finding with the clause behind it, the change types it reads, the exports it takes and what each framework asks. It states what the rows show and quotes the clause; it reads no code and no system, and gives no view on any control.
First box: the change export with its header row, one change per line (CSV, tabs or pipes). Columns such as id, author, approver, approved_at, merged_at, type, ticket and tests are recognised by name. Second box, optional: the deployment log, deployment, change, system, deployed_at, deployed_by. Lines like approvers: a.name, b.name | emergency window: 5 days | timezone: UTC set the preamble.
The change population
The deployment log (optional)
The frameworks ticked are the ones whose clauses each finding shows. Nothing is sent anywhere until you choose to save.