Posted by: David Schneier
assessments, Audit, compliance, governance, GRC, regulations, regulatory, Regulatory Compliance, regulatory guidance, risk, risk assessments
I love GRC, at least the concept. I’ve gotten way more than my fair share of print time expounding on its many virtues and how it continues to make inroads into so many organizations. It’s the next and necessary step in the evolution of audit and compliance, a fact (yes, fact) of which I’m certain.
But why is it that no one can ever truly and honestly agree on what exactly GRC is? I first wrote about this very issue in 2008, then again in 2009 and 2010 and once again earlier this year. Beyond the too few thought leaders on the topic there’s very little clarity. And most of the credible GRC sources seldom extend from the theoretical to the practical (my opinion but let’s remember, this is my blog). For those in the trenches who have a vested interest in trying to apply the most basic elements of the discipline there’s very little out their available to help them figure out where to begin and what to do. When you throw into the hodgepodge of concepts the dozens of vendor spawned interpretations it becomes nearly impossible for any two people to ever agree on something close to a common definition.
What a shame.
It’s a shame because conceptually GRC is too important of an evolutionary step within the audit and compliance space to be botched. The huge pile of industry and government requirements seems to grow almost daily, the amount of resources available to manage the work only seems to shrink daily and these trends show no sign of slowing down. The blueprint for a better and more efficient approach is right there before us practitioners and yet we can’t quite see the forest for the trees. I’m not sure what the primary reasons are or if they can even be boiled down to just a few but I’m gonna give it a try just the same.
First, stop listening to the software vendors explain what GRC is or isn’t. They have solutions to sell and while some of them are truly impressive they’re going to align their GRC definition with the capabilities of their product. Second, stop reading white papers and frameworks. There is some very important content available in the industry published by some very, very bright people but in the abstract much of it is at best daunting to internalize or understand and at worst suffocating to the point where you’ll just get frustrated and put it away for another time. Third, don’t think you can simply bring in an advisory firm to either define or develop a related program. My experience in working on GRC inspired projects is that both the corporate culture and its capabilities are way too important of an element to either overlook or underestimate. An external perspective often can’t detect these nuances and so what they design is doomed for failure because it can’t be sustained in the real world.
What can you do to overcome these all too common pitfalls? Your homework.
There’s no real shortcut to identifying where to begin laying down your most fundamental steps for a GRC program. Only you and others in your institution can identify both the pain points and also the most obvious opportunities. All too often the first step involves forming a committee which is usually a recipe for delay (someone I worked with years ago once advised that if you want to make sure a project never happens bury it under a committee). But what you can do is seek out and enlist the support of partners that share a like mind or a common goal. I don’t usually recommend engaging internal audit at the onset but you might want to include a trusted member of its team. You might even consider reaching out to your examiner for suggestions and where to begin. Perhaps you have control owners within your infrastructure who spend way too much time generating content to satisfy compliance requirements and are willing to lend a hand if it means easing their burden at some future point. But whatever you do to start forming a team and outlining ideas you need to think it through with your expert knowledge and understanding of your institutions capabilities.
Once you begin forming that plan with some deliverable’s and goals you can consider augmenting your efforts with an expert GRC hand to guide you. Once you firm up what you think your organization is capable of and have had the chance to vet that plan with key stakeholders you can research GRC products that are closely aligned with what you’re looking to accomplish (the right vendor will want to learn about what you’re trying to do rather than tell you how to do it, trust me. And yes, I’m biased). And once you have a stronger sense of what you’re looking to accomplish you can engage the structured approach of a framework.
Oh and as for a single definition of GRC I’m clinging to the one I’ve been using since first reading about it several years ago. GRC harmonizes efforts across previously detached disciplines that existed in their own silos within an organization (this is my fancy version). In simpler laymen’s terms it’s the point of integration between related functions reducing redundant activities and allowing the left and right hand to work together. And the only wrong way to try and implement some of its elements is to not even try.
No matter its size your institution is neither too small nor too complex to benefit from GRC. No matter how many times you may have tried to build something unsuccessfully it’s entirely possible to accomplish. No matter how overwhelming or confusing you’ve found the concept to be at the point where you tried to get the rubber to meet the road there’s a simpler more viable approach.
Make it your corporate New Years resolution for 2012, I implore you.