The promise of governance, risk and compliance technology is alluring, but getting it to work effectively is a different story, reports Alan Earls.
While governance, risk and compliance (GRC) management is nothing new, assembling these three disciplines continues to be challenging – particularly as companies look to optimize their compliance efforts to become more cost-efficient.
The growing focus on GRC as a single, unified framework grew out of the passage of the Sarbanes-Oxley Act of 2002 (SOX) and the requirement for publicly held U.S. companies to devise and implement governance controls to support the compliance mandates of SOX. Risk management, an implicit element in the SOX formulation, essentially came along for the ride, as companies recognized the possibility of addressing these topics from a holistic point of view.
But even if one is unfamiliar with GRC, the reality is that its activities are usually already occurring in one's organization, he says. Internal audit has probably been evaluating processes and controls for years, or IT security has been managing compliance to various access rules. Similarly, business continuity programs are likely reviewing impacts and risks on a regular basis. “Really, any function that assesses a risk, evaluates a control, governs according to a regulation or common framework, or evaluates performance, is addressing a GRC function,” says Patrick Potter, GRC strategist at RSA Archer Business Continuity and Audit, a Hopkinton, Mass.-based information technology as a service (ITaaS) provider.
However, implementing a GRC program can be overwhelming because it can touch every part of the organization, engaging different domains and cutting across many management perspectives. But, the good news is that the pieces do fit together and can integrate successfully, although success varies, says Renee Murphy, a senior analyst covering GRC at Forrester.
She says enterprise-wide acceptance is becoming universal. Typically, she says, one part of the organization will get the ball rolling, whether it is finance, security or some other domain. Once the idea of risk management gets airborne, says Murphy, “the tentacles go out to the rest of the organization and it boils up to become enterprise risk management.”
She says that while implementing GRC is important, learning to leverage it is equally critical. “Many organizations seem happy to simply know what their posture is – for example, relative to risk – but that information can be used to support better decision-making,” Murphy says.
Another obstacle to widespread acceptance is developing a taxonomy that is useful across the organization. For example, risk may be defined in different ways by HR or by the IT department. Having a means to discuss these holistically is important to successful integration.
“You tend to ask yourself, ‘Where do we start?,'” says Potter. It's a journey that can start anywhere in the organization, though only limited progress will be made without some roadmap, he adds.
There are several factors to consider to set the right tone and to bring elements of these disparate processes together to improve GRC effectiveness and efficiency, Potter says. The first step is to establish a top-down approach with aligned disciplines, tools, methods and resources around which all the different groups requiring GRC can rally.
As part of that program, one should be looking at risk in a common way and from a cost/benefit perspective. One of the pitfalls of not doing this, Potter warns, is that if two groups in the same company have different views of risk, one could either underestimate the impacts or, alternatively, develop what he calls a “tempest-in-the-teapot syndrome,” where the company ends up trying to do too much too fast.
“A correct and common cost/benefit view is important because this will drive better decisions and corresponding actions,” he says.
Meanwhile, one must continually refine and improve the program. “GRC is a big undertaking, but one that cannot be ignored in today's world,” Potter says. “It won't be perfect in the beginning, but planning with the destination in mind, the journey will yield results.”
Importantly, though, organizations should be sure to tie GRC efforts – risk in particular – to security, says Forrester's Murphy. “If you see an organization trying to make 1,500 servers and all its data completely bulletproof, that is all well and good, but leveraging risk management to focus efforts more on core processes and data can save you money,” she says.
Still, she admits, “If you go to 900 organizations you will get 900 different definitions of GRC.”
And, it is precisely that problem – the way GRC has become a kind of catchphrase for vendors and consultants – that alarms Paul Proctor (left), vice president and distinguished analyst at Gartner. The idea of linking GRC functions across an enterprise is laudable, but difficult to achieve, he says.
“If your organization lacks the maturity to do it successfully, you are not ready,” he says. For instance, Gartner clients will sometimes pick five to 10 use cases for deployment of GRC across different areas of a company, but will find that over an 18-month timeframe they are only able to achieve success in one of those areas. “Rather than focusing on the top two or three use cases to start, they spread themselves too thin,” says Proctor.
Too many organizations take vendors at their word and believe they can implement everything through a GRC product. But, GRC should be about automating processes that are already functioning successfully. “If you don't already have a risk management process, you can't buy it out of a box,” he says. “The promise of the technology is wonderful, but the execution is something else.”
Proctor says companies often budget too little for implementation. “People will buy a tool and $50,000 worth of consulting services, but when the clock finishes ticking, they may still be wrestling with creation of their requirements document,” he says.
