Anyone else seeing a big gap between "control is designed well" and "control actually works"?

Something I keep running into in control testing: everyone focuses on whether a control should work, not whether it actually does.

On paper, a control can look airtight. Clear owner, sensible frequency, procedure that actually addresses the risk, documentation that's complete. That tells you the design is sound.

But then things get busy. Someone's out, the business wants to move fast, and suddenly the real test shows up:

• Are approvals happening before the transaction, or getting rubber-stamped after?
• Are exceptions actually investigated, or just cleared and closed?
• Is that quarterly review genuinely happening, or getting reconstructed the week an audit request lands?
• Does the control hold up consistently, or only when someone knows it's about to be tested?

A technically sound control can still be operationally unreliable, and I feel like that distinction doesn't get enough attention.

Documentation tells you what's supposed to happen. Testing tells you whether you can actually rely on it.

We ended up moving control testing into SimpleRisk mostly so the operating history sits next to the control itself instead of living in a separate spreadsheet nobody updates until audit season, but I'm curious how other teams handle it.

Do you catch the design-vs-operating gap in your own testing, or does it usually surface during an external audit instead?