How a Risk Control Matrix Improves Audit Readiness
A risk control matrix maps each business risk to the specific control that mitigates it, names the control owner, states how the…
Find the carry points
Start by following one real transaction end to end and recording every point where a human moves data rather than deciding something. Someone exports a report and pastes it into another sheet. Someone reads a number off a screen and types it into a form. Someone forwards an email so a colleague can key its contents into a system.
Each of these is a carry point. They are invisible in process documentation because they are not part of the official process; they are the connective tissue people invented to make the official process work.
- Data exported from one system and imported into another by hand
- Values read from a screen and typed into a different screen
- Email or chat used as a queue between two systems
- Spreadsheets that exist solely to reformat one system’s output for another
- Recurring reports rebuilt manually each period from the same sources
Quantify before choosing what to fix
Not every carry point is worth removing. Record for each one how long it takes, how often it happens, how many people do it, and how often it goes wrong. Frequency multiplied by duration gives the time cost; error rate multiplied by downstream correction effort gives the hidden cost, which is frequently the larger of the two.
The carry points that combine high frequency with a meaningful error rate are the ones to address first. A monthly task taking twenty minutes with no errors is rarely worth an integration project, however irritating it is.
| Frequency | Error rate | Priority |
|---|---|---|
| Daily or more | Errors with downstream impact | Address first |
| Daily or more | Rarely wrong | Address second |
| Weekly | Errors with downstream impact | Address second |
| Monthly | Errors with downstream impact | Consider validation rather than automation |
| Monthly or less | Rarely wrong | Leave alone |
Fix the flow before adding a tool
The common sequence is backwards: buy an automation tool, then look for things to automate. This produces automation of steps that should not exist at all, which is worse than the manual version because the pointless step is now permanent and has a licence cost.
Ask first whether the step is needed. A surprising proportion of recurring reports are produced for people who no longer read them, and reformatting steps often exist because a downstream system was configured to expect a layout nobody chose deliberately. Removing a step beats automating it every time.
What good looks like afterwards
Data entered once, at the point where it originates, by the person who knows it is correct. Systems that need it receive it without a human intermediary. Where a person does intervene, it is to make a judgement, not to retype.
Measure the result in recovered hours and reduced error corrections rather than in tools deployed. The second is easy to count and tells you nothing.