10 steps to a sustainable integrated GRC architecture

Organisations today are facingincreased risk and regulatorypressures. The risk management,compliance and governance reforms thatfollowed the corporate failures of the pastdecade have dramatically changed today’sbusiness environment. Organisationsworldwide are coping with a proliferationof new regulations and standards, and arechallenged to do so in a way that supportsperformance objectives, upholds stakeholderexpectations, sustains value andprotects the organisation’s brand.
Recent studies indicate that Fortune 1000corporations are subject to 35–40 differentregulatory mandates and the managementof regulation and compliance has becomea serious risk factor. Complying with eachindividual regulation is always complicated,lengthy and costly. Managing the burdenof complying with multiple and overlappingregulations is becoming increasinglydifficult and expensive.
To address these issues, organisationshave invested in multiple risk and complianceinitiatives, with little co-ordinationbetween them. Working in silos causes asubstantial amount of duplicated controlactivities, which results in high cost andinefficiency. The lack of consistent methodologyamong the multiple GRC initiativescauses a limited visibility at uppermanagement and board levels. Executivemanagement is unable to obtain a comprehensiveview of risk and compliance.

The challenge

In many cases promoting an integratedGRC initiative in organisations requiresdealing with the natural scepticism of someof the staff members. Claims that integratedGRC is nice in theory but will not work inpractice are common.
In fact, there are many good reasons forthis scepticism. To implement an integratedGRC platform, organisations need to find away 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 architecturerequirements.
8. Diverse participants within theorganisation.
The fact that in many cases several consultingfirms are involved in the differentprojects, bringing different methodologiesto the table, combined with the naturalinternal politics within organisations,makes the challenge of building an integratedGRC architecture even morecomplicated. Besides the professional challenges,there are serious cultural barriers tobe considered. Building the architecture isjust the first stage of working in an integratedfashion. This architecture cannot beimplemented successfully without ensuringa convenient platform for co-ordinationbetween all the participants.
Another common barrier comes from theworld of IT – the existence of informationexisting in diverse platforms such as MSExcelfiles, MS-Word documents, Accessdatabases or other dedicated applications.Managers are afraid of losing the informationand time invested in accumulatingthis information during the migrationprocess to a new architecture and system.Automating the data import of legacy andexisting information must be accounted forto overcome this IT barrier.
Due to the complexity mentioned above,most organisations still manage GRCprojects in silos, adopting different methodologiesand different software point solutionsfor each project. As a result of this approach,organisations face the following difficulties:

• Inconsistency among the differentprojects.
• Lack of a unified view of risk and compliancethat limits management’s decisionmakingprocess.
• Lack of scalability from an enterprisewideprospective.
• Duplication of activities and overlappingefforts, which increases cost, internaloverhead and external consultingexpenses.

As Gartner, the IT research and advisoryfirm, said: “Companies that select individualsolutions for each regulatory challengethey face will spend 10 times more on the IT portion of compliance projects thancompanies that take on a proactive andmore integrated approach.”

Building an integrated GRCarchitecture

An integrated GRC strategy must providean environment that allows each GRCprocess to be fully managed independently,while providing tools for defining complexrelationships, and sharing and linkinginformation between the different regulationsand standards.
The goal is not only to generate a maintainableand reusable framework, but toensure, over time, compliance with a listof changing legislative, regulatory, qualityand internal control requirements.
Based on our experience in implementingdozens of risk and compliance projectsin large and fragmented enterprise organisations,we have applied our accumulatedknow-how and expertise to design a step-bystep,practical process for building and implementingan integrated GRC architecture.
The process is suitable for any type oforganisation but was specifically developedfor large enterprises where multipleGRC audit groups and processes werecreated separately over time, and wherethese disparate GRC functions continuedto evolve in parallel, with little interactionbetween them.
One of the critical factors that candetermine the success of incorporating aculture of GRC integration in an enterpriseis having a high-level, internal sponsor.Besides the functionality and technicalobstacles of GRC integration, it can bepolitically difficult to integrate and fosterco-operation between disparate auditfunctions in the organisation. An internalpatron with enough influence can help toovercome the natural internal hardships,objections and frictions that already existand can be magnified when trying to fosterprofessional GRC collaboration.
The process we have designed for generatingan integrated GRC approach iscomposed of four key phases.
The first phase is perhaps the most crucialone, in which we model the integratedarchitecture in a structured, 10-step process.We call this step GRC modelling.
The second phase is defining and implementinga pilot for the integrated GRC architecture.We believe that, in almost all cases,the right strategy for long-term success is abottom-up approach. By this we mean thecompany should choose initially two, threeor, at most, four parallel audit processes tointegrate and focus on a specific subset thatis common to the chosen GRC projects.We have often seen companies decide toimplement a high-level, top-down strategythat encompasses mapping the entire organisationand design a comprehensive GRCarchitecture for most or all of the separateGRC functions. We understand the inclinationto plan a comprehensive and long-termstrategy. The danger lies in that this highleveltop-down strategy can realistically takeup to two years years to develop, while enterprisestoday are subject to internal, marketand regulatory pressures forcing them to bedynamic and undergo rapid change. By thetime the master GRC plan is ready, the organisationand its audit processes have evolvedand the strategic architecture designed nolonger fits the new organisation.
After selecting the audit projects thatwill participate in the pilot, we must definethe pilot boundaries by agreeing to:

• Define concrete pilot objectives.
• Select a subset of the organisation structureand/or sub-processes while ensuringthat both business and IT processesare included.
• Select from one of several scenarios forthe GRC integration
• Define a realistic pilot timeline.
• Designate key participants from eachaudit process.
• Solicit (if possible) the involvement ofthe internal, critical sponsor.
After defining and agreeing to the pilotscope, it can begin. The designated pilot playerstrack and/or implement the first phase ofGRC modelling on the chosen subset (orscenario) based on the timeline developed.
In phase III, pilot analysis and GRCarchitecture modification, the pilot participantsindividually and as a team analyse thepilot results and perform the important,but oft-overlooked, step of modifying theGRC architecture based on the conclusionsof the pilot analysis. Each participant separatelyanalyses the pilot results from twoperspectives: a) how did the pilot perform in relation to the ongoing workflow andfunctionality of the specific auditing grouprepresented by the participant; and b) howdid the pilot perform in relation to the overallobjective of GRC integration, reducingduplications and redundancies betweenthe selected audit groups and improvingthe overall GRC efficiency? The entire pilotteam reviews all the participant results andthen discusses together and agrees to modificationsto the GRC architecture.
Phase IV is the final deployment phase ofthe integrated GRC architecture that wascreated and improved on in the pilot processthroughout the organisation. Phase IVis an ongoing phase that is planned carefullyby the enterprise. The company might beginby continuing to focus on the two to fourselected GRC processes and expanding thedeployment from the pilot subset to a widerscope. Alternatively, the organisation mightdecide to expand the subset of sub-processesfrom the initial scope of two to four awuditprocesses to include more such groups.
We have found that, as the deploymentproceeds, fewer modifications are requiredto the overall GRC architecture. Because itwas designed with a bottom-up approach, theintegrated GRC solution more easily evolveswith time and the scope of the implementationwidens both vertically and horizontally.

10 practical techniques

1. Scoping

As stated above, in the scoping phase wedefine two to four GRC processes, becausethe basis for the integrated GRC architecturewill be built around them.

2. Defining building blocks

Each regulatory process is composed ofmain building blocks such as: organisationalunits, processes, sub-processes, risks,controls, loss events, IT systems, financialaccounts, audit plans and scenarios.
Not all the building blocks are relevantfor each regulatory requirement. Afterdefining the building blocks, we need toassign the right building blocks to eachGRC process. This mapping will be usedlater on to define the relations between thebuilding blocks with regards to each riskmanagement or compliance process.
Table 1 above presents a sample matrixmapping building blocks and GRCprojects.

3. Defining common terminology

Due to the diversification of the GRCmethodologies, adopting a commonlanguage among all GRC projects is acrucial step to avoid misunderstandingswithin the organisation.
Often different GRC project managersare using the same terminology for differentdata information. For example, whenthe Sox manager refers to “process”, he isreferring to a different place in the architecturethan the operational risk manager.
Co-ordination between these two managerscan prove difficult unless they define amutual, common terminology.
When defining a common terminology,it is recommended to define a commonname for each and every data field and toassign each field to one or more relevantGRC projects.


4. Ensuring consistent organisationalstructure

One of the typical mistakes we have seenacross many enterprises is the existence ofdifferent organisational structures for eachGRC process. Variant organisational structuresoften inadvertently cause mistakenassessments that are based on erroneousrisk and control calculations up the organisationaltree.
Obviously, a short scoping process isneeded to determine which organisationalunits will participate in each GRC project.

5. Correlate processes and units

Because organisational processes usuallycross several organisational units, it is importantto define which part of the process isperformed in each unit. This enables organisationsto analyse the information using theorganisational structure perspective.
For example, we assume a human resourcesprocess creates a residual risk of 10 X.
Company A documents this process withno correlation to the actual organisationalunits that are running this process.Company B divided this process intothree sub-processes as follows:
As opposed to company A who has onlymapped residual risk to process, company Bhas the ability to analyse the informationboth from the process point of view andthe organisational structure viewpoint. Thiscan be useful when aggregating all the processesbecause this method easily highlightsthe more ‘risky’ organisational units. Thistechnique also enables us to define more specific and accurate key risk, contextual andperformance indicators to leverage existinginformation for extensive analysis of the data(see point 10 below).

6. Enable high-resolution granularity

According to one of the most famous axiomsin the GRC industry, a correlation of manyto-many between all the building blocksis required to enable integrated GRC. Forexample, it is common knowledge that thereare many-to-many relationships betweenrisks and controls.
This is indeed necessary, but not quiteenough to support an integrated GRC environment.The organisation must be ableto define different, distinct attributes foreach instance of common risks and controlsshared by multiple GRC processes. Acommon control that occurs in two separateGRC processes might be critically importantfor one regulation and less important in theother. The ability to define many-to-manygranularity at the level of each attribute ofeach building block is critical for the successof an integrated approach.
Here is a sample that illustrates the needfor this granularity:
Risk: Purchase-related transactions maynot be recorded in a proper period.This risk has several attributes, such as riskimpact, risk likelihood and risk response,and is found in both Sox and operationalrisk processes.
The qualitative impact of risk when apurchase-related transaction is recordedon say, the January 1, 2008 instead of thecorrect date of December 31, 2007 is differentfor Sox and operational risk.
Since Sox is all about financial reporting,most companies would assign the risk impacthere as high, while from an operational riskperspective, the fact that this transactionrecording was delayed by one day is minor,and the impact would be classified as small.This sample shows us that, to reducethe amount of risks being managed, eachattribute of the risk should be assigned adifferent value in relation to other dimensionssuch as GRC project, organisational processand organisational unit. This requires a highlevel of granularity in the database.
Companies that select a GRC systemthat cannot support many-to-many relationsat the level of attributes will beforced to choose from one of the followingbad options to overcome this limitation:either they will have to documentthe same risk again and again to assign theaccurate attribute value for each project,process or organisational unit, or they willdefine this risk only once with constantattributes in a way that does not reflect thesituation in practice or allow for accurateanalysis and remediation.

7. Designing control hierarchy

To reduce the duplication of controlsbetween separate compliance procedures,the organisation needs tools to definecontrol dependencies intelligently.
Sometimes, a high level control in a regulationmight be identical to a combinationof five controls in another standard. Theability to define such smart links and multilevelhierarchies between risks, controlsand GRC projects is vital to reducing theoverheads of managing and testing controlsacross the enterprise.
For example, a detailed control objectiveof CobiT is ensuring network security,which is a fairly high-level objective. Toensure that this high-level objective is metin the organisation, a number of lowerlevelcontrols must be tested, most likelybased on IT Security standard ISO27001.Each of the lower level ISO27001 controlsmight be effective or ineffective, and indicatewhether the CobiT objective is met.
The system should enable smart correlationsof n-level hierarchy to support thiscapability.

8. Assigning roles and responsibilities

To enable and facilitate coordinationbetween GRC participants, there is a clearneed to define the rights to view, update andmodify shared information.

9. Defining alerts and notifications

To enhance corporate internal communication,it is imperative to automate alerts andnotification techniques.
Typical triggers for sending alerts andnotifications are:

organisational change; process change;redesign of shared control;new risk; successful implementation of remediationtask; andchange of process owner.

10. Leveraging correlative informationbetween the GRC projects

Each GRC unit has its own individualworkflow that might consist of periodiccontrol testing, conducting multi-yearaudit plans or accumulating loss events. Toachieve an overall organisational risk view,information must be shared between thedifferent processes.
For example, the internal audit teamshould receive status of control tests fordetermining the frequency of audit plans bytopic. Loss event information collected bythe operational risk group should be sharedwith other GRC functions.

Summary

The process of building the integrated GRCarchitecture as described in this article canhelp organisations improve the quality of riskand compliance information, prevent duplicatedactivities, decrease costs and create along-term framework for existing and futureregulatory and risk management needs.

Sponsored content