Delivery and engineering

Write controls for the estate you have

A control document drafted from good intentions describes a better-run organisation than the real one. The review that matters most is the one done by the people who operate the systems.

In short
  • An assurance engagement tests whether a control exists and operates. A well-written control that is not running is a finding.
  • The people who run the systems should review control documents before anyone signs them.
  • A recorded exception, with an owner and a decision, is worth more than a control that describes something you do not have.

This year we rewrote our own IT control documents ahead of our annual independent assurance audit. The drafting was careful. Each document gained control objectives, numbered controls, an owner for each one, how often it runs, and the evidence it leaves behind. On paper, the result was a well-governed IT estate.

Then three of them came to me for review, as the person who administers the systems they describe, and a number of controls could not stand as written.

How a good document drifts from the truth

Nobody wrote anything false on purpose. Control documents are usually drafted from a mixture of older policies, architecture diagrams, supplier proposals and what people remember. Each source is a little out of date, and each describes something that was true once, planned for later, or assumed to be standard.

Put them together and the document describes the estate as everyone intended it to be. Some controls referred to equipment we do not have. Some described processes that had been planned and not yet switched on. A few referred to servers that are no longer on premises. Every one of them read well.

Why it matters for assurance

An ISAE 3402 engagement asks a straightforward question of each control: does it exist, and is it designed and implemented as described? The auditor does not grade the writing. They ask for evidence, and a control that describes an unbuilt capability produces none.

A document that overstates the environment is therefore worse than a thin one. It creates findings where none were needed, and it tells the auditor that nobody who runs the systems read it before it was signed.

What we changed

The operator reviews before anyone approves. Every control document now goes to the people who run the systems before it goes to management for signature. Their question is simple: could I produce the evidence for this control tomorrow?

Unknowns go back as questions. Where the review could not confirm a fact, the document was not redrafted on an assumption. The question went back to the person who knew the answer, in writing, and the document waited.

Gaps become decisions. Where a control describes something the business does not have, there are two honest options. Build it, or record it as an exception with an owner, a reason and a date for review. Some of those are technical fixes that take a day. Others involve cost, and belong in front of leadership as a decision.

The general lesson

Most organisations that go through assurance for the first time find this, and many find it late, in front of the auditor. It is much cheaper to find it at your own desk.

If you are preparing for ISAE 3402 or any similar engagement, give the draft control set to the person who administers the systems and ask them to strike out anything they cannot evidence. What survives is your control environment. What does not is your work plan.

How we approach security and assurance for clients is set out on the trust and security page.

Sources
  • nVisionIT internal controls programme, 2026.
Keep reading

More from Insights

Delivery and engineering

From policy to control

Most IT policies say what should happen. An auditor needs to know who does what, how often, and what evidence it leaves. Rewriting our policies into that shape changed more than their format.

21 September 2026 · 3 min read
Delivery and engineering

Structure before speed in a development engagement

Standards applied the same way on every engagement are what let a small development team keep its pace after the first month. What that looks like in practice.

26 August 2026 · 3 min read