While doing a Risk Assessment, I found that in some old RA documents, after controls have been placed, the Impact in the forcasted value was changed that did not make sense to me. To me the impact never changes as the impact of a critical service being down is the same whether a control is in place or not. What changes however is the probability bring the Risk down (Risk = Probability x Impact). Is this correct?

3 Answers 3


The impact may change if the control put in place alters a potential attacker's abilities should the problem be exploited.

A good example of where the impact would change is when the mitigation involves segregating networks. Before the segregation, an exploit on OldCorp Unsupported Legacy Daemon X might lead to someone getting access to the internal network, then exfiltrating all your yummy internal documents out of SMB shares. After segregation, the box on which OldCorp ULDX sits is no longer in a position to route packets to your "regular" corp network, so the impact of it getting owned is reduced.

  • 1
    Yet this introduces the risk of complacency and updates lagging behind :) Sep 2, 2013 at 13:11
  • 3
    Sometimes business critical means putting legacy crap on a risk register and firewalling it off until it can be replaced. Sucky, but that's life.
    – Polynomial
    Sep 2, 2013 at 13:31
  • 2
    An even classicer example is any least privilege situation for services - if you exploit the service, you are still limited in your impact....
    – AviD
    Sep 2, 2013 at 14:26
  • Interesting view point. I was thinking on the example of disruption of service (Impact). In your example above, I would consider the Illegal Access to internal network as Impact and the security breach to the legacy server as threat. While I can agree that the threat can be reduced but the Impact of security breach (regardless of how it is caused) does not change.
    – AdnanG
    Sep 2, 2013 at 16:39
  • You misunderstand threat, risk and impact. The threat is from your external agent. The risk is that someone penetrates the network or the server. The impact is loss or destruction of data, service interruption etc
    – Rory Alsop
    Sep 3, 2013 at 20:07

depends on what you mean by "controls" then. given the fact you use a monitoring-system you still will have the impact of a service going down, but you will get noticed very soon and can start recovery. or, if monitoring intelligently, get noticed and act before a service might go down.

the sames goes for implemented standby-systems that could take over sevices, either fully or halfautmated, or stuff like emergeny-response-plans. everything that helps keep the time-to-recovery short, will limit the impact.

you'll always try to avoid outages, but redundancy is costly, so your option is very often to limit the time to recover, if an outage might occure. If you take the calculation from Feral Oink, Impact(event) might be described as Impact(outage * outage_time) where you are able to influence the outage_time, thus decreasing the impact.

  • That is logical. If we have a control as a redundant server that works as in active-active mode to handle the traffic of the down server, the impact of the first server going down is reduced. However, when we have the impact in the same scenario as the service interruption of the server, the impact is regardless of the reason for this service interruption which would mean no change in impact. It boils down to how we are defining the terms at the end and what controls are we putting in place.
    – AdnanG
    Sep 3, 2013 at 2:27

Your definition of risk is Risk = Impact(event) * Probability(event).

The general case is expected value, or E(x) = x * Prob(x).

If we want to describe it in measurable terms, dollar value is the most general metric of choice that people can be convinced to care about, so

Dollars-at-Risk = Loss due to event * Probability of event occurring

Your risk policies will lower Probability of the event occurring (the incidence level), we hope!

In the absence of any documentation, it seems likely that your predecessors, who drafted the old risk policies, made the mistake of changing both terms. The only way that the other term, Loss due to event will change would be from something external but causal e.g. passage of time, or due to contingency. Let's say the incident is a network breach that results in a system outage.

Passage of time
The dollar loss due to an outage could have increased since your colleagues drafted their risk analysis documents. For example, costs due to outage, and the associated lost productivity, might be higher because current staff, i.e. data scientists, are more skilled and more highly compensated than their predecessors, i.e. applied statisticians.

System outage impact might have decreased. For example, statisticians, I mean data scientists, do all their high performance computing in the AWS EC2 cloud (via BYOD smartphone) now, instead of a Cray or mainframe in the basement.

Contingency-based risk assessment would be exceedingly unlikely without an accompanying explanation. Any such explanation would be included, as part of the risk control policy.

Also, it would be difficult to do with any accuracy. Merely as a thought experiment, let's extend that outage scenario. An outage might not affect the data scientists, but it could take out billing and payroll processing, which would be very costly! But that would mean that the basement mainframe went offline. No risk mitigation policy is likely to cover such an extreme outlier event, nor should it, not as long as there are mainframes running MVS/TSO, and RACF.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.