GRC is not enough

The problem with GRC (governance, risk and compliance) is that it’s not a three-way issue. At minimum, there are four or five different forms of governance, two types of compliance and seven different types of risk.

Compliance is easy: it’s either internal, imposed by corporate governance standards, or it’s external, imposed by regulations or standards of various types. You could probably split the latter up into categories but why create unnecessary complications?

As far as governance is concerned, there’s corporate governance, IT governance, and process governance. There is also either data governance and content/web governance or you could concatenate these into information governance.

But it is risk that is the real issue. This is partly because people use different terminology: to some people risk is simply about business risk: if I make a business decision what is the potential downside if I call this wrong? In capital markets, for example, what is my exposure in case I have shorted the market and it goes long, or vice versa?

The problem is that this is far too limited a view of what risk is. Take data quality for example, if you have poor data quality then you expose yourself to risk through uncertainty about the truth reflected in the data. For example, one company I was recently talking to was able to reduce its capital requirements by £50m simply by getting more surety about the quality of its data. Similarly, there is spreadsheet risk—that is, the risk (near certainty in many cases) that there may be errors in critical spreadsheets—which also relates to capital markets because many algorithms are built using spreadsheets.

That’s three types of risk but we’re not finished yet. There’s compliance risk. If you don’t comply then you may get fined (see HSBC) or you may be forced into extra work (being raised PCI levels) or you won’t be able to do something that you would like to (GCSx) or you may even go to gaol (Sarbanes-Oxley).

Next there’s IT risk: what’s the impact on your business if your systems go down? Or if SLAs are not met? Or if a migration (Heathrow Terminal 5) goes wrong?

Then there is the risk of direct attacks on your business: either external attacks on your IT systems or internal attacks such as fraud, malicious damage or information theft.

Now, GRC vendors do not recognise most of these types of risk. Fraud, which any layman would consider a form of risk, is not typically treated within so-called GRC solutions. And you can see why not: GRC, treated literally and in its entirety, is too big for most (any) vendors to handle, so they’ve cut it down into silos that they can treat. But silos are always a problem and I think a more holistic approach is needed.

If you think about these different forms of risk, they can mostly be managed within existing GRC frameworks: business risk, data and IT governance and compliance cover five of these seven types of risk. But they don’t cover fraud or cyber attacks or similar security issues. I therefore we think that we should really be thinking about GRCS (S for security), at least organisationally, if we want to be complete about this. Of course, security works closely with compliance: meeting the EU data retention directive, for example, is as much a security issue as a compliance one, and the same applies to PCI, GCSx and so on. On the other hand, there are security risks that are not about compliance and compliance (accessibility, for example) risks that are not to do with security.

There’s a lot more to consider of course, and I’ll return to this in future articles but unless someone can convince me otherwise I’m going to be working on the basis of GRCS.