From policy to control

A typical IT policy reads like good advice. Backups should be taken regularly. Access should be reviewed. Changes should be approved. Every sentence is sensible, and an auditor can do almost nothing with any of them, because none says who does it, how often, or what proof exists afterwards.

This year we rewrote our IT policies into control form. It took longer than we expected, and it improved the thinking more than it improved the formatting.

What a control looks like

Each document now opens with its control objectives, the outcomes the controls exist to achieve. Under each objective sit numbered controls, and every control carries the same four things:

An owner. A named role, not a team or a department.

A frequency. Daily, monthly, on every change, on every new starter. "Regularly" is not a frequency.

An evidence artefact. The record the control leaves behind: a log, a signed review, a ticket, a report.

A retention period. How long that evidence is kept, so it still exists when someone asks for it.

Writing those four fields for every control is where the policy's real gaps show. If nobody can name the owner, the control has not been happening. If nobody can name the evidence, it cannot be proven that it has.

What the customer is responsible for

A service provider's controls never cover everything. Some protections depend on what the customer does: managing their own users' access to a system we host, telling us when someone leaves, protecting their own credentials. These are complementary user entity controls, and each document now lists them explicitly.

Writing them down is useful for both sides. The customer sees exactly which obligations sit with them, and we stop implying we control things we do not.

One owner for every boundary

A control set is written across many documents: access, change, backup, recovery, physical security, logging, suppliers. The risk is that two documents both cover the same ground slightly differently, or that each assumes the other covers it and neither does.

We fixed this by giving every boundary one owner. Where two documents touch, one owns the requirement and the other refers to it, and both say so. We also check programmatically that every control one document refers to actually exists in the other.

The network is not the boundary any more

The largest rewrite came from a change in our architecture. Access used to be controlled largely by network position: if you were on the VPN or inside the office, you were trusted. We moved the boundary to identity, with Entra ID and Conditional Access deciding who gets in based on who they are and what device they use.

Many older clauses still derived protection from network location. Each of those was rewritten, either as an identity control or as a lateral-movement control that states plainly it is not an access control. A policy that describes an architecture you have left behind will be tested against the one you now run.

Why it was worth it

Restructuring the documents turned a set of statements into something that can be tested, owned and evidenced. It also produced a single control matrix, generated from the documents themselves, so the matrix cannot drift from what the policies say.

We now bring the same structure to client work where assurance is a requirement. More on that is on our cyber security page.