A control earns its place when it makes a decision faster, clearer or safer. If its only output is a document produced for someone else to read, it has become overhead — and teams will route around it.
Why control frameworks drift from the work
Frameworks are usually adopted to answer an external question: a certification, a client's due diligence, a regulator's expectation. Answering that question well is legitimate. The drift begins when the control is designed around the answer rather than around the activity it is meant to govern.
Two systems then run in parallel: how work actually happens, and how work is described. Every audit cycle widens the gap, because the cheapest way to close a finding is to add reporting rather than change practice.
Designing controls into the activity
The alternative is to place the control where the decision is made and let the evidence fall out of it. An access review that happens because a manager approves a role change in the system is stronger than a quarterly spreadsheet reconciliation, and it costs less.
This requires being specific about ownership. Every control needs one named person who can change how the underlying activity works — not a team, and not the function that reports on it.
A test for any control you own
Ask three questions. Which decision does this control improve? Who would notice if it stopped operating? What evidence does it produce without anyone assembling it?
Controls that fail all three should be retired or redesigned. Keeping them is not conservative; it dilutes attention across a framework that people no longer trust.