Six remedies to curb your GRC implementation fears

This article is a part of Risk Update 3. 

GRC solutions can enhance and even automate some of an organisation’s risk management capabilities and practices, but their implementation often appears challenging. However, with the right planning, team, access to data and a focus on the end-user, a great outcome is achievable.

1. Define key Risk Management frameworks and processes in advance

It is important to understand the business context before defining your list of functional requirements or user stories. Agreeing the frameworks, processes, and ways-of-working that your GRC solution will need to support will enable you to assess options and scope features with confidence. Taking a solution out-of-the-box is preferable for ease of maintenance and support, but may not meet your functional Minimum Viable Product (MVP). Defining your key Risk Processes, reporting requirements and having a prepared risk and control taxonomy in advance will help you clearly articulate MVP, support your market evaluation, and enrich conversations with key vendors. If possible, ask vendors for a Sandbox, and test out how your key processes and risk and control libraries will be uploaded and executed out of the box, and what customisations may be required.

2. Focus on the end user and their experience

A great GRC solution will support risk management and compliance across all three lines of defence. However, these tools are often highly bespoke and not intuitive for users that are unfamiliar with GRC concepts. Define your end user personas, starting from risk and non-risk users. This will help build out user journeys, support your functional requirements and even form the basis for your security and access permissions. Focus on what your users will need from the GRC solution and what the easiest way will be for them to meet these needs. There is often an over-reliance on risk teams to maintain GRC data, so enable your business stakeholders to take accountability with a well-designed user experience. Practically, this means involving your end-users during the build by demonstrating the solution within a Sandbox, and their participation in showcases and User Acceptance Testing.

3. Consider key data sources and leverage integration

If you want more than a glorified spreadsheet, consider how you can use data to drive informed risk decision making. This may include leveraging risk and control libraries or internal asset inventories (such as Configuration Management Databases) and Service Management tooling (such as those used to track IT change, incident, and problem management). Some GRC tools offer low/no code integrations or alternatively may natively integrate with systems your organisation uses to manage key controls. Centralisation of incident data can be achieved through integration with disparate systems containing non-IT incidents (e.g. fraud and WHS/HR), and workflow systems which track remediation activity. Understanding key data requirements and selecting a tool that allows you to access these will help when defining risk profiles, automating controls assurance and monitoring compliance.

4. Define a legitimate MVP and iterate

Like any system implementation, the modular nature of GRC solutions make them great candidates for iterative development. Even if you are implementing functionality over time, you can get value from your solution immediately. For organisations without an existing GRC solution, define the MVP to get your team up and running. For those moving off an incumbent, you may want to focus on ensuring that existing functionality is workable and introduce new features progressively to avoid complexity. Aside from this functional approach, the MVP can also be structured according to departments and depth. In the case of a departmental approach, some choose to roll out their GRC solution to certain teams (e.g. IT) first, before the rest of the organisation. Slicing the implementation according to depth means deploying your risk processes (e.g. risk profiling) one organisational level at a time.

5. Get the right mix of skills in your implementation team

We have found that it takes dedicated and experienced resources to support a GRC implementation. If you are planning on using an external delivery partner, your risk teams should be supported by Business Analysts and Product Managers who understand risk management, and if possible, have experience with the chosen solution to challenge and validate design decisions. This will allow you to define detailed functional requirements and get the most value out of your delivery partner, all while your business as usual Risk Management team can get on with supporting the business.

6. Limit complex workflows

The configurable nature of GRC solutions gives organisations the ability to build out highly complex workflows. It is tempting to customise business rules, approval requirements and security controls to manage how records are created, assessed, reviewed, and endorsed. In our experience, defining repeatable, flexible MVP workflow requirements for key objects will greatly decrease delivery complexity, improve the user experience, and assist operations teams in defect troubleshooting. As well as these, fewer customisations will often make upgrade pathways easier and quicker to implement. When vendors release patches and major platform upgrades, builds which are closer to out-of-the-box are easier to digest and typically have fewer functionality clashes and demand lower effort for verification testing.

Amstelveen Risk Update: Edition 3, June 2020

Download the article