How to Implement an Integrated GRC Architecture

 

Background

Risk Management, Compliance and Governance reforms that followed the corporate failures of the past decade have dramatically changed today’s business environment. Organizations worldwide are coping with a proliferation of new regulations and standards, and are challenged to do so in a way that supports performance objectives, upholds stakeholder expectations, sustains value and protects the organization's brand.

Recent studies indicate that Fortune 1000 corporations are subject to 35-40 different regulatory mandates and the management of regulation and compliance has become a serious risk factor in itself. Complying with each individual regulation is always complicated, lengthy and costly. Managing the burden of complying with multiple and overlapping regulations is becoming increasingly difficult and expensive. The need for an integrated GRC (Governance, Risk Management and Compliance) platform in today's business environment is obvious. Despite the hype around this topic, only a few organizations have succeeded in implementing a truly integrated GRC platform due to the complexity of the GRC environment.

 

GRC Complexity

In order to implement an integrated GRC platform, organizations need to cope
with the following complexity:

1. Multiple Regulations:
   
   • Vertical Industry Regulations (e.g. Banking: Basel II, Insurance: Solvency)
   • Horizontal Regulations (e.g. Sox)
   • Internal Corporate Governance
   • International Regulations
   • Regional Regulations
   • Local Regulations
2. Different Scope
   
   • Operational Risk
   • Internal Audit
   • Financial Control
   • IT Governance
   • Anti-Fraud Management
   • Business Continuity Planning
   • Information Security Risk
3. Different Consulting Firms involved in each project
4. Different Objectives for each project
5. Different Methodologies and Diverging Workflows
6. Different Data Architecture Requirements
7. Diverse Participants
   • Business Executives
   • Risk & Compliance Officers
   • Business Unit and Process Managers
   • Employees
   • Contractors
   • Consultants
   • Business Partners

Due tthis complexity, most organizations still manage GRC projects in silos, adopting different methodologies and different software point solutions for each project. As a result of this approach, organizations face the following difficulties:

• Inconsistency among the different projects
• Lack of a unified view of risk and compliance that limits management’s decision making process
• Lack of scalability from an enterprise wide prospective
• Duplication of activities and overlapping efforts that increase cost, internal overhead and external consulting expenses

Owing tthe complex regulatory environment, GRC related costs in enterprises are skyrocketing. For example, according ta recent SIA study, the cost of compliance in the U.S. securities community alone has nearly doubled in three years reaching $25 billion in 2006.

"Companies that select individual solutions for each regulatory challenge they face will spend 10 times more on IT portion of compliance projects than companies that take on a proactive and more integrated approach." Gartner

The Integrated GRC Approach

An integrated GRC strategy must provide an environment that on one hand allows each GRC process to be fully managed independently, while providing tools for defining complex relationships and the sharing and linking of information between the different regulations and standards.

 

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

• Definition of a single GRC terminology. Adopting a common language is s a crucial step to avoid misunderstandings within the organization.
• Creation of a unified organizational structure. Variant organizational structures often inadvertently cause mistaken assessments that are based on erroneous risk and control calculations up the organizational tree.
• Granularity at the level of risk and control attributes. It is common knowledge that there are many-to-many relationships between risks and controls. This is indeed necessary, but not enough to support an integrated GRC environment. The organization must be able to define different, distinct attributes for common risks and controls shared by multiple GRC processes. A common control that occurs in two separate regulations might be critically important for one regulation and less important in the other. The ability to define this level granularity is critical for the success of an integrated approach.
• Defining hierarchical, complex relationships between controls. In order to reduce the duplication of controls between separate compliance procedures, the organization needs tools to define control dependencies intelligently. For example, a high level control in a regulation may be identical to a combination of 5 controls in another standard. The ability to define such smart links and multi-level hierarchies between risks, controls and GRC processes is vital to reducing the overhead of managing and testing controls across the enterprise.
• Leveraging information between separate GRC workflows. Each GRC unit has its own individual workflow that might consist of periodic control tests, multi-year audit plans or collected loss events. In order to achieve an overall view of the organization’s risk; information must be shared between the different processes. For example, the Internal Audit team should receive status of control tests for determining how to build its audit plans. Loss event information collected by the operational risk group should be shared with other GRC functions.

Consequentially, we believe that the deployment of a comprehensive, integrated GRC strategy is composed of 3 phases:

GRC Modelling		GRC Operations		GRC Automation
In this phase tools are needed to model the relations between the different entities and to integrate them into the different GRC workflows. Among the activities in this phase: Defining a common language Defining a common organizational structure Defining hierarchies between risks, controls and modules Defining many to many relationships at the level of the attributes of risks, controls, and other data entities Leveraging and integrating information flow between the diverging workflows		This is the stage where each individual business or GRC unit uses a software platform to perform its own specific process. Among the activities in this phase: Process Documentation Risk and Control Assessment Reporting Remediation Plans Loss Data Accumulation More		After the ongoing GRC operations are modelled and operating for at least 1-2 years, these offline GRC processes can evolve into a more transactional system. In this phase, selected GRC processes can be automated and linked with the organization’s online systems and thereby saving time and costs of manual processes. Among the activities in this phase: Control Testing Loss Events Identification KRI Monitoring KPI Monitoring Identification of abnormal behaviour for BCP and/or Fraud Management Scenarios.

Easy2comply™ - Integrated GRC Approach

easy2comply™ is a web based software platform that enables companies to continuously manage and control compliance, corporate governance and risk management processes with built-in tools for GRC modelling. There are 5 groups of GRC applications supported:

1. Operational Risk Management (ORM) including modules such as general ORM, Basel II, Solvency II, Arrow, BilMoG, MaRisk, etc.
2. Internal Control Management (ICM), including modules such as general ICM, SOX, JSOX, MiFID, Turnbull, Tabaksblat, etc.
3. IT Risk and Governance (ITG) including modules such as: CobiT, ITIL, ISO27001, ISO17799, Business Continuity Planning (BCP), BCM (25999), Information Security.
4. Internal Audit Management (IA)
5. General Compliance (GC) for special needs such as corporate governance and procedures, strategic projects, privacy and local laws, and more.

easy2comply™ provides the tools and functionality required to design the integrated workflow and data relationships between the different GRC projects, while providing each software module with its own full set of functionality, unique workflow and if relevant, best practices data.

 

easy2comply™’s unique data model is composed of 4 logical layers built as a single data model. It is this architecture that enables the intelligent sharing of information between the different GRC projects, the elimination of redundancy between risks and controls and enabling each project to be managed separately according to its specific time frame, methodology, workflow and reporting needs.

 

 

• The bottom layer is a repository that stores all the entities that are part of the GRC projects such as: organizational units, processes, sub-processes, systems, risks, controls, loss events, scenarios and others.
• The second layer provides tools that enable GRC modelling - the creation of complex relations between the data entities and workflows thereby facilitating the integrated multi-regulatory concept.
• The third layer is the applications layer for the different GRC modules. Each application is composed of the relevant methodology, functionality and workflow needed for its specific requirements.
• The fourth layer is a shared management layer that enables communication, coordination, and measurement of GRC processes. Authorized users can create and view reports, dashboards, remediation simulations and plans, warnings and notifications, and more.

About Dynasec

Dynasec Ltd. is a leading provider of Governance, Risk Management and Compliance (GRC) solutions. Our flagship product, easy2comply™ is the perfect answer for businesses of all sizes seeking to simplify their compliance and risk management processes.

easy2comply™ can be deployed either on-demand (SaaS) or on-site to suit each customer's preferred configuration. We serve customers in many markets including: financial institutions, telecom, energy, and government, pharmaceutical, healthcare, commercial organizations.

How to manage effectively Operational Risk

For Basel II, Solvency II and Arrow

Introduction

Operational risk exists everywhere in the business environment. It is the oldest risk facing any commercial institution and in particular banks, insurance companies and other financial institutions. Any financial institution will face operational risk long before it decides on its first market trade or credit transaction.

Of all the different types of risks financial institutions face, operational risk can be the most devastating and at the same time, the most difficult to anticipate. Its appearance can result in sudden and dramatic reductions in the value of a firm.

Operational risk cannot be managed successfully with a few spreadsheets or databases developed by an internal risk management department. In fact, one of the biggest mistakes an institution can make is to rely on simplistic and traditional solutions, which can lead to less than ideal choices about managing operational risk.

easy2comply™ enables organizations to efficiently meet and adapt to internal operational risk practices as well as external regulations such as: Basel II, Solvency II, FSA mandates and others by automating and simplifying the process of collecting, storing, analyzing, tracking and reporting on information relevant to operational losses, risk and control assessments, definition and management of key risk indicators and scenarios.

easy2comply™ Operational Risk Architecture

Loss Data

The loss database is a key, standard element of the Operational Risk Management module. The collection and analysis of internal loss data provides management information which can be fed back into the operational risk management and mitigation process. In addition, the database of internal loss events builds up over time and provides the basis for quantitative analysis and the calculation of capital allocation .

Data quality of loss reporting is often a major concern in many organizations. Dynasec Enterprise simplifies the collection of loss reporting by offering a 3- step process with built-in workflow capabilities:

1. Loss Event Capturing
   In the first stage, authorized users can report on a loss event, a suspected loss event or a near miss. This loss event capturing process is performed with a comprehensive and customizable form that contains all the necessary fields and information for later loss event analysis.
2. Loss Event Evaluation
   In the second stage, authorized users, generally from the risk management department, are automatically alerted of any loss event reported in the system. They can assess the impact of the loss event and describe the associated risks and damages in various formats which provide the basis for later in depth analysis and loss event reporting.
3. ss Event Conclusions and Follow Up Actions
   At this stage, authorized users can summarize the conclusions resulting from a loss event; define follow up action items with due dates, and assign responsible persons for each action item. All action items are incorporated into easy2comply™’s integrated action and remediation plan for tracking and management of tasks.

easy2comply™’s flexible platform enables organizations to tailor their own fields in the loss database forms above, although certain standard fields such as selecting the appropriate Business Line and categorizing the Event Type are mandatory. Additional fields can easily be defined during the system configuration, requiring no programming.

easy2comply™ offers the following standard fields:

• Event Name
• Event ID
• Event Reporting Date
• Reporter Name
• Event Type (Internal/External)
• Related Organizational Unit
• Related Processes
• Related Business Line
• Related Event Category
• Related Controls
• First Event/Repeating Event/Near Miss
• Correlative Events (In case of a Repeating Event)
• Event Description
• Event Identification Day
• Start Handling Date
• End Handling Date
• Participants
• Key Personnel Involved
• Implemented Risks
• Implemented Risk – Direct Damage
• Implemented Risk – Indirect Damage
• Implemented Risk – Unquantifiable Damage
• Insurance Cover
• Conclusions
• Follow Up Action Task
• Follow Up Action Date
• Follow Up Action Responsible
• Attached Files
• Authorization process

Risk and Control Self Assessment (RCSA)

Risk and Control Self Assessment (RCSA) is one of the integrated components that easy2comply™ offers for effective management of operational risk. easy2comply™ establishes a coherent structure that automates the entire workflow for managing the risk and control framework including: systematic documentation of processes and sub processes, identification of the risks that could prevent the attainment of process objectives and mapping of the controls that should be in place to mitigate these risks.

easy2comply™ is designed in a way that enables companies to construct both actual and ‘horizontal’ or virtual organizational structures for the operational risk management process. The flexible system provides up to 1024 layers of hierarchy in the organizational structure that can be defined by the system administrator. Furthermore, easy2comply™ enables the creation of an unlimited number of ‘horizontal’ or virtual organizational units which cross the actual organizational tree. Authorized users subjectively select single or groups of hierarchical organizational units within a horizontal unit. Such horizontal organizational units are used to identify cross- company trends and to perform competitive analysis between cross- company business units. (For example: all wholly-owned subsidiaries or all purchasing departments throughout the organization).

Organizational processes and sub-processes can be documented using an integrated flowchart engine which graphically represents the process flow. Each component in the flowchart is linked to the RCSA matrix, providing for easier documentation maintenance, consistency and improved change management.

Organizations who already document their structure in an external system can take advantage of easy2comply™’s open systems environment and import or link to pre-documented organizational trees.
Furthermore, processes are linked to organizational units using an m:n approach. This enables analyzing risk and controls from both perspectives: organizational and process-oriented.

Risk Control Self Assessment can be performed at any level, including organizational units and processes. The self assessment can be based on data from 3 different sources: pre-populated data using a sophisticated templates mechanism, data built from scratch in the system during the assessment (and saved as a template if necessary) or legacy data previously accumulated and automatically inputted into the system. Adding, deleting and modifying information is easy and intuitive, although, subject to the user access rights that have been pre-selected.

Documenting and assessing risk both qualitatively and quantitatively includes but is not limited to the following information:

• Risk Name
• Risk Description
• Qualitative Information (can be based on a risk assessment wizard)
  • Severity
  • Probability
  • Other
• Quantitative Information (can be based on a risk assessment wizard)
  • Severity
  • Probability
• Scenario Analysis
  • Normal Scenario
    • Description
    • Loss
    • Frequency
    • More...
  • Serious Case Scenario
    • Description
    • Loss
    • Frequency
    • More...
  • Disaster Scenario
    • Description
    • Loss
    • Frequency
    • More...
• Risk Category
• KRI
• Key Risk
• Risk Type
• Tolerance Level
• Risk Response

Documenting and assessing controls includes but is not limited to the following information:

• Control ID
• Control Activity Description
• Control Objective
• Control Activity In Place
• Control Weight
• Key Control
• Control in Place
• Control Design Rating
• Control Owner
• Control Nature
• Control Frequency
• Relation to COSO
• Financial Effect
• Preventive/Detective
• Recommended Testing Procedure
• Sample Size Required
• Criteria for Effectiveness Testing
• Criteria for Ineffectiveness Testing
• Tester
• Testing Start Date
• Testing Due Date
• Attachment
• Findings
• Recommendation
• KPI
• Attachments
• On Management Procedures

The relations between risks and controls is based on an m:n approach where each risk can be mitigated by several controls and every control can impact various risks.

The system also allows for a correlation of m:n between controls. easy2comply™ allows for control hierarchies and dependencies between controls. For example, a control status can be based on a calculation of subcontrols. Each control in the system might have a different index of status which can be defined by the authorized users.

easy2comply™ provides functionality for copying, importing and exporting risk and controls between different segments of the organization tree and/or the process tree and can define multiple types of relations between them. Throughout the lifecycle of the operational risk management process, the system enables the reduction of the overall number of risks and controls being managed in the organization which results in a more efficient operation.

Key Risk Indicators

Key Risk Indicators (KRI) allocation and analysis is a core feature of Dynasec Enterprise Operational Risk module. The KRI module provides management with an early-warning system, underscoring those areas where pre-defined thresholds are exceeded and thus highlighting potential danger spots in a timely fashion.

Each Key Risk Indicator can be automatically generated or manually entered. Dynasec Enterprise provides the infrastructure to develop and determine both of these methods. KRIs are freely definable and there is (practically) no limit to the number or type of KRIs which can be set up.

Some of the basic information for an automatic KRI is held within the Dynasec Enterprise system. In fact, the information can be embedded in the risk control self assessment process as for example, a KRI when there are a number of missing controls in a process. Organizations can take advantage of this integrated approach to reduce the time required for reconciliation or other cross-checking requirements.

Alternatively, if the required information is located in external, typically transaction-based systems, easy2comply™ can link to those systems via standardized protocols to gather the required information. For example: the number of dealer transactions rejected for exceeding trading limits can be a KRI created and tracked in the system which has been linked to the external application that manages dealer transactions and calculates this figure.

There are situations where the information is more readily available manually or where it is not found in any other system. In these cases, suitably authorized managers can enter the KRI values directly into the system, online.

Documenting and assessing KRI’s includes but is not limited to the following information:

• KRI ID
• KRI Name
• KRI Description
• KRI Type (KRI, KCI,KPI)
• KRI Source
• KRI Norm
• Related Risk(s)
• KRI period
• KRI Test
• KRI Impact
• KRI Change
• Correlated KPI/KCI
• Conclusion
• Action Plan
• Other

Action and Remediation Plans

easy2comply™ provides integrated risk measure/action plan functionality in the operational risk management module. This functionality enables creation, execution, management and follow-up of action and remediation plans in order to improve organizational processes and controls and to mitigate risk exposure.

Action plans can be defined by authorized users as a result of:

• Poor Control
• Loss Event
• KRI
• Simulation
• Other general events

Each action plan includes but is not limited to the following information:

• Task Owner
• Due Date
• Task Description
• Related Organizational Units/Processes/Risks/Controls
• Task Status
• Authorization Process
• Log of Authorized Changes
• Log of Rejected Changes
• More

Open tasks can be distributed to the owners. An email will be automatically sent by the system to notify each owner of his or her tasks with a link to the system. A reminder will be sent if the task date has passed and escalation alerts and procedures can be defined to enable additional emails to be sent to selected managers or other individuals.

Risk Simulation

Risk simulation is an integral feature of the easy2comply™ Operational Risk module. A typical operational risk framework in many organizations includes several sources of information such as internal and external loss data, risk and control self assessment and key risk indicators. The Risk Simulations enable the analysis of this information by creating correlations between the different sources of information using various mathematical and statistical methods.

easy2comply™ Risk Simulation includes, but not limited to, the following information:

• Organizational Loss Distribution Approach
  • Severity
  • Probability
  • Periodic (Annual, 3 years, 5 years)
• Various vertical and horizontal angles of analyzing LDA:
  • Per Business Unit
  • Per Business Line
  • Per Process
  • Per Category Type
  • Per Horizontal Units
• Value at Risk Calculations using:
  • Monte Carlo Simulation
  • Historical Simulation (in development)
  • Variance – Covariance Matrix (in development)
• Residual Risk Distribution
• Control Status Analysis
• Heat Maps
• Horizontal Risk and Control Analysis
• More

Reporting

easy2comply™ provides management reporting tools for both regular and adhoc reporting requirements including dashboards, pre-built, standardized reports and a user-friendly report generator. The outputs generated by the different reporting options can also be exported to external tools such as Excel, PDF, Power Point and Word and allow the organization to identify trends and to perform analysis from multiple perspectives as outlined below.

The Operational Risk Management Module supports multiple building blocks including:

• Organizational Units
• Processes
• Risks
• Controls
• Loss Data
• KRIs
• Simulations
• IT Systems
• Business Lines
• Risk Categories
• People

In easy2comply™, each building block can serve as a basis for analyzing the information and aggregating the data. You can view graphic dashboards with drill-down capabilities and run both textual and graphical reports, such as pie charts and distribution schemes.
easy2comply™ Report Generator enables authorized users to define on their own report templates and re-use these templates at any time or in conjunction with any building block. When building a report template, all data base fields are available for selection and can serve as a basis to filter the information when running the report.

Key Benefits of Proposed Solution

The main benefits an organization can enjoy from deploying easy2comply™ Operational Risk Management modules are:

• Increase accuracy and visibility of your risk information
• More quickly identify and remediate deficiencies
• Increased management insight
• Optimization of business performance
• Reduce the cost and complexity of your operational risk process
• Integration of all risk management components on a single, coherent platform
• Incorporate a robust software architecture to incorporate current and future operational risk management needs

About easy2comply™

easy2comply™ software platform is composed of 5 solution families:

• Operational Risk Management
• Internal Control Management – including SOX, MiFID, Turnbull, JSOX, etc.
• IT Risk and Governance - including ISO 27001/17799, BCP, BCM, ITIL, etc.
• Internal Audit Management module
• Open GRC Framework

About Dynasec

Dynasec Ltd. is a leading provider of Governance, Risk Management and Compliance (GRC) solutions. Our flagship product, easy2comply™ is the perfect answer for businesses of all sizes seeking to simplify their compliance and risk management processes.
easy2comply™ can be deployed either on-demand (SaaS) or on-site to suit each customer's preferred configuration. We serve customers in many markets including: financial institutions, telecom, energy, and government, pharmaceutical, healthcare, commercial organizations.

Dynasec’s customers include financial institutions, telecom, energy and other many other enterprises.

10 steps to a sustainable integrated GRC architecture

As firms struggle to keep up in an ever-changing regulatory environment, Mati Ram, CEO at Dynasec, presents 10 practical techniques that can help organizations to build a sustainable integrated GRC architecture

Organizations today are facing increased risk and regulatory pressures. The risk management, compliance and governance reforms that followed the corporate failures of the past decade have dramatically changed today’s business environment. Organizations worldwide are coping with a proliferation of new regulations and standards, and are challenged to do so in a way that supports performance objectives, upholds stakeholder expectations, sustains value and protects the organization’s brand.

Recent studies indicate that Fortune 1000 corporations are subject to 35–40 different regulatory mandates and the management of regulation and compliance has become a serious risk factor. Complying with each individual regulation is always complicated, lengthy and costly. Managing the burden of complying with multiple and overlapping regulations is becoming increasingly difficult and expensive.

To address these issues, organizations have invested in multiple risk and compliance initiatives, with little co-ordination between them. Working in silos causes a substantial amount of duplicated control activities, which results in high cost and inefficiency. The lack of consistent methodology among the multiple GRC initiatives causes a limited visibility at upper management and board levels. Executive management is unable to obtain a comprehensive view of risk and compliance.

The challenge

In many cases promoting an integrated GRC initiative in organizations requires dealing with the natural skepticism of some of the staff members. Claims that integrated GRC is nice in theory but will not work in practice are common.

In fact, there are many good reasons for this skepticism. To implement an integrated GRC platform, organizations need to find a way to manage the following complexity:

1. Multiple regulations and standards.
2. Various regulators.
3. The differing scope of each regulation and standard.
4. Various concepts.
5. Different reporting due dates.
6. Different workflow for each project.
7. Different data architecture requirements.
8. Diverse participants within the organization.

The fact that in many cases several consulting firms are involved in the different projects, bringing different methodologies to the table, combined with the natural internal politics within organizations, makes the challenge of building an integrated GRC architecture even more complicated. Besides the professional challenges, there are serious cultural barriers to be considered. Building the architecture is just the first stage of working in an integrated fashion. This architecture cannot be implemented successfully without ensuring a convenient platform for co-ordination between all the participants.

Another common barrier comes from the world of IT – the existence of information existing in diverse platforms such as MS-Excel files, MS-Word documents, Access databases or other dedicated applications. Managers are afraid of losing the information and time invested in accumulating this information during the migration process to a new architecture and system. Automating the data import of legacy and existing information must be accounted for to overcome this IT barrier.

Due to the complexity mentioned above, most organizations still manage GRC projects in silos, adopting different methodologies and different software point solutions for each project. As a result of this approach, organizations face the following difficulties:

• Inconsistency among the different projects.
• Lack of a unified view of risk and compliance that limits management’s decision-making process.
• Lack of scalability from an enterprise-wide prospective.
• Duplication of activities and overlapping efforts, which increases cost, internal overhead and external consulting expenses.

As Gartner, the IT research and advisory firm, said: “Companies that select individual solutions for each regulatory challenge they face will spend 10 times more on the IT portion of compliance projects than companies that take on a proactive and more integrated approach.”

Building an integrated GRC architecture

An integrated GRC strategy must provide an environment that allows each GRC process to be fully managed independently, while providing tools for defining complex relationships, and sharing and linking information between the different regulations and standards.

The goal is not only to generate a maintainable and reusable framework, but to ensure, over time, compliance with a list of changing legislative, regulatory, quality and internal control requirements.

Based on our experience in implementing dozens of risk and compliance projects in large and fragmented enterprise organizations, we have applied our accumulated know-how and expertise to design a step-by-step, practical process for building and implementing an integrated GRC architecture.

The process is suitable for any type of organization but was specifically developed for large enterprises where multiple GRC audit groups and processes were created separately over time, and where these disparate GRC functions continued to evolve in parallel, with little interaction between them.

One of the critical factors that can determine the success of incorporating a culture of GRC integration in an enterprise is having a high-level, internal sponsor. Besides the functionality and technical obstacles of GRC integration, it can be politically difficult to integrate and foster co-operation between disparate audit functions in the organization. An internal patron with enough influence can help to overcome the natural internal hardships, objections and frictions that already exist and can be magnified when trying to foster professional GRC collaboration.

The process we have designed for generating an integrated GRC approach is composed of four key phases.
The first phase is perhaps the most crucial one, in which we model the integrated architecture in a structured, 10-step process. We call this step GRC modeling.
The second phase is defining and implementing a pilot for the integrated GRC architecture. We believe that, in almost all cases, the right strategy for long-term success is a bottom-up approach. By this we mean the company should choose initially two, three or, at most, four parallel audit processes to integrate and focus on a specific subset that is common to the chosen GRC projects.
We have often seen companies decide to implement a high-level, top-down strategy that encompasses mapping the entire organization and design a comprehensive GRC architecture for most or all of the separate GRC functions. We understand the inclination to plan a comprehensive and long-term strategy. The danger lies in that this high-level top-down strategy can realistically take up to two years years to develop, while enterprises today are subject to internal, market and regulatory pressures forcing them to be dynamic and undergo rapid change. By the time the master GRC plan is ready, the organization and its audit processes have evolved and the strategic architecture designed no longer fits the new organization.
After selecting the audit projects that will participate in the pilot, we must define the pilot boundaries by agreeing to:

• Define concrete pilot objectives.
• Select a subset of the organization structure and/or sub-processes while ensuring that both business and IT processes are included.
• Select from one of several scenarios for the GRC integration .
• Define a realistic pilot time-line.
• Designate key participants from each audit process.
• Solicit (if possible) the involvement of the internal, critical sponsor.

After defining and agreeing to the pilot scope, it can begin. The designated pilot players track and/or implement the first phase of GRC modeling on the chosen subset (or scenario) based on the time-line developed.

In phase III, pilot analysis and GRC architecture modification, the pilot participants individually and as a team analyze the pilot results and perform the important, but oft-overlooked, step of modifying the GRC architecture based on the conclusions of the pilot analysis. Each participant separately analyzes the pilot results from two perspectives: a) how did the pilot perform in relation to the ongoing work-flow and functionality of the specific auditing group represented by the participant; and b) how did the pilot perform in relation to the overall objective of GRC integration, reducing duplications and redundancies between the selected audit groups and improving the overall GRC efficiency? The entire pilot team reviews all the participant results and then discusses together and agrees to modifications to the GRC architecture.

Phase IV is the final deployment phase of the integrated GRC architecture that was created and improved on in the pilot process throughout the organization. Phase IV is an ongoing phase that is planned carefully by the enterprise. The company might begin by continuing to focus on the two to four selected GRC processes and expanding the deployment from the pilot subset to a wider scope. Alternatively, the organization might decide to expand the subset of sub-processes from the initial scope of two to four audit processes to include more such groups.

We have found that, as the deployment proceeds, fewer modifications are required to the overall GRC architecture. Because it was designed with a bottom-up approach, the integrated GRC solution more easily evolves with time and the scope of the implementation widens both vertically and horizontally.

10 practical techniques

1. Scoping
As stated above, in the scoping phase we define two to four GRC processes, because the basis for the integrated GRC architecture will be built around them.

2. Defining building blocks
Each regulatory process is composed of main building blocks such as: organizational units, processes, sub-processes, risks, controls, loss events, IT systems, financial accounts, audit plans and scenarios.

Not all the building blocks are relevant for each regulatory requirement. After defining the building blocks, we need to assign the right building blocks to each GRC process. This mapping will be used later on to define the relations between the building blocks with regards to each risk management or compliance process.
Table 1 below presents a sample matrix mapping building blocks and GRC projects.

3. Defining common terminology
Due to the diversification of the GRC methodologies, adopting a common language among all GRC projects is a crucial step to avoid misunderstandings within the organization.

Often different GRC project managers are using the same terminology for different data information. For example, when the Sox manager refers to “process”, he is referring to a different place in the architecture than the operational risk manager. Co-ordination between these two managers can prove difficult unless they define a mutual, common terminology.

When defining a common terminology, it is recommended to define a common name for each and every data field and to assign each field to one or more relevant GRC projects.

4. Ensuring consistent organizational structure
One of the typical mistakes we have seen across many enterprises is the existence of different organizational structures for each GRC process. Variant organizational structures often inadvertently cause mistaken assessments that are based on erroneous risk and control calculations up the organizational tree.

Obviously, a short scoping process is needed to determine which organizational units will participate in each GRC project.

5. Correlate processes and units
Because organizational processes usually cross several organizational units, it is important to define which part of the process is performed in each unit. This enables organizations to analyze the information using the organizational structure perspective.
For example, we assume a human resources process creates a residual risk of 10 X.
Company A documents this process with no correlation to the actual organizational units that are running this process. Company B divided this process into three sub-processes as follows:

As opposed to company A who has only mapped residual risk to process, company B has the ability to analyze the information both from the process point of view and the organizational structure viewpoint. This can be useful when aggregating all the processes because this method easily highlights the more ‘risky’ organizational units. This technique also enables us to define more specific and accurate key risk, contextual and performance indicators to leverage existing information for extensive analysis of the data (see point 10 below).

6. Enable high-resolution granularity
According to one of the most famous axioms in the GRC industry, a correlation of many-to-many between all the building blocks is required to enable integrated GRC. For example, it is common knowledge that there are many-to-many relationships between risks and controls.

This is indeed necessary, but not quite enough to support an integrated GRC environment. The organization must be able to define different, distinct attributes for each instance of common risks and controls shared by multiple GRC processes. A common control that occurs in two separate GRC processes might be critically important for one regulation and less important in the other. The ability to define many-to-many granularity at the level of each attribute of each building block is critical for the success of an integrated approach.

Here is a sample that illustrates the need for this granularity:
Risk: Purchase-related transactions may not be recorded in a proper period.

This risk has several attributes, such as risk impact, risk likelihood and risk response, and is found in both Sox and operational risk processes.
The qualitative impact of risk when a purchase-related transaction is recorded on say, the January 1, 2008 instead of the correct date of December 31, 2007 is different for Sox and operational risk.

Since Sox is all about financial reporting, most companies would assign the risk impact here as high, while from an operational risk perspective, the fact that this transaction recording was delayed by one day is minor, and the impact would be classified as small.

This sample shows us that, to reduce the amount of risks being managed, each attribute of the risk should be assigned a different value in relation to other dimensions such as GRC project, organizational process and organizational unit. This requires a high level of granularity in the database.

Companies that select a GRC system that cannot support many-to-many relations at the level of attributes will be forced to choose from one of the following bad options to overcome this limitation: either they will have to document the same risk again and again to assign the accurate attribute value for each project, process or organizational unit, or they will define this risk only once with constant attributes in a way that does not reflect the situation in practice or allow for accurate analysis and remediation.

7. Designing control hierarchy
To reduce the duplication of controls between separate compliance procedures, the organisation needs tools to define control dependencies intelligently.

Sometimes, a high level control in a regulation might be identical to a combination of five controls in another standard. The ability to define such smart links and multi-level hierarchies between risks, controls and GRC projects is vital to reducing the overheads of managing and testing controls across the enterprise.

For example, a detailed control objective of CobiT is ensuring network security, which is a fairly high-level objective. To ensure that this high-level objective is met in the organisation, a number of lower-level controls must be tested, most likely based on IT Security standard ISO27001. Each of the lower level ISO27001 controls might be effective or ineffective, and indicate whether the CobiT objective is met. The system should enable smart correlations of n-level hierarchy to support this capability.

8. Assigning roles and responsibilities
To enable and facilitate coordination between GRC participants, there is a clear need to define the rights to view, update and modify shared information.

9. Defining alerts and notifications
To enhance corporate internal communication, it is imperative to automate alerts and notification techniques.
Typical triggers for sending alerts and notifications are:

• organisational change;
• process change;
• redesign of shared control;
• new risk;
• successful implementation of remediation task;
• change of process owner.

10. Leveraging correlative information between the GRC projects
Each GRC unit has its own individual workflow that might consist of periodic control testing, conducting multi-year audit plans or accumulating loss events. To achieve an overall organisational risk view, information must be shared between the different processes.
For example, the internal audit team should receive status of control tests for determining the frequency of audit plans by topic. Loss event information collected by the operational risk group should be shared with other GRC functions.

Summary

The process of building the integrated GRC architecture as described in this article can help organisations improve the quality of risk and compliance information, prevent duplicated activities, decrease costs and create a long-term framework for existing and future regulatory and risk management needs.