The Anatomy of a Strong Control: From Approval to Evidence

An approval is a decision. A control design explains how that decision addresses a defined risk, what must happen before it is made and what follows when the evidence is incomplete.

The problem

“Finance approves supplier changes” sounds reassuring, but leaves important questions open. Which changes? Who checks them? What does the reviewer verify? Can new details reach the payment process before the review is complete?

Why it matters

A vague description can leave different people performing different checks while everyone believes the same control exists. A signature may show that someone clicked approve; it does not, by itself, explain the work performed.

An original hypothetical case

An equipment-maintenance company receives a request to change a supplier's bank details. The teaching risk is an unauthorised change becoming active and eligible for payment. No actual supplier, account or incident is represented. The process below is an illustrative design, not a universal prescribed procedure.

Objective: name the unwanted event

The intended outcome is that only verified and authorised bank-detail changes become eligible for payment. “Check supplier forms” describes an activity; the objective explains what that activity is meant to protect.

Owner: assign a decision, not a department

In this case, an AP supervisor checks the proposed change separately from the requester and record editor. The design identifies an authorised delegate and the authority needed to hold an unresolved request. Where full separation is impractical, management must evaluate appropriate alternative safeguards rather than assume a second signature solves the problem.

Frequency: connect the check to the event

The check applies to every proposed bank-detail change before activation. A periodic review after activation serves a different purpose. The control description should state the trigger and the point at which the process must wait.

Evidence: retain what was checked

The illustrative case record links a request identifier to the comparison performed, verification route, reviewer, time, decision and system change reference. Verification uses a separate trusted contact channel whose provenance and suitability have been assessed, not contact details introduced by that same request. An old telephone number is not automatically reliable. Evidence should show the check performed, rather than a signature alone; real records should avoid unnecessary personal or bank-data exposure.

Escalation: make the exception route usable

If verification is unresolved, the proposed new details remain unavailable for payment selection and the issue goes to the finance lead for documented handling. Urgency is not an informal override. Legitimate existing liabilities may need a separate authorised payment route; this example does not recommend stopping every supplier payment. The response window must fit the exposure.

Monitoring: challenge whether the design still works

In the case, the controller performs a weekly review of master-change activity, unresolved requests and possible bypasses. Weekly is an illustrative choice, not a required frequency. The reviewer compares authoritative change or audit records with case evidence and investigates gaps. If the source log omits changes, a clean ticket list may give false comfort. Monitoring must also follow recurring causes and whether corrective action was effective.

Inside Assurance Perspective

A useful control description connects the risk, responsible decision-maker, required steps, timing, retained evidence, exception route and follow-up. These six design lenses are a teaching aid. They are not a score that certifies a control as effective.

What should change

Replace “approved by Finance” with an operational description that another competent person can understand and carry out. Then test implementation and actual performance separately. Good wording does not establish that a check operated, that access restrictions held or that every event entered the records. Compromised communication channels, privilege abuse, collusion and judgment can still leave exposure.

Put It Into Practice

Choose one control in your process. Write its objective, owner, trigger, evidence, escalation and monitoring. Ask what happens when evidence is missing and which independent record could reveal an omitted event. Finish by naming one risk the design does not resolve.

Further reading

GAO's 2025 Green Book provides primary guidance on responsibilities, implementation, documentation and monitoring in a US federal context. It informs the concepts here; it is not presented as an Indonesian legal requirement or an endorsement of this example.

Beyond the numbers. Inside the business.