Write approval policies your auditors will love

Every company already has approval policies. Most of them live in people’s heads. Ask who can approve a $4,000 software renewal and you’ll get three different answers, each followed by “but it depends”. That works until the person who knows the answer is on holiday, or until an auditor asks you to show why a request was approved.

A good policy is short enough for an agent to follow and clear enough for an auditor to read without a walkthrough. Here is the template we use with every team we onboard.

Start with the requests you already approve

Don’t write policies from a blank page. Pull the last three months of approvals from Slack, email or your ticketing tool and sort them into piles. You’ll find that a handful of request types make up most of the volume, and that the people approving them almost always say yes.

Those piles are your first policies. Anything approved nine times out of ten, by the same kind of person, for the same kind of reason, is a rule waiting to be written down.

The five parts of a readable policy

Every policy we write has the same five parts, in the same order:

1. Scope. Which requests does this cover? “Software purchases under $2,000 for existing vendors.”

2. Conditions. What has to be true? “The requester’s team has budget left this quarter and the vendor is on the approved list.”

3. Outcome. What happens when the conditions are met? “Approve automatically and notify the budget owner.”

4. Exceptions. What sends it to a person instead? “Any new vendor, any contract longer than 12 months.”

5. Owner. Who maintains this rule and reviews it each quarter?

That’s it. If a policy needs a sixth part, it’s usually two policies pretending to be one.

Write conditions an agent can check

“Reasonable cost” is not a condition. “Under $2,000” is. Every condition should be something the agent can verify from data it already has: an amount, a vendor list, a team, a cost center, a date. If a condition needs judgment, it belongs in the exceptions, where a person makes the call.

A useful test: read the condition aloud to someone new on the team. If they need to ask a follow-up question before they could apply it, the agent will need to ask too, and that question should be answered in the policy instead.

Make exceptions explicit

The fastest way to lose an auditor’s trust is a policy that quietly approves edge cases. List the exceptions plainly, and send each one to a named approver rather than a shared channel. An exception with no owner is just a delay with extra steps.

What auditors actually look for

After sitting through a lot of audits with customers, we’ve noticed that auditors care about three things far more than the wording of the rule itself:

• Consistency. Was the same rule applied the same way every time?

• Traceability. Can you show which rule approved a given request, and which version of that rule was live at the time?

• Change control. Who changed the rule, when, and who signed off on the change?

Metrivo records all three automatically. Every decision links back to the policy and the version that made it, and every edit to a policy is logged with its author and approver. When the auditor asks, you export the trail instead of reconstructing it from memory.

Review them like code

Policies drift. Budgets change, vendors come and go, and a threshold that made sense last year becomes a bottleneck this year. Put a quarterly review on the owner’s calendar and look at two numbers for each policy: how many requests it approved, and how many exceptions it raised. A policy that raises lots of exceptions is either too narrow or hiding a second rule.

The rule of thumb

If you can’t explain why a request was approved in one sentence, neither can your auditor. Write the sentence first, then write the policy.