# 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.

<!--
Guidance: How to use this template
- Purpose: the single source of truth for which risks the company has
  identified in each significant process and which controls address
  them. Testers plan from it, the auditor maps to it and the annual
  assessment (`compliance/icfr-management-assessment`) summarises it.
- Fill sections 2 to 4 first (process index, assertion key, attribute
  definitions), then one matrix block per process in section 5. Keep
  one row per risk and control pair; a control that addresses three
  risks appears in three rows with the same control ID.
- The RCM is usually maintained in a spreadsheet or GRC tool. This
  Markdown version is the controlled specification: column meanings,
  allowed values and the approved year-end extract.
- The worked example is fictional: Corvid Commerce Group plc (IFRS
  reporter, EUR, calendar year, listed in London with ADSs in New York,
  SEC foreign private issuer filing Form 20-F; entities CC-HOLD, CC-DE,
  CC-UK, CC-US and CC-VN), treated as an accelerated filer for this
  example.
- Common pitfall: control descriptions that say "reviews" without
  saying what is compared, at what threshold, by whom and what evidence
  is kept. Testers cannot test, and the auditor cannot rely on, a
  control whose precision is not described.
-->

## Document control

<!-- Guidance: The RCM changes during the year. Version it at least at scoping, at interim and at year end, and keep the year-end extract unchanged after the assessment is approved. -->

| Field | Value |
|---|---|
| Document ID | [RCM-YYYY] (*Example:* RCM-2026) |
| Company | [Legal name] (*Example:* Corvid Commerce Group plc) |
| Fiscal year | [YYYY] (*Example:* FY2026, 2026-01-01 to 2026-12-31) |
| Linked assessment | [ICFR-ASSESS-YYYY] |
| Scoping threshold | [Amount] (*Example:* EUR 525k performance materiality (group materiality EUR 700k)) |
| Control framework named in the report | [Name and year] (*Example:* COSO 2013 Internal Control Integrated Framework) |
| System of record | [GRC tool or spreadsheet, location] |
| Version | [1.0] |
| Status | [Draft / Approved scoping version / Approved year-end version] |
| Owner | [@head-of-internal-control] |
| Approvers/reviewers | [@cfo], [@head-of-internal-audit], process owners |
| Last updated | YYYY-MM-DD |
| Classification | Confidential; shared with the external auditor |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Head of internal control | [@name] | [Submit] | YYYY-MM-DD |
| Process owners (each process) | [@names] | [Confirm accuracy] | YYYY-MM-DD |
| Head of internal audit | [@name] | [Reviewed] | YYYY-MM-DD |
| Chief financial officer | [@name] | [Approve] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.9 | YYYY-MM-DD | [@name] | *Example:* Scoping version, 9 processes, 46 key controls |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Walkthrough updates; consolidation tool controls CTL-R2R-010 to 014 added from 2026-07-01 |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Year-end version; CTL-REV-004 version 2 after DEF-2026-003, CTL-REV-007 delegate step after DEF-2026-001, ITG-ACC-002 monthly after DEF-2026-002 |
| 1.2 | 2026-10-25 | [@name] | Updated to the single FY2026 deficiency story, SO-005 hosting reference, borrowings completeness step and extended coverage check |

## Contents

- [1. Scope and use](#1-scope-and-use)
- [2. Process and sub-process index](#2-process-and-sub-process-index)
- [3. Financial statement assertions key](#3-financial-statement-assertions-key)
- [4. Control attribute definitions](#4-control-attribute-definitions)
- [5. Risk and control matrix](#5-risk-and-control-matrix)
- [6. Information produced by the entity](#6-information-produced-by-the-entity)
- [7. Service organisations and CUEC mapping](#7-service-organisations-and-cuec-mapping)
- [8. Fraud risk flags](#8-fraud-risk-flags)
- [9. Segregation of duties conflicts](#9-segregation-of-duties-conflicts)
- [10. Framework mapping and coverage checks](#10-framework-mapping-and-coverage-checks)
- [11. Maintenance and change log](#11-maintenance-and-change-log)
- [12. Glossary and references](#12-glossary-and-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Scope and use

<!-- Guidance: Say which entities, accounts and processes the RCM covers and how it is used. Questions: Is the scope the same as the annual assessment? Who may change the RCM and how? Pitfall: an RCM that lists every control in the company, so key controls are lost among operational checks. -->

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.

| Scope item | Example value |
|---|---|
| Entities *(Example)* | Corvid Commerce GmbH (CC-DE, Germany), Corvid Commerce Inc (CC-US): full scope; Corvid Commerce Group plc (CC-HOLD) and Corvid Commerce Ltd (CC-UK): revenue, receivables, payroll, equity, borrowings; Corvid Commerce Vietnam LLC: capitalised development, payroll |
| Processes *(Example)* | 9, see section 2 |
| Risks *(Example)* | 38 |
| Controls *(Example)* | 71, of which 46 key |
| Change authority *(Example)* | Process owner proposes, head of internal control approves, CFO approves changes to key controls |

## 2. Process and sub-process index

<!-- Guidance: Number each process and sub-process and link it to its narrative or flowchart. Every significant account must map to at least one process. Pitfall: processes named after departments instead of transaction flows, which hides hand-offs between teams. -->

| Process ID | Process | Sub-processes | Significant accounts | Process owner | Narrative or flowchart |
|---|---|---|---|---|---|
| OTC *(Example)* | Order-to-cash, subscriptions | Contract set-up, billing, revenue and deferral, collections | Subscription revenue, deferred revenue, receivables | Head of revenue accounting | NAR-OTC-01 |
| COM *(Example)* | Order-to-cash, commerce | Order intake, shipping, returns, cut-off | Commerce revenue, receivables | Commerce finance lead | NAR-COM-01 |
| P2P *(Example)* | Procure-to-pay | Supplier master data, purchasing, receipt, invoice, payment, accruals | Payables, accrued expenses, operating costs | Head of accounts payable | NAR-P2P-01 |
| PAY *(Example)* | Payroll | Joiners and leavers, pay changes, payroll run, payroll journals | Staff costs, payroll liabilities | Group payroll manager | NAR-PAY-01 |
| INV *(Example)* | Inventory | Receipts, third-party warehouse, counts, provisions | Inventory | Supply chain controller | NAR-INV-01 |
| RND *(Example)* | Research and development capitalisation | Project approval, time recording, capitalisation, amortisation, impairment | Capitalised development costs | Vietnam finance director | NAR-RND-01 |
| TRY *(Example)* | Treasury | Cash, bank reconciliation, borrowings, covenants, FX | Cash, borrowings | Group treasurer | NAR-TRY-01 |
| R2R *(Example)* | Record-to-report | Journal entries, reconciliations, consolidation, estimates, disclosures | All accounts, disclosures | Group financial controller | NAR-R2R-01 |
| ITG *(Example)* | IT general controls | Access, change, operations | All accounts relying on systems | Chief information officer | NAR-ITG-01 |

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.

```mermaid
flowchart LR
  A[Contract signed in CRM] --> B[Subscription created in billing platform]
  B --> C[Invoice issued and deferred revenue recorded]
  C --> D[Monthly revenue release by schedule]
  D --> E[Sub-ledger interface to ERP]
  E --> F[Deferred revenue roll-forward review CTL-REV-004]
  B -. CTL-REV-001 contract set-up check .-> B
  E -. CTL-REV-003 interface reconciliation .-> E
```

## 3. Financial statement assertions key

<!-- Guidance: Use one assertion set throughout the RCM and the testing workpapers. If the auditor uses a different grouping, add a mapping column. Pitfall: tagging every risk with every assertion, which defeats the purpose of linking. -->

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.

| Code | Assertion | Plain-language question |
|---|---|---|
| E/O | Existence or occurrence | Do recorded assets and liabilities exist, and did recorded transactions happen in the period? |
| C | Completeness | Is everything that should be recorded included? |
| V | Valuation or allocation | Are amounts measured correctly, including estimates, and allocated to the right period and account? |
| R | Rights and obligations | Does the company own the assets and owe the liabilities recorded? |
| P | Presentation and disclosure | Are items classified, described and disclosed as the accounting framework requires? |

## 4. Control attribute definitions

<!-- Guidance: Define each column and its allowed values before filling the matrix, so that two testers fill it the same way. Pitfall: "automated" used for any control that involves a system; a report reviewed by a person is an IT-dependent manual control. -->

| Attribute | Allowed values | Definition and use |
|---|---|---|
| Key | Key / Non-key | Key: relied on in the assessment and tested for operating effectiveness. Non-key: documented, not tested |
| Type | Preventive (P) / Detective (D) | Preventive stops an error before it is recorded; detective finds it after recording, in time to correct it |
| Nature | Manual (M) / Automated (A) / IT-dependent manual (ITDM) | Automated runs in a system without human action; ITDM is a person acting on system output |
| Frequency | Annual, quarterly, monthly, weekly, daily, recurring (many times a day), event-driven | Drives sample sizes in the testing workpaper |
| Precision | Threshold or criteria | The amount or condition that triggers investigation, for review controls |
| IPE | IPE ID or "none" | Reports or data used to perform the control (section 6) |
| ITGC dependency | Application name or "none" | Systems whose general controls must operate for the control to be reliable |
| SOC reliance | SO ID or "none" | Service organisation report the control depends on (section 7) |
| Fraud flag | Yes / No | Control addresses a fraud risk from section 8 |
| Green Book principle | 1 to 17 | Main principle the control evidences (section 10) |

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

<!-- Guidance: One block per process. Each row pairs one risk with one control. Write the control description as who, what, when, how, threshold and evidence. Questions: Does every relevant assertion of every significant account have at least one key control? Is the precision of each review control stated? Pitfall: listing a policy as a control; a policy says what should happen, a control is the action that checks it happened. -->

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)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-OTC-001 *(Example)* | Subscription set up with price or term different from the signed contract | E/O, V | CTL-REV-001 | Revenue analyst compares each new or modified contract above EUR 20k annual value to the billing set-up before first invoice; differences corrected and evidenced in the contract checklist | Key | P | M | Event-driven | Revenue analyst | none / Billing platform / SO-001 |
| RSK-OTC-002 *(Example)* | Revenue released before or after the service period | V | CTL-REV-002 | Billing platform releases deferred revenue daily on a straight-line schedule from the service start and end dates | Key | P | A | Recurring | Billing platform owner | none / Billing platform / SO-001 |
| RSK-OTC-003 *(Example)* | Sub-ledger not fully transferred to the general ledger | C, E/O | CTL-REV-003 | Revenue accountant reconciles billing sub-ledger totals to ERP revenue and deferred revenue accounts monthly; differences above EUR 5k investigated and cleared before close | Key | D | ITDM | Monthly | Revenue accountant | IPE-001, IPE-002 / ERP, billing platform / SO-001 |
| RSK-OTC-004 *(Example)* | Deferred revenue balance misstated through unusual credits, cancellations or manual adjustments | V, C | CTL-REV-004 | Head of revenue accounting reviews the group deferred revenue roll-forward (opening, billings, releases, adjustments, closing) monthly, investigates every line whose movement differs from expectation by more than EUR 50k and any adjustments line above EUR 50k in absolute value, records a written explanation with support for each (version 2, from 2026-10-01) and signs within 5 business days of month end | Key | D | ITDM | Monthly | Head of revenue accounting | IPE-002 / Billing platform / SO-001 |
| RSK-OTC-005 *(Example)* | Credit notes issued without authority | E/O | CTL-REV-005 | Billing platform workflow requires approval by the revenue manager for credit notes above EUR 2k | Non-key | P | A | Recurring | Revenue manager | none / Billing platform / SO-001 |
| RSK-OTC-006 *(Example)* | Expected credit loss allowance misstated | V | CTL-REV-006 | Group financial controller reviews the ageing-based loss allowance calculation quarterly, compares loss rates to actual write-offs and approves overlays | Key | D | ITDM | Quarterly | Group financial controller | IPE-003 / ERP / none |
| RSK-OTC-007 *(Example)* | Manual deferral journals at an entity (start dates, billing in advance, mid-term upgrades) posted in error | V, E/O | CTL-REV-007 | US entity controller reviews every manual journal into or out of deferred revenue at Corvid Commerce Inc against contract data before close; a named delegate performs the review when the controller is absent, and the close checklist blocks sign-off until the review is evidenced (from 2026-10-15) | Key | D | ITDM | Monthly | US entity controller | IPE-019 / ERP, billing platform / SO-001 |
| RSK-OTC-008 *(Example)* | Unusual movement in revenue or deferred revenue at any entity not noticed | V, C | CTL-REV-008 | Group FP&A prepares monthly revenue and deferred revenue analytics by entity and product against an expectation built from billings and the contract schedule; the group financial controller investigates variances above EUR 250k and evidences follow-up | Key | D | ITDM | Monthly | Group financial controller | IPE-020 / Billing platform, ERP / SO-001 |

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)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-COM-001 *(Example)* | Revenue recorded for goods not shipped by period end | E/O | CTL-COM-001 | Commerce finance lead agrees shipments in the last five and first five working days of each quarter to carrier confirmations; cut-off errors above EUR 10k adjusted | Key | D | ITDM | Quarterly | Commerce finance lead | IPE-004 / Order management / none |
| RSK-COM-002 *(Example)* | Orders invoiced at wrong price | V | CTL-COM-002 | Order management system takes prices only from the approved price list; manual price override requires a second user | Key | P | A | Recurring | Commerce operations manager | none / Order management / none |
| RSK-COM-003 *(Example)* | Returns not recorded | C | CTL-COM-003 | Monthly reconciliation of warehouse return receipts to credit notes; unmatched items followed up within 10 days | Non-key | D | ITDM | Monthly | Commerce finance analyst | IPE-005 / Order management / none |

### 5.3 Procure-to-pay (P2P)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-P2P-001 *(Example)* | Payment to a fictitious or altered supplier bank account | E/O | CTL-P2P-006 | Supplier master data changes are approved in ERP by an accounts payable supervisor other than the requester, after call-back to a known contact; weekly change report reviewed | Key | P | ITDM | Weekly | AP supervisor | IPE-006 / ERP / none |
| RSK-P2P-002 *(Example)* | Invoices paid without receipt of goods or services | E/O | CTL-P2P-002 | ERP three-way match blocks payment when invoice, purchase order and receipt differ by more than 2% or EUR 500 | Key | P | A | Recurring | Head of accounts payable | none / ERP / none |
| RSK-P2P-003 *(Example)* | Unrecorded liabilities at period end | C | CTL-P2P-004 | Group financial controller reviews payments made in the first 20 days after period end above EUR 25k and open purchase orders with receipts, and books accruals | Key | D | ITDM | Quarterly | Group financial controller | IPE-007 / ERP / none |

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)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-PAY-001 *(Example)* | Payments to leavers or unauthorised pay changes | E/O, V | CTL-PAY-001 | Each entity's HR lead reconciles the payroll provider's change report to approved HR forms before each payroll run | Key | P | ITDM | Monthly | Entity HR lead | IPE-008 / Payroll service / SO-002, SO-003 |
| RSK-PAY-002 *(Example)* | Payroll journal does not match payroll run | C, V | CTL-PAY-003 | Payroll manager reconciles payroll register totals to the general ledger by entity; differences above EUR 1k cleared before close | Key | D | ITDM | Monthly | Group payroll manager | IPE-008 / ERP, payroll service / SO-002, SO-003 |

### 5.5 Inventory (INV)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-INV-001 *(Example)* | Inventory at the third-party warehouse does not exist | E/O, R | CTL-INV-002 | Corvid staff attend quarterly full counts at the third-party warehouse, resolve differences above EUR 5k per item and post adjustments approved by the supply chain controller | Key | D | M | Quarterly | Supply chain controller | IPE-009 / ERP / none (SO-004 has no SOC report) |
| RSK-INV-002 *(Example)* | Slow-moving stock not provided for | V | CTL-INV-003 | Supply chain controller reviews the ageing report quarterly and applies the provisioning policy; CFO approves overrides | Key | D | ITDM | Quarterly | Supply chain controller | IPE-010 / ERP / none |

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)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-RND-001 *(Example)* | Costs capitalised for projects that do not meet the capitalisation criteria in the accounting policy | E/O, V | CTL-RND-001 | Project review board approves each project for capitalisation against the documented criteria before any cost is capitalised; technical accounting signs the assessment | Key | P | M | Event-driven | Vietnam finance director | none / none / none |
| RSK-RND-002 *(Example)* | Hours charged to capital projects are inflated | E/O | CTL-RND-002 | Engineering managers approve weekly timesheets; finance compares capitalised hours to project plans monthly and investigates variances above 15% | Key | D | ITDM | Monthly | Vietnam finance director | IPE-011 / Time tracking tool / none |
| RSK-RND-003 *(Example)* | Impaired development assets not written down | V | CTL-RND-003 | Group financial controller performs an annual impairment indicator review and test for assets not yet in use | Key | D | M | Annual | Group financial controller | IPE-012 / none / none |

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)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-TRY-001 *(Example)* | Cash balances misstated | E/O, C | CTL-TRY-001 | Treasury analyst reconciles every bank account to the general ledger monthly; reconciling items older than 30 days escalated; reviewer signs within 7 business days | Key | D | ITDM | Monthly | Group treasurer | IPE-013 / ERP / none |
| RSK-TRY-002 *(Example)* | Borrowings incomplete or misclassified, or covenant breach not disclosed | C, P | CTL-TRY-003 | Group treasurer agrees the debt register for the EUR 50,000k senior facilities (term loan and revolving facility) and lease liabilities to lender statements and the lease register, prepares the quarterly covenant calculation, and the CFO reviews classification of borrowings and disclosure | Key | D | M | Quarterly | Group treasurer | IPE-014 / none / none |
| RSK-R2R-001 *(Example)* | Unauthorised or erroneous manual journal entries, including management override | E/O, V | CTL-R2R-002 | Manual journals above EUR 50k need approval in ERP by a preparer's manager; monthly report of all manual journals reviewed by the group financial controller for unusual users, accounts and timing | Key | P, D | ITDM | Monthly | Group financial controller | IPE-015 / ERP / none |
| RSK-R2R-002 *(Example)* | Consolidation errors in eliminations or currency translation | V, C | CTL-R2R-010 | Consolidation tool validation rules block unbalanced eliminations; group reporting manager reviews intercompany mismatch report and translation rates monthly | Key | P, D | A, ITDM | Monthly | Group reporting manager | IPE-016 / Consolidation tool / none |
| RSK-R2R-003 *(Example)* | Disclosures incomplete or inconsistent with the financial statements | P | ELC-008 | Disclosure committee reviews the annual report with a completed disclosure checklist and tie-out | Key | D | M | Annual | Disclosure committee chair | none / none / none |

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)

| Risk ID | What could go wrong | Assertions | Control ID | Control description | Key | Type | Nature | Frequency | Owner | IPE / ITGC / SOC |
|---|---|---|---|---|---|---|---|---|---|---|
| RSK-ITG-001 *(Example)* | Inappropriate access to ERP lets users bypass segregation of duties | All (indirect) | ITG-ACC-001 | Access requests approved by the data owner before provisioning | Key | P | ITDM | Event-driven | IT service manager | none / ERP / none |
| RSK-ITG-005 *(Example)* | Privileged (administrator) access to ERP held by people who no longer need it | All (indirect) | ITG-ACC-002 | ERP security lead reviews all privileged accounts by company code, removals within 5 business days; quarterly, performed monthly from October 2026 to March 2027 after DEF-2026-002 | Key | D | ITDM | Quarterly (monthly to 2027-03) | ERP security lead | IPE-021 / ERP / SO-005 |
| RSK-ITG-002 *(Example)* | Leavers keep access | All (indirect) | ITG-ACC-003 | HR and contractor leaver feeds disable accounts within one business day; monthly leaver reconciliation (contractor feed added 2026-10-01) | Key | P, D | A, ITDM | Daily, monthly | IT service manager | IPE-017 / ERP / none |
| RSK-ITG-003 *(Example)* | Excessive access in order management | All (indirect) | ITG-ACC-006 | Quarterly user access review by application owner, removals evidenced within 10 business days | Key | D | ITDM | Quarterly | Commerce systems owner | IPE-018 / Order management / none |
| RSK-ITG-004 *(Example)* | Unauthorised program changes alter calculations | All (indirect) | ITG-CHG-001 | Changes to ERP configuration tested and approved by business owner before transport to production; developers have no production access | Key | P | ITDM | Event-driven | ERP change manager | none / ERP / SO-005 |

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

<!-- Guidance: List every report, query or spreadsheet used in a key control, how it is produced and how its completeness and accuracy are assured. Pitfall: testing the review control but not the report it relies on. -->

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.

| IPE ID | Name | Source system | Type | Used by | Completeness and accuracy procedure |
|---|---|---|---|---|---|
| IPE-001 *(Example)* | Billing sub-ledger revenue summary | Billing platform | Standard report | CTL-REV-003 | Agree totals to system dashboard; SOC 1 covers report logic |
| IPE-002 *(Example)* | Deferred revenue roll-forward | Billing platform export plus spreadsheet | Standard report plus user spreadsheet | CTL-REV-003, CTL-REV-004 | Agree opening to prior closing, billings to invoice register, closing to sub-ledger; spreadsheet formulas locked and reviewed annually |
| IPE-019 *(Example)* | US manual deferral journal listing | ERP | Standard report | CTL-REV-007 | Parameters (company code, journal type, period) evidenced; count agreed to the journal register |
| IPE-020 *(Example)* | Group revenue analytics pack | Billing platform and ERP extracts plus spreadsheet | User spreadsheet | CTL-REV-008 | Totals agreed to the consolidated trial balance; formulas locked; expectation inputs agreed to the billing schedule |
| IPE-021 *(Example)* | ERP privileged user list by company code | ERP | Standard report | ITG-ACC-002 | Extracted by IT security, timestamped, count agreed to the ERP role administration screen |
| IPE-006 *(Example)* | Supplier master data change log | ERP | Standard report | CTL-P2P-006 | Parameter check (date range, all company codes) evidenced each run |
| IPE-015 *(Example)* | Manual journal listing | ERP | Custom report | CTL-R2R-002 | Query logic reviewed after each change; total agreed to the general ledger journal count |
| IPE-018 *(Example)* | Order management user list | Order management | Standard report | ITG-ACC-006 | Extracted by IT, timestamped, count agreed to system admin console |

## 7. Service organisations and CUEC mapping

<!-- Guidance: For each service organisation report, list the CUECs it names and the company control that meets each one. Pitfall: CUECs that no one owns, or that are met only by a policy statement. -->

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.

| CUEC ID | Provider (SO ID) | CUEC summary in own words | Corvid control | Tested | Gap |
|---|---|---|---|---|---|
| CUEC-BIL-01 *(Example)* | Billing platform (SO-001) | Customer approves its own users and their roles in its tenant | ITG-ACC-005 | Yes | None |
| CUEC-BIL-02 *(Example)* | Billing platform (SO-001) | Customer reviews output reports and reconciles them to its ledger | CTL-REV-003, CTL-REV-004 | Yes | None |
| CUEC-BIL-03 *(Example)* | Billing platform (SO-001) | Customer checks that contract data entered is accurate | CTL-REV-001 | Yes | None |
| CUEC-BIL-04 *(Example)* | Billing platform (SO-001) | Customer tells the provider promptly about leavers with admin rights | ITG-ACC-003 | Yes | None |
| CUEC-HST-01 *(Example)* | ERP hosting (SO-005) | Customer approves and reviews its own application users, including privileged users | ITG-ACC-001, ITG-ACC-002 | Yes | None in design; Q2 2026 review missed for one company code (DEF-2026-002) |
| CUEC-PAY-01 *(Example)* | Payroll processor (SO-002, SO-003) | Customer authorises pay changes before submission | CTL-PAY-001 | Yes | None |
| CUEC-PAY-02 *(Example)* | Payroll processor (SO-002, SO-003) | Customer reconciles payroll output to its records | CTL-PAY-003 | Yes | None |

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

<!-- Guidance: Mark risks that come from the fraud risk assessment and show the controls that address them. Management override and revenue recognition are always included. Pitfall: fraud risks listed in the fraud assessment but never linked to a control. -->

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.

| Fraud scheme | Risk ID | Controls | Residual concern |
|---|---|---|---|
| Fictitious or premature revenue *(Example)* | RSK-OTC-001, RSK-OTC-004, RSK-OTC-007, RSK-COM-001 | CTL-REV-001, CTL-REV-004, CTL-REV-007, CTL-REV-008, CTL-COM-001 | Contract modifications late in a quarter; manual deferral journals when a reviewer is absent |
| Management override through journal entries *(Example)* | RSK-R2R-001 | CTL-R2R-002, ELC-002 | Top-side consolidation entries |
| Supplier bank account diversion *(Example)* | RSK-P2P-001 | CTL-P2P-006 | Social engineering of AP staff |
| Payroll ghost employees *(Example)* | RSK-PAY-001 | CTL-PAY-001 | Small entities with one HR person |
| Inflated capitalised hours *(Example)* | RSK-RND-002 | CTL-RND-002 | Incentives tied to capitalised project budgets |

## 9. Segregation of duties conflicts

<!-- Guidance: List incompatible duties, where the conflict exists in systems or practice, and the mitigating control. Pitfall: a conflict matrix that is never compared with actual user access. -->

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.

| Conflict ID | Duty A | Duty B | Where it exists | Users affected | Mitigating control |
|---|---|---|---|---|---|
| SOD-001 *(Example)* | Create or change supplier master data | Approve payments | ERP, UK entity | 1 | CTL-P2P-006 weekly change report reviewed by group AP supervisor |
| SOD-002 *(Example)* | Post manual journals | Approve manual journals | ERP, Vietnam entity | 2 | CTL-R2R-002 monthly listing reviewed by group financial controller |
| SOD-003 *(Example)* | Develop ERP changes | Move changes to production | ERP | 0 | ITG-CHG-001 enforced by tool |
| SOD-004 *(Example)* | Issue credit notes | Receive customer cash | Billing platform, US entity | 1 | CTL-REV-004 roll-forward review of adjustments |

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

<!-- Guidance: Prove completeness two ways: every relevant assertion of every significant account has at least one key control, and every principle of the framework is evidenced. Pitfall: a long RCM with a gap nobody noticed because no one ran the coverage check. -->

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.

| Significant account | E/O | C | V | R | P |
|---|---|---|---|---|---|
| Subscription revenue *(Example)* | CTL-REV-001, CTL-REV-007 | CTL-REV-003 | CTL-REV-002, CTL-REV-004 | n/a | ELC-008 |
| Deferred revenue *(Example)* | CTL-REV-003 | CTL-REV-003, CTL-REV-004 | CTL-REV-004, CTL-REV-007, CTL-REV-008 | n/a | ELC-008 |
| Trade receivables and loss allowance *(Example)* | CTL-REV-003 | CTL-REV-003 | CTL-REV-006 | n/a | ELC-008 |
| Commerce revenue *(Example)* | CTL-COM-001 | CTL-COM-001 | CTL-COM-002 | n/a | ELC-008 |
| Inventory *(Example)* | CTL-INV-002 | CTL-INV-002 | CTL-INV-003 | CTL-INV-002 | ELC-008 |
| Capitalised development costs *(Example)* | CTL-RND-001, CTL-RND-002 | n/a | CTL-RND-003 | n/a | ELC-008 |
| Borrowings and lease liabilities *(Example)* | n/a | CTL-TRY-003 | CTL-TRY-003 | n/a | CTL-TRY-003 |
| Accrued expenses *(Example)* | n/a | CTL-P2P-004 | n/a | n/a | ELC-008 |

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.

| Green Book component | Principles | Key controls or evidence | Gaps |
|---|---|---|---|
| Control environment *(Example)* | 1 to 5 | ELC-001 to ELC-004 | None |
| Risk assessment *(Example)* | 6 to 9 | ELC-005, annual scoping, change log | None |
| Control activities *(Example)* | 10 to 12 | Sections 5.1 to 5.8 | None |
| Information and communication *(Example)* | 13 to 15 | IPE register, ELC-007, ELC-008 | None |
| Monitoring *(Example)* | 16, 17 | Internal audit plan, deficiency log | None |

## 11. Maintenance and change log

<!-- Guidance: Record every change to a key control, with reason and approval, so that testers know which version of the control they are testing for each part of the year. Pitfall: overwriting a control description mid-year, so the first half of the year was tested against a description that no longer exists. -->

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.

| Change ID | Date | Control or risk | Change | Reason | Approved by |
|---|---|---|---|---|---|
| RCM-CHG-01 *(Example)* | 2026-07-01 | CTL-R2R-010 to 014 | Added; consolidation tool replaced spreadsheets | System change CHG-2026-01 | CFO |
| RCM-CHG-02 *(Example)* | 2026-10-01 | CTL-REV-004 | Version 2: threshold basis stated (movement against expectation above EUR 50k, or adjustments line above EUR 50k) and written investigation with support required before sign-off | Remediation of DEF-2026-003 | Head of internal control |
| RCM-CHG-03 *(Example)* | 2026-10-01 | ITG-ACC-002, ITG-ACC-003 | Privileged access review monthly until 2027-03; contractor leaver feed added | Remediation of DEF-2026-002 | Head of internal control |
| RCM-CHG-04 *(Example)* | 2026-10-15 | CTL-REV-007 | Named delegate and close-checklist block added | Remediation of DEF-2026-001 | Head of internal control |

## 12. Glossary and references

<!-- Guidance: Keep definitions short and in your own words; list rule versions used and point to the companion templates. -->

| Term | Meaning in this document |
|---|---|
| RCM | Risk and control matrix: table that links financial reporting risks to the controls addressing them |
| Key control | A control management relies on and tests for its assessment |
| Precision | How small a misstatement a review control would detect, set by its threshold and criteria |
| IPE | Information produced by the entity and used in a control |
| ITGC | IT general control over access, change and operations |
| CUEC | Complementary user entity control named in a service organisation report |
| SoD | Segregation of duties |
| Compensating control | A control that meets the objective of another control that failed |

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.