Risk control matrix: one row per risk, one control that actually addresses it

A risk control matrix — an RCM — is the document that links each risk in a process to the control that addresses it, and records how that control is performed, by whom, how often, and what evidence it leaves. It is the working core of a control programme: the scoping, the testing plan and the deficiency evaluation all read from it.

The failure mode is almost always the same. The rows describe activities rather than risks: "invoices are processed", "payroll is run". An activity is not a risk, and a matrix built on activities cannot say whether the control is sufficient, because there is nothing for it to be sufficient against.

What each row of a risk control matrix holds

• The process and the sub-process, in the words the business uses.
• The risk, stated as what could go wrong and its consequence — not as a topic.
• The financial statement assertion affected: existence, completeness, accuracy, valuation, rights, presentation.
• The control that addresses it, described so that a stranger could perform it.
• Whether it is preventive or detective, manual or automated, and its frequency.
• The control owner, by role.
• The evidence the control produces, named specifically.
• Whether it is a key control, and the testing approach and sample size that follows.

The evidence column is the one to fill in first when building a matrix, not last. If nobody can name the artefact, the control will fail testing regardless of how well it is described — and the discovery is much cheaper now than during the audit.

Writing risks that can be controlled

A usable risk statement has a cause, an event and a consequence: "a supplier bank account is changed fraudulently, so payments are diverted". That sentence implies its own control — verification of bank detail changes through an independent channel — and implies its evidence, being the record of that verification.

Compare "vendor master data" as a row. It names a topic and controls nothing. Matrices full of topics grow endlessly because nobody can tell when a risk is adequately covered.

Mark key controls sparingly. Every control marked key must be tested every year, with a sample size that follows its frequency. Teams that mark everything key create a testing programme they cannot complete, and an incomplete testing programme is a worse position than a smaller one that finishes.

Keeping it alive

1. Build it with the people who perform the controls, in a walkthrough rather than an interview.
2. Review it whenever the process or the system changes — not annually by default.
3. Version it, so a control that was changed mid-year can be tested against the version that applied in each period.
4. Cross-reference each row to the test performed and the result, so the matrix and the testing file agree.
5. Retire risks that no longer exist instead of carrying them for continuity.

An RCM is a living spreadsheet with an audit trail attached: many columns, several editors, and a need to prove later what it said in March. Ettex Sheets keeps the matrix with its version history and its review trail, so the row the tester sampled and the row that exists today can be compared rather than confused. Where the internal controls are already documented this way, the balance sheet reconciliation schedules and access reviews they reference are the same records the matrix points at.