The many-to-many relationships contained on the Risk Control Matrix make it the most complex area of the Governance Portal. To simplify the end-users experience, the forms and sub forms utilized for the risk-control analysis follow a consistent layout. For each risk-control object (e.g. process, objectives, risks, controls, and testing details), the following convention is followed:
Main attributes: section that contains inherited information such as the organizational unit, process, IT application, or project/event to which the matrix belongs (if applicable), as well as descriptive attributes of the object (e.g. COSO primary objective, Control Type); a link to risk event analysis. The attributes contained in this section do not typically vary from period to period.
Evaluation attributes: section that contains key evaluation fields (e.g. control operating effectiveness), status and period; the attributes contained in this section typically vary from period to period. Two primary key evaluations performed within the Risk Control Matrix are: 1) Design Effectiveness - performed on the risk form; the design effectiveness of controls are assessed based on the relationship of controls to the risks they are intended to mitigate; 2) Operational Effectiveness - performed on the control form and supported by testing details linked to each control
Linked Items List: the Risk Control Matrix houses multiple many-to-many relationships. For each object, users can view other objects (e.g. risks linked to objectives, controls linked to risks) through lists contained at the bottom of each form.
Each RCM also contains links to various activities that can be performed for a given object. These links are available through the facilitative tabs and in the main attribute section and become active once an RCM is created.
These links allow users to:
Complete a RCM Review
View and create Action Plans for the RC Matrix
View and create Tasks or Notes for the RC Matrix
Associate key risk and performance indicators to the RC Matrix
View a history of changes made within the RC Matrix
View Quick Reports (scorecards)
Manage view and edit access by Roles
View matrix links between risks, objectives and controls
Leverage existing RC Matrix via the Template Library
Expand/Collapse All sections of the RC Matrix
View the last modified by and last modified date fields
View archived evaluations
Access checklist summary information
There are several attributes that are captured for internal controls including:
Control Type1, 2
The “control type” will impact an evaluator’s ability to rely on a control when assessing design. The system allows definition of two control types to give further detail in describing different types and methods of controls.
Control Significance
This provides information around how important a given control is in relation to others. It will be a great attribute to filter on for reporting purposes.
Control Frequency
Gives an idea of how often a particular control is used or “in action.” It will also be a great attribute to filter on for reporting purposes.
Primary COSO Component
When performing a review of internal controls over financial reporting, most of the attention at the process level focuses on control activities and monitoring.
Control Activities – Internal controls that specifically address financial reporting objectives or risks.
Monitoring – Addresses the effectiveness of the key control activities built into the process as well as the effectiveness of the control environment, risk assessment and information/communication components.
Control Owner
Owner of the control activity.
The risk and control matrix addresses three questions with respect to controls design:
What are the controls?
Who owns the controls?
How are they rated?
Tests of the operating effectiveness of a control are concerned with how the control was applied, the consistency with which it was applied and by whom it was applied.
Tests ordinarily include procedures such as:
Inquiries of appropriate personnel (i.e., process and control owners)
Inspection of relevant process documentation
Observation of the entity's processes and controls in operation
Reapplication or re-performance of the operation of the control
A combination of procedures is often used to obtain sufficient evidence regarding the operating effectiveness of a control
The Risk Control Matrix is accessed from the Org Unit Process Model, the Process Form, IT Applications, and/or Projects and Events. In addition, a risk control matrix is also available for use by internal audit. (See Identify and Evaluate Controls for additional information). Users will be instructed to create a risk matrix, after a process has been linked to an organization. From there they can access the risk matrix from the process form.
The matrix is aligned with SOA 404 requirements to identify objectives and evaluate the design and operating effectiveness of controls. In addition, the detailed analysis performed in the RCM can be used to support operational risk assessments revolving around the impact and likelihood of a risk event occurring in various areas of the business and Internal Audit control evaluations within organization, processes, projects/events or IT applications.
The process of completing the RC matrix can be summarized as:
Top down identification (creating a list of each item and linking to create relationships):
Objectives that apply to a process, organization, project/event or IT application
Risks that could impact specific objectives
Controls that mitigate each risk
And
Bottom up evaluation of the:
Design effectiveness - controls must be appropriately designed prior to evaluating each individual control's operating effectiveness
Control's operating effectiveness - how effective are the controls operating?
Risk evaluation - if the controls are designed and operating effectively, then related risks are mitigated
Objective evaluation - if all risks related to an objective are mitigated, then the objective is achieved
Process evaluation - if all objectives that apply to a process have been achieved, the process is working effectively
Residual Risk - if some of the objectives applied to a process, organization, project/event or IT application have not been achieved, then remaining unmitigated risks are classified as residual risk.