Most compliance failures don't begin in a boardroom. They don't begin with a rogue employee or a cynical executive who decided the rules didn't apply to them.
They begin in a meeting room, where somebody said — without thinking too hard about it — "Oh, that's being handled."
Nobody lied. Nobody cut corners. Nobody meant any harm. Someone just assumed. And that assumption quietly lived inside the compliance programme, unexamined, unchecked — until an auditor arrived, or worse, an incident did.
That is the peculiar cruelty of assumptions in compliance. Known problems can be prioritised, escalated, and resolved. Assumed controls, on the other hand, feel fine. They show green on the dashboard. They occupy a line on the control register. They just don't actually work.
Where Assumptions Come From
Assumptions don't emerge from laziness alone — though that plays a role. More often, they are the natural by-product of organisations that move fast, hire often, and document rarely.
A process gets established. A person owns it. That person leaves. Their replacement inherits the responsibility but not the context. Nobody explicitly hands anything over, so everybody implicitly assumes that somebody else has it covered. The control continues to exist on paper. In practice, it has been orphaned.
Here is how assumptions typically enter a compliance programme — not dramatically, but one quiet gap at a time:
- An employee exits. IT assumes HR will flag it for access revocation. HR assumes IT will handle it automatically. The account stays active for four months.
- A policy was reviewed and approved two years ago. Nobody scheduled a re-review. It gets carried forward in the register because — surely — someone would have flagged it if it needed updating.
- An audit is six weeks away. The control owner assumes the evidence has been collected continuously throughout the year. It hasn't been. A scramble begins.
- A risk owner was assigned during last year's risk assessment. Nobody checked in since. The risk is still listed as "being monitored." It isn't.
- A control worked perfectly for three years. The underlying system changed. Nobody tested whether it still works. It doesn't.
None of these feel like failures in the moment. Each one feels like a reasonable gap that will sort itself out. Together, they represent a compliance programme running on borrowed confidence.
Why Auditors Have No Patience for Assumptions
Here is something worth understanding about how auditors think. They are not in the business of evaluating your intentions. They are not grading your effort. They are assessing one thing: what can you demonstrate?
"We usually do that" is not evidence. "We've always done that" is not evidence. Even "we definitely did that" is not evidence, if you cannot show it. Auditors work with artefacts — documents, records, system logs, approval trails, timestamps. The invisible activity, however diligently performed, does not exist in an audit context.
During any formal assessment, the questions are direct and the expectations unambiguous:
- Is this procedure documented? Show me the document.
- Who owns this control? Show me the assignment in writing.
- Was this reviewed? Show me the review record and sign-off.
- Was this approved? Show me the approval trail.
- Was this executed? Show me the evidence of execution.
If the answer to any of these is "well, we assumed that was happening" — the finding is already written.
The Real Cost — Beyond the Audit Finding
Let's be honest about something that compliance conversations often gloss over: audit findings are not the worst thing that can happen to you.
Audit findings are embarrassing and expensive. They require remediation plans and follow-up evidence and executive explanations. They ding your programme and your professional credibility. But they are, in the grand scheme of things, survivable.
What is genuinely dangerous is what assumptions allow to exist beneath the surface, undetected, for months or years before any audit ever arrives.
The Uber Data Breach (2016): Hackers accessed the personal data of 57 million users and 600,000 drivers. Uber's security team discovered the breach internally — and then paid the attackers to delete the data and stay quiet. For over a year, the assumption held internally that the incident was "handled." Regulators, customers, and drivers had no idea. When the truth emerged in 2017, the company faced $148 million in settlements and a global reputational catastrophe. Somebody assumed silence was the same as security.
Capital One (2019): A misconfigured web application firewall allowed a former AWS employee to access data belonging to over 100 million customers. The configuration had been in place long enough that nobody questioned it — it was assumed to be working because it had always been there. The breach cost Capital One over $80 million in regulatory fines alone, and the CISO resigned. A control that isn't periodically tested isn't a control. It's a hope.
The pattern in both cases is the same. A control existed. Nobody validated whether it was functioning. When it failed — or when the gap was actively exploited — the consequences were not contained to an audit finding. They became regulatory action, litigation, and reputational damage that took years to repair.
That is the real cost of assumptions. Not a line in an audit report. The incidents that happen because nobody confirmed the door was actually locked.
"But We're Too Busy to Validate Everything"
This is the argument that gets made, and it deserves a direct response.
Yes, GRC teams are stretched. Yes, the control register is long and the team is small and the audit calendar is relentless. Nobody is arguing for perfection. But consider what "too busy to validate" actually means in practice. It means you are maintaining a compliance programme whose true state you do not know. You are presenting a picture of assurance that may be inaccurate. You are, in effect, assuming that what was true six months ago is still true today.
That is not a resource problem. That is a risk you are choosing to carry — and often, a risk you are not even disclosing.
The question isn't whether you can validate every control every month. The question is whether your highest-risk, most consequential controls have any mechanism for confirmed, evidenced verification — or whether they are simply trusted to be operating because they were operational at some prior point in time.
What Mature Programmes Do Differently
The difference between a compliance programme that survives scrutiny and one that falls apart under it is not the number of controls. It is the discipline around confirming those controls are real.
Defined Ownership — Not Informal Understanding
Every control in your register should have a named owner. Not a team. Not a department. A person — with their name on it, and an acknowledgement that they know they own it. Informal understandings evaporate when people change roles. Documented ownership persists.
Evidence as a Habit — Not an Audit Scramble
Evidence collection should be an ongoing operational activity, not something that happens in the six weeks before an audit. When evidence is gathered continuously, it reflects how the control actually operates. When it's gathered retrospectively, it reflects how the team remembers or reconstructs things — which is a different thing entirely.
Periodic Testing — Not Perpetual Assumption
Controls degrade. Systems change. People leave. Processes drift. A control that was effective eighteen months ago may not be effective today, and the only way to know is to test it. Scheduled, documented, evidenced testing — even on a risk-based frequency — converts assumption into assurance.
Accountability Mechanisms — Not Just Assignments
Assigning ownership is necessary but not sufficient. There must be a mechanism by which ownership is tracked, follow-through is verified, and gaps are escalated. A control owner with no accountability structure is just a name in a spreadsheet. The accountability loop — assign, track, confirm, escalate — is what transforms a register into a functioning programme.
A Final, Uncomfortable Thought
There is something worth sitting with here. Assumptions in compliance are not just an operational problem. They are a governance problem.
When a board or an executive committee signs off on a compliance report that says controls are operating effectively — and that conclusion rests, in part, on untested assumptions — they are making a representation they cannot actually support. That is not compliance. That is the appearance of compliance. And when the gap is eventually exposed — by an auditor, by a regulator, by an incident — the question asked will not be "why didn't the control work?" It will be: "Why did you say it was working when you didn't know?"
"Assumed" is a word that sounds like knowledge. It is not. It is the absence of knowledge, dressed up in confident language. And in the world of governance, risk, and assurance, the absence of knowledge is precisely where risk lives.
Strong compliance programmes are not built on optimism. They are built on evidence — because evidence is the only thing that survives scrutiny. Everything assumed is, eventually, proven or disproven. The only question is whether you discover the truth on your terms, or someone else discovers it on theirs.