THURSDAY, NOVEMBER 5, 2009

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.
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
 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
 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.
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.
!