When One Control Fails: Assessing Dependency-Driven Risk in the Risk Control Matrix

A shared dependency can make controls that appear independent in a risk control matrix (RCM) vulnerable to a common failure mode. Multiple controls may rely on the same report, application configuration, access restriction, or change process. Mapping these relationships can help auditors identify where apparent coverage depends on a shared condition—but the map alone establishes neither a failure nor its effect.

One analytical approach is to model the RCM as a directed graph with defined nodes and typed links. Nodes may represent risks, control objectives, individual controls, reports or data sets, applications, and enabling processes. Label each relationship—for example, “consumes report,” “automated by application,” or “depends on access provisioning”—and record its evidence basis. Treat each link as a hypothesis until verified. This graph schema is analytical guidance, not a method prescribed by the IIA or COSO.

For each suspected dependency, identify the control objective, plausible failure mode, and relevant operating period. Establish that the control uses the identified input or technology; assess whether the information is complete and accurate for the control’s purpose; examine relevant enabling processes; and determine whether the condition affected the control’s ability to prevent or detect the stated risk. A shared system name alone does not establish a consequential dependency.

Consider two reconciliations that use the same system-generated report. Their coverage may depend on the report’s completeness and accuracy, as well as on the process that generates or changes it. Depending on the system and control design, audit procedures may examine report parameters and lineage, compare selected data with an independent source, inspect relevant configuration or change evidence, and test review and exception follow-up. This is an illustrative scenario, not evidence that any particular control is deficient.

Keep three conclusions separate: whether the dependency exists, whether a relevant failure occurred, and whether it affected control operation. Document evidence and assumptions separately. If testing identifies an effect, assess its nature and extent before changing control assessments, audit coverage, or related risk conclusions under the organization’s assessment method. A graph can help prioritize inquiry; it does not prove failure, quantify impact, or determine residual risk.

Used carefully, dependency analysis makes common reliance visible and helps auditors target testing. Its value lies in following possible links with evidence and changing conclusions only when that evidence and the applicable method support a change.

Beyond the numbers. Inside the business.