Nirav Doshi, AVP - Risk Management, National Payments Corporation of India (NPCI)
Matured organizations have one specific expectation from their Risk team. A framework should be designed that cohesively binds strategic, operational & IT risks. The output should be able to give an easy view of the risk exposure. Most importantly, maturity will be achieved when risk management can assist the CXOs in taking important decisions.
Governance, Risk & Compliance. (GRC). In the risk world, this might safely be one of the most loosely used acronym. The reason is simple. Until a few years back, everyone thought, "Let’s throw people on problems." Now, they think, "Let’s throw a tool on a problem." Assumption is that the tool will solve all the problems.
"Organizations should slowly move away from a mindset of penalizing the risk identification activity. Instead, move towards an incentivizing culture for adhering to processes and implementing controls"
Also, unlike age-old functions like HR, Finance etc., GRC activities are fragmented across the organization. GRC activities are fragmented across the organization. Hence, the confusion about who is responsible for governance of controls & who is responsible for their implementation. It is not easy to define boundaries of where governance starts and ends.
What is the objective of a GRC tool? Just automate a few workflows? Would you automate the process of risk management, when you are not even having monthly risk discussions with stakeholders?
Getting a risk buy-in is by far the most difficult thing to achieve. GRC projects fail not for the content but for the limited buy-in they get. Eventually the organizations have woken up to a harsh reality that GRC implementation is not like implementing a firewall or an email solution. GRC stakeholders and users are altogether different from some other tool implementation. Hence Boards are willing to spend more time on discussing the approach of the GRC tool implementation.
Scenario - Monday morning…
So,amidst all these realities, on a fine Monday morning you are told that your Board has given approval for GRC tool procurement. Prepare a plan for its procurement & implementation but before you put dates please ensure that you work on the below pre-requisites.
Check your team composition
Organizations need GRC implementation to be driven by a ‘Change Champion’ to drive the Risk Management. For this, there needs open and real dialogue about important risks that organization faces. Do you have even a single team member who has a good clarity about top 5 risks of organization/depts.; visibility of your application and network ecosystem? Someone to meet the ground level teams who will be using the GRC tool daily. If you don’t have this skill in your team, it might be a better idea to have this part of the planning outsourced to an organization who has a track history of assisting in GRC implementation. However, don’t forget to map the payment terms of this consultant to each milestone of GRC tool implementation.
Know your stakeholders
You need to know who all you want to bring under the GRC scope and in which phase. It must be thought out initially itself and not an afterthought. This is because expectations of a compliance team are altogether different from expectations of a CTO. Similarly, Finance, HR etc. all have very different expectations from GRC.
Defining a GRC architecture
It is necessary that the architecture is well thought-off basis the expected audiences and reporting expected from the GRC tool. One of mistakes organizations do is feeding in too much data into GRC tool without filtering it. E.g. to meet the expectations that GRC should be implemented within 6 months, risk teams generally rush to implement some low hanging fruits like integrating vulnerability management module. The output they get is more a list of technical issues and not really the risks. This eventually makes a GRC tool work merely as an issue tracker (read glorified automated excel).
The first big step
There should be no confusion in your stakeholders that GRC has CXO sponsorship and is aligned to address business needs. A crisp but defined project charter should be used to kick-off the GRC program. Only plan to move those processes in GRC tool which have at least 70 percent buy-in from stakeholders. Don’t rush to just implement a workflow which stakeholders don’t feel inclined to use.
The structure of your policies
Compliance expectations of GRC tools are driven by the policies. Hence, it is imperative to check if your policies are compatible with each other. Are your legal, audit, info-sec, compliance, corporate governance, operations etc. policies i n s ync? Dot they complement e ach-others well – at least t hey don’t contradict each-others? I f not, you might want to bring about a better sync and inter linkage amongst such polices.
The Risk Culture
Is it possible for you to make risk-aware decisions when your teams are busy hiding their gaps from you?
Most of the organizations are today functioning in risk-delusion mode. Risks are always going to be there. Organizations should slowly move away from a mindset of penalizing the risk identification activity. Instead, move towards an incentivizing culture for adhering to processes and implementing controls. Appreciate those teams who identify and mitigate risks within their areas proactively. If organizations can set the GRC process right, GRC tool will definitely be successful.