<Rather Technical - for the jargon wielding consultant - casual readers read at your own risk> Why do you take a risk? Because you want to be rewarded. If there is no reward, there is no point in taking a risk. You put money in the stock market because you want to multiply it. You climb into a raft hurtling down rapids because you want to feel the exhilaration. You ‘expect’ a reward for every risk you take. This reward is the ‘upside’ or the ‘positive risk’. You can either lose money (downside risk) or gain pots of money (upside risk). You can either suffer grievous  injuries (downside risk) or tell stories to anyone who is willing to listen to you about your adventurous rafting experience (upside risk). These ‘upside risk’ and ‘downside risk’ seem like  natural definitions. We have always been told that risk and reward are two sides of the same coin. This perspective of upsides and downsides to risk is also mentioned in the ISO 31000. It defines ‘Risk’ as the effect of uncertainty on objectives. While that statement alone does not tell us much, ISO 31000 cleverly adds a few notes. One of the notes says that ‘effect’ means a positive or negative deviation from the expected. There you go. The international organisation for standardisation clearly stating that risks can be both positive and negative. While I understand the logic behind it, I completely disagree with this definition of risk. (Yes, I am the idiot who has boatloads of problems with auditors from certification bodies who interpret things in their own way - usually ending in someone kicking me across the table on my shins and grinning at the auditor “Fine, we will create a document that mentions blah blah blah. That should resolve it, I am sure?” with the auditor replying “That is what I have been telling you all morning.”) I think this definition of risk causes a lot of confusion to us information risk and ISMS professionals. Especially with the risk assessment of ISO 27001:2013 aligning itself with the ISO 31000 principles and guidelines, the confusion starts to compound. ISO 27000, defines risk as the combination of the probability of an event and its consequence; and it defines an ‘event’ as the occurrence of a particular set of circumstances. There seems to be little correlation between the two definitions! Imagine that you are doing a risk assessment for a critical server in your data centre. You come up with the threats and vulnerabilities that can affect your server. For example, you have diligently listed down “Lack of timely patch application” as a vulnerability and identified “Virus” as the threat. You start to write the consequences. You imagine the worst possible scenario (prepare for the worst, you were taught). Is there an upside? In fact, SHOULD you be thinking of an upside to this? Is your method wrong? Should you focus on the overall objectives that the server should achieve? - Something like 100% uptime and a glowing performance review followed by a plum pay rise? I think it is time to leave these confusing definitions aside (and use them only for certification audits) and think of some practical definitions. Remember the old probability theory you studied in school? Coin tosses and dice rolls? Bags containing balls of assorted colours? This should be our starting point. For any possible asset in use, there is a bevy of ‘events’ that can happen. If you roll a die, you can get either 1, 2, 3, 4, 5 or 6. Your event space is {1,2,3,4,5,6}. The technical term for this is a sample space. Of course you can have this event space as infinite. (For example - the number of patches released by Adobe on any given day:)) Let us say, a friend lays a bet with you. If you roll a number greater than 3 on the dice, he will buy you dinner and if you don’t, you buy him dinner. It is a fair wager, with equal probability, but we are getting ahead of ourselves. We know that there are six possible ‘outcomes’ of you rolling that dice. There is ‘uncertainty’ around the ‘outcomes’. You are willing to take the ‘risk’ of the outcome being {1,2,3}, because you want a free dinner. All possible outcomes represent the uncertainty, while unwanted outcomes are your risks. You can take steps to mitigate this risk, that is, increase the probability of wanted outcomes over the probability of risk. You can ‘load’ the dice so that the probability is higher for it to roll{4,5,6}, or you can try to convince your friend to pay for anything other than a 6 being rolled. You are doing ‘risk mitigation’ in this case. It is really that simple. Of course, purists would want to hack me to pieces, but that is a risk that I am willing to take for the pleasure of simplifying infosec. So, unknown outcomes imply uncertainty. You don’t know whether your outcome will be positive or negative. You are uncertain. Negative outcomes are risks that you try to avoid or mitigate. You have a server installed for handling emails. It can result in a pleasant communication system for your entire organisation (Expected outcome). However, it can crash, leaving no backup. It can get affected by virus. A disgruntled employee may pull the power cord. A fire may gut all records. Etc. Etc. (Risks). You put in controls to reduce the probability and impact of the risks, while increasing the probability and impact of the expected outcome. This way of looking at ‘events’, ‘’outcomes’, uncertainty’ and ‘risks’ simplifies our thinking. It may or may not be the official line to tow, but it is easily the simpler and more practical.