Most organisations confuse three things: policy, compliance, and governance.
Policy is what you wrote down. Compliance is what you can prove. Governance is what actually happens when nobody is checking, on a normal Tuesday, in the middle of a busy quarter, when the team is under deadline pressure and the person who originally read the policy has long since left.
The first two are documents. The third is a behaviour. Organisations that mistake one for the other develop a false sense of security that is more dangerous than having no policy at all.
Free · 4 minutes
If your most senior engineer left tomorrow, would anyone still understand the system?
Fourteen questions on documentation, dependencies, and the gap between how the architecture works and how many people know it. Banded finding on screen, full sheet by email.
The gap in plain sight
The pattern is consistent and rarely malicious. Nobody is lying. Nobody is breaking the rules deliberately. The policy is filed, the compliance documents are dated and signed, and the operational reality has quietly diverged from both.
The data residency policy specifies US datacentres. The reality is a Zoho form storing submissions in the EU, a CRM bolted on a year later that runs in the US, and a SaaS suite procured by a different team that splits between both regions. Nobody made a coherent decision. The architecture grew in pieces, each piece chose its own region for its own reasons, and the policy document still describes the world as it existed on day one.
The development standard requires linting and automated checks. The pipeline reports that checks pass. The checks pass because the linting rules are weak, the most informative warnings are suppressed, and the standard is enforced only where it doesn’t slow anything down. The standard exists. The practice does not.
The security posture is described as appropriate. The obvious entry points are addressed. The forgotten ones — the staging environment open to the internet, the legacy admin panel nobody owns, the subdomain that points at a server that was decommissioned but not removed from DNS — were not reviewed. Security has been performed at the perimeter. Held throughout, it has not.
The authentication policy mandates two-factor authentication for system access. Sensitive data is then sent over email, as an attachment, in plain text. The strong control at the front door is bypassed by the open window at the back.
In each case, the documents are correct. The compliance posture is technically defensible. The actual behaviour is somewhere else.
Who knows
When the gap is named, the response divides cleanly.
The technical team knows. They have known for a long time. They have watched the divergence accumulate, raised concerns that were not actioned, and developed a quiet expertise in the difference between what the organisation says it does and what it actually does. When someone with authority finally arrives and asks the right question, the technical team is not surprised. They are relieved.
The management layer is defensive. The gap reflects on them. They commissioned the policy. They signed off on the compliance documentation. The discovery that operational reality has diverged from both is uncomfortable in a way that is personal, not technical. The instinct is to explain why the divergence is reasonable, or to question whether the divergence is real, or to focus on the documentation rather than the behaviour.
Neither response is the problem. The problem is the structure that produced the divergence in the first place.
The wrong people, at the wrong time
The root cause is consistent: governance decisions are made by the wrong group of people, at the wrong point in the project.
The business identifies a need. Vendors are selected. Contracts are signed. Architectures are committed. And then, late in the process, IT is told to make it work — which includes making it compliant, secure, and consistent with the policy that was written years ago and has not been substantively reviewed since.
By the time governance is reviewing the decision, the decision has been made. The options are limited to accepting it as-is, documenting an exception, or rebuilding. Most organisations choose the second. Exceptions accumulate. Each one is reasonable in isolation. Together they form the gap between what the policy says and what the operation does.
Governance built into a project on day one is cheap. It shapes the vendor selection, the architectural choices, the data flows, the access model. The constraints inform the decisions rather than being applied to them afterward.
Governance bolted on at the end is either expensive or theatrical. Most organisations, faced with the cost of doing it properly, end up with theatrical — documentation that describes a state the organisation does not actually occupy.
What real governance looks like
Real governance is not a document. It is a set of behaviours that hold under pressure, on a normal day, when nobody is auditing them.
It looks like vendor selection that considers data residency before price. Architectural decisions that confirm regulatory implications before commitment. Access reviews that happen because they are scheduled, not because an incident triggered them. Standards that are enforced in the pipeline, not aspirations published on a wiki. Exception handling that produces a decision and a date, not a document and a shrug.
It looks, more than anything, like the right people making the right decisions at the right time. The technical team is consulted before architecture is committed. Compliance is engaged before contracts are signed. The CTO function — whatever shape it takes in the organisation — has authority over technology decisions, not visibility after the fact.
When governance is real, the policy and the practice converge. When it is theatrical, they diverge quietly, and the divergence is invisible until something makes it visible.
A few rules
Policy is not governance. Writing it down is the easy part. Holding it operationally is the work.
Compliance is not governance either. Being able to prove something on demand is not the same as doing it consistently. The audit is a snapshot. Governance is the film.
Ask the technical team what actually happens. They know. They have been watching the gap develop. They will tell you, if the question is asked by someone with authority and the answer will not be used against them.
Governance built in is cheap. Governance bolted on is theatrical. Make the relevant people part of the decision at the point the decision is made. Not after.
If only the obvious things are governed, nothing is governed. The forgotten subdomain, the staging environment, the legacy admin panel — these are tests of whether governance is real or performed.
The gap between policy and practice is the diagnostic. When the documents say one thing and the operation does another, the issue is not the documents. It is the structure that allowed them to diverge.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.