Overview

Risk Assessment is very important as it provides the organization with an objective measure to differentiate between low risks and high risks. Risk Identification is an important step but often we end up with hundreds of risks without a clear way of determining which risks are the ones most important. The Risk Assessment methodology below describes how easy2comply meets these challenges.

Easy2comply also offers the ability to perform a quantitative assessment of the risk as well as a Scorecard / Questionnaire approach. These are not dealt with in this methodology paper.

The qualitative methodology is divided into three components:

1. Inherent Risk
2. Controls
3. Residual Risk

The combination of the Inherent Risk value together with the Controls generates a Residual Risk level

The logic behind this approach is based on AS/NZS 4360 Risk Assessment methodology. It assumes that the Risk has an inherent value or score and that this risk can be assessed under a normal (uncontrolled) environment. A high risk score is not good; a low risk score is good.

When controls are added or linked to the risk, it makes a statement that these controls are assisting in the management of the risk.

Each control has a measure of Effectiveness – this describes how well the control is functioning in the management of the risk. A high measure is good; a low measure is not good.

The residual risk is calculated by querying the number of controls and each of their individual measures, and determining how much of the risk remains in the context of the control assessment. The aim is to bring the residual risk as close to zero as possible.

Inherent Risk – Impact

The Impact describes the level of the impact to the organization should the risk materialize.

The system has a default scale for Impact which is as follows;

Behind each Impact category lays a score between 1 and 5. A low impact category results in a lower score.

The impact could be linked to different “ideas”. For example, the impact could represent financial impacts, or it could equally represent the impact on achieving a business objective.

The terminology of the Impact categories can be modified for a particular client installation. “Not Significant” could be changed to “$0 – $100”; “Catastrophic” could be changed to “> $1M”.

Inherent Risk – Likelihood

The Likelihood describes how likely the risk is to materialise. You can have a risk with a very large impact, yet the likelihood of it occurring is extremely rare. For this reason, the system allows you to document the likelihood of occurrence.

The system has a default scale for Likelihood which is as follows;

Behind each Impact category lays a score between 1 and 5. A low impact category results in a lower score.

The Likelihood is an expression of frequency. If required, the terminology of the Likelihood categories can be modified for a particular client installation. “Rare” could be changed to Every 10 Years”; “Almost Certain” could be changed to “Daily”.

Inherent Risk Score

The Inherent Risk Score is a simple multiplication of Impact and Likelihood generating a score between 1 and 25.

Controls

Each control has two fields that determine its relative importance in the context of managing the risk: Status and Weight.

Control Status

As described above in the introduction, each control has a measure that determines the level of effectiveness of the control. The system determines that the control is effective between 0% and 100%. The system does not allow a percentage to be directly entered. Rather it equates a Status to a particular percentage.

Some examples can be found below:

The number of options within each Status in each option is unlimited but in general it would be between 2 and 5.

The idea behind this is that different controls in different environments may require different ideas to be represented. Compliance Controls may be scrutinised through the eyes of percentage of Implementation, yet Sarbanes-Oxley Controls may be binary in the approach, i.e. they are either Fully Effective or they are Ineffective with no place in between.

The important thing is that behind these categories exists an equivalent percentage. This ensures that controls can be aggregated no matter the terminology used.

The category of Control Status used is referred to in easy2comply as a Control Index. Control Indexes can be created by an Administrator. Each control can be allocated to a single Control Index for the sake of consistency.

Control Weight

If there is a risk with three controls, the question often arises as to whether the controls all have an equivalent responsibility, or whether some controls are more important than others.

One way to deal with this is to use the Key Control field which provides a visual cue as to which controls are critical and which aren’t. This is useful but is insufficient when determining the relative importance of a large number of controls.

The Control Weight is always defaulted to Medium, but can be changed as follows:

Behind the weighting is a score or value that the application uses to calculate an overall weighting.

The weighting only has relevance when there is more than one control or when there is more than one control and there exists a difference in the weighting.

If the controls had an equal weighting, and there were four controls, each control would contribute 25%.

To understand the calculation when there is an unequal weighting, we need to look at the following examples.

Example 1

I have four controls. Three are medium, and one is critical.

This means that each of my controls with a Medium weighting now has an adjusted relative value of 21.43%, but my control with a Critical weighting has an adjusted value of 35.71%.

The system now combines the control weighting together with the control status.

Let’s assume we have the following Control Status Index:

If we continue using this example above where there are four controls.

The Medium controls each have a 21.43% weighting, and the Critical control has a 35.71%.

The Effective controls have 100% effectiveness, the Partially Effective control has 50% effectiveness, and the Ineffective control has 0% effectiveness. Combined together, it looks likes this:

Example 2

I have six controls. Two are medium, two are high, and two are critical.

This means that each of my controls with a Medium weighting now has an adjusted relative value of 12.5%, my controls with a High weighting has an adjusted relative value of 16.67%, and my controls with a Critical weighting have an adjusted value of 20.83%.

The system now combines the control weighting together with the control status.

Let’s assume we have the following Control Status Index:

If we continue using this example above where there are six controls.

The Medium controls each have a 12.5% weighting, the High controls each have a 16.67% weighting, and the Critical controls have a 20.83% weighting.

The Effective controls have 100% effectiveness, the Partially Effective control has 50% effectiveness, and the Ineffective control has 0% effectiveness. Combined together, it looks likes this:

Residual Risk

As explained in the introduction, there are three components to the Risk Assessment methodology. We have covered the first two already which are the Inherent Risk calculation, and the Controls. The third element is the Residual Risk calculation.

This calculation is performed automatically by the software. It analyses the Inherent Risk score, and the Total Overall Control Effectiveness, and determines the amount of risk remaining.

If the Overall Control Effectiveness is 53.58% as in the first example above, or 43.75% as in the second example above, the remaining risk is 46.42% and 56.25% respectively.

If the Inherent Risk score was 20, then the residual risk score would be 9.28 and 11.25 respectively.

If we put this into a table, it looks like this:

Summary

In this paper we analyse the standard risk assessment methodology that is implemented within the easy2comply software.

The methodology is a parameterisation that can be adjusted by easy2comply professional services. If there is a business requirement to adjust the methodology, please contact easy2comply.

For example, we can change the 5 x 5 matrix to a different combination, we can change the values that sit behind each Impact and Likelihood category, and we can change the way that the Residual Risk score is calculated.

Risk Management, Compliance and Govenrnace 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 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 to this 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 to the complex regulatory environment, GRC related costs in enterprises are skyrocketing.  For example, according to a 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 have a 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

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:

1. Defining a common language
2. Defining a common organizational structure
3. Defining hierarchies between risks, controls and modules
4. Defining many to many relationships at the level of the attributes of risks, controls, and other data entities
5. Leveraging and integrating information flow between the diverging workflows

GRC Operations

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:

1. Process Documentation
2. Risk and Control Assessment
3. Reporting
4. Remediation Plans
5. Loss Data Accumulation
6. More

GRC Automation

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:

1. Control Testing
2. Loss Events Identification
3. KRI Monitoring
4. KPI Monitoring
5. Identification of abnormal behaviour for BCP and/or Fraud Management Scenarios.

Dynasec Enterprise – Integrated GRC Approach

Dynasec Enterprise 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.
2. Internal Control Management (ICM), including modules such as general Internal Control, SOX, Tabaksbat, etc.
3. IT Risk and Governance (ITG) including modules such as: Cobit, ITIL, ISO17799, ISO27001, Business Continuity Planning (BCP)
4. Internal Audit Management (IA)
5. General Framework (GF) for special needs such as corporate governance and procedures, special projects, local laws, and more.

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

Dynasec’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 it’s 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 forth 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

Founded in 2002, Dynasec is a worldwide provider of an integrated GRC (Governance, Risk and Compliance) software platform for managing multiple standards and regulations such as: Internal Control, Sarbanes-Oxley (SOX), Basel II Operational Risk, Solvency, Cobit, Itil, ISO17799, ISO27001, Internal Audit, Business Continuity Planning (BCP), Anti-fraud management, and more.   Companies have implemented Dynasec’s multi-regulatory approach include: Rabobank, Mitsui Sumitomo Insurance, Dexia, Arag Insurance, Electricity Company of Israel, Cellcom Mobile, Carl Zeiss and many more.

Many questions were asked and I would like to focus on a few of them as they raise some interesting ideas for all of us.

A risk manager from the United States wanted to know about the overlap between Operational Risk and Sarbanes-Oxley. Whilst this blog won’t go into a lot of detail about the similarities and differences, the point that I made was around Controls coverage.

The SOX program covers all of the controls surrounding the Financial Reporting process, as well as the information flows into the end financials. The analysis on these controls is incredibly rich and deep, from identification, assessment, and all the way through to testing.

In contrast, Operational Risk covers a much broader set of controls across the organization; however the analysis on these controls is generally a lot shallower. Quite often it is sufficient to record that the controls exists and that they work.

These different approaches are both supported by the easy2comply SOX and Operational Risk software.

Another question was asked about how to deal with HR and IT in an Operational Risk program. This is something that always comes up, and needs a clear policy that makes sense for the organization. I would argue that Risks need to be managed where the exposure is, and that depends on the individual risk.

If we look at a trading desk, the manager as part of his Op Risk assessment may rightly identify an exposure to a specific individual or perhaps to a core IT system that supports his entire business operation. The trading desk’s exposure to these risks is very real, and as such, it should be part of his assessment even though they are HR and IT risks.

On the other side, the IT and HR department should be performing their own risk assessments for issues that are relevant to them. HR can be managing general exposures, focusing on for example standardization of hiring procedures, discrimination policies, and staff training. By contrast, the trading desk manager might not be concerned about the male/female ratio but the HR manager will be.

IT should and most likely already do manage their own risks. IT have a certain advantage in the world of Risk Assessment as the nature of their work is very output oriented and as such can be measured and reported on. There will be risks that the IT department will manage such as management of Service Level Agreements with third parties, overall system downtime across the organization, or the policies on migrating software from testing into production. These risks will never feature on the trading desk manager’s assessment unless they give him a specific and personal exposure.

The key thing to remember is that Risk Assessment is a partnership, and the Operational Risk Manager needs to coordinate activities across both the business units and the support units to ensure that all material risks are being identified and worked on.