Controls are part of the process
When people talk about compliance, they often picture a separate activity: a checklist completed before an audit, or a team that reviews work after it is done. A different approach is to build checks into the work itself. Operational controls are the steps, approvals, limits and records that are part of how a process runs, designed to reduce the chance of error, misuse or missing information.
Centralizing operations can make this easier. When many teams run the same process in the same way, a control can be designed once and applied everywhere. When each team improvises, the same control either has to be reinvented many times or is quietly skipped in some places.
This article looks at that design question from an operational point of view. It is general information, not legal advice, and it does not attempt to describe what any specific law or regulation requires.
Why standard procedures help auditors
An audit, in simple terms, asks whether an organization does what it says it does. Auditors typically look for a described process, evidence that it was followed and some way of noticing when it was not.
Standard procedures help with each of those. A written procedure shows what the organization intends. A common workflow produces records in a predictable form, so evidence is easier to find. And because every unit follows the same steps, an auditor can sample a few cases and form a reasonable view of the whole, instead of having to learn a different local method each time. Good standard operating procedures are the foundation of this, since a control that is not written down is difficult to demonstrate or to teach.
Consistency does not guarantee compliance. A procedure can be followed perfectly and still be the wrong procedure for an obligation. Interpreting what the organization must do belongs to qualified legal and compliance advisers, and the operational design should follow their guidance.
Common kinds of operational control
Controls are often grouped by when they act. The examples below are generic illustrations.
- Preventive controls stop a problem before it happens, such as requiring a second person to approve a payment above an agreed amount, or limiting who can change a supplier’s bank details.
- Detective controls notice a problem after the fact, such as a regular comparison of two records that should match, or a report of unusual transactions.
- Corrective controls limit the harm once something has gone wrong, such as a documented way to reverse an error and record the reason.
A well-designed process usually combines these. Relying only on detection means problems are found late. Relying only on prevention can make a process slow and can still miss unusual cases.
Separation of duties
One of the most widely used ideas is separation of duties: the person who starts a transaction should not be the only person who approves or reconciles it. Centralized processes can enforce this by assigning steps to different roles in a shared system. It is harder to maintain when small local teams each have one person doing everything.
That said, separation can be impractical in very small units, where compensating measures such as additional review by someone elsewhere may be used instead. This is a good example of a point where central design needs to meet local reality.
Evidence and records
Controls matter little if there is no trace that they operated. Centralized workflows tend to record who did what and when, which can make evidence easier to produce than it would be from scattered emails and spreadsheets. Retention rules matter here as well, since records need to be kept for as long as the organization requires, and no longer than necessary. The topic of data retention schedules covers that side in more detail.
Records are only useful if they are accurate. A system that logs approvals which were in fact rubber-stamped provides paperwork without assurance.
Where centralized controls can go wrong
Central control is not automatically better control. Several problems are worth keeping in mind.
- One-size-fits-all design. A control suited to a large, high-value transaction may be pointless friction for a small, routine one. Over-controlling low-risk activity wastes effort and encourages workarounds.
- Distance from the work. Designers at the center may not know how a process actually runs at a site. Controls that look sound on paper may be impractical in practice.
- Checkbox behavior. When staff see controls as bureaucracy, they may complete them without thought. Controls that are understood are more likely to work.
- Concentrated failure. If a central process or system is flawed, the flaw spreads everywhere at once. Testing and change control reduce this, but cannot remove it.
- False comfort. A tidy set of procedures can make an organization feel safer than it is. Controls need periodic testing to confirm that they still operate.
Ownership and review
A control without an owner tends to decay. Someone should be responsible for each process, for checking that its controls still make sense, and for updating them when the work changes. System ownership roles and clear decision rights make it easier to see who can approve a change to a control and who must be consulted.
Where a unit genuinely needs to differ, a standards exception process lets the difference be recorded, justified and reviewed, instead of being a hidden departure from the standard.
A sensible approach
Organizations that want to strengthen operational controls often start with a small number of important processes, such as payments, access to sensitive information or supplier set-up. They describe how the work is done today, identify where errors would matter most, and add or simplify controls accordingly. They then test the controls and adjust them.
The link to broader compliance management is straightforward: operational controls are one of the ways obligations are put into practice, while the compliance function tracks the obligations themselves. Neither replaces the other. For any real obligation, qualified legal, risk and compliance professionals should be consulted, and no design can guarantee a particular audit result.