Risk and control matrix (RCM): how to build one that works

A risk and control matrix (RCM) is the working document that links what could go wrong in a process to the controls that stop it, the people who own those controls and the evidence that shows they work. Done well, it is the backbone of management’s control self-assessment, the internal audit plan and any board statement about control effectiveness. Done badly, it is a spreadsheet of vague control descriptions that nobody tests and nobody updates.

This guide explains how to build an RCM that stands up to scrutiny: how to map processes and risks, how to write control descriptions that can be tested, how to separate key controls from secondary ones, and how to test design and operating effectiveness. It also explains why the timing matters. For UK listed companies, the revised Provision 29 of the UK Corporate Governance Code takes effect for financial years beginning on or after 1 January 2026, and a well-built RCM is one of the most practical ways to give a board the evidence it will need.

What a risk and control matrix is

An RCM is a structured register, usually built process by process, that records each significant risk, the control or controls that address it, and the attributes of each control: its type, frequency, owner and evidence. It turns a general statement that “we have controls” into a specific, testable inventory.

Most organisations anchor their RCM in the COSO Internal Control – Integrated Framework (2013). COSO defines internal control as “a process, effected by an entity’s board of directors, management, and other personnel, designed to provide reasonable assurance regarding the achievement of objectives relating to operations, reporting, and compliance”.¹ The framework sets out five components (control environment, risk assessment, control activities, information and communication, and monitoring activities) supported by seventeen principles.¹ Under COSO, an effective system of internal control requires each component and relevant principle to be present and functioning, and the five components to operate together in an integrated manner.¹

An RCM lives mainly in the risk assessment and control activities components, but a mature one also records entity-level controls (such as a code of conduct, board oversight and authority limits) and IT general controls, because process controls depend on them.

Why the RCM matters for Provision 29

The UK Corporate Governance Code 2024 applies to companies listed in the commercial companies category or the closed-ended investment funds category. The Code as a whole applies to accounting periods beginning on or after 1 January 2025, but Provision 29 applies only from accounting periods beginning on or after 1 January 2026; until then, the 2018 version of Provision 29 continues to apply.² The commercial companies category was created when the FCA’s UK Listing Rules replaced the premium and standard listing segments on 29 July 2024.³

The revised Provision asks the board to monitor the risk management and internal control framework, review its effectiveness at least annually, and cover “all material controls, including financial, operational, reporting and compliance controls”. The annual report should then include a declaration of effectiveness of the material controls as at the balance sheet date, and a description of any material controls that have not operated effectively.² The FRC’s guidance does not prescribe a framework or define a material control, and says it is not the FRC’s role to dictate what a material control is for a company.⁴ That leaves boards needing a defensible, documented inventory of controls with evidence of testing. In practice, that is an RCM.

Mapping processes and risks

Start with scope, not with controls. A common weakness is to begin by listing the controls that already exist and then writing risks to fit them. That produces an RCM that confirms the current design rather than challenging it.

1. Define the process universe. List the end-to-end processes in scope (for example purchase-to-pay, order-to-cash, record-to-report, payroll, treasury, inventory and fixed assets) and break each into sub-processes. Align the list with your chart of accounts and your principal risks, so that nothing material sits outside it.
2. State the objectives. COSO’s sixth principle is that the organisation specifies objectives with enough clarity to identify and assess the risks to them.¹ For a financial process, objectives are usually framed as completeness, accuracy, validity, cut-off and authorisation. For operational and compliance processes, write them in business terms.
3. Write risks as “what could go wrong”. A good risk statement names the event and its consequence: “Payments are made to fictitious suppliers because supplier bank details can be changed without independent verification.” A poor one is a heading: “Supplier risk”.
4. Include fraud and technology risks deliberately. COSO requires the organisation to consider the potential for fraud when assessing risks, and to select and develop general control activities over technology.¹ Fraud scenarios, including management override, rarely surface unless someone asks the question directly. Our fraud risk assessment template sets out a structured way to do that.
5. Rate inherent risk. Use the same impact and likelihood scales as your enterprise risk register, so that the RCM and the risk register tell the same story to the board.

Walk through each process with the people who perform it. The walkthrough is where you find the spreadsheet outside the system and the approval that happens by email after the payment run.

Describing controls well

COSO describes control activities as the actions, established through policies and procedures, that help ensure management’s directives to mitigate risks are carried out. They may be preventive or detective, may combine manual and automated activities, and include authorisations and approvals, verifications, reconciliations and business performance reviews. Segregation of duties is typically built into them, and where it is not practical, management selects alternative controls.¹

A control description should allow someone who has never seen the process to test it. In practice that means answering six questions:

• Who performs the control (a role, not a named individual)?
• What exactly do they do, and against what source or threshold?
• When and how often (each transaction, daily, monthly, quarterly)?
• How are exceptions identified, investigated and resolved?
• What evidence is retained, and where?
• Which information does the control rely on, and how do we know that information is complete and accurate?

Compare “Management reviews supplier changes” with “For every new supplier or change to supplier bank details, a member of the finance controls team who did not raise the request verifies the details by calling the supplier on a number obtained independently, then approves the change in the ERP system; the system prevents the requester from approving their own change.” The second can be tested. The first cannot.

Classifying control type

Dimension	Options	Why it matters
Timing	Preventive (stops the error or fraud occurring) or detective (identifies it after the event)	A risk covered only by detective controls may be acceptable, but the board should know that is the design.
Method	Manual, IT-dependent manual (a person acting on a system report) or automated (configured in the system)	Automated controls depend on IT general controls over access and change management; IT-dependent manual controls depend on the report being complete and accurate.
Level	Entity-level, process-level or IT general control	Process controls rarely compensate for a weak control environment or poor system access security.
Frequency	Per transaction, daily, weekly, monthly, quarterly, annually	Drives the testing approach and sample sizes.

Sample risk and control matrix layout

There is no mandated format. The columns below are a practical minimum; many organisations add assertion mapping, inherent and residual risk ratings, linked policies and test results.

• Ref: a unique control reference that never changes, so test results and actions can be traced across years.
• Risk: what could go wrong, written as an event and consequence.
• Control activity: the who, what, when and how described above.
• Type: preventive or detective; manual, IT-dependent manual or automated.
• Frequency and owner: how often the control operates and the role accountable for it.
• Key control: whether the control is relied on to address the risk (see below).
• Evidence: what a tester would inspect.

Illustrative example only: generic purchase-to-pay rows to show the level of detail expected, not a recommended control set for any particular organisation.

Ref	Risk	Control activity	Type	Frequency and owner	Key?	Evidence
P2P-01	Payments are made to fictitious or fraudulent suppliers because supplier records or bank details are created or changed without independent verification.	Each new supplier and bank detail change is verified by call-back to an independently sourced number and approved in the ERP by a finance controls team member who did not raise the request. The system blocks self-approval.	Preventive; IT-dependent manual	Each change; finance controls manager	Yes	ERP approval log; call-back record
P2P-02	Invoices are paid for goods or services not received, or at prices that differ from the purchase order.	The ERP matches each invoice to the approved purchase order and goods receipt within a configured tolerance. Unmatched invoices are blocked from payment until resolved and released by the accounts payable supervisor.	Preventive; automated	Each invoice; accounts payable manager (configuration owned by ERP system owner)	Yes	Configuration report; blocked-invoice report and release log
P2P-03	Errors or unrecorded liabilities in the purchase ledger are not identified.	Statements from suppliers in a defined population are reconciled to the purchase ledger monthly; differences are investigated and cleared, and the financial controller reviews and signs off the reconciliations.	Detective; manual	Monthly; financial controller	No (secondary)	Signed reconciliations with supporting workings

Key versus secondary controls

Not every control in an RCM deserves the same attention. A key control is one that, on its own or with a small number of others, is relied on to reduce a significant risk to an acceptable level, so that its failure would leave the risk materially unaddressed. Secondary (non-key) controls still matter, but they provide supporting or overlapping coverage. “Key control” is practitioner language rather than a term defined by COSO, so write down your organisation’s criteria and apply them consistently.

Useful questions when selecting key controls:

• Does this control address a risk rated high, or a principal risk?
• Is it preventive and close to the source of the risk, or does it catch problems late?
• Does it cover the whole population, or only part of it?
• If it failed, would another control detect the problem in time?
• Is it automated or dependent on individual judgement?

Key controls are not the same as Provision 29 “material controls”, although the two will overlap. The FRC’s guidance says material controls are company-specific, and that when deciding which controls are material the board considers how a deficiency could affect the interests of the company, shareholders and other stakeholders. It suggests they could include controls over principal risks, over price-sensitive external reporting, over fraud (including override of controls), and over information and technology risks such as cyber security and data protection.⁴ A good RCM lets you flag which key controls the board has designated as material, so the declaration rests on a clear, traceable subset.

Testing design and operating effectiveness

Testing has two distinct stages, and the order matters. The UK auditing standard on responses to assessed risks, ISA (UK) 330, makes the same distinction: testing the operating effectiveness of controls is different from evaluating their design and implementation, although the same types of procedure are used and both can be performed together.⁵ Internal auditors and management testers can use the same logic.

	Test of design	Test of operating effectiveness
Question	If performed as described by a competent person, would this control prevent or detect the risk?	Did the control actually operate as designed throughout the period (or at the date) being assessed?
Typical procedure	Walkthrough of one instance end to end; inspection of system configuration; review of the control description against the risk	Inspection of evidence for a sample of occurrences; reperformance; for automated controls, testing the configuration and relying on IT general controls
Common finding	Control does not address the risk, relies on an unreliable report, or lacks a defined threshold	Control was skipped, performed late, performed by the wrong person, or left no evidence

There is no value in testing operating effectiveness for a control that is poorly designed. Fix the design first, then test.

For operating effectiveness, ISA (UK) 330 asks auditors to obtain evidence about how controls were applied at relevant times, the consistency with which they were applied, and by whom or by what means; it states that inquiry alone is not sufficient.⁵ In practice, set sample sizes in a documented methodology that scales with control frequency and risk, select samples from a population you have confirmed is complete, and define in advance what counts as an exception.

Record deficiencies against the control reference, rate their severity, and report them. COSO’s seventeenth principle requires deficiencies to be evaluated and communicated in a timely manner to those responsible for corrective action, including senior management and the board as appropriate.¹ The FRC’s guidance adds that, when establishing whether a control is operating effectively, the board should also consider its design and implementation.⁴ Because the Provision 29 declaration is made as at the balance sheet date, testing needs to be timed so that controls are shown to be working at, or close to, that date, with any earlier deficiencies shown to be remediated and retested.

Keeping the RCM current

An RCM decays quickly. Systems are upgraded, teams are restructured and new products launch, and each change can make a control description wrong overnight. COSO’s ninth principle requires the organisation to identify and assess changes that could significantly affect the system of internal control,¹ and the FRC’s guidance makes the same point about risk registers: they need regular review and updating to reflect change.⁴

• Assign ownership. Each process owner should own their section of the RCM and confirm it at least annually. Internal audit can challenge it, but should not own it.
• Build change triggers. Make RCM review part of the change process for system implementations, reorganisations, acquisitions, outsourcing and new products.
• Keep it aligned with procedures. If the policy or procedure says one thing and the RCM another, testers will find exceptions that are really documentation errors. Controls should be written into the procedures people follow.
• Control versions. Keep a change log showing what changed, why and who approved it.
• Reconcile to the risk register. A principal risk with no mapped controls is a gap; controls mapped to no risk are usually redundant effort.

For a new internal audit function, the RCM often drives the first risk-based plan; see our guide on how to set up an internal audit function.

How we can help

We build and refresh risk and control matrices, test the design and operating effectiveness of key controls, and help boards prepare for Provision 29 through our internal controls reviews. Where control descriptions and day-to-day practice have drifted apart, our policies, procedures and SOPs service brings them back into line. We work with corporates and listed companies of all sizes. To talk through where your RCM stands, book a free 20-minute call.

Frequently asked questions

What is the difference between a risk register and a risk and control matrix?

A risk register records the organisation's risks, their ratings and owners, usually at a strategic or operational level. A risk and control matrix goes further down into processes, linking each risk to the specific controls that address it, with the control type, frequency, owner and evidence. The two should reconcile, so that every principal risk in the register maps to controls in the RCM.

Is a risk and control matrix required for Provision 29?

No. Provision 29 of the UK Corporate Governance Code 2024 does not require any particular document, and the FRC's guidance deliberately does not prescribe a framework or define a material control. In practice, however, boards need a documented inventory of material controls and evidence that they have been tested, and an RCM is the most common way to provide it.

How often should a risk and control matrix be updated?

Process owners should confirm their section at least annually, and the RCM should also be updated whenever a significant change occurs, such as a system implementation, restructuring, acquisition or new outsourcing arrangement. Building RCM review into the change process is more reliable than relying on an annual refresh alone.

References

1. Committee of Sponsoring Organizations of the Treadway Commission (COSO), May 2013. Internal Control – Integrated Framework: Executive Summary
2. Financial Reporting Council, 22 January 2024. UK Corporate Governance Code 2024
3. Financial Conduct Authority, July 2024. PS24/6: Primary Markets Effectiveness Review – Feedback to CP23/31 and final UK Listing Rules
4. Financial Reporting Council, 29 January 2024 (as updated to 5 November 2025). Corporate Governance Code Guidance
5. Financial Reporting Council, 25 September 2025. International Standard on Auditing (UK) 330 (Revised July 2017): The Auditor's Responses to Assessed Risks (updated September 2025)