5

Click here to load reader

GRC Reference Architecture- Enterprise Data Architecture and Framework

Embed Size (px)

Citation preview

Page 1: GRC Reference Architecture- Enterprise Data Architecture and Framework

T H U R S D A Y , N O V E M B E R 5 , 2 0 0 9

GRC Reference Architecture: Enterprise Data Architecture &

Framework

GRC – Governance, Risk, & Compliance. Whether you use this specific

acronym or not the fact is your organization does GRC. There is not a

single executive that will tell you that they lack corporate

governance, do not manage risk, and completely ignore compliance.

The truth of the matter: GRC has been a part of business since the

dawn of business.

GRC is akin to CRM (Customer/Client Relationship Management) in the

1980’s. Before CRM systems and processes entered the organization

client information and relationships were still being managed. The

challenge was that they were being managed in scattered silos that

ended up with inconsistent and redundant data with no view into the

entire profile of the client and its interaction with the business. CRM

systems entered the picture to create a single view of customer

information and interactions across business processes and roles. GRC

systems and processes aim to achieve the same thing – to provide an

integrated picture of governance, risk, and compliance information

and processes across the business. To accomplish an integrated view

of GRC requires the establishment of a GRC business process and

technology architecture.

In the next several newsletters I am focusing on the communication of

Corporate Integrity’s GRC Reference Architecture. This GRC Reference

Architecture is party of my broader GRC EcoSystem of technology,

consultants, and information providers (over 1300 firms cataloged to

date). It is also the foundation of the revisions going into OCEG’s GRC

IT Blueprint.

The GRC Reference Architecture is comprised of: a data

architecture/framework, enterprise core GRC application(s),

role/business function specific applications, as well as industry and

geographic/jurisdiction specific applications.

This week we look at the information foundation (from a high-level) in

the Enterprise GRC Data Architecture & Framework. A firm foundation

is necessary to build extensible and agile GRC system and processes.

Page 2: GRC Reference Architecture- Enterprise Data Architecture and Framework

Intricate relationships between different information the heart of a

successful GRC technology strategy. When I was in grade school I loved

it when the teacher had us draw points around a circle and draw lines

connected to every other point resulting in a beautiful geometric

pattern that captivated the eye. The same visual represents the many

to many relationships of GRC information. If you think about it –

policies, risks, controls, events, requirements, enterprise

assets/processes, responsibilities, and objectives all map to each

other. Organizations need to know what policies set management

thresholds for specific risks; what events happened that violated

specific policies, materialized risk, and caused an infraction of a

regulatory requirement; what controls are established in specific

policies and defined to control what risks; which business objectives

are risks related to and how do we monitor controls to stay within

acceptable tolerance levels of risk while aiming for that objective.

The core of a GRC Data Architecture and Framework integrates the

following libraries of information within the organization: • Objective library. This is often the missing piece of GRC. Most

GRC strategies are focused on meeting requirements and putting out fires of risk. However, governance starts with understanding

Page 3: GRC Reference Architecture- Enterprise Data Architecture and Framework

corporate performance, business strategy, and objective management. A good GRC system will define business objectives and cross-reference those to risks, requirements, and other areas of GRC.

• Risk library. The problem with risk management is that it often happens in silos and there is no aggregate view of risk. Organizations need a consistent data framework to define, manage, and monitor risks. This requires that risks be mapped to objectives but also to other elements such as controls implemented to treat risks, events that show where risk has materialized, responsibilities to define risk owners, as well as policies used to establish and set thresholds of risk.

• Control library. Controls establish the fundamental building blocks of a GRC program. They aim to make sure the organization is staying within boundaries of risk and compliance while allowing the organization to pursue its objectives. Controls are in place to protect the organization. A good GRC system will allow for the cross referencing of controls to business objectives, risks, events (control failures/weaknesses), policies, regulatory requirements, as well as the business environment of processes and assets.

• Event library. Whether called cases, events, incidents, issues, investigations . . . the organization aiming for an integrated and efficient GRC system will need a common repository of events and losses that have impacted the organization. This starts with the recording of an event, the documentation on investigation and response, to allocating loss information that feeds into risk models. Events document policies that were violated, actions took, control issues/weaknesses, responsible parties as well as what part of the organization was impacted.

• Responsibility library. Every business objective, risk, policy, requirement, business asset has something in common – an owner. Businesses get into a world of hurt when they do not know who is responsible for what policy, risk, regulatory requirement, etc. Defining ownership of the components of GRC is essential to a successful risk and compliance strategy.

• Policy and procedure library. Policies set the boundaries of the organization – they establish the expected/required behavior of individuals, systems, processes, and relationships within business. At the highest level they articulate values and code of conduct, at the detailed level they tell you exactly where boundaries lie. Policies map to risks to establish risk culture, tolerance, and appetite; they map to events where an organization can see where policies have been violated; they map to controls as specific statements within policies often are the control statements themselves; they map to requirements

Page 4: GRC Reference Architecture- Enterprise Data Architecture and Framework

to meet specific boundaries set forth by regulators; and they also map to the enterprise as policies govern everything from the entire business (e.g., code of conduct) to specific business operations/processes.

• Requirement library. The focus of GRC is to stay within boundaries while achieving business objectives. A central store of requirements from regulators, laws, code of conduct, ethics, values, social responsibility, contracts . . . allows the organization to document what it has to be compliant to. This enables the mapping of requirements to policies, risks, controls, business objectives, enterprise assets/processes, as well as events that identify where a requirement has been missed.

• Enterprise library. No matter what area of GRC information you are looking at it applies to something in the organization. It can apply to the whole organization such as a code of conduct, or a specific business unit, process, entity, business relationship, employee/role, or event information category itself. Organizations that successfully approach GRC have established enterprise modeling to relate objectives, risks, controls, events, policies, responsibilities, and requirements to the business.

Illustration: last week I was discussing the role of GRC applications

and information and how they integrate with a global professional

services firm looking to implement a GRC strategy and solution to

govern their internal operations. They asked – “We have been using

Sharepoint for policy management, does this need to be part of the

GRC system?” My reaction was that this the approach many

organizations take but challenged them to consider the intricacies of

this approach which would handicap their GRC strategy. These

included challenging them if they have a central and authoritative

repository of all policies? Do they have a way to manage the lifecycle

of policies from authorship, approval, communication,

regular/periodic maintenance, training, attestation, and archiving of

policies? Do they have a way to track exceptions to policies? More

specifically to the relationship of policy information – can they map

policies back to regulatory requirements, risks, controls, business

objectives, as well as the events/investigations in which policies were

violated? It was at this point they saw the picture of why an

integrated GRC system adds value across the business silos of risk and

compliance that have gone in different directions in the past.

Page 5: GRC Reference Architecture- Enterprise Data Architecture and Framework

This is just a high-level view of the core data components of a GRC

architecture. Next week I will publish the core enterprise GRC

applications that leverage this data. Detailed training on the GRC

Reference Architecture can be found in Corporate Integrity &

OCEG's GRC Strategy & Technology Bootcamps. !