Business Impact Calculator

Business impact analysis calculator: rank functions by downtime cost and recovery priority

This calculator does the arithmetic at the centre of a business impact analysis: for each business function you describe, it works out what an hour of downtime costs, scores how critical the function is, ranks every function against every other one, and derives a recovery sequence that respects the dependencies between them. It is about outage — what stops working, how much that costs per hour, and what you restore first.

Everything runs in your browser. You are typing revenue figures and headcount into a page, and none of it is transmitted; the PDF report is generated locally and downloaded straight to your machine. Nothing is saved between visits either, so export before you close the tab.

What you enter per business function

A BIA is only as good as the unit of analysis. This tool works at the level of a business function — order processing, payroll, customer support, warehouse dispatch — not at the level of a server. For each one you provide:

• Identity: name, description, owning department (13 to choose from), and a named owner.
• Impact ratings, 1–5 on five axes: financial, operational, legal/regulatory, reputational, and safety.
• Time-based impact, 1–5 at six horizons: 1 hour, 4 hours, 8 hours, 24 hours, 48 hours, and 1 week. This is where you capture that some functions degrade gracefully and others fall off a cliff at hour four.
• Recovery targets: MTD (maximum tolerable downtime), RTO (recovery time objective) and RPO (recovery point objective), all in hours.
• Financial inputs: annual revenue attributable to the function, and staff count.
• Dependencies: which other functions this one needs in order to operate.

The formulas, in full

Nothing here is hidden, and it is all worth checking against your own assumptions.

Hourly loss. The headline money figure is revenue plus idle labour:

• Hourly revenue = annual revenue ÷ 2,080 — that is 52 weeks × 40 hours, a standard business-hours year rather than 8,760 calendar hours.
• Staff cost = staff count × $50 per hour, a fixed blended rate baked into the tool.
• Estimated hourly loss = hourly revenue + staff cost.

Overall impact score is a weighted average of your five 1–5 ratings:

Risk score blends that with duration sensitivity and size:

• Time impact average = mean of the six time-horizon ratings.
• Revenue weight = annual revenue ÷ 1,000,000, capped at 5.
• Staff weight = staff count ÷ 20, capped at 1.
• Risk score = (impact score × 2 + time impact average + revenue weight + staff weight) ÷ 5.

Criticality tiers follow from that score: 4.0 and above is Critical, 3.0 to 3.99 is High, 2.0 to 2.99 is Medium, below 2.0 is Low. Functions are then sorted by risk score descending and numbered as priority ranks.

Total annual risk sums each function's hourly loss multiplied by a fixed assumption of four hours of downtime per year. That constant is not configurable, so read the figure as “what four hours of outage across every function would cost” rather than as a probability-weighted expected loss. If you want annualised loss driven by real event frequency, that is a different calculation and a different tool.

A worked example

Take an order-processing function: $4,000,000 of attributed annual revenue, 12 staff, impact ratings of financial 5, operational 4, legal 3, reputational 4, safety 1, and time-based impact of 3, 4, 5, 5, 5, 5 across the six horizons.

• Impact score = (5×0.30) + (4×0.25) + (3×0.20) + (4×0.15) + (1×0.10) = 1.5 + 1.0 + 0.6 + 0.6 + 0.1 = 3.80
• Time impact average = (3+4+5+5+5+5) ÷ 6 = 27 ÷ 6 = 4.50
• Revenue weight = 4,000,000 ÷ 1,000,000 = 4.00 (under the cap of 5)
• Staff weight = 12 ÷ 20 = 0.60
• Risk score = (3.80×2 + 4.50 + 4.00 + 0.60) ÷ 5 = 16.70 ÷ 5 = 3.34 → High
• Hourly revenue = 4,000,000 ÷ 2,080 = $1,923.08
• Staff cost = 12 × $50 = $600.00
• Estimated hourly loss = $2,523.08, and its contribution to total annual risk is ×4 = $10,092.31

For contrast, the tool's default new-function values — $500,000 revenue, 5 staff, ratings of 3/3/2/2/1 and time impact 2/3/4/4/5/5 — give an impact score of 2.45, a time average of 3.83, a risk score of 1.90 (Low), and an hourly loss of $240.38 + $250.00 = $490.38. Note that at five staff the labour component exceeds the revenue component. That crossover happens below roughly $520,000 of attributed revenue, and it is a useful sanity marker: if a function you consider critical is coming out labour-dominated, its revenue attribution is probably understated.

Where the model will and will not match your reality

Three assumptions do most of the work, and you should decide consciously whether each holds for you.

• The $50/hour staff rate is fixed and not editable. If your workforce is materially more or less expensive, the labour half of every hourly loss is scaled wrong by the same factor throughout. Because it is a constant, the ranking between functions is barely affected — but the absolute dollar figures are, so adjust them mentally before quoting them.
• 2,080 hours assumes a business-hours operation. For a 24/7 function — a warehouse on three shifts, an always-on e-commerce site — dividing annual revenue by 2,080 overstates the hourly rate, because revenue actually accrues across 8,760 hours. Either use 8,760-equivalent revenue attribution or accept that the number describes a business-hours outage.
• Revenue attribution is the hardest input and the one nobody checks. If every department claims the revenue it touches, the attributed totals will exceed company revenue several times over and the revenue weight will inflate everything toward Critical. Attribute each dollar once, to the function that would stop earning it.

Two more limits worth stating plainly. RTO, RPO and MTD are captured and reported but do not feed the risk score — they appear in the tables and the PDF as the recovery targets you have declared, not as scoring inputs. And the score caps bite: revenue weight stops climbing above $5m and staff weight above 20 people, so a $50m function and a $5m function contribute the same revenue weight. That is intentional — it stops one enormous function from flattening the ranking — but it means very large functions are compressed together and you will need judgement to separate them.

Dependencies and the recovery sequence

This is the part a spreadsheet does badly. Ranking functions by criticality gives you a priority list; it does not give you a recovery order, because restoring the highest-value function first is useless if it depends on something further down the list.

The tool resolves this with a dependency-aware ordering: at each step it finds the functions whose dependencies have all been restored already (or whose dependencies are not in your list at all), picks the highest-priority one among them, and repeats. The result is a sequence in which nothing is restored before what it needs. If it detects a circular dependency it cannot resolve, it stops resolving and appends the remainder in priority order — so a recovery sequence that suddenly reverts to pure priority ranking is a signal that you have declared a dependency loop worth going back and untangling.

The practical value shows up when a Medium-tier function like identity or network services turns out to sit ahead of a Critical revenue function in the sequence. That inversion is exactly the finding a BIA exists to produce, and it is invisible if you only rank by impact.

Reading the results

Three tabs present the same analysis at different depths:

• Overview — the organisational score (the mean risk score across all functions), the list of Critical and High functions, and the recovery sequence with each function's RTO and MTD alongside.
• Details — a full table: priority rank, tier, risk score, RTO, RPO, MTD and hourly loss per function.
• Charts — a radar chart across the five impact axes and bar charts comparing functions.

The PDF export produces a report with an executive summary, the critical-function list, a per-function table (priority, tier, risk score, RTO, MTD, hourly loss) and the recovery sequence. It is generated in the browser and saved locally.

How to run this without producing a document nobody trusts

1. Enumerate functions before scoring any of them. Get the whole list in first. Scoring as you go anchors every later function against the first one you entered.
2. Score impact with the people who own the function, not with IT. The legal and reputational axes in particular are not IT's to guess at.
3. Fill in time-based impact honestly, including the flat ones. A function rated 5 at every horizon is telling you it has no tolerance at all; a function rated 2, 2, 3, 4, 5, 5 is telling you where the deadline really is. Both are useful, and a column of identical 5s across every function usually means the exercise was rushed.
4. Declare dependencies even when they feel obvious. They are the only input that changes the recovery order.
5. Sanity-check the top of the ranking against intuition. If the result surprises the people who run the business, one of the inputs is wrong — usually revenue attribution. Fix the input, do not overrule the model.
6. Export the PDF and record the assumptions alongside it, particularly the $50/hour rate and the 2,080-hour year, so that whoever reads it in six months knows what they are looking at.

Used this way, the output is a defensible priority order and a per-hour cost you can put next to the price of shortening an RTO — which is the argument a BIA is ultimately for.