GRC (Governance, Risk Management, and Compliance) has become a core issue for any CIO over the course of the last few years. SOX brought popularity to IT compliance – and nowadays everyone seems to talk about GRC. But sometimes, the approaches chosen seem to increase risk instead of mitigating it.
What might seem to be sort of a provocative thesis unfortunately is the reality. There are, from our perspective, four critical aspects in many of today’s GRC initiatives. The first one is that GRC requires an organization which is GRC-ready. The second is that often too many tools are used. The third is the distinction between Enterprise Risk Management and IT Risk Management which isn’t valid. And, last but not least, people tend to fill a checkbox and stop – instead of continuously managing risks.
GRC-ready organizations
The first question any organization has to answer is who is in charge of GRC. There are some typical answers, like CFO or – from an IT perspective – CIO or the internal auditors.
The breadth of possible answers is a spotlight to the real issue: Typical enterprise organizations don’t have the one organizational unit which is responsible for GRC. That’s especially true with a holistic view on GRC, instead of artificially separating the “enterprise” (e.g. Non-IT) part and the IT part of GRC.
Successful GRC initiatives require an organizational foundation. That might be sort of a matrix. But, more consequently, it might be an organization which results in a fundamental change of today’s IT organizations and the role of the CIO. In fact, GRC is the layer where Business-IT alignment becomes a reality. Thus, a CIO might take the role of the CCO/CRO (Chief Compliance/Risk Officer) as well. That’s, by the way, an approach which has a big advantage over GRC as responsibility of the CFO: The CFO doesn’t audit himself.
For sure there is no simple answer to the question of the ideal structure of a GRC-ready organization. ISACA and others have proposed organizational models for risk management. Our advice is to start with sort of a matrix organization but fundamentally re-think the IT organization in the light of GRC.
Platforms – not tools
Over the course of the last two years, a lot of GRC platforms appeared at the market. They are positioned as the answer to the issues companies have been facing when adding more and more tools for specific compliance requirements (one for SOX, one for HIPAA,…) and for specific platforms. Too many tools are unmanageable and by far too costly.
There is no doubt that GRC requires a platform approach. But that approach should neither be limited to IT GRC nor should it be limited to what Kuppinger Cole calls IAM-GRC, e.g. GRC solutions which only cover the (Identity and) Access Management-related issues of GRC. Future GRC platforms have to cover SIEM (Security Incident and Event Management) as well as for example availability risks managed by ITSM (IT Service Management) tools.
Today, there is no vendor out there who provides a complete platform for all aspects. But a GRC strategy has to keep that evolution in mind and to focus on efficient as well as effective solutions with (again) a holistic approach to GRC.
Integrated Risk Management
Most vendors as well as most organizations today differentiate between IT Risk Management and Enterprise Risk Management (and between IT GRC and Enterprise GRC). Wrong. When risks are structured, there are, from a business perspective, strategic and operational risks. The risks of wrong strategic decisions are a business topic. But if we look at operational risks, it becomes obvious that virtually any operational risk is directly related to an IT risk – and vice versa. If you look at that issue the other way round, you end up with the question of “why is an IT risk a risk?”. The simple answer is: Because it might affect operations and, at the end, the EBIT.
Given that there is a direct relationship between operational risks and IT risks, it doesn’t make any sense to use separate solutions to manage operational risks and IT risks. But today, many ERM (Enterprise Risk Management) tools don’t provide interfaces to IRM-Tools (IT Risk Management) or direct management capabilities for the related IT risks. On the other hand, IRM tools very seldom allow describing and managing the related operational risks.
This gap is, for sure, a risk, because it avoids a (again) holistic risk management.
Continuous GRC initiatives
The last point is about the distinction of checklists and continuous risk processes. It is also about the difference between compliance and risk management initiatives. Compliance initiatives often end with a completed checklist. There are many tools out there which claim to address PCI compliance requirements. Fill the 12 checkboxes and you are done. In Germany, many companies do audits by the German TÜV (Technical auditing company) for IT Security, according for example to ISO 27001. Once done, they fix some obvious problems and then it’s done for some 12 or 24 months, until the next audit.
But what happens in the meantime? In contrast to the frequently checklist-oriented approach of compliance initiatives, risk management is per se a process. It is about defining risks, continuously monitoring these risks, proactively defining actions, and managing actual risk situations.
On the other hand, that approach allows focusing on the (hopefully) few aspects which are at risk. Thus, “management by risks” provides clear advantages. If compliance requirements aren’t met, that is a risk. But there are many things outside of compliance. The worldwide lead for GRC at KPMG, Edge Zarella, once told me that at one of their large customer’s roundabout 2% of the business processes were affected by SOX compliance initiatives – but the other 98% can be at risk as well. Thus, real GRC – a holistic GRC – is centered around the ongoing risk management, not around a singular aspect of regulatory compliance.