GRC tool selection starts with a clear understanding of business goals

Determining an organization's IT GRC tool needs must begin with an operational assessment of the process or problem the business is trying to address.

This Content Component encountered an error

Although it seems counterintuitive, having too many choices can actually make a decision more difficult. Psychologists describe it as "decision fatigue." It's a phenomenon whereby decisions become more stressful, and also more difficult to make, because of increased choice.

Anybody considering the purchase of a tool for IT governance, risk and compliance (GRC) can probably relate.

The fact is there are a lot of products under the IT GRC umbrella that provide a diverse array of features. The downsides to this are obvious: It can be challenging to make a purchase because not all products fit every need, and tradeoffs sometimes need to be made because not every product does everything equally well. But those with a clear vision of their specific goals can probably find a product that does what they need.

Understanding the specific business problem you're trying to solve is a critical factor when you're purchasing an IT GRC solution. Understand that problem clearly, and chances are good you'll find a product to address it. Understand it poorly, and you'll likely find product selection difficult -- not to mention that you'll likely regret your choice down the road.

Coming to a clear understanding of the business problem you want to solve can be harder than it sounds, as no two organizations are the same when it comes to GRC. Your risk management and compliance problems are likely very different from those of other organizations. Why? The reason has to do with the nature of IT GRC itself. GRC rests at the intersection of three unique disciplines -- IT governance, IT risk management and compliance, which makes it three times more likely there will be deviations in how organizations manage these areas. Even the disciplines themselves have varying business interests and areas of focus.

The key to approaching the IT GRC marketplace is having a concrete understanding of how you wish to employ the tool and what particular challenges you intend to use it to solve.

"Governance," "risk management" and "compliance" are not identical disciplines; in fact, in some cases they can be at odds. The point of GRC as a unifying concept isn't to squeeze the three into one. Instead, it's about recognizing that they have related concerns, and therefore, managing them synergistically and viewing them holistically is advantageous. The GRC products marketplace reflects this: Some tools might be more risk-focused, with corresponding capabilities supporting those activities. Others target the other two areas of the triad.

The question to ask is, "Which of your business problems will an IT GRC tool support?" Though it might sound trite, the key to approaching the IT GRC marketplace is having a concrete understanding of how you wish to employ the tool and what particular challenges you intend to use it to solve. To best determine that, you first need to understand enough about your own organization -- and the processes you currently follow -- to be able to spot the weak areas. This will help you to see where a solution might fit.

GRC maturity and automation

To perform this critical self-examination, it's helpful to look at both the level of effort that goes into your GRC processes and the maturity of those processes.

How does a typical organization without automated GRC capabilities keep track of and manage GRC activities? Often, it's by complicated spreadsheets. For compliance, those spreadsheets might map overlapping regulatory requirements together, and demonstrate how meeting these requirements influence corporate policy statements. For risk practitioners, they might be used to conduct risk assessments, to track mitigation activities and to perform risk calculations. In the governance world, they might be used to manage service-level agreements, to direct performance toward strategic and tactical goals, and to map those goals to specific technical initiatives.

Don't get me wrong: Spreadsheets have a place, and sometimes they really are the best tool for the job. But they also require a high level of organization and discipline because they need to be updated regularly. Also, input and reporting are usually manual.

Even if the specific methodology isn't a spreadsheet, but instead a general-purpose office tool such as a Word document or database for these tasks, it still requires staff to be disciplined. They need to remember to keep the office tool updated; they need to keep track of critical event dates; they need to remember to follow the process -- and, in fact, understand what the process is.

Also, keep in mind that when multiple stakeholders are involved, there are usually multiple versions of artifacts extant at the same time, all with varying degrees of accuracy, completeness and relevancy. As a consequence, how resilient are these methods? How consistent is their output from iteration to iteration? How easy is it to understand the quality and effort associated with a given output?

More on GRC Technology

Take stock of the weak areas in your IT GRC processes. As you better understand what your specific processes are, take note of where they might fall short of ideal with respect to maturity, and where they might require significant effort to maintain. You can start to see the areas where specific GRC tools could potentially shine by taking note of the business problems you might want to address. These tools provide a framework upon which to rest your GRC processes and provide some level of automation of them. If chosen correctly, GRC tools can decrease your maintenance, are resilient to attrition and provide consistent output. They can also increase your GRC processes' overall maturity.

As I said initially, the specific GRC problems you have will be unique to you. But through automation, IT GRC tools can shift attention away from the mechanics of the processes themselves, such as recordkeeping, data collection, reporting, and, in some cases, data analysis. Instead, you can focus on what matters: the output of the GRC processes and the business decisions you make in response.

ABOUT THE AUTHOR:  Ed MoyleEd Moyle is director of emerging business and technology at ISACA. He previously worked as a senior security strategist at Savvis and a senior manager at CTG. Before that, he served as a vice president and information security officer at Merrill Lynch Investment Managers.

This was first published in July 2013

Dig deeper on Compliance policy management software

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Related Discussions

Ed Moyle asks:

Is your organization looking to purchase new IT GRC tools?

0  Responses So Far

Join the Discussion

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCIO

SearchHealthIT

SearchCloudComputing

SearchDataCenter

SearchDataManagement

SearchSecurity

Close