“I think we need a GRC tool. Where do we start?”
I’m not going to say that I get 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 (in their mind) is pretty simple – just get me the list and rankings published by “[…] and […]” (fill in the blank spaces with your favorite analyst companies). That should do the trick.
This is usually what triggers the question about how to find a GRC solution, with the IT department reaching out asking for a discussion on what a GRC solution is 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 (in 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 to this question 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 that 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 look internally and see what is already available and being used (tools, spreadsheets, shared drives, etc.).
Even if you then decide that none of them are the right option, this will still give you a good idea of what people are using 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 a “nice to have” now, but 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 oversimplified the process, 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?”