How might a more constructive conversation about risk sound?
WESTERMAN: We talked to a medical transcription firm that went from zero to 3,000 transcriptionists over the course of about six years. They're a highly virtual firm, and they had to replace their backbone IT infrastructure to make this virtual firm work. So they put together two infrastructure plans. One was an Internet-based platform where hospitals could download doctors' voices to the system through the Internet, transcriptionists could download and transcribe them, and ship the transcripts back up again. The other plan called for a hardwired, bulletproof setup with all the kinds of hardware and software protections you would expect.
The management team, when deciding between the two viewpoints, had a holistic discussion of risk. The bulletproof infrastructure was great for two of the risks that should matter most to this firm: availability and access. It's health care data, so the setup had to be very secure. But it was hard to hook new hospitals into it, or use transcriptionists in other countries. In the end, management decided to go for the Internet, even though it meant a little bit of a hit on access and availability risk. If they hadn't thought all the way through to agility, they would have adopted a platform that would have made them more rigid and hurt the company's ability to compete.
Does addressing risk require different capabilities beyond what IT professionals think of as security, in addition to new ways of thinking?
WESTERMAN: There are three core disciplines of IT risk management. The first is the IT foundation: the applications and the infrastructure and the supporting skills. If you are well architected, you are just less at risk. A good architecture is only as complex as it needs to be. So how can we make the architecture only as complex as it needs to be, and make sure we are managing our IT foundation extremely well?
Another core discipline is risk governance: how we identify, assess and make decisions about risk, and then take action and monitor the results to make sure we have done something about it. We don't always think about how to do that with this holistic view of risk. There is this dilemma that the people at the highest levels, who are best able to make priority decisions among risks, are least able to know what risks the organization is facing because they're not down in the details. On the other side, the people who know what risks the organization is facing are least likely to have the enterprise-wide perspective to prioritize risks.
In most organizations an effective risk governance process is highly distributed; the people who are closest to the work identify risks, and higher-level folks can look and make those prioritization decisions. Then the work of mitigating the risks can be sent back down to the people who are managing at the field or corporate level. It's a way to take the distributed knowledge and the centralized perspective and put them together. And having done that, expand the set of risks to talk about to all the risks, not just the ones we typically think about with security.
The third core discipline is having a risk-aware culture. Without it, the other elements will fail. A risk-aware culture has two elements: awareness of what threats they're facing, and how to behave in a risk-aware way. The ability to talk about risk among your peers and what we can do to fix it is a big deal.
Beyond top executive support, how do you create real risk awareness, not just lip service?
WESTERMAN: We did some survey research on risk management mechanisms. It turns out that risk awareness training is the Rodney Dangerfield of risk management; it gets completely no respect. But as it turns out, it's one of the most important things we have. Firms that do risk awareness training actually have lower risk for availability, accuracy, access and agility.
The trick to making risk-awareness training work is letting people at each level know what is appropriate for them to know. Talk to end users about protecting their own access, privacy issues, and how to deal with people outside the company. On the IT development side, talk about how we think about controls, how we make sure we've architected well, and that we have the right security in place. At the very top level, the key element is how to lead by example. Do we ask about risk at the same time we ask about return? Do we talk about funding projects that will reduce risk even though they might not have a huge ROI? The most important thing, though, is that the senior team leads by example and says, here is how we want to think about risk, here are the kinds of questions I'm going to ask regularly, here's how we're going to make those tough decisions, and even sometimes go against our own personal interests in the interest of a less risky enterprise.
It can be hard to assess and agree on risk. How should companies do it?
WESTERMAN: One of the best ways to identify risk is to do, in essence, an internal audit. Hold an internal brainstorming session or get an external IT auditor to help you identify the risks you're facing. Internal folks don't always see the situations that lead to risk, because they're in the middle of them. But eventually we want to get out of that audit-oriented view and imbed risk management into IT projects. So as you go through your basic business case to do a project you think about architectural compliance, data center capacity and other elements, and about what IT is going to do to the operational risks of the firm at the same time. Then you can say whether this project is taking us in the direction of less risk or more risk, and ask what we can do to prepare for any additional operational risks this project may create.
Let's say you do a risk assessment and you find that many areas need improvement. That can feel overwhelming. How do you get started and how do you follow through afterward?
WESTERMAN: We recommend doing business continuity planning in parallel with the IT audit. Business continuity planning requires not only understanding what is going on inside IT, but also what it means in terms of priorities for the business. If a system goes down, what processes are affected and how important are those processes to the business. In the process, we make decisions about, say, our tolerance for downtime on this system versus that system. Those are business decisions on priorities that really need to be made with the business. In addition, business continuity planning talks about when systems go down, which ones need to come up first and in which order. Business continuity planning is a wonderful way to start those conversations about business tradeoffs. But at the same time, do the audits to find the holes we ought to fill immediately.
Many companies run into trouble because risks that seem low turn out to be high, or because they were unable to anticipate risks. How do you avoid these problems?
WESTERMAN: This is a big issue. A lot of that is done through external benchmarking, comparing and measuring incidents you've experienced with incidents other people have experienced, to try to figure out whether your likelihood and impact estimates are correct. It's a matter of taking your assessment and continually revising it. Monitoring what's happening to competitors is also helpful.