An auditor reviewing a company without a working risk control matrix has to work out from scratch which controls should exist in the first place.
This sits close to both ICFR work and broader internal control framework design. The matrix is the practical, granular tool that makes both of those higher-level structures testable, instead of leaving them described only in policy documents.
What a good RCM contains
For each key process, a good RCM records the risk addressed and the control designed to manage it. It also records who performs the control, how often, and the evidence that proves it happened. A statement that 'segregation of duties exists' is not enough; the RCM names the roles, the system and the transaction types.
Where it gets built from
An RCM is usually developed alongside or right after internal control reviews. The review identifies the risks worth documenting and testing, which is a better starting point than a generic control library that may not reflect how your business operates.
A common failure mode
An RCM copied wholesale from a template often has control descriptions that do not match how the company operates. This is usually exposed in the first real testing exercise, whether an internal review, an external audit or a regulator inspection. Once one control description proves inaccurate, confidence in the whole document drops.
Connecting the RCM to IT systems
Where a control is automated in an ERP system rather than performed manually, the RCM needs to reference the system configuration that enforces it. This links it to ITGC review work. A control that depends on a system setting is only as reliable as the access controls governing who can change that setting.