Being audited: what to expect and how to prepare

Teams facing their first technology audit generally prepare for the wrong thing. They tidy code, write documentation nobody asked for, and arrive tense, having spent a fortnight on work that will not be examined.

The exercise is more procedural and less adversarial than it feels from the inside. What follows is what actually happens and where the effort is well spent.

The engagement described under it audit services runs this way; most others are close enough that the preparation transfers.

What actually gets asked for

Lists and evidence, mostly. Who has access to production. When access was last reviewed. When a backup was last restored. Which changes went to production in a given month, and who reviewed them. What personal data is held and where.

Notice what is absent: opinions about code quality, architecture diagrams, and descriptions of intent. Auditors are collecting things a system produced, not things a person believes.

The preparation that helps

Produce three lists before anyone asks. Everyone with production access. Every third-party service holding your data. The date of the last restore test.

If assembling those takes more than a day, you have found the first finding yourself, privately, which is a considerably better position than having it found for you.

Nominate one point of contact. Auditors asking six engineers the same question get six answers, and the inconsistencies become findings about control rather than about knowledge. One person routing requests removes most of that.

Set aside real time. A few days of a senior person’s attention, more if documentation is thin. Treating it as something that fits around delivery is how a two-week exercise becomes a six-week one.

The preparation that does not

Tidying code. Writing documentation the week before. Rehearsing answers. Changing anything in production during the review, which introduces risk and muddies the evidence.

The strong temptation is to fix things quietly as they surface. Resist it during the review — note them, fix them after, and let the finding be recorded. A finding that was remediated during the audit and recorded as such is a good signal. One that quietly disappeared is a problem for both sides.

Answer exactly what was asked

The most common self-inflicted cost. A question about backup frequency gets answered with an account of the entire infrastructure, which surfaces three things nobody had asked about and extends the review.

This is not concealment. Scope exists for a reason, and volunteering material outside it converts a bounded exercise into an open-ended one. If something outside scope genuinely worries you, raise it deliberately as its own conversation rather than as a digression.

Findings are not accusations

Almost every organisation fails several items. The purpose is establishing which failures are load-bearing for the decision being made, and most are not.

A finding of “shared administrative account” is a fact about a control, not a judgement about the engineer who created it — usually under time pressure, for a sensible reason, years ago. Teams that receive findings as criticism become defensive, and defensive teams give worse answers, which produces more findings.

The useful posture: for each finding, agree whether it is accurate, then discuss consequence separately. Those two conversations go badly when merged.

After the report

The report is not the output. What changes is.

Take the findings that would change a decision, assign each an owner and a date, and record the ones you are consciously accepting along with why. That last category matters — an accepted risk with a named accepter is a decision, and an ignored finding is an oversight, and the next audit will treat them very differently.

What the good ones feel like

A well-run review is mostly quiet. Requests arrive in batches, they are specific, and they reference the scope document. There are few surprises, because the plan said what would be examined.

The signal that one is going badly is scope drift: requests that do not map to anything agreed, arriving individually, each small enough to seem unreasonable to refuse. Cumulatively they turn a bounded exercise into an open-ended one, and the fix is to point at the plan rather than to keep answering.

That is a legitimate thing to do. Asking how a request relates to the agreed scope is not obstruction, and a reviewer who cannot answer it has drifted.

What I cannot promise about this

The tone varies enormously by auditor and by whether the exercise is voluntary or imposed. A review commissioned by your own board and one commissioned by an acquirer feel different regardless of method, and preparation does not change that.

I also cannot tell you a finding count to expect. It depends on the age of the organisation and whether anyone has done this before, and any figure I offered would be invented.

Related reading: the audit process covers the stages from the other side, the audit plan covers the document that defines scope before any of this starts, and internal audit covers the version run by colleagues rather than outsiders.