When threat modelling, should you include the threats a system cannot mitigate?

If so, where should you stop? It could be very time-consuming to list all the threats one cannot mitigate.

4 Answers 4


It depends why you cannot mitigate them and what you'd get from writing them down. You certainly want to find categories, rather than listing individual threats.

For example, it may be that you cannot defend against root. If it keeps coming up, write it down and move on by pointing at it when the next variation comes up. Writing it down is useful because it lets you get out of ratholes. You want to write down the category ("Root wins" vs "1. root can change this config file; 2. root can stop this process...")

It may be that you have a slew of threats because you're taken a dependency on some rev of (say) Ubuntu which includes a lot of attack surface, in which case writing it down may help someone who can authorize moving off Ubuntu to a smaller distro.

A list of threats you cannot address can be useful as part of your security documentation (MSFT does this with "10 immutable laws of security") to manage relations with customers and bug finders.


While I think Jonah B covered things pretty well. Just to be more direct.

I would say "Yes", certainly.

Risks you cannot mitigate are as important as any other risk.

Residual risk is the important measure. This is the risk that remains after mitigation. You take all of the residual risks into account when working out the overall risk. Where there is no mitigation, the residual risk is the same as the initial risk.

Then, as Jonah says, you need to have an open discussion within the organisation about the residual risks and what they mean to the business. You also need to understand the risk appetite. How much risk will the organisation want to carry? This needs all organisational risk to be managed holistically of course.

UPDATE: Where should you stop? When the risks are irrelevant.

This also depends on who you are doing the modelling for. Senior and C-level people will only want the big ticket items that impact the business as a whole. Project Managers will want anything that could impact project delivery. Service managers want risks that will impact live running, SLA's etc.

If you are modelling a system change that will improve an organisations bottom line by $2m pa, you may be interested in risks that might have a monitory impact of a few hundred dollars in a year - unless they also have some other important impact such as customer trust or legal issues.

There is no single, one-size-fits-all solution for risk management.

  • This is good, and seems implicitly scoped to things being developed for local use, rather than shipping a product? Sep 11, 2016 at 16:31
  • Thanks. Feel free to upvote! ;) Not really scoped as you say. The principles of risk management are the same no matter what development or delivery approach you have. It applies absolutely as much to product selection as to bespoke development. Sep 11, 2016 at 17:08
  • If you can't mitigate them, then how is it relevant? (I include insurance in the set of mitigations.) Sep 21, 2016 at 20:09
  • @AdamShostack: because the residual risk is what you either have to carry or walk away from. Everyone takes risks. By understanding them and the potential imacts, you can tilt the odds in your favour Sep 21, 2016 at 20:38

It depends on the context, audience, etc. In general, scope is important, and at any particular scope there should be an understanding of the impact of significant unmitigated threats.

At the level of the business or organization, significant unmitigated threats can be signals to get out of a particular area of practice, or to get additional business insurance, or to hire, or to take some other strategic action.

At the level of systems, significant unmitigated threats can suggest areas of architectural improvement.

At the level of an application, significant unmitigated threats scoped to the application should generally get on the backlog.

Applications change frequently, so threats at that level contribute to application change. Systems and businesses change more slowly; threats on those levels don't need to be constantly revisited.


There is a definite value in including threats you cannot mitigate. Threat mitigation is just one way in which a threat can be handled. The risks posed by threats can be:

  1. Avoided (eg. not having the feature that creates the vulnerability)
  2. Transferred (eg. insurance)
  3. Mitigated
  4. Accepted

In order to choose the correct way to handle the risk that the threat poses you need to know about the threat (ie. that it exists) and what impact it might have on your system.

Another reason why it is important to include threats that cannot be mitigated is because those threats can potentially be used as an enabler for a different threat to your system (which you might be able to mitigate).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .