The risk and control matrix is the most consequential document in internal audit that almost nobody is taught to write. It is the bridge between two worlds: on one side, the risk assessment that decided this process was worth auditing; on the other, the test program that will produce the evidence. Every scope decision, every sample, every finding traces back to a row in this matrix. And because RCMs are copied from engagement to engagement — last year’s file is always the starting template — the quality of the one you build today compounds for years. A sharp RCM propagates sharpness. A lazy one propagates laziness with a version history.
This guide is the reference we wish had existed when we built our first one: the full column set with the reason each column exists, how to write the two fields that determine whether the matrix is any good — the risk statement and the control description — six fully worked rows drawn from processes we have covered in depth, and the practical craft of building, maintaining, and reusing the matrix across SOX, RCSA, and framework-mapping work.
This guide was rewritten in September 2026 to add three things readers asked for: a worked example of a matrix being rebuilt for one real process end to end (MidState’s accounts payable audit, including the two rows that produced findings), a mapping of every column to the Global Internal Audit Standards and to COSO’s seventeen principles so the matrix can be defended in a quality assessment, and the twelve-question review checklist a manager should run before the matrix goes into the file. The template itself is unchanged.
In this guide
- What the RCM is and where it sits
- The template: every column and why it exists
- Writing the risk statement
- Writing the control description
- Six fully worked rows
- Worked example: rebuilding MidState’s AP matrix
- The classification fields — and how they drive testing
- Building an RCM from scratch
- Keeping it alive
- Beyond the audit file: SOX, RCSA, and framework mapping
- Mapping the matrix to the Standards and to COSO
- The classic mistakes
- The reviewer’s checklist: twelve questions
- Where the matrix goes next
What the RCM is and where it sits
An RCM is a process-level inventory that pairs each material risk with the controls that address it, classifies those controls, and links each one to how it will be tested. Three ideas in that sentence do the work. Process-level: the RCM lives at the level of accounts payable, payroll, or user access management — not at the enterprise level. The enterprise risk register and the RCSA capture what management believes across the whole organization; the RCM is the auditor’s instrument, built for one process, at the granularity where controls actually operate. Pairs: the matrix is relational — its whole value is the mapping. A risk with no control in its row is a gap you found before fieldwork started. A control that maps to no risk is scope you can cut. Links to testing: every key control’s row should point at the test that will be performed and, once fieldwork runs, the workpaper where the evidence lives.
In the engagement file, the RCM sits exactly between planning and fieldwork. The risk assessment decides which processes get audited and why; the RCM decomposes the chosen process into testable risk-control pairs; the test workpapers execute against those pairs and reference their IDs. When a reviewer can walk finding → workpaper → RCM row → planning rationale without asking anyone a question, the file is doing its job. That traceability is also why the RCM — not the report — is usually the first thing an external quality assessor or an external auditor seeking to rely on your work will ask to see.
The template: every column and why it exists
| Column | What goes in it | Why it exists |
|---|---|---|
| Process / sub-process | The process area this row belongs to (e.g., AP → vendor master maintenance) | Lets one matrix cover a full cycle while staying sortable and reviewable |
| Risk ID | Stable identifier (R-AP-03) | Findings, workpapers, and next year’s file all reference it; never renumber mid-life |
| Risk statement | Event + cause + consequence, one risk per row | The anchor for everything else in the row — see the writing guidance below |
| Inherent risk rating | Impact and likelihood before considering controls | Drives which risks need key controls and how much testing they earn |
| Control ID | Stable identifier (C-AP-07) | Same referencing logic; one control can map to several risks and keep one ID |
| Control description | Who does what, when, how, and what evidence results | The single field that determines whether the control is testable — see below |
| Control owner | The role (not the person) that performs the control | Roles survive turnover; “Maria” is not a control owner, “AP supervisor” is |
| Preventive / detective | P or D | Shapes test design and tells you whether the control stops errors or finds them later |
| Automated / manual / ITDM | A, M, or IT-dependent manual | Automated controls get test-of-one plus ITGC reliance; manual controls get samples |
| Frequency | Each occurrence, daily, weekly, monthly, quarterly, annual | Drives the sample size under the standard grids |
| Key / non-key | Whether this control is relied on to address the risk | Key controls get tested; non-key controls get documented and left alone |
| Objective / assertion | Financial assertion (existence, completeness, accuracy…) or the operational objective served | Proves coverage: every material objective should trace to at least one key control |
| Test approach | Inquiry, observation, inspection, reperformance — and of what | Forces the test to be designed at RCM time, not improvised in fieldwork |
| Evidence / population source | The report, system table, or file the test will draw from | Surfaces population-completeness problems before sampling starts |
| Test / workpaper ref | Link or reference to the executed test sheet | Completes the traceability chain reviewers and QA walk |
| Result / deficiency ref | Effective, or a pointer to the finding | Turns the matrix into the engagement’s live scoreboard |
That is the full set. The minimum viable matrix — risk statement, control description, P/D, A/M, frequency, key flag, test approach — is seven columns, and a small function auditing a simple process should start there. Add the remaining columns when something will actually consume them. The worst RCMs are not the sparse ones; they are the seventeen-column monsters where half the fields were filled in once, never maintained, and now quietly contradict the fields next to them.
Writing the risk statement
Most weak RCMs fail here first, because risk statements get written as category labels instead of events. “Fraud risk.” “Payments may be incorrect.” “Compliance risk related to payroll.” None of these can anchor a row: you cannot pick a control for them, cannot rate them, and cannot test anything against them. A working risk statement names an event, a cause, and a consequence: “Fictitious or duplicate vendor invoices are entered and paid because vendor-master and three-way-match controls fail or are overridden, resulting in cash loss and overstated expenses.” Now the row can do its job — the plausible causes point at the controls that belong beside it, and the consequence tells you how hard to test them.
Three rules keep the field honest. One risk per row: “invoices may be fictitious, duplicated, or coded to the wrong period” is three risks with three different control sets — split them, because a compound risk row always ends up half-covered while looking fully covered. A risk is not the absence of a control: “there is a risk that reconciliations are not performed” describes a control gap, not a risk; the risk is what the reconciliation would have caught. Write the exposure, then let the control column say what addresses it — otherwise the matrix can never represent the gap, which is the most important thing it can show. Match granularity to decisions: a typical process RCM carries eight to twenty risks. Fewer, and rows are so broad that “covered” means nothing; more, and you are cataloguing rather than assessing. If two risks would always be rated together and tested together, they are one risk.
Writing the control description
The control description has one quality bar: could an auditor who has never seen this process design the test from this field alone? That is the handoff test, and most descriptions fail it. “Management reviews the reconciliation” fails five times in five words — which management, reviews for what, how often, against what criteria, leaving what evidence? A working description carries five elements: who (a role, not a name), what (a specific verb acting on a specific object), when (frequency or trigger), how (the mechanism and thresholds), and evidence (the artifact the control leaves behind). Rewritten: “Within five business days of month-end, the AP supervisor reviews the AP subledger-to-GL reconciliation, investigates reconciling items over $10,000, documents resolution in the recon file, and signs off in Blackline.” Now the test designs itself — the evidence element tells you what to inspect, the thresholds tell you what to reperform, the timing tells you what “operating effectively” means.
Watch the verbs. “Monitors,” “oversees,” “ensures,” and “is responsible for” are not control verbs — they describe intentions, and you cannot test an intention. “Matches,” “approves,” “reconciles,” “blocks,” “recalculates,” and “certifies” are control verbs: each implies an observable act and a way to verify it happened. One more discipline: the description states the control as designed. Whether it operates that way is what the walkthrough and the test are for — never edit the description to match sloppy practice you observed; record the practice as a gap instead.
Six fully worked rows
Here is the template doing real work — six rows spanning purchase-to-pay, payroll, T&E, and the ITGC layer, written to the standard above. Classification reads preventive/detective · automated/manual/IT-dependent manual · frequency; all six are key controls.
| Process | Risk statement | Key control | Class | How you would test it |
|---|---|---|---|---|
| AP — invoice processing | Fictitious or duplicate vendor invoices are entered and paid because match controls fail or are overridden, resulting in cash loss and overstated expenses | The ERP blocks payment of any PO-based invoice that fails three-way match to PO and goods receipt within tolerance (price 2%, quantity 0); mismatches route to a buyer queue and cannot be released without AP-supervisor override, which is system-logged | P · A · each transaction | Inspect match configuration and tolerances; test one transaction per match scenario; extract the full override log and test a sample of overrides for justification and approval |
| AP — vendor master | Payments are diverted because vendor bank details are changed without verification, resulting in loss to external or internal fraudsters | Vendor master changes require second-associate approval in-system before taking effect; bank-detail changes additionally require call-back verification to the number on file (never the number on the request); the AP manager reviews a complete monthly change report | P · ITDM · each change + monthly | Sample changes for system approval and call-back evidence; reperform two monthly reviews; verify the report’s completeness against the vendor-master change log |
| Payroll — ghost employees | Fictitious or terminated employees remain on payroll and are paid because HR records and payroll processing are not reconciled, resulting in fraudulent wage cost | Monthly, the payroll manager reconciles active payroll records to HR active headcount; unmatched records are investigated and resolved within the cycle; the reconciliation and dispositions are documented and reviewed by the controller | D · M · monthly | Reperform two months from source data; test disposition evidence for every exception; independently match the full year’s payroll to HR actives and to badge or VPN activity |
| Payroll — off-cycle payments | Unauthorized off-cycle or manual payments are processed outside standard payroll controls, resulting in overpayment or fraud | Every off-cycle payment requires a documented reason code and payroll-director approval before processing; quarterly, the controller reviews the complete off-cycle register against supporting requests | P+D · M · each occurrence + quarterly | Run analytics on the full off-cycle population (it is small); inspect approvals for all or a sample; trace the quarterly review evidence for two quarters |
| T&E — expense claims | Personal, inflated, or duplicate expenses are reimbursed because manager review is absent or perfunctory, resulting in loss and policy erosion | The T&E system requires line-manager approval with receipt images attached before reimbursement; claims over $5,000 route to second-level approval; the system blocks exact duplicates (same employee, amount, date, merchant) | P · ITDM · each claim | Inspect routing and duplicate-rule configuration; run analytics for near-duplicates and claims split just under thresholds; sample approved claims and reperform the policy check |
| ITGC — user access | Users obtain access beyond their role — including SoD-conflicting or privileged access — because provisioning bypasses approval, enabling error or fraud in every dependent process | Access is provisioned only from an approved ticket specifying the role; privileged access additionally requires IT-security approval; quarterly, application owners certify all users and privileges, with removals executed within five business days | P+D · M · each grant + quarterly | Sample new grants to ticket and approval; test the certification for population completeness and removal timeliness; run a full-population SoD conflict scan |
Read the rows against the five-element standard and notice what makes them testable: every control names its performer, its trigger or frequency, its thresholds, and the evidence it leaves — and every test column follows directly from the classification. The AP and payroll rows are condensed from the full starter matrices in our accounts payable and payroll audit guides, and the expense row from the T&E guide — each of which unpacks its process into the fuller risk set these single rows represent.
Worked example: rebuilding MidState’s accounts payable matrix
The six rows above show what good rows look like. What they cannot show is how a matrix changes when it meets a real process, so here is one that did. MidState Beverage is the three-state drinks distributor that runs through our worked examples: 61,400 vendor invoices and about 148 million dollars of spend over the fourteen months its first analytics run covered, 3,140 active vendors, twelve depots raising requisitions, and a 2013-vintage ERP with a three-way match at the centre of the payables process. The prior-year accounts payable RCM had nineteen rows and had been copied forward three years running. The staff auditor assigned to the engagement did what the previous section recommends: a refresh walkthrough first, then the institutional record, then the control library as a completeness check. The matrix that came out the other side had twenty-three rows, four rewritten control descriptions, two new gap rows, and one control demoted from key. The table shows the five rows that changed most, what the prior-year matrix said, what the walkthrough and the data showed, and what changed. The full engagement, findings and all, is written up in the accounts payable audit guide, and the analytics run that fed two of the rows in the AP analytics catalog.
| Row | What the prior-year matrix said | What the walkthrough and the data showed | What changed in the row |
|---|---|---|---|
| R-AP-03 / C-AP-07 — three-way match | “The ERP blocks payment of any PO-based invoice that fails three-way match; tolerance 2 percent on price, zero on quantity.” | Configuration inspection showed the tolerance had been 5 percent or 250 dollars since 2019. The 2 percent figure had arrived with a template and been copied forward ever since, and two prior-year test sheets recorded “inspected” against a tolerance the ERP had never held. | Control description rewritten to the actual tolerances. Inherent rating unchanged. Test approach extended: extract every invoice auto-cleared inside the widened band and reperform the match on a sample, because the band is where a mispriced invoice now lives. |
| R-AP-04 / C-AP-08 — override of match failures | “Mismatches route to a buyer queue and cannot be released without AP-supervisor override, which is system-logged.” | The analytics run found 37,400 route-cash overrides in fourteen months, 1,412 of them approved by the same user who had entered the item. The routing rule permitted it; the description had simply assumed it did not. | Row split. The system logging survives as a detective element with its own test. A new gap row records that entry and approval are not segregated for overrides, with no key control against it. Design deficiency raised as finding F2 of the route cash audit and cross-referenced here. |
| R-AP-06 — duplicate payments (new) | No row. The prior matrix treated duplicates as covered by the three-way match. | The first AP analytics run matched on vendor, amount and normalised invoice number: 41 confirmed duplicate payments totalling 286,000 dollars, 29 of them through vendor records duplicated when two acquired distributors were migrated onto the ERP, with 241,000 dollars recovered within the quarter. The ERP’s own exact-match check had been switched off during the migration and never switched back on. | New risk row added. The ERP duplicate check is recorded as the key control with a design note that it keys on exact matches only and must be confirmed switched on; a monthly fuzzy-match routine owned by AP recommended as the detective layer. Recovery tracked through the issue log. |
| R-AP-02 / C-AP-03 — vendor bank-detail changes | “Bank-detail changes require call-back verification to the number on file; the AP manager reviews a complete monthly change report.” | Call-backs were performed, but the evidence lived in individual clerks’ mailboxes rather than on the vendor record, and the monthly review left no sign-off anywhere. Design sound; evidence of operation weak. | Description kept; the evidence element rewritten (“call-back note attached to the vendor record; review sign-off on the report”). Test approach changed to inspect the record, not the mailbox, with an operating-effectiveness observation on the missing sign-offs. |
| C-AP-11 — controller’s monthly review of the AP aging | Key control: “The controller reviews the AP aging monthly.” | Nobody could say what a bad aging would look like, what threshold would trigger action, or what the review had ever caught. It is an activity, not a control. | Demoted to non-key and re-described as a monitoring activity. The hours it used to consume moved to the override population, which is where the risk actually was. |
Three of the five changes came from the walkthrough, not from the data: the tolerance change, the mailbox evidence, and the aging “review” that turned out to be a habit. Two came from full-population analytics, and those two, the self-approved overrides and the duplicate payments, are the ones the audit committee remembered. That split is typical. The walkthrough fixes the description of the control environment; the data finds the money. A matrix built from the template alone would have found neither, because the template’s version of the three-way match row was, word for word, the one the prior-year file carried.
Two mechanical points from the rebuild are worth copying. First, the row count moved from nineteen to twenty-three not because the process grew but because two compound risk rows were split (“invoices are fictitious, duplicated or coded to the wrong period” became three rows with three control sets), one gap row was added for duplicates and one was created by the override split. The matrix went into the file with seventeen key controls, two open gaps, and four non-key controls, and every one of the twenty-three rows carried a date and a version note explaining what changed and why. Second, the rewrite took the staff auditor a little under two days, most of it walkthrough time with the AP supervisor and the ERP analyst, which is the right shape for the effort. The matrix is cheap to write and expensive to understand; spend the time on understanding and the writing takes an afternoon.
The classification fields — and how they drive testing
The classification columns are not metadata — they are the test plan in compressed form. Preventive vs. detective decides what evidence exists: preventive controls are tested at the gate (configuration, blocked-transaction behavior, approval before the fact), while detective controls are tested by reperformance plus a second question preventive controls never face — what happened to the exceptions? A detective control that finds issues nobody resolves is a smoke detector with the battery removed. Automated vs. manual decides how much testing effort a control costs: an automated control earns a test of one per scenario plus configuration inspection, but only while the ITGC layer — access and change management, the last worked row — holds up; if ITGCs fail, the test-of-one logic collapses and the automated population needs sampling like everything else. IT-dependent manual controls need both halves tested: the integrity of the system report and the quality of the human review of it — auditors habitually test the review and take the report on faith. Frequency converts directly to sample size under the standard conventions — annual 1, quarterly 2, monthly 2–5, weekly 5–15, daily and per-transaction populations at the 25/40/60 tiers — the full logic, attribute grids included, is in our sample size guide. And the key flag is a budget: key means “we will test this and rely on it,” so a matrix where everything is key has no priorities, only a testing bill nobody will pay. If you cannot bring yourself to spend fieldwork hours on it, it is not key.
Building an RCM from scratch
Build from the process, not from a template. The sequence that works: walk the transaction first — follow a purchase order from requisition to payment, a hire from offer letter to first paycheck — and draft risks from what could break at each handoff you just watched. Handoffs are where processes fail: between systems, between departments, between the automated step and the human one. Then mine the institutional record: prior audit findings, loss events and near misses, policy requirements, and system configuration all nominate risks and controls that walkthroughs alone miss. Only then — last, as a completeness check — open the generic control library or framework baseline and ask what it lists that you have not covered. Run the sequence in reverse, template first, and you get the matrix that describes no real company: fifty imported controls with the company name find-and-replaced, half of which do not exist here and none of which mention the system the process actually runs on.
Validate the draft with the process owner before fieldwork — they confirm facts (who performs what, in which system, how often), while you keep the judgments: ratings, key flags, and test approaches are the auditor’s call, not a negotiation. Expect a day or two of focused effort for a standard process, dominated by walkthrough time — which is exactly as it should be, because the walkthrough is where the understanding comes from. If you want the mechanical part done for you, our RCM Workbench generates a starter matrix in the structure this guide describes — built to be edited against your walkthrough, not submitted as-is.
Keeping it alive
An RCM describes an organization that is busy ceasing to exist. Reorganizations, system implementations, new products, findings, and loss events all invalidate rows — the same refresh triggers that reopen the risk assessment apply here, for the same reason. Two habits keep the matrix honest. First, date and version every row (or keep a changelog tab): when a control description changed, and why, is exactly what you need when this year’s test results contradict last year’s. Second, reconcile the matrix to reality at the start of every engagement — a refresh walkthrough before testing begins. The alternative is the classic embarrassment of auditing controls that were decommissioned two systems ago, discovered only when the auditee asks why you are requesting evidence from a platform they retired. And keep ownership straight: the audit RCM belongs to internal audit; management’s SOX documentation belongs to management. The content overlaps heavily, and merging the documents anyway quietly converts audit’s instrument into management’s representation — the RCSA lesson all over again.
Beyond the audit file: SOX, RCSA, and framework mapping
The same structure earns its keep outside the engagement file, which is why field consistency across uses pays off. SOX/ICFR: the assertions column stops being optional and drives the coverage argument — every relevant assertion for every material account traces to a key control, and deficiency aggregation works row by row through the matrix. RCSA: when management’s self-assessment register shares the RCM’s field structure, self-ratings and audit test results become directly comparable — and the divergence between them is one of the most useful risk signals either document produces. Framework and regulatory mapping: when a new requirement set arrives, coverage analysis is a mapping exercise against the matrix you already have. Mapping the 17 requirements of the IIA’s Third-Party Topical Requirement against an existing third-party RCM, for instance, shows in an afternoon which requirements your existing rows already satisfy and which are genuine gaps. And one more, unglamorous but real: the RCM is the fastest process education a new auditor can get — reading a good matrix is a guided tour of how the process works, where it breaks, and what the organization does about it.
Mapping the matrix to the Standards and to COSO
No standard requires a document called a risk and control matrix. What the Standards require is exactly what a good matrix produces, which is why an external quality assessor will ask for it before asking for anything else. Under the Global Internal Audit Standards the engagement-planning requirements sit in Principle 13 and the fieldwork requirements in Principle 14, and the columns of the template map onto them almost one to one. COSO’s 2013 framework is the other reference the matrix has to survive, because management’s SOX documentation, the RCSA and the external auditor all speak in its seventeen principles. The table gives the mapping; the paragraphs after it say what to do with it.
| RCM columns | What the Global Internal Audit Standards require | Where it lands in COSO 2013 |
|---|---|---|
| Process / sub-process · Risk ID · Risk statement · Inherent rating | Standard 13.2, Engagement Risk Assessment: understand the activity under review, identify the risks relevant to it including fraud risk, and identify the controls that mitigate them. The risk statement column is where the assessment is written down; the inherent rating is how it is prioritised. | Principle 7 (identifies and analyses risk), Principle 8 (assesses fraud risk), Principle 9 (identifies and analyses significant change). A refresh walkthrough is Principle 9 in practice. |
| Objective / assertion | Standard 13.3, Engagement Objectives and Scope, and Standard 13.4, Evaluation Criteria: the objectives the engagement will conclude on and the criteria controls are judged against. The assertion column is the coverage proof that every objective traces to a control. | Principle 6 (specifies suitable objectives). For ICFR the assertions are the objectives. |
| Control ID · Control description · Control owner | Standard 13.2 again: the controls identified must be described well enough to be evaluated. The five-element description (who, what, when, how, evidence) is the practical test of “well enough”. | Principle 10 (selects and develops control activities), Principle 12 (deploys control activities through policies and procedures). A control with no owner fails Principle 12. |
| Preventive / detective · Automated / manual / ITDM · Frequency · Key flag | Standard 13.5, Engagement Resources, and Standard 13.6, Work Program: the classifications are what turn the matrix into a resourced test plan, because they set the sample sizes and the hours. The key flag is the scoping decision the work program depends on. | Principle 10’s points of focus ask for a mix of control types (preventive and detective, manual and automated); Principle 11 covers the general controls over technology that every automated row depends on. |
| Test approach · Evidence / population source · Test / workpaper reference | Standard 13.6, Work Program, for the design of the tests; Standard 14.1, Gathering Information for Analyses and Evaluation, for the reliability, relevance and sufficiency of what the tests draw on; Standard 14.6, Engagement Documentation, for the trail from row to workpaper. | Principle 13 (uses relevant, quality information) for the population source; Principle 16 (ongoing and separate evaluations) for the testing itself. |
| Result / deficiency reference | Standard 14.2, Analyses and Potential Engagement Findings; Standard 14.3, Evaluation of Findings, which is where significance is rated; Standard 14.4, Recommendations and Action Plans. The deficiency column is how findings flow back to the row that produced them. | Principle 17 (evaluates and communicates deficiencies). The aggregation of deficiencies for ICFR runs row by row through this column. |
Three practical uses follow from the mapping. In an external or internal quality assessment, the assessor samples engagement files and walks risk to control to test to finding; a matrix whose rows carry the columns above is conformance with 13.2, 13.6 and 14.6 in one document, which is why the QAIP playbook treats the RCM as the first artefact to check. In SOX work, the assertion column and the key flag are the two fields management’s documentation and the external auditor will both read first, because they carry the coverage argument for the audit of internal control over financial reporting; the SOX 404 guide and the scoping guide cover how far that argument has to reach. And when a new requirement set arrives, the mapping runs the other way: the COSO seventeen-principles guide shows how to lay a framework over an existing matrix and read off which principles are already evidenced by a row and which are not.
One warning about the mapping. It is tempting to add a “Standard” column and a “COSO principle” column to the template and fill them in. Do not, unless something will consume them. A matrix that references 13.2 on every risk row and Principle 10 on every control row has added two columns of identical text and no information. Keep the mapping as a one-page note in the engagement file, or as this table, and let the rows stay lean.
The classic mistakes
| Mistake | Why it hurts | The fix |
|---|---|---|
| Template-first build | Generic controls that describe no real company; the matrix passes review and misses everything local | Walkthrough first, institutional record second, library last as a completeness check |
| Gaps left invisible | Risks without controls quietly dropped from the matrix instead of flagged — hiding the most important thing it can show | Keep the unmatched row, mark it as a gap, and carry it straight into the findings process |
| Activities listed as controls | “Management monitors performance” cannot prevent or detect anything specific, so testing it proves nothing | Definition test: what specific failure does it prevent or detect, and what evidence does it leave? |
| Everything marked key | The testing budget explodes, or the key flag becomes decorative — either way priorities vanish | Key = will be tested and relied on; rank controls per risk and cap key controls per process |
| Copy-forward without reconciliation | You test controls that no longer exist, in systems that were retired, owned by people who left | Refresh walkthrough at the start of every engagement; date and version rows |
| Ratings frozen after findings | The matrix says “effective” while the audit file says otherwise — the file contradicts itself | Wire the deficiency reference column into the reporting process so results flow back to rows |
The reviewer’s checklist: twelve questions before the matrix goes in the file
The classic mistakes above are easier to catch with a list than with instinct, and the person best placed to catch them is the reviewer, not the author, because the author has been staring at the rows for two days and can no longer see them. The checklist below is what a manager should run, cold, before the matrix is accepted into the file and the work program is built from it. It takes about forty minutes for a twenty-row matrix. Paste it into the review note template so the answers are recorded, because a matrix that passed this review last year and fails it this year is telling you something about the process, not just the document.
Risk rows. 1. Does every risk statement name an event, a cause and a consequence, and only one event? 2. Is any “risk” really the absence of a control in disguise (“reconciliations may not be performed”), and if so has it been rewritten as the exposure the control would catch? 3. Do the inherent ratings look like a distribution rather than a wall of “high”, and does the highest-rated risk have the most testing behind it?
Control rows. 4. Could an auditor who has never seen this process design the test from each key control description alone: who, what, when, how, and what evidence? 5. Are the verbs control verbs (matches, approves, reconciles, blocks, recalculates, certifies) rather than intentions (monitors, oversees, ensures, is responsible for)? 6. Is every owner a role rather than a name? 7. Do the classification fields agree with the description: a control described as monthly carries a monthly frequency, an automated control names the system, an IT-dependent manual control names both the report and the reviewer?
Coverage and dependencies. 8. For every automated or IT-dependent control, is there a row or a cross-reference for the general IT controls it depends on, and is somebody testing them? 9. For every detective control, does the test approach cover what happens to the exceptions it finds, not just whether it runs? 10. Does every material objective or assertion trace to at least one key control, and is every risk without a control kept in the matrix and marked as a gap rather than quietly dropped?
Discipline. 11. Is the key flag a budget: would you defend spending fieldwork hours on every control marked key, and is the total testing bill one the engagement can actually pay? 12. Was the matrix reconciled to reality in a walkthrough this year, are the rows dated and versioned, and does every key control’s test reference resolve to a real step in the work program?
A matrix that answers “no” to questions 1, 4 or 10 should go back to the author before anything else happens, because those three failures propagate: a vague risk row produces a vague control row, a vague control row produces an untestable work program step, and an invisible gap produces a clean opinion on a process that has a hole in it. The rest are fixable in the review meeting. What the reviewer should not do is fix them silently. A corrected matrix with no review note teaches the author nothing, and next year’s copy-forward will carry the same faults back.
Where the matrix goes next
The RCM rewards craft like almost nothing else in the audit file, because it compounds: the matrix you sharpen this year is the template someone copies for the next five. Write risk statements that name events, control descriptions that pass the handoff test, classifications that mean what they say, and the downstream work designs itself. Each key control’s test approach expands into steps in the work program; each frequency turns into a sample under the 25, 40, 60 conventions; each executed test lands in a workpaper that references the row; and each exception comes back through deficiency evaluation to the result column, which is how the matrix becomes the engagement’s scoreboard rather than its starting point. Start with the structure in this guide, generate the mechanical skeleton with the RCM Workbench if you want a head start, and then do the part no template can: walk the process, and write down what is actually there.
Related guides
- How to audit accounts payable — the MidState engagement the worked example is drawn from, with the full starter matrix
- How to audit payroll — the source of the ghost-employee and off-cycle rows
- Internal audit risk assessment — the assessment that decides which processes get a matrix at all
- The engagement planning memo template — the document that sits immediately before the RCM in the file
- How to write an audit work program — what each key control’s test approach expands into
- Walkthrough documentation template — the record of the walkthrough the matrix is built from
- Walkthrough versus test of controls — when a walkthrough is evidence and when it is not
- Manual, automated and IT-dependent controls — the classification column in depth
- Audit sample sizes: 25, 40, 60 — how the frequency column becomes a sample
- Segregation of duties — the control the MidState override row was missing
- User access reviews — the certification behind the ITGC worked row
- Control deficiency evaluation — what happens to a row when the test fails
- COSO’s seventeen principles — the framework the mapping section refers to
- GIAS Domain V: performing engagements — Standards 13.1 to 14.6 in full
- The QAIP playbook — how the matrix is assessed in a quality review
- The RCSA process — management’s version of the same structure
- All internal controls guides and all templates
Leave a Reply