GRC Implementation Success, Part 2: GRC’s Place in the Business
DoubleCheck Software presents GRC Implementation Success, a guest blog series by Blue Hill Research Principal Analyst David Houlihan. This series draws on five years of Blue Hill studies in GRC in order to highlight key lessons for purchasing and implementing GRC software.
Part 2 of this series looks to the common business role and objectives that underlie the various use cases for GRC. Part 1 examined why GRC implementation success is critical to the success of the overall GRC investment.
“Governance, Risk, and Compliance” (or GRC) can refer to a wide variety of business processes and software capabilities. Each letter in GRC itself refers to a broad swath of operations that can occur across several operational contexts within the organization. We might see GRC in the IT department, in finance, in multiple legal mitigation and compliance strategies, or even as larger roll-up of enterprise risk.
Because this particularized need often drives the software purchase, it can be difficult to divorce GRC’s larger business role from the various specialized uses it might place across an enterprise. Unsurprisingly, the GRC market itself is fragmented and diverse, with many vendors offering similar sets of capabilities to serve various, specialized sets of use cases. As a result, we can break GRC into seemingly endless sub-markets based on function (internal audit, compliance, quality, supplier / vendor governance, etc.) or standards framework (FERC, SOX, KYC, HIPAA, anti-bribery, FDA, etc.).
Essential Elements of GRC
Across these various business use cases, we generally see the same core set of software functionality implemented in some form. Blue Hill has previously identified these core capabilities as:
- Centralized risk data management
- Process and controls management
- Workflow management
- Automated monitoring and alerting
- Automated reporting
In most cases, some combination of these capabilities will be found in a GRC implementation, while the real differences tend to emerge in the content libraries and workflows used.
Figure: Core Functionality Supported by GRC
Source: Blue Hill Research, February 2015
Nonetheless, the host of specializations and use-case-based nuances can obscure the underlying commonalities. Investment decisions relating to GRC thus tend to focus on the instigating point problem (“We need a solution for SOX”). That’s not bad in and of itself, but it often prevents the organization’s understanding of larger business objectives to proceed beyond good intention and assumption. While there are reasons good and bad for this (often the point need is real), it often leaves the organization with a lack of clarity that will hamper its ability to scope and plan the implementation . . . or to accurately assess the total business value.
GRC’s Role in the Business
GRC is used to enhance an organization’s ability to complete one or a combination of the following processes: risk analysis, controls process management, and the generation of reports to serve a variety of business stakeholders.
Often, the use of a GRC platform is a replacement for manual processes and spreadsheet-based information management. In these contexts, GRC is correcting for the time-intensive nature of manual activities or the version control and silos that emerge in manual data management environments.
To see how these dynamics reoccur in GRC implementations, we can review several GRC business cases that Blue Hill has examined in its research:
- Regional North American Utilities Provider: With risk management efforts distributed among line of business management in a decentralized model, the organization needed a platform for the consolidation of risk data to support enterprise risk analysis at executive and board of directors levels. The organization needed to be able to normalize multiple types of risk, facilitate information collection from an “effectively endless” array of reporters, and permit two dedicated staff to meet standard reporting intervals as well as provide real-time insight on request.
- United States Pharmaceutical Manufacturer: The organization’s quality assurance management efforts were dominated by spreadsheets, manual processes, and a “disaster of a file share platform.” As a result, quality reporting suffered from significant wasted effort and FDA and customer audit requests that created significant business interruptions. The organization sought a solution that could integrate with existing knowledge repositories, provide centralized control of documents and versions, and support the management of core processes.
- Global Metals Mining and Manufacturing Company: Spreadsheets served as the organization’s primary mechanism for modeling and reporting on financial risk. Distributed business units used managed local financial risks through manual risk registers in spreadsheets or local ERP solutions with no common risk analysis or reporting framework. After identifying the potential for error generated by manual processes and divergent methodologies, the organization implemented a global enterprise risk platform to provide a centralized source of truth and standardized risk methodology.
- Large European Commercial Bank: Regular vulnerability scans performed by the organization resulted in over 60,000 lines of data that could not be effectively analyzed within the organization’s vulnerability scanners. As a result, the organization exported vulnerability data to spreadsheets to conduct manual categorization and risk analysis. This resulted in lags in time to act on information and opportunities for error, while consuming roughly three days of employee time to compile each report. The organization required a platform to consolidate, categorize, and format data for business reporting.
- Large International Financial Holding Company: A regulatory agency identified the need to implement an automated system for tracking, managing, and reporting on risk within 90 days to resolve an issue. The organization possessed a legacy GRC platform on an outdated version. To upgrade the solution and obtain the required automation would result in failure to meet the terms of the resolution. As such, the organization identified a replacement solution from another vendor that provided the needed functionality and could be implemented within the required cycle.
Essential Business Drivers of GRC
In each of the cases identified above, we can see the same organizational needs at work. From these, we can distill two basic business objectives for GRC investment:
- Reduce operational burdens: Often the objective is to reduce the time and labor associated with performing risk, compliance, and governance tasks. This can involve either (or both) dedicated risk and compliance teams or other business stakeholders that are responsible for supplying information to these teams. Blue Hill finds that the most common area of focus for this objective is in the generation of standard and ad hoc reports for enterprise consumption. In response, Blue Hill’s The Hidden Costs of Spreadsheets in Compliance and Risk Management study found that the adoption of GRC results in between 25% and 30% in time saved in compliance and risk activities. The business can consume the benefits associated with labor reductions in terms of an FTE (full-time equivalent) reduction. However, more often Blue Hill sees these benefits translate into increased labor quality, with time traditionally associated with rote tasks transferred to business-critical and strategic activities.
- Understand or reduce enterprise risk: Improved information centralization as well as standardization and automation in reporting provide improved visibility into the scope and nature of the risks facing the organization. It also reduces the time lag between what is reported and the present business state. The organization thus becomes empowered to act with greater understanding of its needs and becomes more responsive to emerging issues. These factors can help to reduce overall risk exposure. While significant, these benefits are tied closely to the organization’s ability to avoid the occurrence of business-adverse events. Accordingly, it can be difficult to estimate the impact of GRC in these areas.
In most cases examined by Blue Hill, both of these objectives are present to one degree or another. Often, because the second factor is commonly tied to indirect benefits, organizations often focus the business cases justifying investment on the potential labor impact. The risk impact thus tends to become an added benefit that does not need to be tracked to demonstrate the “success” of the investment.
For organizations planning GRC investments and implementations, these dynamics play a crucial scoping role. Application costs, implementation project scope, and related factors should be tethered to the short-term operational upside the organization believes it can obtain. Without these boundaries, the organization can easily fall in the trap of over-engineering its solution or failing to give enough attention to factors that can cause an implementation to extend indefinitely.
As we’ll see in Part 3, precision in business requirements is the single most important factor in obtaining this balance.
Next, we look at: Defining Business Requirements for GRC.
Before this, we discussed: Why Implementation Success is Investment Success
