Robert Kugel's Analyst Perspectives

My colleague Mark Smith and I have frequently commented on the artificiality of the emerging software category governance, risk and compliance (GRC). To be sure, once stand-alone categories of software (IT governance, audit documentation and industry-specific compliance management, to name three examples) have started what I expect to be a long convergence process. Moreover, since just about all controls and risk management efforts require a secure IT environment to be effective, there is a growing interdependence between effective IT governance and everything else connected with enterprise GRC. The main issue I have with the GRC label is that many of those in IT departments may think it makes sense to adopt a GRC platform or standardize on a vendor for all this. From an operational perspective, GRC is far too amorphous and decentralized for that. I believe that today and for at least the next several years it makes more sense to base software purchases on the specific needs of users rather than the supposed convenience of buying a single GRC platform for a company. Odds are that such a unified platform will constrain an organization’s overall ability to manage governance, risk and compliance even if it is more efficient. Companies face two basic technology challenges as they try to automate and manage their governance, risk management and compliance efforts. One concerns vendor selection: As in most purchases, there is a general issue of what software best balances the trade-offs between current business requirements, existing infrastructure and (perhaps) longer-term standardization objectives. The second issue, related to risk management, is data availability. Financial services companies can have sophisticated risk management systems because the definitions of risk for banks, insurance companies and the like are well established, the data needed to measure it is readily available and automation of controls is mature (although by no means perfect). In other industries, automating risk management is more complicated because the data needed to measure and control risk may not be collected already, it may be difficult for a company or business unit to define or quantify risk metrics, or both may be issues. At this point, I believe that governance and risk management for IT departments are further along than in other parts of the business because decades of work has been done to define standards and ensure that environments are secure and controlled. I expect many IT departments (as opposed to others) will find comprehensive solutions available to automate, measure, manage and optimize their governance and risk management efforts, and therefore IT may find that focusing on a limited set of vendors is both possible and practical today. That is not so with the lines of business and general corporate management. Many compliance requirements and the software that addresses them are specific to an industry or department. Thus, at this point, I see little value – and potentially much harm – in looking for a “platform solution” to these varied needs. As for risk management, today’s reporting, analytics and BI technologies are adequate to support these efforts. The initial challenge is less about the tools than the fundamentals of risk management. An array of questions arises as soon as we start to think about this. What are the key risks? How should they be measured? Is data available on which to base the measurement? If not, how can it be made available? How can risks be mitigated? What is the corporation’s risk tolerance? When risk events occur, who should handle them and how? In many companies, people understand the risks that face their part of the business, but this knowledge is tacit, not explicit. Therefore one of the first steps in maturing risk management in an organization is “simply” performing a comprehensive key risk definition program. (Of course, there’s nothing simple about it.) A follow-on step is to ensure that executives and managers define and understand cross-functional risks, those where a risk event in one part of a company can have a parallel or follow-on impact elsewhere. (For example, failure to get a building permit to complete construction of a new store will affect inventory requirements until the delay is resolved.) Once past these steps, the next is to agree on what data must be collected, how and by whom. For some companies, this may be relatively easy to complete. But I expect that most midsize or large companies will find that building out risk management metrics and gathering the data will take years. Risk management, controls and compliance with laws and regulations all are essential to good corporate governance. A category of software that supports these functions will benefit companies by making their compliance efforts more efficient and their risk management more effective. Even so, it’s important for executives and managers, especially in IT departments, to understand that there is no single product suite for enterprise GRC yet and that for the next several years, less overarching business needs must be the focus of GRC software purchases. Best regards, Robert Kugel – SVP Research

Robert Kugel's Analyst Perspectives

The Value and Limits of the Term “GRC”

Our Analyst Perspective Policy

Our Analysts

David Menninger

Jeff Orr

Keith Dawson

Mark Smith

Matt Aslett

Matthew Brown

Robert Kugel

Stephen Hurrell

ISG Software Research

Subscribe to Email Updates

Posts by Month

Posts by Topic

Analyst Perspectives Archive

Company

Resources

Helpful Links