How to Build a Risk Control Matrix (RCM) for Finance and Operations

Table of Content

1. Introduction to How to Build a Risk Control Matrix

One of the most helpful items in the toolkit of a governance, risk, and compliance professional is a Risk Control Matrix (RCM). In its simplest form, it is a structured document that maps the risks within a business process to the specific controls created to manage those risks, showing, for each risk, which control is in place, who owns it, how it works, and whether it is working effectively. An RCM provides management, auditors and boards with a clear, evidence-based view of the control landscape across the most significant financial and operational processes.

Although valuable, the Risk Control Matrix (RCM) is often encountered by junior or mid-level professionals who may lack a clear understanding of how it is constructed and used. It may be presented as a spreadsheet with columns for risks, controls, and ratings. Still, without any context regarding the process that produced it or the methodology that underlies the ratings, it can feel like an administrative artefact rather than a management tool. The secret to turning it into a compliance document rather than a truly useful risk management tool is knowing how to construct it in its bare bones, from the initial Process Risk Analysis through to Control Effectiveness Testing.

This paper is intended for finance professionals, internal auditors, and junior advisors who wish to learn how to create and maintain a functioning Risk Control Matrix (RCM) for finance and operational processes. It discusses the methodology, the main items in each column, the usual errors that undermine the tool’s utility, and the practical lessons learned by organisations that have constructed RCMs that have stood the test of time, and those that have not.

2. What an Risk Control Matrix Is and Why It Matters

The structure of a Risk Control Matrix (RCM)

A properly formulated Risk Control Matrix (RCM) maps the relationship between five elements in respect to each in-scope process: the risk (what could go wrong), the control objective (what the control is designed to achieve), the specific control (what is actually done), the control attributes (who does it, how often, whether it is preventive or detective), and the control effectiveness assessment (whether it is working). This format enables a reader to trace the rationale behind risk-to-control evidence of effectiveness without having to rebuild the analysis from scratch.

Internal Control Design. The initial approach is always to ask what might go wrong in this process, not what controls are already in place.
Control Mapping Process: 1 This process links each identified risk with at least one control. 1 Where a risk has no control mapped to it, the gap is immediately visible – this is one of the primary values of the RCM as a management tool.
A good RCM is a living document: it is updated as processes change, controls are added or removed, and tests are performed to identify weaknesses that require remediation.

How it is used by auditors, management, and boards

The Risk Control Matrix (RCM) is a key input used by external auditors in scoping their work: should a client have strong preventive and detective controls over the financial reporting process, the auditor may consider reducing the amount of substantive testing in those areas. It is used by internal auditors to plan their engagements and to monitor remediation of control deficiencies. It is used by management to show the board that material risks are under control. And boards employ it to carry on their governance oversight mandate without necessarily having to know the operational specifics of each process.

3. Building the RCM: Risk Identification and Control Mapping

Starting with Process Risk Analysis

The initial and most significant stage in developing a Risk Control Matrix (RCM) is the Process Risk Analysis. It involves a systematic walk-through of every in-scope process – usually achieved by interviewing process owners and examining process documentation – to identify what could go wrong at each step. The Risk Identification Framework utilized at this point should address four types of risk to each process: financial reporting risk (could this process generate a material misstatement?), fraud risk (could this process be misused to benefit an individual?), operational risk (could this process fail in a way that disrupts the business?), and compliance risk (could this process result in a regulatory violation?).

Walk through the process step by step before detecting risks: the only condition for detecting what could go wrong is understanding what actually happens.
Finance Risk Controls: the first processes to be in-scope for any finance RCM are those with a direct impact on financial statement line items: revenue recognition, accounts payable, payroll, and financial close.
The Operational Risk Mapping goes beyond financial processes and, in its analysis, covers operational workflows that influence the quality, continuity, and compliance of the products and services offered by the business.

From risks to controls: the Control Mapping Process

After identifying risks, the Control Mapping Process links each risk to the control or controls to be implemented to manage it. This step demands clarity about what the control is, not some general policy reference, but a specific action observable at the system level: a payment approval step, a reconciliation, a system-level access control, or an independent review. What makes the RCM useful in the testing process is the quality of the control description: a control described as the manager reviews is not testable; a control described as the manager reviews the monthly bank reconciliation and signs and dates the completed reconciliation document within five business days of the month end.

RCM Column	What It Contains	How It Is Used	Quality Standard
Process	The specific business process being analysed (e.g., Procure-to-Pay, Revenue Recognition, Payroll, Financial Close)	Scopes the analysis; allows the RCM to be organised by process for management and audit use	Process should be defined at a level where it can be walked through end-to-end; not so broad that it cannot be usefully mapped
Risk	The specific thing that could go wrong: misstatement, fraud, error, regulatory breach, operational failure	An auditor or reviewer assesses whether all material risks for the process have been identified	Risk should be specific and directional: “Payments made to fraudulent suppliers” is testable; “payment risk” is not
Control Objective	What the control is designed to achieve: prevent, detect, or correct the identified risk	Links the control to its purpose; allows assessment of whether the control is logically capable of addressing the risk	Should match the risk precisely: a detective control does not prevent fraud; it detects it after the fact
Control Description	The specific, observable action that constitutes the control: who does what, how often, and how the completion is evidenced	Provides the basis for Control Effectiveness Testing: can the control be tested as described?	Must be specific enough to test: “Finance manager approves all invoices above $5,000 before payment processing, evidenced by counter-signature on the invoice”
Control Type	Preventive, detective, or corrective; manual or automated; key or non-key	Auditors weigh key controls more heavily in their scoping; automated controls are generally more reliable than manual ones	All three types should be represented across the RCM; reliance on preventive controls only creates blind spots
Control Owner	The specific individual or role responsible for operating the control	Creates accountability; allows the reviewer to identify who to test and who to hold responsible for control failures	Should be a specific named role, not “finance team”; allows direct engagement during testing
Control Effectiveness Testing Result	The outcome of testing whether the control is operating as described: effective, partially effective, or ineffective	Basis for audit reliance decisions; source of management remediation actions	Testing should be documented, and evidence should be referenced; results should reference the specific evidence reviewed.

4. Five Steps to Build and Maintain a Functional RCM

The Risk Assessment Matrix upon which an effective RCM is founded is developed by means of a rigorous five-step procedure. Any step not followed or bypassed results in an internally inconsistent, untestable, or soon outdated RCM, which is not a risk management tool, but a documentation exercise.

Step	What It Involves	Output	Common Failure Mode
1. Define the scope and process inventory	Identify which processes will be included in the RCM; for a finance RCM, the standard scope covers: procure-to-pay, order-to-cash, payroll, treasury, financial reporting and close, and fixed assets	Process inventory with a brief description of each process; confirmed scope endorsed by management	Scope set too broadly (the entire organisation), making the analysis too shallow; or too narrowly (only financial reporting), missing material operational risks
2. Conduct Process Risk Analysis for each process	Walk each process end-to-end; interview process owners; review process documentation; apply the Risk Identification Framework across financial, fraud, operational, and compliance risk categories	Risk register for each process with specific, directional risk statements	Risks identified by reviewing prior-year audit findings rather than by walking through the current process; risks stated too broadly to be useful
3. Complete the Control Mapping Process	For each identified risk, identify the specific control or controls that address it; document the control description to a testable level of specificity; confirm control ownership	Populated Risk Control Matrix (RCM) with risk-to-control mapping; identified gaps where risks have no control	Control descriptions written at a policy level rather than an operational level; controls mapped generically to all risks rather than specifically to individual risks
4. Assess and document Internal Control Design adequacy	For each control, assess whether the design is logically capable of addressing the risk; identify design gaps (controls that exist but cannot detect or prevent the stated risk); distinguish between design adequacy and operating effectiveness	Control design adequacy rating for each control; design gaps identified for remediation	Design adequacy and operating effectiveness are conflated; a control that is well-designed but not operating is rated as effective; a control that operates consistently but is designed incorrectly is rated as adequate
5. Conduct Control Effectiveness Testing and maintain currency	Test a sample of key controls to verify they are operating as described; document testing evidence; update the RCM when processes change, or control deficiencies are identified; establish a review cycle	Testing workpapers with evidence; updated Compliance Control Matrix reflecting current control environment; remediation tracking for deficiencies	Testing conducted only at audit time rather than on a continuous or cyclical basis; RCM not updated when processes change; deficiencies identified but not tracked through to remediation

Step 3 – finalising the Control Mapping Process to a testable level of specificity – is the step that most often results in unusable RCMs when it is not carried out so carefully. The conventional test of the quality of a control description is: Could I test the quality of this control description based only on this description? If the answer is no due to the description being too vague, the frequency not being stated, or the evidence not being identified, the control description will need to be rewritten before the RCM is finalised. An untestable risk control description, presented as a Risk Control Matrix (RCM), cannot provide either audit reliance or management assurance, or a meaningful gap analysis.

5. Process, Real Cases, and Lessons for Practitioners

The RCM build and maintenance workflow

The process of developing a Risk Control Matrix (RCM) from scratch and maintaining it as a living document follows a structured four-phase cycle. The workflow below represents the sequence used by experienced practitioners to sequence this work to a finance function or the scope of an operational process.

Phase 1	Phase 2	Phase 3	Phase 4
Scope & Process Walkthrough	Control Mapping & Design Assessment	Control Effectiveness Testing	Reporting & Ongoing Maintenance
Define scope; conduct process walkthroughs and owner interviews; apply Risk Identification Framework to each process; document risks with specific, directional risk statements for each process step	Complete Control Mapping Process: identify specific controls for each risk; describe controls to testable standards; assess Internal Control Design adequacy; identify design gaps requiring remediation	Test key controls against documented descriptions; gather and retain testing evidence; rate each control as effective, partially effective, or ineffective; identify operating deficiencies for remediation	Report findings to management and relevant governance forum; track remediation of design and operating deficiencies; update Compliance Control Matrix when processes change; conduct annual refresh cycle

Case 1: The RCM that could not be tested

A retail business undertook an internal control documentation project, resulting in a comprehensive-looking Risk Control Matrix (RCM) of 12 processes. When the external auditor tried using the RCM as a basis to scope their audit, they found that the descriptions of the controls were written on a policy basis, not an operational basis: “Management reviews financial transactions appeared as a control against many risks without describing how, how often, what evidence was produced, or how the review was evidenced. No controls could be tested as follows. The auditor must have conducted their own process walkthroughs out of thin air, and the RCM did not provide any efficiency advantage to the audit. The company had taken a long time to prepare a Compliance Control Matrix for use in the compliance reporting process, but not in the management’s audit and reliance process. The lesson: specificity in the description of control is not a nice-to-have; it is the condition by which the tool can be useful.

Case 2: Control Effectiveness Testing that changed the risk picture

A financial services company had been running a well-documented Risk Control Matrix (RCM) for three years. All key controls were found to be effective in the RCM during the previous year’s testing. A new internal audit group, when they took office, carried out a fresh round of Control Effectiveness Testing across the procure-to-pay process, and they found that two of the key controls were inconsistently being applied over the last 18 months: the dual-authorisation requirement on changes to supplier bank accounts, and the monthly accounts payable reconciliation. Neither deficiency was found in previous testing cycles, since testing had been restricted to evaluating whether the control steps were recorded and whether there was evidence in the system, without itself verifying that the evidence was evidence of actual independent action. The case strengthened a principle practised by experienced practitioners at all times: Control Effectiveness Testing must not only verify the existence of documentation, but also its substance.

6. Conclusion

One of the most useful instruments in the risk and control practitioner’s arsenal is a Risk Control Matrix (RCM) constructed to a testable standard, filled in through the genuine Process Risk Analysis and Control Mapping Process discipline, and maintained as a living document through regular Control Effectiveness Testing. It is directly proportional to the quality of the inputs: definite risk statements, testable control statements, and sincere effectiveness statements based on actual evidence.

Note: Any control description undergoes a quality test in an RCM, which is: Could this be tested based on this description alone? If the answer is no, the description must be rewritten before the Risk Assessment Matrix is finalised.
Control Effectiveness Testing: must verify the substance of the control, not merely the existence of documentation; reviewing system-generated evidence without independently confirming the underlying action occurred is a testing gap that has consistently failed to detect the most consequential control weaknesses.
To professionals developing expertise in this space: The best learning comes from constructing RCMs, working with experienced practitioners on live processes, asking why each risk-to-control mapping was made, and understanding the Internal Control Design decisions that shaped the form of each control.