# Risk Calculation: Probability x Impact + Time

Regarding the simple calculation of probability multiplied against impact to capture an exposure value, has anyone seen a formula that adds time to it? The formula in question is p x i + t, where t is the time period when the risk is predicted to occur. When the period is closing in on the actual time, the overall exposure increases by some value.

I have never seen anyone use this formula before until now on my current gig and, after some research, have not found any supporting documentation.

I know this is a simple and often times inaccurate way to truly measure risks but this is an immature organization so baby steps.

• How is time usually being expressed here? Is this like delay profiles, where the probability increases or decreases in a linear way or is fixed time (it will either happen at y2k or it won't at all)? Commented Feb 2, 2023 at 17:29
• Like a trigger date, the date of expected impact. So as time goes by and we get closer to that date, the exposure continues to increase. @Daniel Commented Feb 2, 2023 at 17:49
• It sounds like trying to merge the r = p x I formula with cost of delay, but that's the closest thing I've seen to this. Don't know if that's helpful to you at all. Commented Feb 2, 2023 at 18:00
• Yeah, I'm not sure. It doesn't make sense to me but I could be very wrong. Commented Feb 2, 2023 at 18:57

## TL;DR

The formula doesn't look like a standard risk management formula. While there may be a reason for it, it's likely very organization-specific, and you may want to do a five-why's to understand the goal.

Otherwise, I'd push for a more standardized and holistic approach to risk management that matches the organization's approach to overall program/project risk and aligns with their budget and cadence for implementing controls.

## Thoughts and Suggestions

I've never seen the particular formula you're referencing, as quantitative risk analysis is most useful when you look at it over a fixed or sliding time window. In cybersecurity in particular, you have some standard risk metrics such as:

• Asset Value (AV)
This one should be self-explanatory.
• Exposure Factor (EF)
This is generally a multiplier representing the impact on the value of an asset from an actualized risk. This multiplier could be a fraction of the AV (e.g. you lose 20% of your customers) or more than AV when there are stiff regulatory penalties (e.g. each customer is worth only \$250/year in revenue but the regulatory penalty is \$50,000 per customer record compromised).
• Single Loss Expectancy (SLE)
The estimated financial cost of a realized risk, where `SLE = AV x EF`. In other words, this is a business impact analysis (usually expressed as a dollar amount) for an incident.
• Annual Rate of Occurance (ARO)
The number of loss events you estimate you will experience in any given year.
• Annualized Loss Expectancy (ALE)
The estimated amortization of the risk over your time window, defined as `ALE = SLE x ARO`.

There may be some circumstances when a given risk increases as you get get closer to some target date, such as the risk of a movie being pirated increasing during the pre-release period between post-production and theatrical release. Still, I suspect that the right way to look at that is either to consider the Asset Value (AV) as increasing over time, or the Exposure Factor growing higher.

In any case, you may want to amortize the risk or impact over a different window than yearly, perhaps replacing ARO with the length of your project/program and just rolling in any increasing AV or EF values by treating the SLE as a range or statistical mean. Unless the idea is to somehow increase your risk management controls in lock-step with this unexplained time-related variable, I don't understand the utility value represented by graphing risk as a linear function of time.

Furthermore, `(p x i) + t` would not really change the calculation much unless you somehow represent t as a very large number. Mathematically, multiplication takes precedence over addition, so the impact of t as presented would only cause a monotonic increase. Instead, if you really need to do this calculation at all then it might make more sense to think of it as `t(p x i)` to graph the effect of time on both p and i. This still doesn't seem intrinsically useful to me, but I suppose there could be use cases I haven't thought of.

With that in mind, I would ask someone within the organization about the rationale and objective of calculating risk this way rather than simply controlling for overall risk, and then planning based on the organization's current risk appetite. Since risk changes over time anyway, it just seems more likely that you will still need to periodically re-base your risk calculations and re-evaluate your risk controls the same way you would with anything else in a project plan. I know that you'd never assume that project risks wouldn't change over the life of a project, so I'm not sure why it makes sense to assume that any other type of risk would be more invariant. Just load more work packages for assessing the current risks and controls throughout the project lifecycle if that's the real concern.

If it's something else, then either someone in the organization needs to explain it better, or you should convince them to simply roll elapsed time, or time remaining until some milestone is reached, into a more standard approach to risk management that can be amortized over the life of the project. This avoids trying to represent risk as a continuously changing value instead of something that should be periodically reviewed. I also think a continuously-changing risk value would be very hard to control for outside of an extremely iterative approach; so, I wouldn't recommend even trying to manage an unstable value outside of a well-oiled agile framework without an exceptionally strong business reason.

It seems to me that the probability variable is not independent of time; combining them this way would have the effect of ensuring that the event would occur within a timeframe ((1-probability)**time). That's intuitive, but doesn't model the real world. - a gambler's paradox - you can bet on 11 on the roulette wheel 37 times in a row and lose 37 times in a row (or more simply, you can lose by betting on heads in three successive coin tosses). I fear that this would misinform the decisions.