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.
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.
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.
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.
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.
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.
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.
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.
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.
AI changes the rate at which delivery work is produced. It changes nothing about who is answerable for it. Where that line sits decides whether AI-assisted delivery is an advantage or a liability.