What 31 internal controls taught me about clarity

The problem with "kind of" controls

Early on, it's easy to write controls that sound good but can't be tested.

They read like:

• "Management ensures…"
• "Employees should…"
• "The company verifies…"

But none of that tells you what actually happens, who does it, or what evidence exists.

What changed when I treated it like audit workpapers

When I documented 31 controls, my mindset shifted:

• A control must be specific
• A control must be testable
• A control must produce evidence

If it can't be verified, it isn't controlled.

The structure that worked

For each control, I forced the same pattern:

1. Risk — what could go wrong?
2. Control — what prevents/detects it?
3. Evidence — what proves it happened?
4. Frequency/owner — who/when?
5. Failure mode — what does "not working" look like?

That structure removed ambiguity.

The real lesson

Controls aren't just policies.

Controls are behaviors you can prove.

Key takeaway

Clarity is a control's best feature.

If someone else can't test it, it needs to be rewritten.