One of the biggest debates over the last few years among many technology, security and auditing professionals concerned with what is turning out to be a rabid focus on Risk management is, ‘Why should we integrate processes supporting Governance, Risk and Compliance?’ Let’s break it down and take a look.
Governance by itself is one thing. It’s all about aligning policy with business intent, and driving that accountability into the day to day fabric of the organization. Which, of course, can be a real challenge.
And Risk is another – it’s all about managing exposure within your organization’s appetite, if you are blessed enough to know what that is. Many don’t because there are mini-universes of processes, assets and requirements.
And well, Compliance, is something else again – it is all about internal controls, and testing for design and effectiveness, (it either works or it doesn’t) whether they are in place to satisfy business or regulatory requirements. They Pass or Fail, which is much easier.
The question I am often asked is, so why the big hoo-ha on putting them together? Why G+R+C?
The stock answer is synergy, of course. ‘There are overlapping processes underlying G, R and C and we can lower costs and improve our business if we manage them holistically’. Yes, yes, yes, but seriously, Why?
Seeing, Understanding and Believing
So begins the debate. And a good debate it is – because as it turns out, this is a problem that really does need to be solved. (People who really understand these topics will be at a premium in the industry before too long). A few years later we are emerging from our probing and are starting to connect the dots. The basic answers to why are starting to become clear and I think we can now name them in a very clear and simple way. The first is…
Seeing. We need visibility and transparency. In order to have this, the line of sight from business or regulatory requirement deep into embedded controls has to be relatively unbroken and unobstructed. That doesn’t mean we have to conduct business inside straight lines, but we do need the technology to ‘see around corners’ – more to the point, into and through the web of our hyper-extended, deeply-stacked, dynamic, complex and increasingly virtual organizations. That doesn’t mean we have to conduct business inside straight lines, but we do need the technology to ‘see around corners’ – more to the point, into and through the web of our hyper-extended, deeply-stacked, dynamic, complex and increasingly virtual organizations. Simple pie charts aren’t enough. More often than not, that technology will be visualization and analytics, where we can literally see a model, heat map or trend line and use the combined power of our intuition and analysis to gain the insights we need to construct better decisions. Here we take a lesson from business intelligence and apply it to GRC. We see the key risk indicator (KRI) on the order management process or system approaching a service level agreement (SLA) threshold, and we drill down, slicing and dicing through the stack from the application layer to the network and server technology assets and controls to the root cause. But that drive to the right decision is not possible without….
Understanding. We need context. Too much information and we will get lost. What are we seeing and how important is it, really? What is the contextual relevance? If it isn’t tied somehow to the key risk indicator (KRI), why get distracted? Or, if I can’t drive change with this view – why look at it? What’s the real impact? That is why we GRC people are so obsessed with mappings. We need it to provide contextual relevance. We know that seeing absolutely depends on being able to traverse the web in many directions, through requirements, policies, processes, controls, inventories, measurements and metrics in a meaningful way – we depend on classifications and mapping to give us that context. Mappings today are mostly explicitly made – take a regulation like the Payment Card Industry Data Security Standard (PCI), and use a wizard to associate it with the correct policies that support the control, say, for monitoring the network. Explicit mappings are fine in relatively stable world. But as our environments become more complex, and more dynamic, human beings can’t keep up with manual mappings. Increasingly the technology will be inference engines, where many associations are made dynamically, based on rules and transitivity (A is connected to B and B is connected to C so A is also a connected to C….). Here, we will take our lessons from inference and modeling systems. I know of a CRO that told me ‘I need to pull the thread – whether it is PCI or SOX or the latest risk exposure – and know – very quickly where the problem truly is..’ and of course, not come back with a ball of knotted yarn. And that is not possible without ….
Believing. We need to know that what we are seeing is not only in context, but that it is based on fact. That it is true. We can’t make a call to block traffic, take down a service for an urgent change or to protect critical assets against a breach unless we are pretty darn sure of the potential impact if we do not. So we need empirical evidence that is fresh enough to make the call. Not survey results from six months ago on a control that has gone through a partial overhaul and has not been retested. We need to be able to drill down from the regulation, the KRI or business requirement, through the web into the real information. Increasingly the technology will be our real-time monitoring and management systems: We will take our lessons from network resource management, storage management, document management and virtualization management systems, to harvest that critically ‘true’ information for GRC.
All of this, so we can believe what we see and understand what we need to do to make it better, before we act. When we have all three – seeing, understanding and believing - it is possible to create the cultural impacts needed to have to make GRC a living, breathing entity. Like it or not, just like the human system, these three fundamentals are interconnected and interdependent and needed to articulate and manage the whole picture. And that, bottom line, IMHO, is why we have the +’s in G+R+C.
Yo,
A good start and some interesting thoughts . . . however, I do have a few differences.
The one thing that I really see differently than yourself is the statement that compliance is all about 'internal control.' From someone facing SOX compliance this is often the perspective. If you ask any Chief Compliance Officer and they would state otherwise. Compliance is about understanding and staying within boundaries. These are the mandated boundaries of laws and regulations, as well as the voluntary boundaries of culture, ethics, code of conduct, values, and social responsibility.
For compliance to function well it needs to understand the boundaries and define and and apply policy to stay within those boundaries. Internal controls are just one element of what fall out of policies and procedures that monitor the 'state of compliance' within an organization.
Internal control tends to be black and white, while compliance often deal with shades of grey. Compliance is also interested in investigations, as well as conducting risk assessment for possible misconduct. The framework, in the US, that a compliance program adheres to has been established by the United States Sentencing Commission with its Organizational Sentencing Practices - which many of the regulators have adopted as well. It describes 7 core elements of what a good compliance program looks like and they go beyond internal control.
Below is a related response to a similar discussion I have had on my blog:
http://corp-integrity.blogspot.com/2009/07/who-defines-your-corporations-values.html
I appreciate your comments, but disagree with your points. Particularly the latter one on which you suggest replacing Compliance with Control in the acronym GRC. This is a mistake I see many in the audit community making.
Control is something that flows out of a compliance process. Granted, having controls in place can put someone in a state of compliance (being compliant). However, the compliance process is much broader than this.
The compliance process, contrary to your post, is more than external requirements. Compliance is about complying to internal policies and procedures - not just regulations. In fact, the OCEG definition of Compliance specifically references the nature of compliance to both mandatory boundaries (external) of laws and regulations as well as voluntary boundaries (internal) of social responsibility, ethics, code of conduct, risk tolerance/appetite, and other areas. Compliance is also about staying within bounds of risk tolerance and appetite.
Compliance itself (not the state of being compliant) is an umbrella process that control is a sub-component that falls out of it. Much of compliance is about interpretation - and that gets down to corporate culture. It is about understanding vague laws and regulations and defining the right controls to meet requirements. It is about establishing ethics, values, code of conduct, and broader corporate social responsibility and making them a part of business and operations.
Compliance is much broader than control. When I think of control I think of something that has been defined. Something that is binary, or black and white. Compliance often deals in grey and the organization processes requirements and culture to determine controls that end up (hopefully) in the state of being compliant.
Posted by: Michael Rasmussen | 09/14/2009 at 11:24 AM