Over the last few weeks, I've been fortunate enough to spend some serious time digging into the current state of affairs regarding GRC -- the emerging topic of governance, risk and compliance.
Sure, the topic is hazy, poorly defined and all over the map. That's probably one of the reasons I'm so interested.
That being said, I've seen a few patterns emerge that might make things a bit easier for all concerned.
Also, for those of you who don't like the long-ish posts that result when I dive into a new and complex topic, maybe you'd better skip this one!
GRC Concepts In Thirty Seconds Or Less
Over the last few years, you've probably heard the acronym more frequently. If not, listen for it -- if it's not part of the conversation yet, it will be soon.
Analyst definitions vary considerably -- I saw five different definitions on one page, and I struggled to connect the dots -- no surprise -- but I think it's useful to offer up a working definition in the short term.
Let's start with risk -- if you're a company or an organization of any type, you want to avoid bad things happening. You want to understand what the risks might be, their potential impact, what can be done to mitigate those risks, and what the relative costs might be.
To do this, you need a group of people and some process to go look at those things, understand them, and make recommendations. In a nutshell, that's governance.
And, once the recommendations are made, you need people and process to go do what was recommended, measure the results, and be able to prove what you've done. That's compliance.
You'll find GRC-type thinking emerging everywhere: legal, finance, HR, IT, engineering, research, healthcare, energy exploration. Each subsegment faces a very different risk profile, so GRC is thought of differently depending on who you're talking to. HR risks aren't the same as legal risks aren't the same as engineering risks, and so on.
Most people think of GRC as all about complying with regulations. I think that's partially true -- not complying with a given regulation could be described as a risk of sorts, so I tend to use "risk" to encompass "any bad thing happening that you'd really like to avoid", which of course includes not complying with whatever the latest regulation might be.
What Makes GRC Very Hard
First, since many of risks we're talking about are really risks of regulatory non-compliance, we're facing an interesting situation in the next few years, especially in the United States.
I think it's a pretty safe bet that we'll see dramatically accelerated regulatory activity in the next few years.
It's inevitable in the wake of the economic turmoil we're all wading through. More regulation == more risks of non-compliance == more GRC discussions in our immediate future.
Second, people are using the same buzzwords to describe dramatically different concepts. Sure, at a conceptual level, you can draw pretty arrows and bubbles that look pretty much the same for each GRC discussion. But as soon as you drop one level down, the specifics of "exactly what risks" and "exactly what compliance" diverge dramatically. So it's turning out to be really hard to have a productive conversation when everyone uses the same words to describe very different concerns.
Third, predictably we've got a bunch of vendors and consultants entering the fray with vigor and passion; EMC included. Having all these voices bouncing buzzwords and phrases around the marketplace raises the noise level and makes the conversation even more difficult.
Fourth, the landscape and thinking here is moving very quickly. There doesn't seem to be an extensive and well-accepted body of knowledge regarding best practices and such.
Fifth, human nature kicks in. Customers tend to go right to the end result as quickly as possible. I remember a customer conversation on this not too long ago, and the guy said "look, all I need is a nice compliance report to show the auditors when they come around". I thought this was kind of like saying "gee, all I need is a nice bank account with a bunch of money in it".
There might be more to it than that :-)
And, finally, all us vendors sell tools that primarily help with the compliance part of the discussion. We can't sell you a product or technology to address the governance and risk parts in a meaningful way: that's a people and process discussion.
Common Themes
Not surprisingly, EMC tends to look at this as an information-centric discussion. I know, you're shocked.
Sometimes it's information itself that's the subject of GRC: certain kinds of information will be the target of focused risks -- easy examples are credit card information and personally identifiable information.
More often, though, we use information to document policies, process and procedures, measure compliance activities, provide audit trails on what's been done, reports to interested parties, etc.
So, I've quickly learned to differentiate between "compliant information" (i.e. information that is directly subject to a GRC discussion) and "compliance information" (i.e. information about GRC activities). It's turning out to be a useful distinction.
Now, let's take this from an IT-centric point of view, as all roads lead to IT sooner or later, and GRC is turning out to be no exception.
Over the next few years, it's highly likely that IT leaders will find themselves in many different discussions with many different business leaders about "their" GRC requirements. They won't be 100% clear what they want, or how they want to do it. Funding may be there, or may not be there.
Which leads to a very interesting discussion about platforms and capabilities, rather than specific products and solutions.
Should We Be Thinking About GRC Tools As Core Infrastructure?
Now, this will be a hard one for some folks to get their head wrapped around, but I'm going to try.
Already, I've been exposed to a dozen or more GRC initiatives in customers, and a dozen or more GRC solutions that EMC and other vendors are trying to offer to these people.
And I'm starting to see strong similarities in the capabilities that are required. Which makes me wonder if it makes sense for IT thinkers to start framing up broad capabilities that they'll need in the future, rather than a patchwork landscape of different solutions for different parts of the business.
One core capability that's popping up frequently is "I need to find information wherever it is, classify it, and potentially take action". It doesn't matter if it's an email, a file, an IM, a database record or whatever.
Somewhere out there there's a bit of information that's part of a GRC discussion, and if it can't be found and acted upon, there's going to be problems.
At the back end, there's another frequent requirement along the lines of "I need to preserve this information, make it accessible when needed, prove that it hasn't changed, do it for all kinds of information, delete it securely when I can, and do it cost-effectively".
And in between those two end points, there's a bunch more:
- the need to document policies, procedures and workflows, which themselves become compliant information in many circumstances
- the need to prove that the infrastructure holding the information (whether compliant information or compliance information) is itself compliant
- and probably a much more we could explore -- my head hurts when I think about it.
I think you get my thinking here -- does it makes sense for IT (and vendors) to start thinking about core capabilities that will be needed *regardless* of which part of the business is talking about GRC this week?
Let's look at some practical examples in EMC's portfolio to see how this thinking is getting actualized.
For example, EMC sells email archiving solutions. In some situations, email is considered compliant information. It needs to be discovered and classified. Specific kinds of emails may trigger specific actions and workflows.
Certain emails will need to be preserved, sometimes in a compliant fashion. Or you may have the need to detect emails in flight and drive specific actions: block, encrypt, notify, etc.
If your email is serious stuff, the processes, procedures and workflows will need to be captured and documented, and may be subject to change control and compliance themselves. The IT infrastructure to do all this wonderful stuff may be subject to change control and compliance.
And, of course, nice reports for the auditors showing that all this good stuff is doing its job.
Now, how useful would it be if the tools that did all this wonderful stuff for email could also do it for files, IMs, databases, video, audio, etc. etc.?? The same tools and infrastructure -- just used over and over again?
As I look at our offerings, I see this happening. The tools and capabilities we're using are largely generic, but they're not being marketed that way.
We're not perfectly there, but -- is this where we should be heading?
Getting Ahead Of The Curve
Even if vendors like EMC could do this, would it work?
For example, if the legal department wants "their" solution for their unique problem (and have budget!), would they compromise a bit and accept tools and infrastructure being used elsewhere in the organization?
Well, this certainly won't happen unless IT has done some thinking ahead of the curve, sees them coming, and has a game plan worked out.
Unfortunately, I've been in this business too long and seen the movie before: usually this sort of "let's standardize" discussion comes up after the third or fourth specialized solution goes in, and it dawns on people they're essentially doing the same thing over and over again.
And, Finally, Let's Step Back A Bit
If you're a frequent reader of this blog, you're probably familiar with my thoughts on information governance: the need for organizations to create a new corporate function to help businesses essentially learn to think about information the same way they think about money.
I argue -- and continue to argue -- that this is needed because there's an essential tradeoff between saving money, making money and staying out of trouble that no one existing function can handle on their own.
I think the current GRC discussion fits in nicely into this framework -- it's a sub-discussion about minimizing risks. Framing it entirely as a GRC discussion tends to shift the focus away from the cost and value sides of the same information. Being really good at GRC might end up being expensive and getting in the way of doing business.
Compliance at all costs is probably not a good mindset :-)
You've also probably listened to me harp on about "informationists" -- a mindset we'll all need to learn in order to thrive in the new information economy. Clearly, informationist thinking will be an essential part of learning to cope and thrive with the coming wave of GRC discussions.
The Bottom Line
Things move forward, they rarely move backwards. Looking forward, I think it's safe to say that we'll see many more risks and regulations impacting organizational activities. At the center will either be compliant
information or compliance information. And it's going to come out of many different parts of the organization, at different times and with different priorities.
The key question remains -- will we be able to think in terms of common tools and capabilities to do this in a cost-effective and consistent manner, or will we inevitably descend into a dark age of multiple, tailored solutions: each with their associated costs and friction in the IT infrastructure.
I'm afraid it'll be more of the former, and less of the latter.
Comments