Too much time is being spent on risk assessment, risk management, governance, heavy formalities, etc., without ever getting to the core issues: how sensitive is your organization to “risk”? and, how does your org ensure that risks are held to an acceptable level?

Well I think too much time is being spent mindlessly doing this activities without understanding what the important resources, which makes the rest of the question and effort pointless. Goes back to my earlier rants about operational discipline. But that’s another post that I need to write.

Excellent point. This could easily feed back into the Compliance aspect as well and change the rules to require further enforcement or drop it entirely.

Unfortunately due to the software space, GRC as a concept has been completely bastardized to mean the latest attempt to meet the failed promises of the SIM/SEM/SIEM marketplace.

In terms of the larger space that it occupies, I object to the term GRC largely because it ignores the importance of audit and how it is a necessary supporting leg of governance and compliance. I don’t disagree with the need for Risk, I just think it fits in the picture in a slightly different way.

I don’t think your and my definitions of G, R, A and C are actually that different. My definitions were deliberately high level and I feel that they more or less encompass your much deeper and more specific ones.

The truth is – this is what GRC is about. That is collaboration. GRC is not about a technology product. It is not about one role (e.g., risk, compliance, audit) dominating others. It is about working together in a collaborative discussion, architecture, and framework to drive toward what OCEG calls Principled Performance.

I’m not familiar with OCEG (looking through their stuff now) but I more or less agree with your assertions. Again I think we are actually pretty close in our thinking in reality.

When you attack GRC I am curious by what definition, experience, and framework you are basing your discussion on.

Your opening statement does get to the heart of the matter by referring to the GRC market. GRC is broader than a market for technology and services. It is about collaboration across the business. Getting legal, compliance, operational risk, finance, treasury risk, IT, ethics, audit, health & safety, fraud to work together and communicate with each other. The goal is to gain enterprise perspective on the risk and compliance issues facing the business. Technology helps deliver this, and there is a market for such technology, but GRC is broader than a tech market.

Your definitions and approach to Governance, Risk, Compliance, and Audit are also confusing to me. Governance is more than reacting to requirements. Governance is about establishing to culture, values, and control of the organization. Compliance is about defining boundaries – whether external laws or regulations, internal values and control established by governance. Risk is about measurement and modeling of potential events that can have an impact on the business. All of these do work in harmony together. For instance you can have two different organizations with different governance and cultures – though in the same industry. Each of these different cultures could very well have different views of risk taking and management – different thresholds for risk appetite and tolerance. This is communicated by policies and procedures, monitored by assessment done by compliance. Audit acts as an independent accessor that the organization is controlled the way it states it is. Of course there is much variation and detail to all of this.

GRC is simply 3 legs to a corporate stool that would be very unstable if one was removed.

The problem is there are many bubbles/silos/stovepipes. For every risk person wishing compliance or audit folks to get out of their bubble I can also show another role (e.g., compliance, audit, finance, health & safety, ethics, legal) that wishes risk would come out of its bubble.

While there is a relationship to risk across areas – it does get deeper than just risk management. It gets to ethics, values, code of conduct, staying in boundaries, culture, and more.

The truth is – this is what GRC is about. That is collaboration. GRC is not about a technology product. It is not about one role (e.g., risk, compliance, audit) dominating others. It is about working together in a collaborative discussion, architecture, and framework to drive toward what OCEG calls Principled Performance.

Interesting, even within the subject of risk management you have different factions. I know enterprise and operational risk folks that jump up and down that information risk does not get it. Bubbles within bubbles.

The real issue is that there are different types of risk. If a project risk manifests, the project may fail – which may be in the best interests of the organization but not necessarily the project manager. A security risk manifesting, on the other hand, is bad for the project and the organization.

Another way to categorize risk is by the control you have over them. Some risks are controllable – like internal system configuration. Some are uncontrollable – like whether your auditor is incompetent. In between there are some risks that can be influenced – like how your superior responds to an auditor report.

He’s a GRC industry analyst and consultant (formerly with Forrester Research).

He makes similar points, as do the people who commented on the post.

I *strongly* suggest that you guys get a dialog going with Michael on this topic. Maybe it would lead to a joint conference presentation, webinars, or what ever. We *must* bridge the gap between the risk management community and the regulation-compliance-audit community, IMHO.

Russ

Overall, I need to figure out how to integrate risk tolerance into my revised TEAM Model (http://twitpic.com/ahjek), perhaps as part of defining requirements. Risk tolerance should be something that can be defined in relatively clear business metrics, which means it’s something we might actually succeed in leveraging in lieu of all the other things attempted in this industry (with marginal success). fwiw.