← All articles

Field Notes: What Auditors See That You Don't

By XNM Technologies · June 21, 2026 · 3 min read

Spend a week sitting beside an auditor and the first thing you notice is what they do not do. They do not ask you to walk them through the project. They do not want the narrated tour, the context, the reasons it went the way it went. They open the file and start reading. The story in your head is, to them, hearsay. The only thing admissible is what the record can show on its own, without you in the room to explain it.

That reorientation is jarring the first time you see it. You spent months doing the work; surely the work is the thing being judged. It isn't. By the time the auditor arrives, the work is finished and unobservable. What remains is the trail — and the trail, not the work, is what gets evaluated. This is the uncomfortable field note nobody hands you on day one: the engagement file is the product. Everything else was rehearsal.

They read the file in a different order than you wrote it

You build a project forward, one decision at a time. An auditor reads it backward, starting from the outcome and working toward the evidence that should justify it. That reversal changes what matters. A decision you thought was minor — a small scope change, a quick approval — becomes a focal point if the outcome it led to is material. And the lavish documentation you produced around the parts that went smoothly is, frankly, of little interest. Auditors spend their time where the evidence is thinnest and the consequences are largest.

This is why the volume of your documentation is a poor proxy for its quality. A file can be enormous and still fail, if the few records that actually carry weight — the approvals, the change log, the trail of who touched what — are the ones that are missing or unverifiable. Auditors are not impressed by thickness. They are looking for a small number of specific artifacts, and they can tell within minutes whether those artifacts exist.

Where audit testing time actually goes. Approvals and the change log dominate; the email pile barely registers.
Where audit testing time actually goes. Approvals and the change log dominate; the email pile barely registers.

What the trail has to prove on its own

Strip away everything else and an auditor is checking that the record can answer four questions without your help. Who did this. When. On what authority. And can the document I am looking at be trusted not to have been quietly changed after the fact. A file that answers all four cleanly is a short engagement. A file that answers them with "let me find the person who remembers" is a long one, and a long engagement is rarely a good sign.

  • Attribution: every material action ties to a named person, not a team or a system.

  • Timing: the record carries a date that wasn't applied retroactively.

  • Authority: the person who acted had the standing to act, and the file shows it.

  • Integrity: the document is what it was when it was created, and changes are visible.

Read your own file like a stranger

The most useful habit you can borrow from an auditor costs nothing: periodically open one of your own finished files and read it as if you had never seen the project, with no memory to lean on. The places where you find yourself wanting to explain are exactly the places an auditor will stop and write a finding. Those moments of "well, what happened there was —" are not gaps in your memory. They are gaps in the record, and the record is the only thing that will be in the room when it matters.

We keep a running set of these observations from the field in our records and accountability series. The lesson repeats: build the file for the stranger who will read it, not the team that already knows the story.