OK, Fine. How Do I Start?

ERM will be hard before it's easy, but Frame says the payoff for doing it will come sooner than you think. "Just start, and in six months you'll have the data to start making better decisions."

There are many methodologies that companies can lean on. Which one you're using should matter as little to you as it matters to your customers what internal IT systems you use. For example, Weymouth says Barclays bases much of its risk processes on Cobit, but that doesn't mean he's memorized the document.

Consultant Lam preaches getting started without getting stuck on the details. At first, "going through the process provides more value than the end product", he says. "The process itself will start to expose all those hidden risks, those interdependencies and risks across business units you never considered."

So, without getting stuck on particular methodologies, here is a basic chronology of what you'll be doing.

1. Risk identification. This is, basically, brainstorming. "It's almost too simple," says Higgins. "All it is is 'What if?' "McCann's Sharon, in a previous job as a risk officer, says he handed out questionnaires asking IT staff and business end users to rate risk in five categories. You'll have meetings with the leaders of HR, IT, legal, finance and so on to brainstorm risks to the company. IT will be asked to talk about, say, the environmental risks IT poses to the company. At Rockwell Collins, the risk that a tornado takes out the infrastructure or causes downtime might be mentioned. "But we wouldn't think about hurricanes in Iowa," where the company is headquartered, says Gemmer. The guys in Florida will bring it up. Then, the discussion moves to the enterprise: If the systems go down, what does that mean to our business? Loss of revenue? Reputational damage from call centres being unable to help customers? And so forth.

The point is to talk, and in talking, to find the risks that otherwise might have slipped through the cracks.

2. Risk assessment. You've identified your enterprise risks. Now you need to categorize them. The easiest way to start this is to map them on a probability-impact chart. A simple chart with "low, medium, high" on each axis will allow you to map the probability and impact of each risk. Here's how Weymouth of Barclays explains how he manages the risk of unlicensed software: "When you've got 95,000 desktops, unlicensed software presents a risk to the company. We quantify the gross risk. In the worst case of having to buy licences, pay fines, whatever, the amount comes to X pounds. But we mitigate that risk. We do licence audits. We [raise] awareness. So after all that is laid out we believe that the worst case, mitigated, is actually .2X pounds. Then you look at the probability of that occurring to come up with a net risk."

Once again, the key here is not precision but accuracy. If Weymouth were using real numbers, .2 would be an educated guess. Even more important than accuracy is consistency. Every part of the company defines "low, medium and high" the same way.

MIT's Westerman uses the example of a global chemical company that defines high impact as something that affects 10 percent of working capital, medium impact as equalling 5 percent to 10 percent, and low as less than 5 percent. High likelihood means within a year; medium, one to five years; and low, not likely in the next five years. The point is, every department uses the same metrics and talks the same risk language.

3. Risk mitigation. Eventually, you'll have a map of your enterprise risks. From there, you'll look at how you are controlling risks, see how effective those controls are and decide what else you need to do. While you play a supporting role to the risk office in identifying risks, when it comes to mitigation, you'll be counted on to lead. The risk office can arbitrate the identification of risks, such as that of using unlicensed software. But only you can assess the countermeasures you have in place, such as routine software inventories or controls on desktop configurations, which will offset those risks.

When Higgins implemented a risk management framework at the FBI, she found that one of the risks during the desktop modernization phase of her project was change management for users. If that was not properly handled, user productivity would plummet. This could severely affect intelligence analysts' ability to fight crime, a sensitive problem in the current political climate. (Note the way the risk connects from IT to the analysts to politics, and that the effect of the risk is not specific to IT.) Higgins piloted the rollout on a small scale and used data from the pilots to fine-tune the risk profile of the project.

At this stage, you're making decisions based on what the risk data tells you. You've started to manage by the principles of risk.