What auditors actually ask for

An audit request list arrives as dozens of line items — ledgers, reconciliations, approval evidence, access reviews. Reading it as a document hunt makes the audit feel like a project. Reading it as questions makes it a checklist.

Auditors are usually trying to answer three things:

1. Who can change a number?

Access reviews, role definitions, and leaver logs answer this. If your approval tool provisions through SCIM and records every role change, the answer is a export, not an investigation. If access lives in memory and tribal knowledge, this is where audit week goes to die.

2. When was it changed, and by whom?

The immutable event log is the entire answer. Every matched line, override, and approval should carry who, what, when, and which version of the rule fired. A walkthrough call is what happens when the log cannot answer on its own.

3. Does the process run the same way every time?

Auditors sample. They pick twelve approvals from the year and compare them. If your process has a policy-based route, the samples look alike. If approvals happen in email, each sample is its own story, and stories take meetings.

Make the answers ambient

The pattern across all three: keep the evidence as a byproduct of doing the work. Approvals that already carry their documents, logs that already record their rules, access that already expires — none of this is built for the audit. It is built for Tuesday. The audit is just the week it pays for itself.