There was a time when the IT security department had the only say in approving or denying operational requests. It made for an easier, more secure place to work - but there was no real communication with business development and operations to determine which actions were, in fact, worth risking in the name of achieving business goals. These days, senior management and the risk management department are increasingly in charge of the final decision as to how much risk is acceptable for a given operation, from requiring near-perfect safety to accepting absolutely open operations. IT security's task is now to analyze particular pursuit for threats and risks, list mitigations (and risk acceptance), and perhaps offer recommendations. IT security shouldn't be making the ultimate call on risks. To be honest, I like it that way. Why be responsible for more than you have to be? The challenge has been for management to understand and accept the reality that there's almost always a chance of risk. After all, it's tough to predict unknown unknowns. I doubt, for example, that decision makers at organizations such as Sony, RSA, and the U.S. Army understood that leaving computers unpatched or allowing end-users to click anything they wanted would likely to lead to reputational compromises costing hundreds of millions of dollars. Yet some CEOs or boards of directors either aren't prepared to hear about the potential costs of an attack or of implementing perfect security. The best organizations, by contrast, understand that reputational cyber attacks are likely to happen in the future - thus, they don't shoot the messenger. IT security departments need to feel confident and secure in being able to deliver the potentially bad news as accurately as possible. Figuring out the probability of a particular risk occurring requires first acknowledging that it is likely to happen. If the likeliness is truly low, then it's an easy probability to plug in to your equation: 0.0 percent. If it is likely to happen in the future but you don't have historical measurements on which to base future estimations, start with a long time range and work backward. For instance, would a particular security event be likely to happen in the next 30 years, even given everything the company is doing to prevent such an occurrence? If the answer is yes, you have a baseline to work with: 1 out of 30 years, or 3.33 percent. For large security incidents, such as reputational events, I'd at least go with this baseline. If you're a big company or a larger target or you lack the commitment and resources for such a big fight, maybe one incident every 5 to 10 years is more realistic. Smaller events, such as malware infections, exploited servers, and availability issues, should be easier to base on historical evidence. When in doubt, bear in mind that these milestones are often measured in years versus decades. Also note that events, large and small, aren't mutually exclusive. A small incident might lead to a reputational event, but since you don't know when that is likely to happen, you have to account for both. I get the distinct feeling that organizations handle the small items fairly well, but they don't account for the reputational-level happenings. Beyond underestimating the probability of a security event, there's a tendency to underestimate the likely resulting damage. These costs can be just as difficult to calculate. Again, I'd start with broad ranges to help develop boundaries. For instance, how likely is a security event to result in $100 million worth of damage? At billion-dollar companies, that's a likely outcome over a 30-year period - and should be accounted for as such. IT security departments are no longer the gatekeeper, but perhaps we haven't done a good job of sharing the realistic likelihoods and probabilities. Heck, the last few years have been a wake-up call for us all, reminding us we need to evolve.