Governance, Risk, and Compliance (GRC) or IAM? Which one is right?

Last week I had the privilege of travelling to Singapore to speak to the Asian Financial Services Congress (sponsored by IDC) in the GRC track. My topic was how identity and access management plays (or doesn't play) in GRC. On the panel with me were a regulator and an auditor. It was very interetsing to see the different (and myopic) views each of us had on GRC. The auditor was all about crossing the "t"s and dotting the "i"s, while the regulator was all about the acronym-heavy letter of the law. I, of course, was all about IAM. My argument was that if IAM is done right, GRC naturally follows.

None of us were totally correct. While if IAM is done right (and by right I mean as simply as possible, in a modular and intergreated fashion, with a business-centric approach, and without the rigidity that most of us have come to expect from IAM) you are much closer to GRC than if it isn't done right, the expectations to prove that compliance to an auditor and satisfy a specific regulation will never go away. In other words, the best IAM approach may totally lock down systems and make them secure (and thus compliant), but if it is too difficult to prove that compliance the auditor won't care -- and you'll pay the price.

I came away from the session with a renewed belief that not only do we need to "be" compliant, we have to be able to "prove" that compliance. Luckily, IAM done right (see above) makes proving compliance much easier. If the number of systems to be audited is reduced, if the IAM approach is architected in a way that makes information easily accessed by the right people in language they can understand, and if controls are built upon standards and implemented as simply as possible, the marriage of GRC and IAM is a happy one.

So "be" compliant ... but unless you can "prove" it, what's the point?