Sample template. A starting point to adapt to your organization — not legal advice, and not a finished or binding document. Review with your own counsel before you rely on it.
SOX control matrix (RCM) template
Updated
A SOX control matrix — also called a risk-and-control matrix (RCM) — is the central document of an ICFR program: one row per control, with columns linking each control back to the risk and financial-statement assertion it addresses and forward to how it is tested. This template gives you the column structure auditors expect, with a short note on what each field should contain.
Copy the structure below into a spreadsheet or your compliance tooling. The discipline the matrix enforces is traceability: every control should connect to a specific assertion for a significant account, so anyone can see why a control exists and what breaks if it fails.
The control matrix columns
At minimum, a defensible control matrix carries the following columns. The left side establishes why the control exists (process, risk, assertion); the middle describes the control itself and how it operates; the right side records testing and results. Keep one control per row so that testing status and deficiencies attach cleanly.
| Column | What it captures |
|---|---|
| Control ID | Stable unique identifier for the control |
| Process / cycle | The business process (e.g., revenue, procure-to-pay, financial close) |
| Risk description | The what-could-go-wrong this control addresses |
| Financial-statement assertion | Existence, completeness, valuation, rights/obligations, presentation |
| Significant account | The account the assertion relates to |
| Control description | What the control does, in operator's terms |
| Control owner | Role accountable for performing the control |
| Preventive / detective | Whether it stops or catches an error |
| Manual / automated | Human-performed or system-enforced |
| Key control (Y/N) | Whether it is relied on for the assertion |
| Frequency | How often it operates (per transaction, daily, monthly, ad hoc) |
| ITGC dependency | IT general controls the automated control relies on |
| Test procedure | How operating effectiveness is tested |
| Test result / status | Pass, exception, or not yet tested |
How to use the matrix well
Scope top-down. Start from the financial statements and materiality, identify significant accounts and their assertions, and add controls only where they address an in-scope assertion. A matrix that lists every control someone can think of, disconnected from assertions, is longer but weaker — it cannot demonstrate coverage.
Distinguish key controls from the rest. Not every control needs the same testing rigor; the key controls relied on for an assertion do. Mark them, and make sure each significant assertion has at least one key control mapped to it — a gap there is a design problem, not just a documentation one.
- One control per row, with a stable Control ID that testing and deficiencies reference.
- Every key control traces to a specific assertion and significant account.
- Automated controls record the ITGCs (access, change, operations) they depend on.
- Test status lives in the matrix so coverage and exceptions are visible at a glance.
Frequently asked questions
What is a SOX control matrix?
It is the central ICFR document — often called a risk-and-control matrix (RCM) — with one row per control linking it to the risk and financial-statement assertion it addresses and to how it is tested. It provides the traceability an auditor needs to see why each control exists and what it protects.
What columns should a control matrix include?
At minimum: control ID, process, risk, financial-statement assertion, significant account, control description, owner, preventive/detective, manual/automated, key-control flag, frequency, ITGC dependency, test procedure, and test result. The left columns establish why the control exists and the right columns record how it is tested.
How is the control matrix scoped?
Top-down from the financial statements and materiality: identify significant accounts and their assertions, then add controls only where they address an in-scope assertion. This keeps the matrix proportionate and lets it demonstrate coverage, rather than listing every control disconnected from the assertions it supports.