I Think We Need a GRC Tool. Where Do We Start?

I’m not going to say that I have this question every Monday morning, but it does pop up rather more often than I would have expected. This is especially the case when risk, compliance or audit departments ask their IT counterparts to send them a list of suitable governance, risk and compliance (GRC) vendors but fail to really explain what they need.In essence, the request to their mind is pretty simple—just get me the list and rankings published by “[…] and […]” ( fill-in-the- blank spaces with your favourite analyst companies). That should do the trick.

This is usually what triggers the question above, with the IT department reaching out asking for a discussion on what is a GRC solution to ensure that they only source relevant options to present to their internal clients.

As mentioned by my colleague Jan Gardiner a few weeks ago (GRC ≠ Access Authorization Management), for us at SAP, the GRC portfolio is a combination of more than 10 solutions.

As a result, before even going further into any discussion, my answer is always the same, ”Well, what do you need to do?” I could spend hours explaining and illustrating the benefits of a full internal control solution, but if the original request comes from the audit team who is looking for a tool to help them support their risk-based auditing process, I’m not sure it’ll be of much use.

What’s the Requirement?

So first things first—define the need. Easier said than done of course, but it will be the foundation for everything. In case the requiring team doesn’t have a predefined idea of what exactly it is they need in terms of detailed requirements, you can always reach internally and see what is already available and being used (tools, spreadsheets, shared drives,).

Even if you then decide that none are the right option, this will still give you a good idea of what people are using today and for what purpose. And if you push your investigation further and interview the key users, they might even tell you what they currently lack. This is essential as it may lead to needs or pain points that are beyond the ones initially expressed.

Prepare for Today but Plan for Tomorrow

Now that you know the requirements, define where you are today and where you want to be tomorrow (or the day after). And keep in mind that a tool will never solve all your problems at once but it can bring new ones if expectations aren’t managed properly.

Using the information you collected above, work on a roadmap—what would be the first features needed today to facilitate work life, and what is,at the moment,  a “nice to have” but that you know will be important in the future.

With this in mind, start prioritizing so that the tool selected will be able to answer the immediate requirements, but also accompany the company as it evolves.

Leave Tabula Rasa to Aristotle!

Your company already has a wealth of risk registers, control libraries, audit repositories, and so on.

This is the “GRC memory” of your company and you certainly don’t want to get rid of it.

Collect as much as you can and then work with the business owners to review the data—define what should be carried forward, what is redundant and can be let go, and so forth.

And for what you decide is worth keeping, ensure that it’s complete and well documented. This way, not only will you embark on a new tool, but you will also have secured the consistency of the imported data. No need to have a Formula 1 car if you don’t have the right fuel, right?

Of course, I have over simplified the process, but for  a short blog that was my intent. But I hope this has still given you some food for thought for the next time your business owners call saying, “We need a GRC tool, what do you suggest?”

I look forward to reading your thoughts and comments either on this blog or on Twitter @TFrenehard