Plain definition
A preventive control acts before a risky transaction, change, or access request is completed. It places a condition in the process: a system block, required approval, permitted-user rule, or validation of key evidence. Its purpose is to stop an error or unauthorized action while it is still cheap to correct.
The design must name the risk, the point where the process stops, the person or system that can release it, and the evidence considered. A preventive control reduces a defined risk; it does not prove that every document is genuine or that people cannot collude.
Illustrative example
Suppose an accounts-payable clerk enters a supplier invoice. The payment portal will not release a batch above the clerk’s authority until an independent approver reviews the purchase order, receipt record, and invoice. The approver sees that the invoice price is 10% above the agreed price and returns it to procurement for clarification.
No cash leaves while procurement obtains a corrected invoice or a documented contract change. The control has prevented a payment based on an unresolved difference, rather than leaving finance to recover money after the supplier has been paid.
A preventive control is strongest when it is embedded in the normal workflow; a reminder to “be careful” is rarely a reliable stop.
Why it matters
It protects cash and time by stopping avoidable errors before they become a supplier dispute, bank-recall request, or accounting correction.
It helps management see whether its systems genuinely enforce authority or merely record a promise that someone will check later.
Practical consequence
Choose one high-risk transaction and identify its last safe stop point, the evidence needed there, and the person authorised to release it.
Test a deliberately incomplete or out-of-limit request in a safe environment, and review documented exceptions to confirm that the block cannot be bypassed without a visible decision.