TL;DR
Formal risk assessment is both a science and an art, and overly reductive models lead people astray. For example, consider this variation of a loss-expectancy risk model:
Risk models can be arbitrarily complex, and often rely on higher math to model a large set of possible events and controls. There is an entire field of study and a career path involved with formal risk assessment; I would argue that anything beyond the basics is out of scope (except as a possible input) to project management unless there's a defined phase for formal risk assessment along with sufficient subject-matter expertise assigned to the project. Lacking that, the KISS principle applies.
Focus on risks to the budget and schedule. Other risks, unless part of your charter, are generally out of scope.
Invalid Modeling of Controls
Possibility * Impact - Countermeasures
Your formula is inherently wrong. What you're looking for us something more like a modified model of annualized loss expectancy such that your mitigations reduce both your annualized rates of occurance (ARO) and your single-loss expectancy (SLE) by reducing your exposure factor (EF).
However, as @MarkCWallace has already pointed out, unless you are in a formal audit or risk-management role, the benefits of this complexity are often vastly outweighed by the project manager's core need to document and communicate risks to the project. Simply identifying the risk, and perhaps adding a gut-feel score, is often sufficient (from a project management viewpoint) as an artifact. It is then up to senior management to determine what strategic actions they want to take about the identified risks, including totally ignoring them.
A More Accurate & Comprehensible Formula
Since you can craft mitigating controls that independently impact ARO, SLE, asset value (AV), and EF, a more realistic risk model looks more like:
Residual ALE = Residual ARO x Residual SLE
Another way to think about this formula is:
Residual_Risk =
(ALE - Applicable_Controls) =
(ARO - Applicable_Controls) *
((AV - Applicable Controls) * (EF * Applicable_Controls))
In other words, you can apply controls to almost any piece (and often more than one) of your risk model, and any risk left over is residual risk that you can choose to mitigate, accept, or transfer.
Forget Everything But Costs & Schedules
From the project management perspective, the central benefit of identifying and capturing risks is to manage risk to the project's budget and schedule, and to hedge against the risk of delivering the wrong thing. Consider the following contrived example.
On a purely pragmatic basis, the risk that John Doe (who is the project's sole source of expertise on embiggening widgets, and has a heart condition) might become suddenly unavailable to the project is a much bigger risk to the schedule than the calculated annualized loss expectancy. The risk that Jane Doe (who has twenty years of experience, but through entrenched sexism is paid $0.60 on the dollar compared to her male colleagues) might leave the project to work for a company that doesn't discriminate against women is a tangible risk to your budget.
These sorts of risks can be quantified, but the qualitative risks are often easier to discern and much more visceral. It's still not the project manager's job to do more than hoist the risk flag so senior management can ameliorate the risks, but at least you're now focusing attention on risks that have a more tangible set of mitigations. For example, senior management can reduce risks to cost and schedule by adding resources, building cross-functional teams, or increasing the budget to pay people what they're worth.
As a project manager, you can (and generally should) suggest pragmatic controls when you can identify them. However, the choice to implement the controls belong to senior management. If management breaks the project, they get to keep both halves.
