- Risk Transformation
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.
What is GRC Software?
Governance, Risk and Compliance (GRC) solutions assist organisations to consistently implement and maintain risk and compliance frameworks, processes, and procedures through the centralised management of related data stemming from risk activities. GRC tools provide a platform to manage and understand risk exposure across organisations. Choosing and implementing the right GRC tool can be difficult, as the organisation’s needs and circumstances must be considered, as well as the tool’s capabilities in meeting these.
Why can it be difficult to implement?
Traditionally, these solutions involve complex, long running implementations that cut across multiple business functions. Aligning delivery priorities and requirements across differing core business units as well as group/corporate functions like Finance, Security, Technology, Legal, Compliance and Audit is challenging enough, before consideration of the consolidation of multiple pre-existing toolsets, data-migration and the integration of different systems.
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.