Most audit teams already have a Risk Control Matrix. The problem is not usually building one. The problem is that the matrix stops functioning as a working tool somewhere between the walkthrough and the workpapers. Rows get copied forward from last year. Controls get described so vaguely that nobody can design a clear test procedure from them. Risks without a mapped control may be overlooked rather than evaluated as potential control gaps.
In this article, I will explain what a Risk Control Matrix contains, why auditors rely on it, how to build one step by step, and the mistakes that can make control testing harder than it needs to be.
What Is a Risk Control Matrix?
The RCM is used to document the auditor’s understanding of the risks and controls within the audit. It connects risks, controls, and the procedures used to evaluate those controls. It also links the evidence to the conclusions reached by the auditor.
A risk control matrix (RCM) is a structured method to show the relationship between risks and controls. Depending on the engagement and methodology, an RCM may also document the control-testing procedures, evidence, results, control type, frequency, and control owner.
The Institute of Internal Auditors (IIA) explains that a risk and control matrix may show how risks and controls are connected to the audit team’s testing and, as the engagement progresses, how risks and controls are related to conclusions and recommendations. The IIA also provides examples of risk and control matrices that illustrate the connections between conclusions, risks, and controls.
What Does an RCM Contain?
A functional RCM may include:
Business objective: What the process is intended to achieve.
Risk: The event or condition that could prevent the objective from being achieved.
Risk cause: Why the risk could occur.
Risk impact: The potential consequences if the risk occurs.
Control: The activity intended to prevent, detect, or otherwise address the risk.
Control owner: Who is responsible for performing the control.
Frequency: How often the control operates.
Control type: Whether the control is preventive or detective, and whether it is manual, automated, or relies on a combination of methods.
Testing procedure: How the auditor will evaluate the control.
Evidence: Information or documentation that supports the testing.
Result: The outcome of the testing.
Exception: A deviation or deficiency identified during testing, where applicable.
Workpaper reference: A link or reference to supporting engagement documentation.
Not all elements of the RCM are mandatory. The degree of information provided in the RCM will be dependent upon the nature and scope of the audit being performed. The IIA’s standards also recognize that elements of a Risk Assessment Matrix may be expanded as an audit proceeds.
Why Auditors Use a Risk Control Matrix
An RCM is a key tool utilized by auditors to maximize the efficiency of their work. Traditionally, the RCM has been used to validate compliance by auditors. The RCM, however, allows auditors to logically relate various elements of an audit, such as risks, controls, testing, and evidence.
Connecting risks to controls: The RCM is a single source document that describes the relationship between risks and controls, and therefore, auditors do not need to determine such relationships from a number of documents and workpapers.
Identifying control gaps: If a significant risk has no mapped control, the auditor should evaluate whether another control or risk response addresses the risk and whether a control gap exists. This omission should alert the auditor to review the risk and consider other means to alleviate the risk.
Planning control testing: The RCM helps auditors connect identified controls to the testing approach, including the test objective, relevant period or population, expected evidence, and evaluation criteria. The specific scope and extent of testing should still be determined based on the engagement's objectives, risk assessment, methodology, and auditor judgment.
Supporting review and workpapers: An auditor should build the RCM in such a way that reviewers can determine the relationship between risks and controls and audit workpapers, based on audit tests and conclusions. In addition, a properly designed RCM helps in determining the support and rationale for the auditor's conclusion. The IIA supports the use of Risk and Control matrices by the auditors and emphasizes adequate documentation to support the auditor's conclusion.
How Auditors Build a Risk Control Matrix
Auditors usually construct a risk control matrix in a standard manner, although they may refine the matrix during the course of an engagement. Identifying and understanding risks at this stage helps auditors eliminate vague or ambiguous risks and control and testing shortcomings at later stages of the engagement. The IIA mentions that risk and control matrices are developed during the course of an engagement and are refined as auditors proceed to the testing phase.
1. Define the Audit Objective and Process
Understand the scope of the engagement by determining the process being reviewed and the objective, applicable time period, and the criteria against which the process is evaluated. This provides the context for identifying the risks and controls that belong in the RCM.
After determining the risks for the matrix, auditors may refer to a number of sources. In addition to the prior year’s RCM, which the auditors may also review, relevant sources may include the process documentation, policies, and the views of process owners and other relevant personnel. The IIA notes that reviewing and evaluating control design may include documents such as policies and procedures, as well as other sources.
2. Identify the Risks
Auditors document risks in a manner that explains the possible adverse events and the impact of such events. The description should be clear and specific.
Compare these two descriptions:
Weak: “Access risk”
Stronger: “A terminated employee retains access to the system; therefore, the terminated employee may access and utilize the company's data."
The second statement of risk gives personnel the opportunity to connect that risk to a control and consider the methods that would be appropriate to test that control.
3. Identify the Controls
Controls are actions implemented to manage the risk. Policies may establish standards for the control environment and management’s actions, but a policy alone does not demonstrate that a control has been implemented.
For example:
Policy: Employees should be granted the minimum level of access required for their job duties.
Control: The IT management reviews and removes access of terminated employees within 24 hours.
There are other considerations for control types, such as the nature of the control, e.g., preventive control or detective control. The definitions of various control types are described in the framework of the IIA standards.
4. Map Controls to Risks
The control and risk relationship may not be one-to-one. A control may mitigate more than one risk, and a given risk may require more than one control.
Considering access controls, one risk may be an employee has unauthorized access to a system. Addressing this risk may require multiple controls, including an access review and a reconciliation of transaction counts and/or balances. The objective is to demonstrate that management has designed controls that address a particular risk and to communicate the relationship between the controls and the risk.
5. Assess Control Design
Evaluate whether the control is suitably designed to address the risk if it operates as intended.
Assessing control design does not determine whether the control actually operated. It is possible for a control to be designed in a way to assess risk but to not mitigate that risk. For significant risks, the IIA indicates that assessment of control design would allow the auditor to determine which controls require an evaluation of operating effectiveness.
6. Define the Testing Approach
For each control, determine the objective of the testing to be performed, the population or time period to be included in the testing, the type of evidence to be obtained, and the criteria against which the control will be evaluated.
The approach to testing should be consistent with the nature of the risk and the control. Testing a control may involve reviewing a document or observing a particular process. PCAOB standards also state that the nature and extent of procedures to test a control and the evidence obtained should be consistent with the materiality of the risk and the auditor’s judgment about the control.
Defining the testing approach before fieldwork begins provides a clearer basis for executing and documenting testing.
7. Link Evidence to the Control
While the identification of audit evidence is an important part of planning an engagement, it does not necessarily mean that the evidence is adequate for the planned test. Evidence may be classified as:
Ready to test: This is evidence that supports the control under examination and is relevant to the testing in question.
Needs clarification: While evidence has been identified, information that is essential to understanding the evidence is lacking.
Not testable: This evidence does not provide sufficient support for the planned test and requires clarification or replacement before testing.
While it may be helpful to the auditors to classify evidence as described above, this classification is not a formal framework within the IIA.
8. Document Exceptions and Conclusions
Each important RCM row should support a traceable connection:
Risk → Control → Test → Evidence → Result → Exception → Conclusion
It is important to understand exceptions to the control and the risk it was intended to address. These exceptions, as defined by the IIA’s standards, should be captured and documented as part of the engagement.
Risk Control Matrix Example
Two examples show how an RCM can connect a risk to its related control, testing approach, evidence, and result, one from IT general controls and one from a financial process.
Example: User Access Review
Risk | Control | Test | Evidence | Example result |
Terminated employees retain system access after their termination date | HR termination notifications trigger timely removal of system access, with designated personnel reviewing completion | Select a sample of terminated employees and compare termination dates with access-revocation records | Termination records, access-revocation tickets, system access logs | No exception identified |
Each element in the example provides information to respond to a different question. In this case, what is the risk? What is the control? How will it be tested? What evidence will be used to support the test? and What was the outcome of the test?
The example of terminating user access illustrates that various controls exist for the same risk. Quarterly review of privileged user access may help identify inappropriate privileged access, but it may not address the separate risk of terminated users retaining system access.
Example: Accounts Payable Control
Risk | Control | Test | Evidence | Example result |
An invoice is paid even though the goods or services have not been properly matched to an approved purchase | Accounts payable performs three-way matching of the purchase order, receiving record, and invoice before payment | Select a sample of payments and inspect whether the required documents were matched before payment | Purchase orders, receiving records, invoices, payment records | Exception identified in sample |
The examples show that IT controls represent only one of the many forms of RCMs. Similar structures are applicable to other forms of risks and controls including financial, operational, compliance and other risks.
According to the IIA, Risk and control matrices, audit procedures and their outcomes represent the key elements of an audit working paper. Controls testing, however, requires that the nature and extent of the evidence be assessed based on the risk and controls being tested.
7 Common Risk Control Matrix Mistakes
These are common RCM failure patterns because they can save time in the short term while reducing the matrix's usefulness for testing and review over time.
1. Starting with last year's RCM: Using the previous year’s RCM without reassessing the current environment can cause changes in risks, controls, and processes to be overlooked.
How to avoid it: Thoroughly understand the risk management process by doing a walkthrough. Use the previous year’s RCM only as a reference.
2. Writing risks too broadly: Using the risk like “compliance risk” does not help in explaining what could go wrong or what would need to be tested.
How to avoid it: Write risk events in a way that identifies what could go wrong and helps in determining the control and how it will be evaluated.
3. Treating policies as controls: A policy statement describes what the organization expects to happen. It may support the control environment, but it does not by itself demonstrate that a specific control activity was performed.
How to avoid it: Confirm that each control describes a specific activity, including who performs it, what they do, when or how often it occurs, and what evidence the activity produces.
4. Writing controls that cannot be tested: A description like “management monitors performance periodically” doesn't identify what is being monitored, what risk the activity addresses, or what evidence should result.
How to avoid it: Apply the Testability Test, and ask who performs the control, what exactly it checks, when it happens, how it happens, and what evidence should exist. If important details are missing, refine the control description before testing.
5. Marking everything as a key control: When the control description states that a particular control is a key control, it gives little added value to the control evaluation process.
How to avoid it: Your firm should create and implement a consistent methodology to evaluate controls. Key controls should be identified using a consistent methodology and reserved for controls that address significant or relevant risks.
6. Hiding risks with no mapped control: Removing risks from the risk assessment because no controls have been identified creates a false sense of control.
How to avoid it: To determine whether a control is available to mitigate the risk, the assessment should be expanded to include whether other information is needed or if there is a control gap.
7. Evidence and Workpaper Disconnect: Test results and conclusions are sometimes documented without referencing the control being evaluated. This creates a situation where the reviewers are unable to identify the rationale for the conclusion drawn.
How to avoid it: Clear and complete links should be established between all components of the review, including the workpaper, tests, evidence, and test results.
How to Make an RCM Ready for Control Testing
When an audit engagement moves into the control testing phase, the essential RCM rows are expected to contain information to define the risk, the related controls, the nature and extent of the testing, the evidence to support the testing, and the conclusions reached. The following five questions, based on how the IIA has described the use of risk and control matrices, provide a framework to address each of the above.
The 5-Question RCM Test
What can go wrong? (Risk event)
What control addresses it? (Control activity)
How will we test the control? (Test procedure)
What evidence should support the test? (Evidence requirement)
What happens if the test identifies an exception? (Exception linkage)
An essential row of the RCM that is unable to respond to the above questions should be considered insufficient for control testing and may require further amendment to be testing ready.
How AI Can Support RCM-Based Control Testing
Control testing consumes a significant share of auditor time through repetitive evidence review, sample testing, and documentation. AI-powered tools like Roz are built to accelerate that specific layer of work while keeping auditors responsible for the final conclusion.
Mapping risks and controls: AI can help organize risks and controls into a structured matrix, reducing time spent on manual setup.
Identifying missing or weak mappings: AI can surface risks without a mapped control or controls described too vaguely to test.
First-pass control testing: Roz analyzes evidence and sample sets against defined or suggested attribute checks and returns a result, PASS, FAIL, N/A, or INFO, along with the reasoning behind it.
Evidence traceability: Each AI-generated result can be traced back to the specific passage in the underlying evidence that supports it, so auditors can verify the result rather than accepting it at face value.
Workpaper preparation: Once a control test is complete, the result, supporting evidence, and annotations can be exported into a formatted workpaper. This fits into the broader audit workflow, where risk and control documentation, testing, review, and workpaper preparation need to remain connected.
The auditor remains in control of the final assessment throughout this process. AI supports the repetitive first pass; auditors verify results, rerun tests when needed, and override results when professional judgment requires it.
Conclusion
A strong RCM isn't measured by how complete it looks. It's measured by whether each important row can be traced from risk to control to test to evidence to conclusion. That traceability is what makes the RCM a working audit tool rather than a static document filed away after engagement kickoff.
Roz supports that connection by turning the testing layer represented in the RCM into a structured, evidence-based control-testing workflow, with auditors reviewing and validating AI-assisted results along the way.
Frequently Asked Questions
What is an example of a risk control matrix?
A simple RCM maps a risk such as “unauthorized system access” to a related control, then documents the test procedure, evidence, and result. See the User Access Review and Accounts Payable examples above.
What is the difference between an RCM and a risk assessment matrix?
A risk assessment matrix ranks risks, often by likelihood and impact. An RCM maps those risks to the controls intended to address them and can also include testing and evidence.
What is the difference between RCM and RACM?
RCM and RACM can refer to similar risk-and-control documents, but terminology varies by organization and methodology. There is no universal technical distinction between the two terms.
Should every risk have a corresponding control?
Not necessarily. A significant risk without a mapped control may indicate a control gap, but it should first be evaluated to determine whether another control or risk response addresses it. Keeping it visible in the RCM helps prevent gaps from being overlooked.
