Risk and Control Matrix Template (SOX ICFR, RCM)

Risk and Control Matrix: [Company name], fiscal year [YYYY]

Risk and control matrix (RCM) for internal control over financial reporting (ICFR): process index, assertion key, control attribute definitions, the matrix linking each financial reporting risk to the controls that address it (key or non-key, preventive or detective, manual, automated or IT-dependent, frequency, owner), information produced by the entity, IT general control dependencies, service organisation reliance and complementary user entity controls (CUECs), fraud flags, segregation of duties conflicts, framework mapping and coverage checks. Supports management's assessment under Sarbanes-Oxley Act section 404(a), Regulation S-K Item 308 (Form 20-F Item 15 for foreign private issuers) and Exchange Act Rule 13a-15(c), following SEC interpretive Release No. 33-8810 (as of 2026-10). Organised along the five components and 17 principles of the GAO Green Book (GAO-25-107721, 2025 revision); COSO 2013 and PCAOB AS 2201 are cited by name and number only. Replace every [bracketed] value and every row marked Example. This is a document format, not legal, accounting or audit advice. Obtain the rules and standards for the normative text.

Document control

Approvals

Revision history

Contents

• 1. Scope and use
• 2. Process and sub-process index
• 3. Financial statement assertions key
• 4. Control attribute definitions
• 5. Risk and control matrix
• 6. Information produced by the entity
• 7. Service organisations and CUEC mapping
• 8. Fraud risk flags
• 9. Segregation of duties conflicts
• 10. Framework mapping and coverage checks
• 11. Maintenance and change log
• 12. Glossary and references
• Standard and licence note

1. Scope and use

This RCM covers the significant accounts, disclosures and locations set in the annual ICFR assessment. It lists the financial reporting risks management has identified (what could go wrong) and the controls that adequately address them. Release 33-8810 lets management choose which controls to rely on: where several controls address the same risk, select the ones that give the most reliable evidence for the least effort, and mark the others non-key. Non-key controls stay in the RCM because they explain the process and may become compensating controls if a key control fails.

The RCM is used by four groups. Process owners confirm that each description matches what they do. Testers plan walkthroughs and samples from it. The head of internal control evaluates deficiencies against it, since a failed control is only meaningful once you know which risk and assertion it covered. The external auditor maps its own risk assessment to it in the integrated audit under PCAOB AS 2201.

2. Process and sub-process index

Write narratives and flowcharts in the company's own words. A flowchart for each process shows where data enters, where it changes hands, where controls sit and which systems carry it. The Mermaid sketch below is an example of the level of detail that helps a tester.

3. Financial statement assertions key

Assertions are the claims that the financial statements implicitly make. The set below is the one used in this example; it groups the categories found in auditing literature into five codes. Pick the assertion where the risk truly lies: a cut-off risk on commerce revenue is about occurrence and completeness at period end, not about valuation.

4. Control attribute definitions

Choosing key controls is a judgement. Prefer controls that are preventive and automated where the system supports them, because a tested automated control with effective change management needs little repeated testing. Prefer a precise review over several weak ones. Prefer controls close to the risk over entity-level controls unless the entity-level control has a stated threshold low enough to detect a material misstatement. Record the reason when a control is designated non-key while it addresses a significant risk, so that reviewers can see the decision was deliberate.

ID conventions: risks are RSK-<process>-NNN, controls CTL-<process>-NNN (ITG-<domain>-NNN for IT general controls and ELC-NNN for entity-level controls), IPE IPE-NNN, CUECs CUEC-<provider>-NN. Never reuse a retired ID; mark it retired in the change log instead.

5. Risk and control matrix

Read each block from left to right: the risk (what could go wrong), the assertions it threatens, then the control that addresses it with its attributes. Write the description so that a person who has never seen the process could perform and test it. Rows marked Example are illustrative for Corvid Commerce Group.

5.1 Order-to-cash, subscriptions (OTC)

Process notes (Example): subscription revenue depends on the billing platform, which runs at a service organisation. The automated release control CTL-REV-002 is tested once (a benchmark of the calculation) only because the SOC 1 report covers change management for the platform and Corvid's own tenant settings are under ITG-ACC-005. The monthly roll-forward review CTL-REV-004 is the main detective control over the balance; its investigation step was made explicit in version 2 from 2026-10-01 after deficiency DEF-2026-003, and the change log in section 11 records both versions. The entity review CTL-REV-007 and the group analytics CTL-REV-008 sit below and above it: when one layer fails, the deficiency evaluation asks whether the others still operate at a precision below materiality.

5.2 Order-to-cash, commerce (COM)

5.3 Procure-to-pay (P2P)

Process notes (Example): the three-way match CTL-P2P-002 is an automated control. Test its configuration once in the year (tolerance settings and the block on payment) and rely on change management controls for the rest of the period. The accrual review CTL-P2P-004 addresses completeness, which is the hardest assertion to test from recorded data; its evidence must show the search for items that were not recorded, not just a review of items that were.

5.4 Payroll (PAY)

5.5 Inventory (INV)

Process notes (Example): the third-party warehouse has no service auditor's report, so Corvid relies on its own attendance at counts. Record the count instructions, who attended, the differences found and how they were resolved. If attendance is ever replaced by a confirmation from the warehouse, assess whether that confirmation alone is precise enough and update the RCM and the annual assessment.

5.6 Research and development capitalisation (RND)

Process notes (Example): capitalisation of development costs is a judgement area, and the Vietnam development centre is the largest source of capitalised hours. The capitalisation criteria come from the group accounting policy manual (finance/accounting-policy-manual); the RCM cites the policy section rather than repeating its content, so that a policy change triggers a review of the related controls.

5.7 Treasury (TRY) and record-to-report (R2R)

Process notes (Example): the journal entry control CTL-R2R-002 combines a preventive approval in the ERP with a detective review of the full listing. Both halves are tested, and the listing is treated as IPE (IPE-015) because it is a custom report. Management override is a presumed fraud risk, so the review criteria include entries posted by senior finance staff, entries posted after the close date, round amounts and unusual account combinations.

5.8 IT general controls (ITG)

Process notes (Example): IT general controls do not address a financial statement assertion directly. They support every automated control, every IT-dependent manual control and every system report used as IPE in the applications listed. When an ITGC fails, identify the dependent controls through the IPE / ITGC / SOC column, then decide whether the failure was exploited, for example by reviewing logs of privileged activity for the period of failure. That analysis goes into the deficiency evaluation, not into this matrix.

6. Information produced by the entity

A review control is only as good as the information reviewed. For each IPE item record its source, whether it is a standard system report, a custom report or a user-built query or spreadsheet, and the procedure that gives comfort over its completeness and accuracy. Standard reports from a system with effective ITGCs need less work than custom queries or spreadsheets, which need their logic and inputs checked.

7. Service organisations and CUEC mapping

When a provider's SOC 1 or ISAE 3402 report lists complementary user entity controls, the provider's control objectives are only achieved if the customer performs them. Map each CUEC to a control in this RCM. If none exists, add one or record the gap in the deficiency log. The GAO Green Book (paragraph OV4.04) uses the same term and expects the entity to implement these controls.

Each year, when the new SOC 1 report arrives, compare its CUEC list with the previous year's list. Providers add, remove and reword CUECs when their systems change, and a new CUEC with no matching control is a gap from the first day of the report period. Read the exceptions section as well: an exception in a provider control that supports one of your key controls must be assessed for its effect on that control, and the outcome recorded in the annual assessment.

8. Fraud risk flags

Link each fraud scheme in the annual fraud risk assessment (compliance/fraud-risk-assessment, Green Book Principle 8) to the controls that prevent or detect it. Fraud controls deserve more evidence in testing because they are designed to work against someone trying to defeat them.

9. Segregation of duties conflicts

Segregation of duties stops one person from both committing and concealing an error or fraud. Compare the conflict rules below to actual user access at least once a year, and after major system changes. Where a small team makes full segregation impossible, record the mitigating review and test it like any other key control.

Sources for the conflict list are the delegation of authority matrix, the ERP role catalogue and the payroll and billing platform role definitions. Run the comparison with a system extract, not with a manager's memory of who does what, and keep the extract as IPE with its own completeness check.

10. Framework mapping and coverage checks

Run two coverage checks before testing starts and again at year end. The account check confirms that every significant account and relevant assertion in the annual assessment has at least one key control that addresses it, directly or through a precise entity-level control. The framework check confirms that each component and principle is present and functioning; it uses the Green Book numbering and must be mapped to the framework named in the management report.

The table is an extract. The full RCM also carries rows for professional services revenue (stage of completion review) and the related-party disclosure, which the annual assessment scopes in on qualitative grounds; every significant account in compliance/icfr-management-assessment section 3.1 must have a row.

11. Maintenance and change log

Review the RCM at least at three points: at scoping, after walkthroughs and at year end. Also update it when a process, system, organisation or accounting policy changes, and after each deficiency is remediated. When a key control changes mid-year, keep both versions with their effective dates; the testing workpaper must cover each version for the part of the year it operated.

12. Glossary and references

References (obtain current versions):

• Sarbanes-Oxley Act of 2002, section 404; 15 U.S.C. 7262.
• 17 CFR 229.308 (Regulation S-K Item 308) and 17 CFR 240.13a-15, eCFR.
• SEC Release Nos. 33-8810; 34-55929 (2007), sections II.A.1 (identifying risks and controls, entity-level controls, IT general controls) and II.B.1 (deficiencies).
• GAO, Standards for Internal Control in the Federal Government (GAO-25-107721, 2025), components, principles 1 to 17 and paragraphs OV4.03 to OV4.05 on service organisations.
• COSO Internal Control Integrated Framework (2013), name only; PCAOB AS 2201, number and title only; SSAE 18 and ISAE 3402, names only.
• Related templates: ICFR Management Assessment (compliance/icfr-management-assessment), Control Testing Workpaper (compliance/control-testing-workpaper), Control Deficiency Evaluation (compliance/control-deficiency-evaluation), SOC 2 Controls (compliance/soc2-controls, for security criteria rather than ICFR), Month-End Close Checklist (finance/month-end-close-checklist), Account Reconciliation (finance/account-reconciliation), Journal Entry Support (finance/journal-entry-support), Delegation of Authority Matrix (finance/delegation-of-authority-matrix).

Standard and licence note

Based on US public law and US government works: the Sarbanes-Oxley Act of 2002, SEC rules in 17 CFR Parts 229 and 240, SEC Release No. 33-8810 and the GAO Green Book (GAO-25-107721), summarised in original wording. The column structure and allowed values are original. The COSO 2013 framework, PCAOB AS 2201, SSAE 18 and ISAE 3402 are cited by name or number only; no text, principle statement, illustration or example from them is reproduced or paraphrased. This template is not affiliated with or endorsed by the SEC, GAO, COSO or the PCAOB. Corvid Commerce Group and all figures are fictional. This template is original text written for this collection. Check the current official versions of each rule, release and standard before use. Template licence: MIT.