ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A SOX risk control matrix, often called an RCM, is the central document of a Sarbanes-Oxley internal control program. It lists, for each significant process, the risks of material misstatement in financial reporting and the controls that address them, along with who performs each control, how often and how it is tested.
Management of a public company must assess the effectiveness of internal control over financial reporting under Section 404(a). Auditors of accelerated and large accelerated filers also attest to it under Section 404(b). The RCM is how management shows its work.
This guide covers the columns to include, how to write risks and controls clearly, how to pick key controls and how to connect the matrix to testing. The examples are illustrative.
The RCM turns an abstract duty into something that can be tested. It links each significant account and process to specific risks, each risk to specific controls and each control to evidence. When an auditor asks how you know revenue is complete, the RCM points to the controls and the test results.
It also drives the rest of the program. The scope of testing, the sample sizes, the training of control owners and the deficiency evaluation all start from the matrix. A weak RCM creates weak testing, which creates unpleasant surprises at year end.
SEC guidance and PCAOB AS 2201, available at PCAOB AS 2201, call for a top-down, risk-based approach, so the matrix should reflect significant accounts, not every process in the company. See SOX 404 for the legal basis.
You cannot fill in a matrix before you know what belongs in it. Begin with materiality and identify significant accounts and disclosures, then the processes and locations that feed them. Quantitative thresholds and qualitative factors such as fraud risk, complexity and prior issues all play a role.
The approach is covered in SOX scoping. Document the reasons for excluding any account or location, since unexplained exclusions attract questions.
Map each significant account to business cycles such as revenue, procure to pay, payroll, treasury, inventory, fixed assets and financial close. Then map the relevant IT systems, because IT general controls support the automated controls in the matrix.
| Column | What it records | Example |
|---|---|---|
| Process and sub-process | Where the risk sits | Procure to pay, invoice approval |
| Risk | What could go wrong | Payment made for goods not received |
| Assertion | Financial statement assertion | Existence, occurrence |
| Control description | Who does what, when | Buyer matches invoice to receipt before payment |
| Type and frequency | Preventive or detective, manual or automated | Preventive, automated, per transaction |
| Key control? | Relied on for the assessment | Yes |
| Evidence | What proves performance | System match log |
A risk in the RCM should describe what could go wrong in the process, not restate the control. “Invoices are paid twice” is a risk. “Approval is required” is a control. Each risk should connect to one or more financial statement assertions: existence or occurrence, completeness, valuation or allocation, rights and obligations, and presentation and disclosure.
Keep the language plain. A reader who has not seen the process should understand what the risk is and why it matters to the financial statements.
Avoid inflating the list. A process often has a handful of risks that really matter. A matrix with hundreds of minor items makes it harder to see the ones auditors will focus on.
A good control description names who performs the control, what they do, how often and what evidence is produced. “Accounts payable reviews invoices” is weak. “The AP supervisor reviews the three-way match exception report each day, investigates items over the threshold and signs the review in the workflow system” is testable.
Classify each control as preventive or detective, manual or automated, and note the frequency. Automated controls, once tested and supported by IT general controls, need smaller samples. Review controls, such as management reviews of reports, need precision: what threshold triggers an investigation, and what data is used.
Also consider segregation of duties, which matters for many risks. See segregation of duties for how to map and test conflicts.
Not every control belongs in the testing scope. Key controls are those that address a risk directly and, if they fail, could let a material misstatement pass undetected. Mark them in the matrix and explain why others are secondary. Redundant controls can be dropped from testing.
Include entity-level controls in the matrix or a companion document: tone at the top, code of conduct, audit committee oversight, risk assessment, whistleblower process and the financial close oversight. They influence how much reliance you can place on process-level controls.
IT general controls, including access, change management and operations, should be mapped to the applications they support. See SOX ITGC for typical requirements.
For each key control, the matrix should reference the test procedure, sample size, test results and any exceptions. The methods are described in SOX control testing. Keep the links simple so anyone can find the test file from the control line.
When a control fails, record the deficiency and evaluate its severity: deficiency, significant deficiency or material weakness, considering the likelihood and magnitude of misstatement and any compensating controls. The process is described in SOX control deficiency evaluation.
Use the results to update the matrix. A control that fails repeatedly may need redesign, not just retesting.
Consider revenue recognition for a software company. Risk: revenue is recognized before the performance obligation is met. Assertion: occurrence and cutoff. Control: each month, the revenue accounting manager reviews a report of contracts with changes in delivery terms, compares it to supporting documents and signs a review checklist. Frequency: monthly. Type: detective, manual. Key: yes. Evidence: signed checklist and report.
The test approach is to pick a sample of months, obtain the report, re-perform the comparison for selected contracts and confirm sign-off. If two of the twelve months lack evidence, the deficiency evaluation starts. The example is invented for illustration, but it shows how one line of a SOX risk control matrix ties risk, control and test together.
Newly public companies often start by documenting these lines for the highest-risk cycles first. See SOX for newly public companies.
Review the matrix at least annually and whenever processes, systems, staff or accounting standards change. Retire controls that no longer exist and add controls for new risks. Keep version history so that the matrix at any quarter-end can be reproduced.
Effort scales with complexity. The discussion in SOX compliance cost explains typical drivers, such as the number of locations, systems and key controls.
Assign an owner to the matrix, typically the internal controls or SOX program manager, and ask control owners to confirm their lines each quarter.
The first mistake is writing controls that describe intentions. “Management monitors results” cannot be tested, so rewrite it with who, what, how often and what evidence. The second is copying a template without tailoring it. Controls that do not exist in practice become deficiencies the moment someone tests them. The third is ignoring the reports used in controls: if a review relies on a system report, the completeness and accuracy of that report is part of the control.
The fourth is scoring too many controls as key. A bloated key control list inflates testing effort without adding assurance. The fifth is leaving out ownership. Every line needs a named person, and ideally a backup. Finally, forgetting changes: a new ERP module, an acquisition or a reorganization can invalidate large parts of the SOX risk control matrix, and it should be refreshed when they happen.
Control owners usually see SOX as extra work. Reduce the friction by walking them through their lines in plain language, showing exactly what evidence you need and agreeing a simple way to store it. Short quarterly check-ins beat long annual training sessions.
Show them why it matters: a clean matrix with well-designed controls shortens audits and reduces year-end scrambles for everyone. Recognize teams that keep evidence tidy, and keep a list of improvements suggested by owners, because they often see simpler ways to achieve the same control objective.
Building the matrices for ten business cycles from scratch is slow. A prepared set of templates gives you a consistent format to populate with your own risks and controls.
The SOX Toolkit contains 45 templates covering scoping and materiality, risk assessment, fraud risk, entity-level controls, process narratives and RCMs across ten business cycles, ITGCs, control testing and deficiency evaluation. Adapt the wording to match how your teams actually work.
Whatever format you use, involve control owners early. The best SOX risk control matrix is one the owners recognize as a description of their real work. For the wider program, see SOX compliance and SOX 302 vs 404.
It is a document that lists financial reporting risks by process, the controls that address them, the control owners and frequencies, and the evidence and testing for each key control.
Only as many as needed to address significant risks. Many programs focus on key controls and avoid listing every minor check.
Usually the SOX or internal controls program manager, with each control owner responsible for their entries.
At least annually and whenever processes, systems or accounting policies change.
The law requires management to assess internal control, and the RCM is the standard way to document and support that assessment.
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026
October 11, 2026