An auditor reviewing a company near Al Malaz without a working risk-control matrix has to start from scratch figuring out what controls should exist in the first place.
This sits close to both ICFR work and broader internal control framework design, since the RCM is really the practical, granular tool that makes both of those higher-level structures testable in practice rather than just described in policy documents.
What a good RCM actually contains
For each key process, the specific risk being addressed, the specific control designed to manage it, who performs the control and how often, and what evidence actually proves it happened, not a generic statement that 'segregation of duties exists' without specifying which roles, which system, and which transaction types.
Where this gets built from
An RCM is typically developed alongside or immediately after internal control reviews, since the review identifies the risks genuinely worth documenting and testing rather than starting from a generic control library that may not reflect how your business actually operates.
A common failure mode
RCMs copied wholesale from a template, with control descriptions that don't actually match how the company operates, get spotted immediately during any real testing exercise, whether that's an internal review, an external audit, or a regulator's inspection, and once one control description is shown to be inaccurate, confidence in the entire document collapses.
Connecting the RCM to IT systems
Where controls are automated within an ERP system rather than performed manually, the RCM needs to reference the specific system configuration responsible for enforcing it, not just describe the control in generic terms. This is where the RCM connects directly to ITGC review work, since a control that depends on a system setting is only as reliable as the access controls governing who can change that setting.
Companies running SAP, Oracle or similar ERP platforms across entities in Riyadh need the RCM to reflect the actual system configuration in each entity, since a control that's automated in one entity's ERP instance may still be manual, and therefore differently risky, in another entity running a different setup.