Main Story: Security, Reconsidered
WESTERMAN: We hear that, and I actually believed for a long time that if we put more process, governance and standards in place, we actually would hurt the agility of the company. But more and more research that my CISR [MIT Sloan Center for Information Systems Research] colleagues and I have been doing shows you can actually have standards, processes and agility. You don't want to be too Draconian, but if we have a good solid foundation, a very well built architecture, and a streamlined yet tight governance process, you can actually have both security and agility. But typically, when you put a risk governance process in place, it tends to be much more difficult before it gets better. It takes a while to work out.
So realistically, expect it will slow you down until you learn to do it better.
Absolutely. And then make sure you are continually improving that process. The idea is to give people good standards to live by, good policies to follow, and then allow them to do their thing as long as they're following those standards and policies. That allows them to be agile while living within a reasonable set of rules. For example, when PFPC, a financial services transaction-processing firm based out of Delaware, first put their risk governance process in place, they identified 300 supposedly major risks. That wasn't useful at all because 300 risks are so many it's hard to keep track. It turned out they had a lot of inconsistency. Two out of seven people involved in the process had identified two-thirds of the risks. The others may have identified not enough risks. So they boiled it down to 30 risks. They started understanding, what does it mean to be a high risk, what does it mean to be something you would report to corporate as opposed to keeping it in your own area, how do we report risks in a consistent way. They got down to 18 or 19 relatively high-importance risks. Now, that's a manageable number; when the CIO goes to the enterprise risk committee meetings, he's got a small number of things he wants to talk about.
Another example of a good risk governance process is [European telecom company] TeliaSonera. They have a really nice process for doing internal security audits on new projects and existing applications. They have tried to make it very much a partnership between IT and business. They identify issues, and work out who will take care of them. Then they come back later to see whether the issues have been addressed. Because they work in partnership--IT does some parts, the business units do other parts--it's non-threatening. It's very much, let's manage the risk in this organization, as opposed to, let's find all the mistakes you've made. This partnership has made the reviews easier because people feel less threatened. The head of security said when we come back these risks have all usually been handled; we almost never have to come back and tell them twice because of the partnership model they've developed.
The last bit I've heard that's really interesting is using the internal IT auditor center at the beginning of the systems development process. In many cases internal auditors tend to function almost as an afterthought--they come in afterward to just kind of bless the system. But more and more CIOs I've been talking to say the best thing they've started to do is put their internal auditors into the initial meetings of a new application development project. The auditors help them avoid issues right up front, so when it comes time for a different auditor to sign off on the system later, the problems aren't there.
So, yes, people are learning to balance security and agility well, although we don't always hear about it. But many people are still struggling to figure out how to make business aware of security issues and talk about risk issues in a holistic way, so businesspeople can make the right investments.