Inside Assurance Toolkit #05 — Risk & Control Matrix

A risk and control matrix becomes useful when another person can trace a business objective to a specific failure, the response intended to address it, and the evidence needed to evaluate that response.

This original working template uses supplier bank-detail changes in a fictional food wholesaler. It contains a blank RCM, three worked example rows and a guide. No company records or actual testing results are represented.

Start with the business objective

The objective is to pay the genuine supplier through an authorised bank account. “Finance risk” is too broad to tell a process owner what could go wrong. A more useful risk event is that an unauthorised bank-detail change redirects a payment. Record the relevant cause and consequence in the risk description when they affect the control response.

Describe an observable control

For the fictional example, a verifier contacts the supplier through a previously verified contact source before new bank details become active. The request records the contact source, response and verifier. A separate authorised approver reviews that evidence, and affected payments remain on hold until verification and approval are complete.

These are three related control activities. Keeping them in separate rows makes ownership, timing and dependencies easier to inspect. A callback to a telephone number supplied in the change request would not provide the same independent check.

Link the description to evidence and a test

Expected evidence might include the change request, the previously verified contact source, the callback record, maker and approver identities, activation timestamps, and payment-hold release records. A tick or signature alone may not explain what was checked.

A test procedure should state what the reviewer will compare and why. First define the period and reconcile the bank-change population to relevant system logs. Then justify the selection of items. For each selected change, inspect whether verification used an independently sourced contact and occurred before activation. Inspect maker/checker separation, authorisation and any override route.

The workbook deliberately does not prescribe a universal sample size. Population characteristics, risk, available evidence, reliance and the engagement approach affect selection. Document exclusions and limitations so another reviewer can follow the conclusion.

Use the workbook without overstating its results

The RCM sheet is the editable working area. Amber cells hold user inputs; pale green cells contain formulas. The Worked example sheet explains three fictional controls. The Guide explains the fields and their limits.

The summary counts recorded controls, exceptions and items marked Not tested. The Core field check only identifies missing descriptive fields. “Core fields populated” does not mean the control is well designed or operated effectively.

Start every new test at Not tested. Record the work actually performed, evidence references, exceptions, and the scope of any conclusion. “No exceptions in tested items” is narrower than saying a whole process is effective.

Try one row

Write a control for a supplier-bank-change override. Identify who can override, what independent approval is required, when an affected payment can be released, and what evidence remains. Ask a colleague to trace the proposed test back to the risk. State one uncertainty that the row cannot resolve.

The template is a starting point for professional judgment. Tailor it to the entity, process, system access, applicable requirements and purpose of the assessment.

Inside Assurance connects professional concepts with the business events behind them.

Beyond the numbers. Inside the business.