Creating consistent processes for eGRC: a negotiation about change

When you’re trying to integrate and align governance, risk management and compliance, where do you start?

With processes.

This has been one of the hottest topics that the RSA Archer eGRC Community has been discussing during the recent eGRC Roadshows that I have been extremely honored to be a part of this fall. The conclusion that organizations have all agreed on is that you need to identify the key processes across your business that relate to enterprise GRC activities, find the commonalities and intersections, and make changes as necessary to create consistency across them.

This is both easier and harder than you might think:

  • It’s easier than you might think because the majority of GRC processes across the business will mostly be very similar to one another. People will use different names for things and think that they’re doing something very different from others, but in terms of underlying principles and steps, they mostly won’t be.
  • It’s harder than you might think because people won’t want to change what they’re doing. Even if it’s just a name change, eg changing an ‘incident’ to be called an ‘issue’, people will fight hard not to change what they’re used to. Processes and their naming conventions can be really personal; they frame how people think about what they do. If you ignore this and try to be dictatorial about process change, you’ll be in for a hard time. To illustrate my point I present to you two examples of pretty much the exact same process for both ‘incident’ and ‘issues’ management. As you will note, the only thing different is what you call each stage of the process. 

Issues Management Process

Incident Management Process









Negotiate change

So when you’re setting out to break down GRC silos and create common processes, you need to allow plenty of time to negotiate process change. The role of a GRC advocate or leader is to orchestrate this negotiation, not impose change on people. If you want to be successful you need to help people to their own conclusions about why the change is necessary and not as bad as they think.

This applies even if you’re just changing the naming conventions (taxonomy) associated with processes (I’ll cover taxonomy in a bit more detail in my next blog). It applies even more so if you’re improving a bad or mediocre process, ie making actual process change. Process change is important if your processes don’t reflect best practice, otherwise the danger is that the improvements you make through eGRC will just make mediocre results happen more quickly.

So to reiterate, every eGRC project should:

1. Start with process.

2. Create consistent eGRC processes across the business.

3. Improve poor or mediocre processes.

4. Negotiation change in Taxonomy.