I’ve discovered another golden building block in my ongoing effort to construct The Ultimate Guide to Ethical and Effective GRC (are you listening, Wiley, HBS, and Penguin/Portfolio?).

Recently, I’ve been studying GRC talent preferences as well as the makeup of operational risk councils (or risk committees), which seem to exist in every leading GRC organization. More recently, I’ve been honing in on the art and science of “exception management.”

I want to hear from you about this pivotal process. How do you handle exception management? What works? What doesn’t?

Exception management is the process by which people respond to the information that GRC technology spits out. As those of you with GRC application experience know, these tools can spit out a deluge of information. That’s why I love this topic; it blasts all of the core business elements to center stage: people, process, and technology.

When executed correctly, exception management enables the organization’s investment in GRC technology to generate valuable returns; it also helps business process owners take on greater GRC responsibility (without too much extra heavy lifting).

However, if exception management is ignored or botched – and it often is – the technology and the entire GRC program can falter. (One internal audit executive told me about a real-life situation in which an application continually e-mailed exception alerts – about a potentially major internal controls red flag – to a manager who no longer worked at the company.)

Here’s the challenge: Most GRC tools – enterprise risk management, continuous controls monitoring, identity management, continuous auditing, access controls, etc. – alert users to potential problems, which are called exceptions. Talk to any GRC manager who implemented a tool in the past five years, and they’ll tell you that the application initially identified hundreds to thousands to tens of thousands of potential “violations.” Countless CFOs, internal auditors, and other GRC people told me this – and then quickly added, “But, please, please, please keep that off the record because it will look terrible.” (Ah, yes, the joys of interviewing a risk-averse profession.)

It may look terrible out of context, but closer inspections inevitably reveal that the bulk of these thousands of violations are not violations at all.

Many were “false positives.” In other words, there were perfectly rational and acceptable reasons why these exceptions were identified as red flags by the application. Technology does not “know” this because it is not intuitive (not yet, anyway). The technology needs people to help create the rules and parameters by which it scours data.

For example, it may be an internal control violation to have the A/P manager in the Tucson office approve an invoice and sign the check to that vendor; however, what if the A/P manager is the only accounting employee in the tiny Tucson office? That’s a risk that we accept. As such, this rule needs to be reflected in the application and internal audit, among others, needs to be aware of this exception. This sort of process needs to be repeated thousands to tens of thousands of times in large companies that use automated GRC tools.

This exercise requires people skills. That’s why gray hair helps. Or, if you’re a younger GRC professional, it helps to have the chutzpah to engage business process owners in the exception management process: Why do you do it this way? How can you do it differently? Are you willing to accept responsibility for this risk?

In the next magazine issue, I’m devoting an article to the art and science of exception management. If you want to participate in that discussion, drop me a note. ###