Skip to main content
Governance Authority
Category: Internal Controls

Risk and Control Matrix

Also known as: RACM, Risk Control Matrix, RCM, Risk and Control Matrix (RACM)
Simply put

A Risk and Control Matrix is a structured document that lists an organization's risks alongside the controls put in place to address them. It helps an organization see, in one place, which risks it faces within its processes or operations and how each risk is being managed. It is typically used as a practical tool for identifying, assessing, and organizing risks and their corresponding controls.

Formal definition

A Risk and Control Matrix (RACM), also commonly called a Risk Control Matrix (RCM), is a structured tool that maps identified risks to the controls intended to mitigate them, functioning as a detailed inventory of risks and their corresponding controls. It generally supports the identification, assessment, and management of risks within specific processes or operations, and can be used to evaluate potential risks against the control measures in place. The specific structure, level of detail, and maturity of a RACM vary by organization, framework, and intended use; the tool itself does not determine ownership of the underlying risks or controls, which typically rests with management, while assurance functions may use it to test control design and operating effectiveness. This entry describes the concept generally and is educational, not audit or compliance advice.

Why it matters

A Risk and Control Matrix gives an organization a consolidated view of the risks embedded in its processes and the controls intended to address them. Without such a tool, risks and controls are often documented in scattered spreadsheets, process narratives, or individual memory, making it difficult to see whether a given risk is actually covered, whether controls overlap or leave gaps, and who is responsible for each. By mapping risks to controls in one structured place, a RACM supports more disciplined conversations about coverage, redundancy, and priority.

The matrix also serves as a shared reference point across the functions that manage and assure risk. Management, which typically owns the underlying risks and controls, can use it to organize and monitor its own control environment, while assurance functions such as internal audit may use the same document as a starting point to test whether controls are well designed and operating effectively. This distinction matters: the matrix itself does not shift accountability, and its existence does not by itself confirm that controls work. It is a documentation and analysis tool, not a substitute for the judgment and testing required to reach a conclusion about control effectiveness.

The usefulness of a RACM depends heavily on how well it is built and maintained. A matrix that is out of date, overly generic, or disconnected from actual process activity can create false comfort. Its structure, level of detail, and maturity vary considerably by organization, framework, and purpose, so a RACM is best understood as a flexible instrument whose value reflects the rigor applied to it rather than a standardized artifact with a fixed meaning.

Who it's relevant to

Management and process owners
Management typically owns the risks and controls documented in a RACM and uses it to organize, monitor, and communicate how risks within specific processes are being addressed. Process owners often rely on it to confirm that each material risk has an assigned control and a clear owner, and to identify where coverage may be missing or duplicated.
Internal audit and assurance functions
Assurance functions may use an existing RACM as a starting point for planning and executing testing, examining whether controls are designed appropriately and operating effectively. The matrix helps focus assurance activity, but reaching a conclusion about control effectiveness generally requires independent testing and judgment rather than reliance on the document alone.
Risk and compliance officers
Chief risk and compliance officers may draw on a RACM to understand the organization's risk profile at a process level and to see how controls map to identified risks. It can support broader risk management and monitoring activities, though it is one input among several and its usefulness depends on how current and detailed it is kept.
Boards and audit or risk committees
While boards and their committees generally exercise oversight rather than build or maintain the matrix themselves, a well-constructed RACM can inform the information they receive about how management is addressing key risks. Directors typically use such tools indirectly, through management and assurance reporting, to test whether the control environment is being managed with appropriate rigor.

Inside RACM

Process or objective reference
Identifies the business process, sub-process, or control objective to which the mapped risks and controls relate, providing the organizing structure for the matrix.
Risk description
A statement of each risk that could threaten achievement of the relevant objective, typically expressed in terms of the event and its potential consequence rather than as a control gap.
Inherent risk assessment
An evaluation of risk before considering the effect of controls, generally rated along likelihood and impact dimensions; some matrices omit this and focus on residual risk depending on the methodology used.
Control description
A description of each control intended to address the associated risk, ideally noting whether it is preventive or detective, manual or automated, and its frequency of operation.
Control ownership
Identification of the individual or function responsible for performing the control, which typically sits with management in the first line rather than with assurance functions.
Assertion or objective linkage
In financial reporting contexts, a mapping of controls to relevant financial statement assertions or control objectives to demonstrate coverage.
Design and operating effectiveness columns
Fields to record conclusions on whether a control is appropriately designed and whether it operated effectively over the period, which are distinct evaluations that should not be collapsed into one.
Residual risk assessment
An evaluation of the risk remaining after considering the controls, used to identify where control coverage may be insufficient relative to risk appetite or tolerance.

Common questions

Answers to the questions practitioners most commonly ask about RACM.

Is a risk and control matrix (RACM) the same as a full risk register?
No, though the two are related and often confused. A risk and control matrix typically maps specific risks to the controls that address them, usually within a defined process, cycle, or assertion (for example, a financial reporting or SOX context), with an emphasis on the control-to-risk linkage and attributes such as control type, frequency, and owner. A risk register is generally broader in scope, cataloguing risks across an entity or domain along with information such as inherent and residual risk assessments, risk owners, and treatment plans, and it does not necessarily document the control detail or the mapping in the structured way a RACM does. In practice organizations may draw on both; whether one substitutes for the other depends on the entity's design choices and the purpose at hand. This distinction can vary by framework and organization, so the labels are less important than understanding what each artifact is intended to accomplish.
Does having a completed risk and control matrix mean the controls are actually working?
Not on its own. A risk and control matrix primarily documents control design, how controls are intended to address identified risks. It does not by itself demonstrate operating effectiveness, which is whether those controls actually functioned as intended over a period. Design effectiveness and operating effectiveness are distinct concepts, and a well-populated matrix can coexist with controls that fail in operation. Confirming operating effectiveness generally requires separate testing or other assurance activity, and conclusions about effectiveness are a matter of evidence and professional judgment rather than something the matrix alone establishes. The matrix is a tool to support that work, not a substitute for it.
Who should own and maintain the risk and control matrix?
Ownership generally sits with the function that owns the underlying process and controls, typically management within the first line, sometimes with support or facilitation from a risk or compliance function. Because the matrix describes controls that management designs and operates, keeping it current is usually a management responsibility rather than an assurance function's. Internal audit or other second- or third-line functions may use, review, or challenge the matrix, but having assurance functions maintain it can blur the separation between those who operate controls and those who provide independent assurance. Specific ownership arrangements depend on the entity's operating model and how it has structured its lines of defense.
What attributes are commonly captured for each control in the matrix?
Practices vary by organization and framework, but a matrix often records, for each control, the risk or risk objective it addresses, a description of the control, the control owner, and attributes such as whether the control is preventive or detective, manual or automated, and its frequency of operation. Some matrices also note the relevant process or assertion, the control's classification as key or non-key, and references to supporting evidence or testing. There is no single mandated set of fields; the attributes chosen should reflect the matrix's purpose and the level of detail needed to support assessment or assurance work. Organizations should avoid capturing more detail than they can realistically keep accurate and current.
How often should a risk and control matrix be reviewed or updated?
There is no universal frequency, and the right cadence depends on the volatility of the underlying processes, risks, and control environment. Many organizations review the matrix on a periodic basis and also update it when triggering events occur, for example, a significant process change, a new system, a reorganization, a change in the risk landscape, or a control failure. The aim is generally to keep the matrix reflective of how controls actually operate, since an outdated matrix can give false comfort. The appropriate approach is a matter of the entity's own judgment and any applicable framework or regulatory expectations, rather than a fixed rule.
How does a risk and control matrix relate to control testing and assurance work?
The matrix typically serves as a starting point for planning and scoping testing: it identifies the controls in place, their attributes, and the risks they address, which helps those performing testing determine what to test and how. However, the matrix documents design and intent, so testing is generally needed to gather evidence on whether controls operate effectively. Assurance functions may also challenge the matrix itself, for instance, whether the identified controls adequately address the stated risks and whether any risks lack corresponding controls. The matrix supports these activities but does not replace the judgment, evidence, and independence that assurance work involves.

Common misconceptions

A risk and control matrix is primarily an internal audit or assurance deliverable.
The identification and operation of controls is generally a first-line management responsibility. A matrix is often owned or populated by process owners in management, while assurance functions may use or test it. Treating it as solely an audit artifact can blur the accountability that typically rests with management for control design and operation.
If a control is listed against a risk, the risk is adequately addressed.
Listing a control does not establish that it is effective. Control design effectiveness (whether the control, if operating, would address the risk) and operating effectiveness (whether it actually operated as intended over the period) are separate conclusions. A documented control that is poorly designed or not consistently performed may leave significant residual risk.
A completed matrix removes or eliminates the underlying risks.
Controls generally reduce risk rather than eliminate it. The purpose of the matrix is to make residual risk visible and to help judge whether it falls within the organization's risk appetite or tolerance, not to demonstrate that risk has been fully removed.

Best practices

Write risks as events with consequences rather than as the absence of a control, so the matrix captures what could go wrong before jumping to how it is managed.
Keep design effectiveness and operating effectiveness as separate assessments, and record the basis and period for each conclusion rather than a single blended judgment.
Assign a named control owner within the appropriate line of accountability, generally first-line management, and avoid attributing operational control ownership to oversight or assurance functions.
Distinguish inherent from residual risk where the chosen methodology supports it, and use the residual view to test whether remaining exposure aligns with the organization's stated risk appetite or tolerance.
Review and refresh the matrix on a defined cadence and after significant process, system, or organizational changes, since a static matrix can misrepresent current controls.
Align the matrix with the entity's chosen framework and objectives, and document its scope and limitations so users understand what is and is not covered rather than assuming comprehensive coverage.