Nobody Can Buy an Audit Until Somebody Says What Arrives

An independent system audit ends in a small stack of documents, and the reason "audit" is such a hard thing to buy is that nobody tells you what they are. So here they are, before any argument for the work.

An inventory of every system in genuine use, including the ones that never made it onto the IT list, with a named person against each row. A data-domain map giving one owner — a person, not a department — for customers, items, prices, stock and the chart of accounts. A licence and subscription table set against who actually signed in last month. A list of access and segregation-of-duties findings, written against roles rather than against people. An integration map with the system of record named for every shared object. And a fix list ordered by what each finding costs in a month if nothing changes, not by how hard it is to do.

Every finding carries a cost of inaction, because a finding without one is an opinion, and opinions get filed.

That is the whole answer. The rest of this article is how those documents get built, in what order, what the work deliberately is not, and how to commission it so that what arrives is usable by somebody who has never met the firm that wrote it.

"Audit" is a word nobody can picture

Everything else you buy in this category has an object attached. An implementation ends in a system people log into. A migration ends in balances that tie. An audit ends in a document nobody describes, so the buyer has to imagine it — and what most people imagine is a slide deck telling them, at length and for a fee, things they already suspected.

That instinct is fair, because plenty of audit reports are exactly that. What separates a report that gets actioned from one that gets filed is not the quality of the analysis. It is whether each finding names an owner, a cost and a next step specific enough to start on Monday. So describe the deliverable first and the method second. A firm that cannot tell you the shape of the documents before the work starts does not have a method; it has a rate card.

The four symptoms that mean an audit rather than a project

Most companies that need this work do not describe themselves as needing an audit. They describe one of four situations.

Two systems disagree and both sides can defend their figure. Sales counts an order when it is confirmed, finance when it is invoiced, and nobody ever wrote down which one the business runs on. The usual reflex is to connect the two systems more tightly, which is why connecting everything to everything produces more argument rather than less — the disagreement is a definition problem wearing a technical costume, and no amount of wiring settles a definition.

A report is technically correct and nobody in the room trusts it. The number is defended by the person who built it and quietly ignored by everyone who has to act on it. The cheapest symptom to diagnose and the most expensive to leave alone, because decisions still get made — just on instinct, with a chart on the screen for cover.

A renewal quote lands and nobody can check it. The uplift is applied to a user count that grew for reasons nobody recorded, on modules somebody added in year two, under a contract negotiated by people who have since left. Being unable to challenge a renewal is not a procurement failure; it is the end state of never having modelled what the system costs in the years after the project team goes home.

One person knows how it works. They are usually excellent and rarely the problem. The problem is that the organisation holds no second copy of what they know, so every change waits for them and their annual leave is a business risk people joke about in meetings.

What arrives

The table is the whole scope. The sections after it explain what makes each worth having.

The system inventory, including the ones nobody listed

The inventory that matters is not the one IT maintains. It includes the desktop database producing the commission report, the pricing model on a laptop, the spreadsheet that is the purchase approval trail, and the messaging group where variations get agreed. Those systems are load-bearing, unowned, unbacked-up and invisible to whoever signs the software budget.

Each row carries what the system holds, who depends on it, what breaks when it stops, where it runs, and one named person. Where the honest answer to the last column is "nobody", that is a finding, costed like any other. The location column earns its place, because many groups cannot say which country a given database sits in — and residency, latency and who is accountable at two in the morning are decisions somebody made by accident.

The data-domain map

One line per domain: customer, supplier, item, price, stock, employee, chart of accounts. Against each, the system where the record is created, the system the business should treat as authoritative, and the person accountable for its accuracy.

The test is that the map contains no committees. "Finance owns it" means nobody owns it, because a department cannot be asked why the price list holds three versions of one customer. A name can — and what that name is actually accountable for, day to day, is set out in what owning a data domain means in practice.

The second column is the one that produces arguments, because two systems routinely both believe they are authoritative and nobody has ever had to choose between them. Deciding that is a short exercise with a durable answer, described in how to settle which system holds the truth.

The licence-versus-usage table

Entitlements on one side, evidence of actual use on the other, per product and per user tier. The recurring findings are not exotic: subscriptions billed for every named user ever created, two products bought separately by two departments to do the same job, modules included in a bundle and never configured. It is also where you first meet the leaver whose account is still active with administrator rights — a finding that belongs to the next document but surfaces here, in the sign-in data.

The table is built from the accounting ledger rather than from the network, because a subscription paid on a card never appears on any network scan. That distinction, and what to do with each line once you have it, is the difference between licence waste and shadow IT. The contractual half of the same finding — what each of these agreements would cost to leave — is a set of clauses that can only be secured before you sign.

The access and segregation-of-duties findings

The finding list is built by reading roles in the system, not by asking people what they are allowed to do. Those two answers diverge sharply, because permissions drift outward and nothing in the life of a system ever prompts anyone to ask whether a right is still needed. The combinations that matter are few and well known — creating a supplier and paying it, changing a price and issuing the invoice, adjusting stock and counting it — and the mechanics of why they get granted in the first place are covered properly in the week-three decision that widens a role to unblock a go-live.

Findings are written against roles and processes, never against named individuals. The distinction is not politeness, it is what keeps the document in circulation: an audit that reads as a performance review of the IT manager stops being read at all, and every right it named stays exactly where it was.

The integration map, with a system of record named

What talks to what, in which direction, how often, what happens to in-flight data when it fails, and — the column most maps omit — which side wins when the two disagree. A map without that column documents the plumbing and leaves the actual question unanswered.

Alongside it sits the data-quality work, because integration findings and data findings are the same findings seen from two ends. The audit samples the places where a number decides money: opening balances, unbilled work, the item master, and the stock figure, which has causes with names and a direction of error you can predict once you know which of them you have.

The fix list, ordered by cost of inaction

This is the document people actually use, and the ordering is the entire point. A fix list sorted by effort puts the easy things first and produces a quarter of visible activity that changes nothing. Sorted by cost of inaction, it puts the dull expensive thing at the top and gives whoever has to fund it a sentence they can repeat to a board without translating it first.

Costing a finding is not a modelling exercise. It is hours, rates, error rates and rework, taken from your own operation rather than from a benchmark, applied one finding at a time. Some findings resist it, and the honest ones are ranked by exposure instead — a retention gap costs nothing at all until the week an authority asks you to produce evidence rather than state a figure, and then it costs whatever that week costs. What you must not do is leave the column blank. A finding with an empty cost column never gets scheduled.

The method, in the order it has to happen

The order is the part firms get wrong, and the part worth insisting on in writing.

Read the configuration first. Roles, approval matrices, tax codes, price-list rules, document numbering, workflow states, scheduled jobs. This is what the system will do regardless of what anyone believes, and it is available before you have taken a minute of anyone's time.

Then read the data. Not a sample dressed for inspection — the whole master files, with duplicates, blanks and dead records left in. Blank mandatory-in-theory fields, orphaned records, the age distribution of open items. Data tells you where the process actually broke, without anybody having to admit anything.

Then read the logs and the exceptions. Who signs in and who does not. Which automations run, what they touch, and whether anything reviews their output. That last question grows more urgent as more of this becomes autonomous, which is why an agent inside a business system needs permissions, an audit trail and a named owner before it goes near a ledger — an unowned automation is a shadow system that writes.

Then read the contracts. Renewal terms, user definitions, escalation clauses, data export rights, what leaving would cost and how long it would take.

Interviews last. By the time you sit with the credit controller you already know the price-override role is on her account, and the question is no longer "what can you do" but "why did you need this, and what happens on the day you cannot". Asked first, the same question produces the process as people wish it ran, and an audit built on that is an expensive way to write down the org chart.

The order has a second benefit: the interviews get short, which is the difference between an engagement that fits around a month end and one that does not. Duration is set by access far more than by effort — if read access is granted early, fieldwork is quick; if every extract has to be requested through a vendor who is not enthusiastic about being audited, it is not. That is also the case for buying a diagnosis as its own piece of work rather than as the first phase of something larger.

The finding that shows up almost every time

You can predict the headline finding before the fieldwork starts, and it is almost never the software itself, or the vendor who sold it to you.

It is that nobody owns the data. Not that ownership is unclear, or contested, or split — that when you ask who decides what a customer record should say, the answer is a department, a committee, or a shrug. Everything downstream follows from that one gap. Two systems disagree because two teams each maintained their own version and neither was wrong. The report is distrusted because the number arrives without anybody standing behind it. The month-end argument recurs because the definition was never settled, only survived.

This is why a better chart almost never repairs a distrusted report, and why a dashboard can be accurate to the decimal and still mislead the room. Precision is not authority. Authority is a name.

The fix is cheap relative to everything else on the list: one named owner per domain, a written definition of the disputed terms, and a standing point in the calendar where that owner confirms or corrects the master file. It does not happen without an audit because no individual manager can assign it to themselves, and nobody else has the standing to.

What an audit is not

Three things get sold under this name and are not this.

It is not a vendor selection. An audit tells you what your systems do, what they cost and where they fail. That is an input to a replacement decision, not the decision. It often establishes that you should not buy anything yet — a finding, not a failure of the engagement.

It is not a penetration test. Access rights, segregation of duties, administrator accounts and whether a restore has ever actually been tested are governance findings, and they sit inside this work. Offensive security is a specialist discipline, you should buy it from a specialist, and where the audit concludes you need one it should say so plainly.

It is not a licence true-up performed for the vendor's benefit. A true-up counts your usage against your entitlement so a supplier can bill the difference. That is the vendor's exercise, run to the vendor's definitions, and it moves in one direction only. Your version asks the opposite question — what are we paying for and not using — and it is the same instinct that treats an end-of-support notice as a supplier's calendar rather than a business case for the upgrade you are being pushed toward.

When you do not need one

If you run one system, have fewer than thirty users on it, and there is one person who can answer every question about how the business works in a single morning, you do not need an audit. You need a conversation. The evidence-gathering that makes this work valuable — reconciling what four departments believe against what the configuration enforces — has nothing to reconcile in a company that small.

The same applies in three other cases. If you already know exactly what is wrong and have simply not done it, buying a report is procrastination with an invoice attached. If your problem is that two managers have never agreed a definition, that is a meeting with a decision at the end of it, not an engagement. And if the work is not in the system at all — orders agreed verbally, costs assembled in a spreadsheet after the fact — then the question is not governance but whether you have outgrown the accounting software you are asking to behave like an ERP, which is a different diagnosis.

Where an audit earns its cost is in groups with more than one entity and more than one system, in companies about to commit to a replacement, after an acquisition, and in any organisation whose board has quietly stopped believing the monthly pack. Below that, say no. A firm that will sell you this work regardless of size has told you what the report is going to be like.

How to commission one so the output is usable

Three things decide whether you get something you can act on, and all three are settled before the work starts.

Do it before the shortlist, not after. This is the commonest reason an audit arrives too late to matter. If a replacement decision is already in motion, the findings change what you buy — which entities go first, which data has to be cleaned before anything moves, which integrations are load-bearing and which were vanity. Ordered the other way round the report becomes a post-mortem, and the thing it would have prevented is the thing that kills most of these programmes: arriving at migration with data nobody owns, which is where projects die and why the software is rarely the cause.

Ask for the deliverables by name, in writing. Not "an assessment of our IT landscape" — the six documents above, each named, with its acceptance condition stated. That every system row carries a person's name. That every data domain has exactly one owner. That the licence table sets entitlement against sign-in evidence rather than against headcount. That every finding carries a cost of inaction, or an explicit statement of why it could not be costed. Written that way the scope is testable on delivery by someone who was not in the room when it was agreed, and the price can be fixed before anyone starts, because the work is defined by its output rather than by its hours. A proposal that resists being written down that way is telling you something useful about what it intends to deliver, and it is cheaper to hear it now than on the day the report lands. It is also the point to hold a published method against what the proposal in front of you actually commits to, and to ask about any gap.

Then ask who benefits from each possible finding. An audit run by the firm that implemented your system, or by a reseller who would like to replace it, is a proposal wearing an audit's clothes. The findings will be true and they will also, often enough, point at that firm's product. Everybody in this market knows it, which is why so many audit reports are ignored: the reader spends the document discounting for motive instead of arguing with the content.

The structural answer goes in the engagement letter. The diagnosis is bought and priced separately from any remediation. Where a fix is something the auditor could do, they say so and price it after the report is delivered, never inside it. And the report belongs to you, in a form you can hand to your incumbent partner or your board.

None of this is clever, and it is not meant to be: a list of what you run, a name against each thing, a price against each problem, and an order of work that starts with the expensive one. What makes it worth buying from outside is not expertise. It is that nobody inside an organisation can compel four departments to answer the same question the same way, and an independent read of the estate you already run can, because it is nobody's colleague and it is not quoting for the fix while it writes.