How to Achieve an Agile and Aligned GRC Program

The thought of implementing a significant change of any kind across an organization is daunting. When it comes to implementing a new technology solution intended to improve your organization’s governance, risk, and compliance (GRC) program it’s difficult to identify where to start.

When you have a lot of different elements to consider—international operations, different levels of control structure, pre-existing silos among operations, risk, and audit—the situation is even more complex. A holistic approach that establishes a solid foundation incorporating the people and the processes—before considering the technology—is the best place to start. 

On a recent episode of LogicGate’s podcast, GRC & Me, David Ngu and Peter Berger joined us from global consulting firm Protiviti to share how they approach this type of transformation, when it comes to compliance, using a holistic—and agile—approach.

Missing Jigsaw Pieces

Before you can begin, all required frameworks must be in place and compatible with each other. Discovering that a key component of the compliance puzzle is missing once the process has started can have significant consequences on the project outcomes.

To ensure all the elements exist, you should conduct a wide-ranging assessment of current processes.

Peter explained, “When starting an assessment of an organization, I often start by asking a fundamental question: ‘What do you understand by the meaning of risk management and compliance?’ And secondly, ‘How do you want that understanding to help your business grow?’”

Asking the first question will result in input from various teams in your organization. Everyone, from the board to internal audit, to the risk management function will have an opinion. The important thing is that alignment from the top down is consistent and that all parties are on board for achieving an improvement.

With that in mind, make sure that existing policies and frameworks are identified and can be mapped out against one another to ensure they form a coherent set of documents. It is usually during this stage that gaps appear in the approach, and thought needs to be put into stitching frameworks together. 

Disruptive Thinking

After you establish how the project is expected to result in a change for your business, start to critically examine existing processes and identify alternative strategies, perhaps with a view to new technologies. 

As David pointed out, “One of the things we are often told by our clients is that they have tried changing tools in the past. They have tried many iterations and it doesn’t work. Is there a better way that we can change and make things more efficient?”

In the same way that digital technologies are creating massive disruptions to industries, from e-banking to Uber to Amazon, your organization should be looking to achieve compliance disruption through challenging the way “it has always been done”.

For example, in late 2020 this Forbes Technology Council article cited Automated Risk Management as the number one disruptive technology of 2021 and beyond. Rather than assuming risk management to be a reactive, rear-view facing discipline, your organization must embrace the power of automation and digital technologies to start managing risk in real-time.

“We have been helping our clients look beyond traditional GRC technology, enabling them to automate controls testing and execution through continuous monitoring. We have used process mining to link up to ERP systems to extract any kind of irregular data and look for trends,” David explained.

The Problem with Big Bang Change

One common misconception is assuming that everything can be changed all at once. This thinking ignores the human element by not providing enough time for people to become accustomed to new ways of thinking and for training to become embedded.

Peter explained, “From my experience, people will not be very eager to start managing risks on a daily basis in a new tool. So, you usually need to help people to understand that everyone faces risks, whether in daily life or business life. However, business life becomes a bit more complex because there are many more people who need to align in the same direction. If the organizations don’t make the right choices, it can become very frustrating. It can become expensive and then after many years of trying to implement a complex sophisticated tool sometimes you just have to throw it out, and that is not a good case.”

When implementing any new solution, there will be gaps within the knowledge of your team about the operating environment. Uncertainty will exist around the dependencies on other systems and suppliers; constraints will exist on people, on systems, and access to hardware and infrastructure. There will be contractual exclusions that could prevent one or more activities from progressing as planned, and there will be a whole load of assumptions made by your team to cover many of the unknown aspects.

As such, all processes will change as they progress and mature. You will acquire knowledge, overcome issues, and face other unforeseeable risks. In this changing environment, your GRC program must be agile and adapt to the pressures it is put under. How is this best achieved?

David summarized it best, “To be agile it is sometimes necessary to stop and think wider than just the technology but in terms of what is the business outcome? I have found that it helps to start with the architecture. You do need to design with an end in mind, but then be able to adapt and change as you go, because sometimes what you plan at the very start will change. If you have small wins, then these should be celebrated and you should keep going, but if you find that you hit a wall then don’t force the tool to work. What will happen is that you end up overbuilding it so that it becomes bespoke and customized, and then it will probably break down in years to come, leading you to wonder why you did it in the first place. So coming back to architecture, driving the project forward, and having the agility to adapt is very important.”

The Successful Transformation Formula

For an organization to implement an agile and aligned GRC program, it is necessary to consider these three key components:

1. Take the recommended steps to fully know the existing operating frameworks within which the GRC landscape operates, and ensure that they operate in concert with one another. With this knowledge, take the opportunity to challenge the existing way of working to better determine if alternative models could prove more effective and efficient.
2. Overcome the silo-mentality and language barriers that exist across the current GRC landscape to ensure that all parties end up moving to the same place with the same common expectations. This also ensures that more standard technology can be deployed, resulting in less customization and a higher likelihood of success.
3. Start with the end architecture in mind, work iteratively, and try not to force a fixed preconceived view of the solution onto the project. Take stock of the successes and failures and update processes as needed. This ensures that not only the technology but more importantly the people are on board with the final solution.

To hear more tips on how your organization can become aligned and agile in your GRC processes, listen to the full episode of GRC & Me here. Learn more about how LogicGate’s Risk Cloud can help get you there at logicgate.com or request a demo.