GRC Implementation Success, Part 8: Future Proofing GRC
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 8 of this series examines non-technical factors that cause GRC platforms to lose their usefulness over time and a few areas of inquiry that can be taken to help extend the life of your investment.
In our previous posts when we’ve looked at what contributes to an efficient and effective implementation, we’ve largely been asking about the initial implementation process itself. In other words: how quickly can we put the technology required in the hands of our stakeholders without incurring unnecessary costs. For the final post of this series, we’ll explore what implementation effectiveness means in terms of extending the lifetime of the platform investment.
How Does a GRC Platform Stop Delivering Value?
A GRC platform investment occurs at a set point in time. It represents an organization’s attempt to solve a particular set of risk and compliance management needs. While it might seem to go without saying that these needs change over time, too often investments in GRC platforms fail to consider how the changing nature of compliance and risk management will impact the useful lifecycle and value of the solution. The result is often that the platform that is deployed becomes too static, inflexible to be able to accommodate new requirements and business contexts that emerge over time.
Too often investments in GRC platforms fail to consider how the changing nature of compliance and risk management will impact the useful lifecycle and value of the solution.
Blue Hill typically observes two sources of business change that impact GRC’s value in interviews with research participants.
The first category stems from changes in the legal frameworks, standards, and emerging risk sources that impact that business. Changes in these areas necessarily impact compliance and risk management activities, impacting the scope of these activities, as well as the processes, stakeholders, controls information types, and workflows that are managed within the GRC platform. When the GRC platform is deployed and configured too rigidly to the original process, and requires hard-coded changes and extensive effort to accommodate the new needs, then these changes can have a critical impact on the utility and value of the GRC platform. As an example of this sort of change, in Part 2, we identified how a Large International Financial Holding Company was forced to invest in a new GRC platform after it determined it would be unable to address shortcomings in its legacy GRC platform found by a regulatory agency in light of new guidance within with the time required by the agency.
Category Two results from changes in organizational attitudes and expectations for the impact of governance, risk management, and compliance management activities. These sorts of shifts can represent no more than a simple change in organizational scope, such as an attempt to centralize and consolidate siloed GRC activities. To this end, Part 2 described how a North American Utilities Provider seeking to obtain an integrated risk management view across its multiple GRC activities found it needed to purchase a new GRC platform after determining that none of its multiple legacy GRC tools could be expanded beyond the initial siloed functions they were deployed to support. Organization-based changes can also involve changes in organizational strategy, such as when an organization begins to seek cross-enterprise roll-ups of risk prioritization to drive strategic problem solving in place of task- or program-based reporting. In these cases, organizations often find that the deployed capabilities of their GRC platform are unable to support the altered use case.
Of course, periodic technology obsolesce and refresh are normal components of the IT lifecycle management. What’s important to observe about scenarios above is that they have nothing to do with the technical sufficiency of the platform to continue to support the initial, intended purpose. Rather, in these scenarios, the end-of-life of the platform occurs because the technology deployed cannot be adapted to support changing business needs in a way that is more expedient or cost-efficient than a net-new technology purchase. When these scenarios occur, they serve not only to erode the lifecycle value of the original investment, but also generate new and potentially unnecessary expenses.
Periodic technology obsolesce and refresh are normal components of the IT lifecycle management.
Evaluating Solutions with an Eye on the Inevitability of Change
An organization loses the opportunity to avoid scenarios similar to those discussed above as soon as it begins deploying a new solution. In other words, ensuring a GRC platform is flexible enough to address future needs represents a core component of the vendor and solution evaluation process. To this end, in Blue Hill’s case study detailing KBR, Inc.’s GRC implementation (and which has been highlighted throughout this series), we observed how the flexibility to accommodate change in organization, process, and control wordings received “high priority” in KBR’s investment planning. It is this expansion in evaluation scope to include non-functional components that will promote the long term flexibility of the platform which will help safeguard its value.
If the notion that the business requirements and context addressed by GRC will inevitably change, why is it often difficult for organizations to assess for this sort of application flexibility. One piece of the answer lies in the dynamic we discussed in Part 2 where GRC platform investments are often driven (and justified) by immediate pressures experienced by the business, sometimes resulting from a recent event or recognized vulnerability. As a result, GRC investments are often tightly constrained to evaluations of functionality, based on a point need. It takes an expansion in scope as well as an awareness of how application architecture and other non-functional components will impact the long-term viability of the solution. It’s for this reason (among others) that Blue Hill’s Contributors to GRC Implementation Success: Avoiding the Worst-Case Scenario benchmark emphasized that early involvement of IT stakeholders in the investment planning and solution evaluation stages represented an important contributor to implementation success.
A Second Look at Application Configurability
We’ve touched on some aspects of the non-functional capabilities that impact GRC platform flexibility previously in this series.
In Part 5, we discussed the role that application configurability plays in deployment timelines. At the time, we mentioned that application configurability also plays a role in ensuring that the platform can be adapted based on changing organizational needs. It is worth underlining a few of those points in the context of future-proofing the GRC platform.
It cannot be overemphasized that changes that can be made via in-application configurability are exceedingly easier (and more cost-effective) than those made by hard-coded changes and customizations (to say nothing about new software purchases). It is also the case that configurability has limits as well. An application can only be configured to pre-designed states.
This adds to the importance of taking a deeper look at the depth of configurability possible within the solutions an organization evaluates. Blue Hill’s GRC Vendor Implementation Success Strategies identified five elements: (1) data elements, (2) data relationships, (3) workflow, (4) user interface, and (5) reports and dashboards. A platform that can be configured between several different modules and/or data management templates will be less flexible over time (and more reliant on the vendor’s approach to problem-solving) than a solution that permits configurability at the data element and data relationship levels. Understanding the scope of configurability that will provide the flexibility that the organization is likely to need will help to ensure that the platform will be able to continue to address even unforeseeable changes.
Table: Configurable Elements of GRC
Anticipating Changes in Information Needs
We can restate one facet of the organizational sources of change that we discussed above as “demand for new and different kinds of output from the GRC platform.” Arguably, the primary role of a GRC platform is to provide a record-keeping and reporting mechanism for a compliance or risk management function. Often, this involves producing regular and ad hoc reports about risk status, controls implementation, and other task- and program-based activities within a siloed use case. In fact, replacing manual, spreadsheet-based information collection and reporting activities is often a core business justification GRC investment. It is also one with a clear, quantifiable impact, with Blue Hill’s The Hidden Costs of Spreadsheets in Compliance and Risk Management study finding that the use of GRC to automate these sorts of manual processes results in between 25% and 30% in time saved in compliance and risk management activities.
When an organization’s GRC reporting and information needs change, it creates the same questions that have been discussed above. Reporting automation based on inflexible templates or that require hard-coding to change become excessively difficult and expensive to adapt to new requirements. These issues are often unlikely to rise to a level that requires a new GRC platform investment, but can require a return to manual work and information analysis that frustrates the purpose and value of the GRC investment.
These dynamics are exacerbated when business leadership begins demanding deeper, strategic insight from GRC programs, including requests for analysis, such as cross-enterprise risk scoring, trend analysis, or forecasts of exposures or operational resource requirements. The automated reporting capabilities within GRC are generally used to understand current or historical performance, based on the data managed within the platform. As a result, responding to demand for enterprise-level insight can result in even more manual analysis or, again, result in the need for new software investments.
Embedded business intelligence (BI) or analytics capabilities within the GRC platform can help organizations to accommodate a shift toward these sorts of information needs.
Blue Hill’s Four Components of an Enterprise Risk Reporting and Management Platform report has identified how core aspects of analytics tools, such as the ability to draw connections across data, roll-up conclusions, or drill down into underlying factors are intended to address exactly these sorts of information needs, assisting organizations to identify connections and trends across data components. Because these tools are developed to facilitate data processing and analysis, they are also often able to support greater ongoing adaptability to information generation needs than more inflexible reporting automation capabilities.
While there is no surefire mechanism that will ensure that a GRC platform will be able to accommodate all future needs, attention to the depth of underlying components such as the analytics tooling and the application configurability, will go a long way to helping an organization to maximize the value that can be realized.
This concludes the GRC Implementation Success guest series by Blue Hill Research.
Before, we discussed: Why implementation success is investment success
GRC’s role and value contributions to the business
How robust business requirements must drive technical requirements
The “Show Me” approach to vendor assessment
Application tailoring without extended deployment
The role of cloud delivery models play in the deployment cycle