If you work anywhere near the risk management functions within your company, whether it be as an executive, manager, auditor, or IT security practitioner, you've probably heard from many vendors trying to sell you a "GRC solution." Burton Group analysts say you just may be better off covering your ears.During a presentation today at Burton Group's Catalyst Conference 2008, Bob Blakley, VP and research director at Burton Group, said that the primary goal of any governance program should be "round-trip" management, meaning a continuous feedback loop between the business and management. And while G(overnance), R(isk management), and C(ompliance) are each important organizational categories, Blakley said, they are not an IT product market or a solution.

If Blakley is right, and I believe to a large extent he is, then that would make it challenging for vendors such as BWise, CA, and Oracle to make inroads with their GRC applications. These applications aim collect data throughout an organization, and help them to be able to monitor how well risk is being managed, whether that be IT security risks, regulatory compliance risks, or other sorts of business risk, such as that from natural disasters, and how well the business continuity and disaster recovery plans have the company prepared.

However, Blakley argued that governance, risk management, and compliance, as a whole, can't be automated -- that these are fundamentally human responsibilities and tasks, tools that can be used to automate certain tasks within the separate GRC functions, and that they should be maintained -- and thought about -- as individual silos.

There are many tools that help organizations manage and automate IT security related risks, from identity and provisioning management to vulnerability scanners and patch managers, and it's also gotten easier to attain the data from those security tools, application logs, provisioning reports, and financial systems to better manage all aspects of regulatory compliance and audit survival.

However, there's not been the same headway in the governance part of GRC. Here's how Blakley defined what needs to be done to achieve proper governance:

• Define organizational risk appetite
• Define corporate policy
• Assign responsibilities to specific people
• Review regular risk management reports
• Measure risk managers on value creation
• Define organizational compliance targets
• Review variance and time-to-remediate reports
• Measure compliance officers on time-to-remediate and compliance effectiveness

While some of these governance activities could be reduced down to a dashboard view, by the time the data and metrics for both regulatory compliance and IT security are pushed up to the executive level, so much detail will have been lost the report would be meaningless.

I also agree with Blakley that GRC should not be used as a "catch-all" term. Security, compliance managers, and business leaders need to say exactly what they mean: governance, risk, or compliance when discussing risk management. And you need to make sure you force your vendors to do the same.