Risk Management: Set Your Domain Experts Free
The blogoshpere is kind of funny sometimes as we all run around referencing each other constantly, so you’ll have to excuse the “my sister’s best friend’s 2nd cousin twice removed’s boyfriends bookie” path for this post. (Actually, I really dig all our cross referencing, I think it creates a cool community of experts). Everything started with Alex Hutton’s What Risk Management Isn’t post, to which Mike Rothman replied, to which Arthur at Emergent Chaos replied. Follow that? Me neither, so here’s most of Arthur’s post (hopefully he doesn’t mind I lifted so much of it). And if it’s confusing at all make sure you read Alex’s original post: Rothman: But I can’t imagine how you get all of the “analysts and engineers to regularly/constantly consider likelihood and impact.” Personally, I want my firewall guy managing the firewall. As CSO, my job is to make sure that firewall is protecting the right stuff. To me and maybe I’m being naive and keeping the proletariat down, but risk management is a MANAGEMENT discipline, and should be done by MANAGERS. Arthur: I have to disagree here. Risk management in the end is the responsibility of management and as such the final decision belongs to them. But how can I as a manager make the right decision and know that a firewall is protecting the right stuff, if my team isn’t well educated on what the risks are? How am I supposed to make the right decisions if don’t know what the issues are? I need to have a staff of analysts, architects and engineers that I can trust to be regularly analyzing and evaluating the systems, applications and networks, so I can make the right choices or recommendations. I don’t need someone who blindly follows a help desk ticket. I don’t know a single CSO who wants to be micromanaging those sorts of decisions. About 5 years ago I got tasked with writing some research in risk management, and it took me over two years to actually get anything published. It’s like, hard, and stuff. Anyway, I came to the usual conclusions that risk management is stuck in too many silos, too many people focus on numbers of no real validity, management can’t understand detailed risks in a specific area, but domain experts can’t understand or manage risks outside of their domain. (I even ended up authoring a called “The Gartner Simple Enterprise Risk Management Framework” (sorry, my employer owns it so you have to be a client to read it)). The thing is, as these various posts illustrate, risk management falls into silos for a reason. We want domain experts making risk decisions in their domains. After nearly 20 years of various rescue work I can make a snap risk decision in that domain that’s far more accurate than any BS statistical model someone else comes up with. By the same token there’s no friggen way that expertise allows me to make a good risk decision outside that domain. In physical security I was great at managing the crowd safety issues at a concert, but we probably would have gone out of business if I chose the acts. (All Buffett all the time baby). So whatever risk approach you take, you want one where executive management makes overall risk tolerance decisions, but individual domain experts measure risk in their areas of expertise. You want a system that gives you the ability to communicate between management and operations. No manager needs a detailed analysis of the latest RPC DCOM flaw, they just need to know if that could cause problems for the overall enterprise, how bad, and where. So Rothman, Arthur, and Alex are all right. Mangement is responsible for overall risk, but domain experts must be the ones making and measuring risk decisions in their specific areas. Management needs to communicate risk tolerance to the experts in a language they can understand, and those domain experts need to communicate enterprise risks back to management in a way they can understand. Yes, it’s possible and probably easier than you think. It can speed up risk management since you don’t get wrapped up in garbage stats and fake ROI arguments. It just takes a good framework, a little bit of effort, and a few people that know what they’re doing to kick it off. Share:
