I had an email exchange with a colleague last week in which GRC (governance, risk and compliance as a unified methodology) was central to the discussion. She felt that there’s been a blurring of the lines in how people view GRC versus ERM (enterprise risk management) as disciplines and wanted to know my take on the two. I fear my reply was more blog post than email but GRC is a topic I have strong opinions about and which has long been a favorite theme in my blogs through the years.
First of all, it’s mind boggling to me that anyone who earns a living anywhere in the GRC spectrum could ever confuse ERM for GRC. My colleague clearly understood the differences but was overwhelmed by content provided by many GRC voices in the community and was wondering if maybe something had changed. It hadn’t. I too have noticed some subtle changes over the past year or so as many of the GRC thought leaders appear to be positioning themselves to pursue a broader range of services and expand their audiences and customer base. With the economy in a shambles, it’s not hard to understand why. But in doing so they may have diluted things to the point where GRC becomes a catch-all phrase for anyone with skills or offering services in audit, compliance or risk management.
What happened to the underlying premise of GRC though?
What happened to applying an integrated approach to how risk and regulatory requirements are managed? What happened to all that promise I first started hearing about nearly a decade ago in which all three disciplines worked together so that risk was properly managed and compliance was achieved without duplication of effort or wasted activities? A few years back, I ranted about how GRC was reduced to either being a complicated software solution or a dense, formulaic methodology that (almost) no one had an appetite for. Now it’s not even that clear.
Maybe it’s just me or maybe it’s because so much of the work I’m involved in over the past few years is driven by GLBA (which really demands a basic GRC approach) that I see the simplicity that’s been lacking. This was a thought that came to mind very recently when reviewing content on the basic tenets of GLBA compliance, which my practice uses to educate our clients. Truth be told, much of what’s required can be clear as mud to busy executives who generally want to do the right things to both comply with the various regulations and also protect their customer/member data but simply don’t know where to start or why. So we lay it out for them in such a way that they can quickly understand the work that needs to be done and make informed decisions.
Think about it though. GLBA requires governance in the form of board of director oversight supported by a framework including a wide range of policies and procedures (e.g. information security, BCP, vendor management, etc.), which needs to be supported by a regularly occurring risk assessment and validated periodically via audits and vulnerability assessments. We’ve got the G, we’ve got the R and we’ve got the C and it’s all wrapped up in one encompassing regulation. And the best part is that for those institutions that are fully compliant, it works. The regulation, if properly implemented and supported, does the job it was intended to do; I’ve witnessed it myself time and again.
What does it mean that GLBA works? It means that GRC as a concept also works. Central to its viability is understanding what you have to do, why and how you have to do it and when to get it done. You can’t just plug something in or buy a template and fill in the blanks; you have to work through it in a logical sequence. And the work being done should absolutely make sense to everyone involved from senior management on down to the line people.
Our practice is fortunate because we’re validated by what our clients hear from their examiners, but in the GRC space it’s not quite so clear-cut. Not that it can’t be, only that as it stands today it isn’t, which is a shame considering that the original intention of the discipline was to simplify things.