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.