Your event log is an audit trail SOX auditors will like

Yes. An append-only event log is, by construction, the kind of audit trail a SOX examiner is trying to reconstruct: every change to financial state is a durable record carrying an actor, a timestamp and a payload, and nothing overwrites what came before. You rebuild current balances by replaying the log, so the state and the trail can never drift apart. In most packaged suites that same evidence is a per-module afterthought.

What does SOX actually test in an order-to-cash system?

Not your business logic. IT general controls (ITGCs) are the plumbing auditors lean on before they trust any automated control, and under PCAOB AS 2201 an automated control is only allowed to count as low-risk if the ITGCs underneath it are effective. Break the plumbing and every "the system applies the discount correctly" control reverts to manual testing.

ITGCs cluster into a small number of domains. Secureframe's guidance groups them into five categories, as of November 2025: change management, access, data backup and recovery, system operations and IT security. Three of those, who can do what, what changed, and how it was built and deployed, are exactly the questions an event log answers without extra tooling.

The trap most teams miss is that scope is triggered by revenue, not by size. A custom order-capture suite is in scope the moment it books or feeds revenue into the SAP financial core, which is roughly the moment it goes live. If you are weighing that build, the same reasoning runs through build vs. buy in 2024: the control surface you own is part of the total cost.

Why is an event log audit evidence by construction?

Because the properties auditors want are the same properties that make event sourcing work at all. An event is an immutable fact: it happened, it is stamped with who caused it and when, and current state is a projection derived by folding the log forward. You do not store "the balance"; you store the events and compute it. Putting order capture, stock, returnables and delivery on one event bus means that single design decision collapses three separate control questions into one artifact.

The contrast that bites at audit time is consistency. In a packaged suite, each module carries its own trail with its own retention window and its own export format, so assembling one coherent story for the examiner is an integration project every quarter. A single event bus gives you one retention policy, one export path and one clock. It is also why who owns which service shapes your control boundaries: segregation of duties on paper means nothing if three teams can all write to the ledger directly.

How do you turn an event bus into SOX-grade evidence?

Owning an event bus does not automatically earn a clean opinion. The log has to be the system of record, not a debug side-channel. The steps, in the order we apply them:

1. Make the log authoritative and immutable. Append-only storage, no update-in-place, and a WORM-style retention lock. Set retention to at least seven years to match 17 CFR 210.2-06 (Rule 2-06 of Regulation S-X). The lock matters because deleting financial records ahead of that window is not a policy slip, it is a federal offence carrying up to 20 years under 18 U.S.C. 1519.
2. Put identity on every event. Authenticated actor, command ID, and causation and correlation IDs, so any event traces back to the request and the human or service that issued it. An event with no actor is a finding waiting to happen.
3. Enforce segregation of duties at the command, not the screen. Authorization decides which principals may issue which commands before an event is ever written. UI-level role hiding is not a control; a control is something the direct API path also honours.
4. Make replay deterministic. Version your projections, pin the fold logic, and be able to rebuild any balance as of any date from the same events. If replay is reproducible, an auditor can independently recompute the number instead of trusting a spreadsheet.
5. Treat config and schema changes as events too. Feature-flag flips, price-list loads and permission grants are change-management events and belong on the same log with the same identity and retention. This is where shipping a rollout as a config change pays back twice: the flip that altered behaviour in one OpCo is already captured as evidence.
6. Give auditors a query, not a CSV. A read model scoped to the control assertion, with actor, timestamp and before-and-after already joined, turns a week of sampling into an afternoon. Map events to control assertions once and keep the mapping in version control.

Where does event sourcing not save you?

It is not a complete ITGC programme. Access provisioning, joiner-mover-leaver reviews and infrastructure operations still need their own controls; the log records who acted, but something else has to decide who may. Immutability also collides with data-subject erasure requests, since you cannot keep an event forever and also delete personal data inside it, so you crypto-shred: encrypt the personal fields per subject and destroy the key, leaving the financial fact intact. Plan that on day one, because retrofitting encryption boundaries into a live log is genuinely painful, and we learned it the slow way.

The more interesting shift is what this does to the audit itself. When the same events feed live projections and the auditor's read model, evidence stops being something you assemble after quarter-close and becomes a query against a system that is already running. The teams furthest along are pointing continuous controls monitoring at the bus directly, so the examiner samples the same stream operations does, in near real time. An audit trail your auditors like is a pleasant outcome; an audit that never needs a data-extract request is where this is heading.