GRC & You, Perfect Together

I was glad to see Ian Glazer's blog response to my recent posting on how GRC could have helped prevent some of what happened to San Francisco's wireless network last week for a number of reasons. First off, It's always a pleasure to hear from the anyone at the Burton Group (even when we have a difference of opinion as far as GRC goes) and even more importantly he pointed out that my logic was not quite what it should have been, so I'm going to use this post to correct that.

First off, I'm hoping that Ian (and the Burton Group in general) will agree to disagree on the topic of GRC which I have discussed previously. First of all, don't think that you can look at GRC (or GRCE) for that matter as one discipline any more that you can refer to IAM as on discipline.

At its simplest level GRC is Governance, Risk and Compliance. I'd like to take some time to review how these concepts could have helped the City of San Francisco prevent this event.

• GOVERNANCE - Who in the CIO's office set up procedures to ensure that there was redundant access to the wireless systems? I find it hard to believe that the city wanted "the keys to the kingdom" in the hands of one person. How would troubleshooting occur if key players are off shift, on vacation or otherwise unavailable.
• RISK MANAGEMENT - I'd assume this did not happen since there was no Governance (under my model) being done. Did someone look through to see what the risks were? In this project I'm sure there was much attention to the people using the network, but there was little thought to who is running the network. This was the thrust of my original posting.
• COMPLIANCE - Were any procedures executed to make sure that checks were being done on the aforementioned Governance and Risk Management issues? Was anyone checking to see if there were any holes int the Governance or Risk Management plans? I'm guessing not.

I think what everyone is missing here (and I did not make very clear previously ) is that GRC is not just software nor is it one monolith process but rather a meta-process if you will that requires organizations look at all three components on a multitude of levels. If organizations do not look at the hard and soft processes there can and will be significant risks. Looking at all Enterprise projects in the through the lenses of Governance and Risk Management and Compliance is essential in today's audit and security governed world.

So in the end Ian, you're right, GRC is not one animal, but I would submit that GRC is a small herd. I'll also go so far to agree with you that GRC Controls are not the solution in this particular case, but thinking in GRC concepts and practices could have taken them a long way.

(Note: this entry has been updated to reflect the fact that Ian Glazer and not Gerry Gebel wrote the post for the Burton Group)