There are a few different notions of risk used in dependability engineering.<\/p>\n
One notion, used in finance and in engineering safety, is from De Moivre (1712, De Mensura Sortis in the Proceedings of the Royal Society)<\/a> and is A second notion, used in quality-control and project management, is Suppose you have a \u20ac20 note in your pocket to buy stuff, and there is an evens chance that it will drop out of your pocket on the way to the store. Then according to (A) your risk is -\u20ac10 (= \u20ac20 x 0.5) and according to (B) your risk is 0.5 (or 50%). Notice that your risk according to (A) has units which are the units of loss (often monetary units) whereas your risk according to (B) has no units, and is conventionally a number between 0 and 1 inclusive. <\/p>\n (A) and (B) are notions 2 and 3 in the Wikipedia article on Risk<\/a>, for what it’s worth.<\/p>\n The International Standards Organisation (ISO) and the International Electrotechnical Commission (IEC) put out guides to the inclusion of common aspects in international standards. One is on Safety Aspects (Guide 51, 2014 edition)<\/a> and one is on Risk Management (Guide 73, 2009 edition)<\/a>. The Guide 51 definition of risk<\/i> is the combination of probability of occurrence of harm and the severity of that harm<\/i>, where harm<\/i>is injury or damage to the health of people, or damage to property or the environment<\/i>. The Guide 73 definition of risk<\/i> used to be change or probability of loss<\/i>, i.e. (B), but has changed in the 2009 edition to the effect of uncertainty on objectives<\/i><\/i><\/a>. <\/p>\n The 2013 edition of ISO\/IEC 15026 Systems and Software Engineering – Systems and Software Assurance, Part 1: Concepts and Vocabulary (formally denoted ISO\/IEC 51026-1:2013), defines risk<\/i> to be the combination of the probability of an event and its consequence<\/i>, so (A).<\/p>\n The IEEE-supported Software Engineering Body of Knowledge (SWEBOK)<\/a> says, in Section 2.5 on Risk Management,<\/p>\n Notice what can go wrong<\/i> is hazard identification, how and why<\/i> is analysis, along with what are the likely consequences<\/i>, which is severity assessment, also part of hazard analysis. What is missing here is an assessment of likelihood, which is common to both (A) and (B), the Guide 51 definition and the Guide 73 definition.<\/p>\n ISO\/IEC 24765:2010 Systems and Software Engineering – Vocabulary defines risk<\/i> to be<\/p>\n ISO\/IEC 24765 thus acknowledges that there are different notions doing the rounds.<\/p>\n The System Engineering Body of Knowledge (SEBOK) says in its Wiki page on Risk Management<\/a> that<\/p>\n the probability (or likelihood) of failing to achieve a particular outcome which is a version of (A).<\/p>\n What are the subconcepts underlying (A) and (B), and other conceptions of risk?<\/p>\n (1) There is vulnerability<\/i>. Vulnerability is the hazard, along with the damage that could result from it, and the extent of that damage; this is often called “severity”. So: hazard + hazard-severity. This is close to Definition 1 of ISO\/IEC 24765. If you have (1) and (2), you have (A) and (B). If you have (A) and (B), you have (2) (=B) but you don’t have (1). But (1) is what you need to talk about security, because security incidents do not generally have a stochastic nature.<\/p>\n
\n
\n(A) the expected value of loss (people in engineering say “combination of severity and likelihood”).
\n<\/center><\/p>\n
\n
\n(B) the chances that things will go wrong.
\n<\/center><\/p>\n
\nRisk identification and analysis (what can go wrong, how and why, and what are the likely consequences), critical risk assessment (which are the most significant risks in terms of exposure, which can we do something about in terms of leverage), risk mitigation and contingency planning (formulating a strategy to deal with risks and to manage the risk profile) are all undertaken. Risk assessment methods (for example, decision trees and process simulations) should be used in order to highlight and evaluate risks.
\n<\/i><\/p><\/blockquote>\n
\n1.<\/b> an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives. A Guide to the Project Management Body of Knowledge (PMBOK\u00ae Guide) \u2014 Fourth Edition.
\n2.<\/b> the combination of the probability of an abnormal event or failure and the consequence(s) of that event or failure to a system’s components, operators, users, or environment. IEEE Std 829-2008 IEEE Standard for Software and System Test Documentation.3.1.30.
\n3.<\/b> the combination of the probability of an event and its consequence. ISO\/IEC 16085:2006 (IEEE Std 16085-2006), Systems and software engineering \u2014 Life cycle processes \u2014 Risk management.3.5; ISO\/IEC 38500:2008, Corporate governance of information technology.1.6.14.
\n4.<\/b> a measure that combines both the likelihood that a system hazard will cause an accident and the severity of that accident. IEEE Std 1228-1994 (R2002) IEEE Standard for Software Safety Plans.3.1.3.
\n5.<\/b> a function of the probability of occurrence of a given threat and the potential adverse consequences of that threat’s occurrence. ISO\/IEC 15026:1998, Information technology \u2014 System and software integrity levels.3.12.
\n6.<\/b> the combination of the probability of occurrence and the consequences of a given future undesirable event. IEEE Std 829-2008 IEEE Standard for Software and System Test Documentation.3.1.30
\n<\/i><\/p><\/blockquote>\n
\nRisk is a measure of the potential inability to achieve overall program objectives within defined cost, schedule, and technical constraints. It has the following two components (DAU 2003a):<\/p>\n
\nthe consequences (or impact) of failing to achieve that outcome
\n<\/i><\/p><\/blockquote>\n
\n(2) There is likelihood. This can be likelihood that the hazard is realised (assuming worst-case severity) or likelihood that a specific extent of damage will result. This is only meaningful when events have a stochastic character. This is (B), the former definition in ISO\/IEC Guide 73, and item 3 in the Wikipedia list.<\/p>\n