Getting The Most Out Of A GRC Platform

Conference track sessions and talking heads may tout the importance of instituting technology-backed governance, risk, and compliance (GRC) processes that integrate the G, R, and C. But the truth is that when the rubber meets the road, most organizations still use GRC platforms for only a single domain.

In order to get the most out of their GRC technology and risk management programs, organizations still have a lot of work to do in developing more comprehensive and harmonized risk measurable, and bringing together IT risk professionals with enterprise risk stakeholders to ensure the whole team is on the same page.

"I think people aren't getting the most bang for their GRC buck from their solutions because they still remain underutilized," says Scott Wisniewski, head of the GRC technology practice at consultancy Protiviti. "They're focusing more or less on a single domain -- just for Sarbanes-Oxley compliance or internal audit and so on -- instead of bringing in other disciplines and start to leverage the efforts."

According to Michael Rasmussen, an analyst for GRC 20/20, at the moment 80 percent of GRC platform purchases are made to solve specific problems.

"Less than 20 problems have an [enterprise GRC] strategy, but even those have multiple vendors," he recently wrote. "I would state it is less than 5 problems that are truly trying to consolidate on one platform."

It's not to say that such a "single-threaded" purpose for a GRC platform won't offer ROI, Wisniewski says.

If you have some decentralized organization and are trying to comply with SOX or other compliance demands in a decentralized organization, trying to manage that through spreadsheets can be difficult. That's why there is good value in using a system just even for that one effort," he says.

[Wish you could tell uour CEO, 'I told you so'? You're not alone. See Airing Out Security's Dirty Laundry.]

However, the question to ask is whether those same platforms could deliver even more value.

"IT risk management programs are largely reactive and compliance-driven. However, further evolution of GRC processes, such as data mining and modeling, could transform a company's risk management program into one that drives action, facilitating process improvement and re-engineering, ultimately resulting in performance gains," says Steve Schlarman, eGRC solutions architect at RSA.

Squeezing those additional returns requires enterprises to ask the fundamental question: What are the organization's higher-level GRC goals?

"Are they looking to optimize their assurance coverage and their cost structure so that they can reduce gaps overlaps? Do they want to reduce operational loss incidents so they can lower their total cost of compliance? And then moving up the chain, do they want to actually move into effective allocation of their assets, resources, and decision-making through more performance-centric activities that they're conducting overall in their program?" says Wisniewski. Asking those questions first, he says, will determine how organizations will seek to use a GRC package to help them attain the goals and may better define which platform to use if the enterprise has more than one in use.

Going through that initial analysis separate from any discussion of platform capabilities will also help the organization make a classic mistake in GRC.

"The first mistake is having the tool define the process," says Torsten George, vice president of worldwide marketing, products, and support for Agiliance. "We have seen that a lot of organizations view it as an afterthought that business process management change is part of the implementation of GRC tools. And that really leads a lot of times to failed expectation, to cost overrun, to failed projects."

To answer those questions and start moving forward with plans to better use GRC platforms, enterprises must bring all of the stakeholders to the table, including senior executives. Without that, it may be difficult affect meaningful change.

"The initial people who may have purchased the GRC application may not necessarily be the beneficiaries of integration. Suddenly they have to share their sandbox with others that used to just be wholly their own," Wisniewski says, explaining that they may not be willing to jump on board without leadership pushing for greater integration.

If one of the goals of the steering committee is to better integrate risk management activities into the mix, then one of the next key steps is to better work toward harmonizing risk nomenclature and measurements across the organization.

"You want to start with development of this consolidating risk framework that's going to consist of GRC business entities that you're tracking, the different types of objectives for different groups," Wisniewski says. "IT might have COBIT-related objectives, while risk management might have more risk categories in their risk modeling. They're going to have to look at this universe of their taxonomy and start to develop a common language out of it."

Without finding ways to describe and measure risks similarly across the organization, the GRC platform will not be able to offer a centralized view of risk, George says.

"It's important outside of the tool to define your processes, to define your nomenclature, and then insert it into the tool," he says. "The tool will not take away from the task."

At the same time, enterprises should understand that there is no magic risk number and that harmonization may not necessarily mean homogenization of risk measurable. Rather than coming up with a totally uniform measurement of the value of risk, focus on specific units of measurements that can be managed to reduce overall risk, Wisniewski suggests.

"Where I see organizations sometimes challenged is that they're trying to come up with some big risk number that relates to every type of risk they might have. It's hard to achieve," he says, suggesting that performance-based metrics are a better intermediary. "On the business-continuity side, we're going to measure the number of key server outages we had. Once you start to put that in a metric of an established threshold, without necessarily saying that I've measured the value of this risk, you can start to manage this because you know that something has tripped the threshold in its own specific unit of measurement that is alarming to the business. "

This kind of work is not easy, and George warns organizations to avoid trying to "boil the ocean."

"Our recommendation is always, let's focus on one use case, get this right, and get really grow with it, take small steps," he says.

That is likely why analysts with Forrester said that in spite of everything, organizations shouldn't be overambitious about what they can do with GRC programs and automation technology just yet.

"We shouldn't be too quick to expect high levels of automation, broad standardization, or real-time reporting any time soon. Looking ahead to how these technical capabilities can deliver such promises is important, but too much attention can distract from some of the basic elements of GRC that are often still underdeveloped in your organization," wrote Chris McClean in a recent report. "Concentrate on the fundamentals of process guidance, terminology, and scope of involvement, and be selective when planning your investments so you can show incremental value over time."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.