Will the Real GRC Please Stand Up?

Just 8 Years ago, no one had heard of the term “GRC” yet today, there are more experts with analyst firms, consulting companies, and software vendors than I could have ever dreamed of. When I began planning and organizing my “Integrated/Federated GRC Environment” in 2001, the only vendor that came even close was Axentis. Remember, I had been in IT for almost 25 years to that point and knew something about technology. GRC had no commonly understood acronym and there weren’t any vendors, consultants or analysts providing guidance let alone technology solutions to help manage the administrative aspects of the myriad of people, processes and information.

So how have all these providers of GRC services and solutions become experts so fast? In many cases they have just expanded marketing of their already in place point solutions referring to themselves now as a GRC solution rather than be burdened with the stigma of a purely point-solution and presumably miss the GRC revolution. Without a clearly defined benchmark to be measured against and being a new term, they have created their own visions and definitions of what GRC means and henceforth, how it should be solved – adding to the confusion.

The reason for this is obvious however, solving the problem is a much more difficult task.

I think it’s about time those of us in the business of GRC, start to confront the confusion we have all created around what G, R and C mean. I won’t name names but I can tell you as I get around and talk to various experts on GRC they may agree on concepts but in practice the solutions are from completely different books not just different pages.

In addition to the GRC practice guidance that OCEG is helping to create, they and their members are working on the whole concept of a GRC technology ecosystem. This will eventually help categorize solutions in a more accurate position within the ecosystem of “GRC solutions”. With guidance from OCEG and the community of contributors from industry Chief Compliance and Risk Officers, Chief Ethics Officers, General Counsels, leading consulting firms and GRC application vendors - we will have real useful information and benchmarks to define the real GRC.

Analyst firms don’t all see GRC the same way either. Their understanding by in large is led by the types of inquiries they receive from their customer base. If their customers are primarily IT focused, the technology requirements for GRC reflect the needs of IT. If they are auditors, they tend to reflect the technology needs of auditors and so forth with other roles across the GRC spectrum. What this promotes is an unbalanced view of what GRC is, what solutions are needed and how solutions compare. It stands to reason that, the guidance and research done by analyst as to the key elements of GRC often target the view from a specific discipline rather than the broad spectrum of stakeholder needs – Enterprise GRC. Not always the case, but how does a buyer or solution vendor really know without the experience of working with a variety of stakeholders or having industry benchmarks from which to measure?

If the company approach to risk and compliance management is unbalanced towards risk or compliance, they are likely overspending and/or underachieving. The application solutions to support these processes need some degree of balance or at least, need to work well within the over-arching technology ecosystem and should make clear where they stand.

I think we have to get real, especially with what “R” means and what “C” means. I am not focusing on G because in some ways R(C) = G (I know this is not exactly true), but lets focus on R and C for now.

“ C” stands for compliance which for many means obeying laws and regulations. That is true but not the whole story. It also means following internal directives, departmental policies and procedures and other requirements based upon management decisions. In other words, compliance is adhering to whatever the process rules are and getting people to follow these rules on a daily basis.

Everyone should recognize that C is a subset of R which is a subset of G. That’s why it’s called GRC, not RCG or CGR or RCG. But one can’t have G without R and it follows one can’t have R without C and that’s my point.

One cannot properly manage risk without managing compliance. If one is simply creating a control framework and assessing or auditing whether procedures and processes are being followed, I guess this is someone’s definition of managing compliance, but in order to assess if something is being done according to the rules you have to tell people what the rules are in the first place. And in order to tell them you have to write it down (we can call that a policy). So in order to really manage risk, sooner or later there are people involved and those people have to be told what they are supposed to do and if they aren’t doing it then someone needs to do something about it and THEY need to know they are supposed to do that. So first comes a requirement and control, then comes a bunch of compliance policy definitions and communications, then comes audit, then comes compliance exception remediation, which auditors don’t do, they are the internal cops, but the process owner in the authority hierarchy needs to be monitoring on their own and also do the remediating, might be a functional person or someone in the legal department, who knows.

My point is, running C isn’t easy, and you can’t run R without it. Now I will bet you are really confused.

I’d like to hear your perspectives on the state of GRC confusion from the solutions and approach perspectives.