I have been looking into business impact assessments and I am confused about the "Impact" part. I have been asked several times about what the impact would be when a system fails, and it appears that this is information that people want to see in a business impact assessment.

My problem is that without an actual scenario (which seems more appropriate for a risk assessment) it seems impossible to do that.

e.g. if the system fails it does not cost 2000€. If the system fails for 24 hours it costs 2000€.

I have been looking into relating this to the MTD or RTO, however that seems problematic as well since reaching the MTD means unacceptable loss by default.

The solution for to me seems to be to describe in the BIA what the impact of an outage would be and use that as input for an actual risk assessment, however I suspect there is a reason why this is common practice.

An example of where I see this practice is in the SP 800-34-rev1 BIA Template

  • There isn't an actual question here, and you need to provide an antecedent to "there is a reason why this is common practice" (i.e. to what are you referring?)
    – schroeder
    Nov 22, 2023 at 12:09

1 Answer 1


You've been given a very broad mandate. You can keep things just as broad in your Impact Assessments.

For example:

  1. Determine the types of impact of a system failure that are relevant and how that impact might be measured (money is often the default, but not always the best measure):
    • Financial
    • Reputational
    • Operational
    • Contractural
    • Regulatory
    • Compliance
    • Environmental
    • Health and Safety
    • etc.
  2. Determine an estimated timeframe where system failure becomes an existential threat to the organisation/department (i.e. the organisation/department can no longer feasibly exist) (this should be the same as the MTD, but see my note below). For example:
  • An imagined space shuttle's air system reaches an existential threshold at 24 hours, after which it no longer matters that the system failed and getting it running again no longer matters (health and safety).
  • An imagined organisation's backup system can fail for 36 months before it begins to present an existential risk (operational, compliance).
  1. From that upper threshold, determine a reasonable time frame to set as a unit of time for impact purposes.
  • Air system failure impacts might be broken up into hour increments
  • Backup system failure impacts might be broken up into month increments
  • Website failure might be broken up into day increments
  1. Determine if there are certain times in the month/season/year where failures would have a disproportionate impact and use those time periods separately in your assessment. For example:
  • Payroll system failure at each end of month
  • School grading systems at each term end
  • Online sales systems from 15 Nov to midnight 24 Dec
  1. Determine the impacts of a system failure within those time frame increment
  • E.g. The website failure accrues $X in business losses and reputational damage each day throughout the year. But $Y in business losses and reputational damage each day during the Christmas rush.

That way, you don't need to have a scenario to start. However, scenarios will be very helpful in uncovering non-obvious impacts and potentially uncovering certain existential risks that hadn't been considered.

MTDs and RPOs

In my experience, MTD is very poorly measured and understood and are often a "paper" exercise. I've worked with some orgs where Management will tell me their carefully measured MTD that they paid consultants high costs to calculate. And I'll ask them during a break, without the MTD calculation in front of them, "So if key system X went down for [MTD/2], you'd be ok?", and most of the time, their eyes bug out at the thought of such a long downtime.

One org told me that they had a MTD of 5 days for their email system. However, upon reviewing their past incidents, a downtime of 10 minutes, with a known and treatable cause, triggered Major Incident procedures and large (unnecessary) spending. So, on paper, their MTD might be 5 days, but Management's actual comfort level was 10 minutes. As a result, I designed risk mitigations around a 10-minute downtime, not a 5-day timeline.

The scenario I use to get people outside of the death spiral of trying to determine these levels and into something real is: "If I blasted a shotgun at the server..." It's shocking, a localised event, with total destruction of both system and data implied. It also side-steps all the discussion about "likelihood" that can cloud this discussion when you present cyber-based scenarios. After that, we can get more nuanced.

  • I agree with this approach however it does not seem to be common practice. BIA's and guides to conducting BIA's that i have seen tendto include that one "Impact" field or output. I am specifically trying to understand why this is (or seems to be) common practice. Do you have any clue?
    – Mattey
    Nov 22, 2023 at 11:47
  • Step 1 is absolutely common practice. 2 is common practice (hence a MTD). 3 is just practical to come up with a "unit of impact" ('common' practice is to set the unit to "day"). 4 is a reality check based on experience. 5. is absolutely common practice. What are you saying is not common practice?
    – schroeder
    Nov 22, 2023 at 11:59
  • "BIA's and guides to conducting BIA's that i have seen tendto include that one "Impact" field or output." -- sure, if you've predetermined the impact (step 1 above) You are going to have to explain what you want better.
    – schroeder
    Nov 22, 2023 at 12:00
  • Please note that 800-34 Rev. 1 is specifically for "Contingency Planning". "Contingency planning refers to interim measures to recover information system services after a disruption. " The range of impacts is limited, and the costs include recovery steps, which is not common to other forms of BIA.
    – schroeder
    Nov 22, 2023 at 12:06
  • In my answer, I explain how to proceed without a scenario, how to properly use MTD (with additional field experience), and how to blend the BIA as a risk management input. These are all the elements in your question. As to your question why there is only one field, there isn't.
    – schroeder
    Nov 22, 2023 at 12:12

You must log in to answer this question.

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