GRC Modeling

Dynasec has defined a series of practical steps for managing multiple GRC processes in harmony which we call GRC Modeling.

Step 1 - Create a Common Terminology
Definition of a shared GRC terminology. Adopting a common language is a mandatory step for facilitating cooperation between corporate control units and avoiding misunderstandings within the organization.

Step 2 - Unify the organizational Structure
Creation of a unified organizational structure. A variety of organizational structures in use by the different GRC projects impede cooperation between corporate units and can often cause inaccurate reporting due to incorrect risk and control calculations up the organizational tree.

Step 3 - Enable Deeper Granularity
Definition of granular relationships at the level of process, risk and control attributes. It is common knowledge that there are many-to-many relationships among the building blocks that are part of the GRC world, such as processes, risks, controls, etc. This is indeed necessary, but not enough to support an integrated GRC environment. The organization must be able to define different, distinct attributes for building blocks shared by multiple GRC processes. For example, a common control that occurs in two separate regulations might be defined as critically important for one regulation and less important in the other. The ability to define this level of granularity is critical for the success of an integrated approach.

Step 4 - Support Multilayer Hierarchy
Organizations needs to comply with international, regional and local regulations covering operational, financial and IT aspects. Each regulator has its own objectives, methodology and perspective and can take a principle-based or a rule-based approach. Some regulations mandate high-level objectives while others specify more detailed requirements. Easy2comply provides tools to achieve GRC convergence and to reduce the duplication of information and control activities among compliance processes by defining hierarchies and dependencies intelligently between the GRC building blocks. For example, the status of a high level control in one regulation may be a calculated result of the status of 5 other lower level controls that are already in place for a different standard. The ability to define such smart links and multi-level hierarchies between processes, risks and controls is vital for reducing the overhead of managing and testing redundant risks and controls across the enterprise.

Step 5 - Leveraging Correlated Information
Each GRC project has its own individual workflow that might consist of periodic control tests, multi-year audit plans or loss event accumulation. In order to attain an enterprise view of risk, information must be shared between the different processes. For example, the Internal Audit team would benefit by receiving internal control testing status as an important input to determine the frequency of audit plans. Clearly, sharing loss event information collected by the operational risk group with other corporate units can be instrumental in identifying unexpected risk exposure and preventing fraudulent activities. Correlating information between the GRC projects is one of the most effective techniques for preventing data inconsistencies, inaccurate reports and assessments.