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.
