A risk and control matrix, or RACM, is used to map identified risks to the controls designed to mitigate them. Internal auditors can use a RACM to document risks and evaluate control design and operation, but the same structure is also useful for compliance, finance, operations, IT, security, and control-owner teams that need one place to connect risks, controls, evidence, testing status, and residual exposure. The Institute of Internal Auditors describes a risk control matrix as a way to document risks and the controls that address them in audit work, or more exactly, audit-related work (IIA).
Use the template below as a practical starting point. Adapt the fields and scoring labels to your control environment, do not treat this as a mandatory format for any specific framework.
Risk and control matrix template: recommended columns
| Column | What to enter |
|---|---|
| Process or control area | The business process, system, department, or control domain being assessed. |
| Risk ID | A unique reference, such as AM-01 or FIN-03. |
| Risk description | A clear statement of what could go wrong and why it matters. |
| Risk category | Optional grouping, such as compliance, financial reporting, operational, security, privacy, or third-party risk. |
| Inherent likelihood | Likelihood before considering controls. Use your chosen scale, such as Low/Medium/High or 1–5. |
| Inherent impact | Impact before considering controls. Use the same scoring discipline consistently. |
| Inherent risk rating | Combined inherent exposure before controls are considered. |
| Control ID | A unique reference for the control linked to the risk. |
| Control description | The activity designed to reduce the likelihood or impact of the risk. |
| Control owner | The role or person accountable for performing or overseeing the control. |
| Control type | Preventive, detective, or corrective if your organisation uses that classification. |
| Control frequency | How often the control operates, such as per transaction, daily, monthly, quarterly, annually, or event-driven. |
| Evidence or artifact | The record that shows the control occurred, such as a report, approval, ticket, log, reconciliation, or review sign-off. |
| Design assessment | Whether the control appears appropriately designed to address the stated risk, such as designed, needs review, or gap identified. |
| Operating or test status | Whether the control has operated as intended where reviewed or tested, such as pass, exception found, not tested, or remediation open. |
| Test result or review notes | Brief details of the review result, exception, sample issue, or open question. |
| Residual likelihood | Likelihood after considering the control. |
| Residual impact | Impact after considering the control. |
| Residual risk rating | Remaining exposure after controls or countermeasures are considered. |
| Action owner or remediation notes | Who will address gaps, exceptions, or control improvements. |
| Last reviewed date | The date the row was last reviewed or updated. |
The core fields are the ones that connect the risk, the control, the evidence, the assessment status, and the residual risk. Smaller teams can simplify the template by removing optional categories or detailed testing notes, but avoid reducing it to only likelihood and impact. At that point, it becomes a basic risk matrix, not much of a control documentation tool.
A RACM can help an internal audit activity identify risks and key controls, consider likelihood and impact, assess control design adequacy, and test adequately designed controls for whether they operate as intended (IIA). For evidence and assessment fields, NIST notes that control assessments may examine documented artifacts, mechanisms, activities, and people, and may use methods such as examine, interview, and test to generate findings about control effectiveness in practice (NIST SP 800-53A Rev. 5).
What a risk and control matrix is — and what it is not
A RACM is a working document that links a risk to the control activity meant to reduce that risk. Its value is in the connection between the risk statement, the control owner, the evidence, the review or test status, and the remaining exposure.
| Tool | Primary purpose | How it differs from a RACM |
|---|---|---|
| Basic risk matrix | Scores risk using likelihood and impact. | It helps prioritise risks, but usually does not document the specific control, owner, evidence, and operating status. GOV.UK’s example of a basic risk matrix focuses on likelihood and impact scoring (GOV.UK). |
| Risk register | Tracks risks, owners, status, and treatment actions. | It is usually a broader risk-tracking record. A RACM is organised around the controls and evidence connected to each risk. |
| Project risk template | Tracks risks to project delivery, such as schedule, budget, dependencies, or scope. | It may include mitigations, but it is not always designed for control design, control operation, or audit evidence. |
| RACM | Maps risks to controls, owners, evidence, assessment status, and residual risk. | It is control-focused and is most useful when the reader needs to show how each risk is being managed. |
Typical users include internal audit teams, compliance teams, finance and operations teams, IT and security teams, control owners, and leaders reviewing unresolved exposure. The format can be used outside audit, but the level of detail should match the organisation’s actual control environment.
How to complete a risk and control matrix
Complete the matrix from left to right so each row tells a complete control story.
- Choose a process or control area. Start with a bounded process, such as user access management, vendor onboarding, revenue recognition, change management, payroll, or incident response.
- Describe the risk clearly. Write what could go wrong. For example: “Former employees retain access to production systems.”
- Rate inherent risk. Inherent risk is the risk before management actions to alter its severity (NIST inherent risk glossary). Use a simple scoring scale your team understands.
- Identify the control. Document the specific activity that reduces the likelihood or impact of the risk.
- Assign the owner and frequency. The owner should be accountable for the control, not merely aware of it. Frequency should reflect how the control actually operates.
- Classify the control type. A preventive control is designed to avoid an unintended event before it occurs; a detective control is designed to discover and timely correct one after it occurs (GAO). Classification can depend on how the activity is implemented.
- Identify evidence. Record the artifact that shows the control happened: a ticket, system log, approval, reconciliation, exception report, meeting record, or review sign-off.
- Assess design. Ask whether the control, as written, would reasonably address the risk. Use plain labels such as designed, needs review, or gap identified.
- Record operating or test status. Where applicable, record whether the control operated as intended, whether testing found exceptions, or whether review has not yet occurred.
- Reassess residual risk. Residual risk is the portion that remains after controls or countermeasures have been applied (NIST residual risk glossary).
- Add remediation notes. If residual risk remains too high, the control is not designed adequately, or testing found exceptions, assign an action owner and record the next step.
Do not over-engineer the scoring model unless your organisation needs it. A consistent Low/Medium/High scale is often enough for a first RACM. Provided the team agrees what those labels mean.
Completed example: access management risk and control matrix
The example below uses access management because it shows how one risk can connect to a control trigger, evidence, review status, and residual exposure. NIST describes account-management control concepts that include aligning account management with termination and transfer processes, notifying designated roles when users are terminated or transferred, and disabling accounts within an organisation-defined period; relevant records may include account-management audit records and termination records (NIST SP 800-53 Rev. 5).
| Process area | Risk ID | Risk description | Inherent risk | Control ID | Control description | Owner | Type | Frequency | Evidence | Design assessment | Operating or test status | Residual risk | Remediation notes |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| User access management | AM-01 | Former employees retain access to production systems after termination. | High | CTRL-AM-01 | HR termination records trigger notification to the identity or IT operations owner, who disables relevant user accounts within an organisation-defined period. | IT security operations / identity owner | Preventive, with detective review if exception reporting is used | Per termination; exception review as defined by the organisation | HR termination record, deprovisioning ticket, identity system log, account-management audit record | Designed | Exception found: one account disabled after the defined period | Medium | Review HR-to-IT notification gap, update procedure, and retest after remediation. |
This row basically does not prove compliance with a specific framework and does not prescribe a universal access-removal timeframe. It shows the level of documentation a RACM should capture: the risk, the control, who owns it, how often it operates, what evidence exists, what review found, and what exposure remains.
How to keep the matrix useful after the first draft
A RACM becomes stale when it is disconnected from the way work actually happens. Keep it current by assigning ownership for each control, updating rows when processes, systems, owners, controls, or risks change, and setting a review cadence appropriate to your organisation.
Focus maintenance on the fields that change most often:
- Owners: confirm the named control owner is still accountable.
- Evidence: keep links, report names, ticket queues, or storage locations current.
- Assessment status: update design or operating status when reviews, tests, or exceptions occur.
- Remediation: track unresolved gaps until they are closed or formally accepted.
- Residual risk: reassess it when a control changes, fails, is removed, or is replaced.
A spreadsheet is a useful starting point for building the first version. As ownership, evidence collection, recurring reviews, and framework mappings grow, reassess whether the operating model still keeps the RACM current without relying on manual follow-up.
The practical goal is simple: every material risk in scope should have a clear control, owner, evidence source, current review status, and residual-risk view. Start with the template, complete one process area, then expand only where the additional rows improve control visibility.