Which formulas and meanings should I keep separate?
Keep loss estimates, recovery targets and reliability measurements separate because they answer different questions. SLE and ALE estimate money lost; RTO and RPO state recovery needs; MTTR and MTBF describe observed averages under the definition used in the problem.
Scroll sideways to see every column.
| Term | Meaning | Formula or interpretation | Usual unit |
|---|---|---|---|
| SLE | Single loss expectancy | Asset value × exposure factor | Money per occurrence |
| ARO | Annualised rate of occurrence | Expected occurrences per year | Occurrences/year |
| ALE | Annualised loss expectancy | SLE × ARO | Money/year |
| RTO | Recovery time objective | Target time to restore service | Minutes or hours |
| RPO | Recovery point objective | Acceptable age of recovered data | Minutes or hours of data |
| MTTR | Mean time to repair, restore or recover | Total relevant repair/recovery time ÷ incidents | Time/incident |
| MTBF | Mean time between failures | Operating time ÷ failures, under the stated model | Operating time/failure |
How do I calculate SLE, ARO and ALE?
Calculate SLE from the loss per event, express ARO as occurrences per year, then multiply them to get ALE. For a simple asset-value problem, exposure factor is the fraction of the asset’s value lost in one event.
Suppose an asset is worth £80,000 and a particular event would cause a 25% loss. SLE = £80,000 × 0.25 = £20,000. If that event is expected once every four years, ARO = 1 ÷ 4 = 0.25 per year. ALE = £20,000 × 0.25 = £5,000 per year.
Exposure factor and ARO happen to be 0.25 in this example, but they mean different things. One is the loss fraction; the other is the annual event rate. Label them before multiplying.
ALE is an average estimate, not a promise that the organisation will lose exactly £5,000 each year. Losses can cluster or fail to occur in a given year. NISTIR 8286A Rev. 1 discusses estimating cybersecurity risk, including quantitative approaches.
A scenario involving phishing or credential stuffing still needs its own loss and occurrence assumptions before you can calculate ALE.
How do I compare a control’s cost with reduced ALE?
Compare the annual control cost with the estimated annual loss reduction, then consider whether the control also meets business or policy needs. A simple expected-loss calculation is useful, but it doesn’t decide every risk treatment on its own.
Using the example above, assume a £2,000 annual control reduces ARO from 0.25 to 0.05 while SLE stays £20,000. New ALE = £20,000 × 0.05 = £1,000. Estimated annual loss reduction = £5,000 − £1,000 = £4,000. Subtract the annual cost: £4,000 − £2,000 = £2,000 expected net annual benefit.
Don’t subtract the control cost from SLE unless the question defines that treatment. Keep annual figures together. A large one-time purchase and an annual running cost need a stated time period before comparison.
A proposed firewall or segmentation control should be evaluated against the path it changes, rather than assumed to remove every source of risk.
A control that narrows authorization permissions changes access scope; describe that change before assigning a new loss estimate.
How do I tell RTO and RPO apart?
Tell RTO and RPO apart by asking whether the requirement concerns downtime or lost data. RTO is about restoring service in time. RPO is about how far back the recovered data may be. NIST SP 800-34 explains these recovery-planning targets.
A service fails at 14:00. Its RTO is two hours, so the target is restoration by 16:00. Its RPO is 15 minutes, so the restored data should be no older than 13:45 in this example. A backup from 13:00 would miss that data-loss target even if restoration took only ten minutes.
Backup frequency alone doesn’t prove an RPO is met. Failed jobs, replication lag and recovery capability affect the actual recovery point. Test restoration, not just whether a backup file exists.
Recovered backups may also need decryption and integrity checks before the restored data is usable.
A recovery plan must preserve access to the required decryption keys as well as the backup data.
- 0113:45 data pointOldest acceptable recovery point
- 0214:00 outageService becomes unavailable
- 0316:00 targetService should be restored by now
How do I calculate MTTR and MTBF?
Calculate MTTR from the relevant repair or recovery durations, and MTBF from operating time between failures under the problem’s stated assumptions. Read what MTTR stands for in that question: repair, recovery, restoration and resolution aren’t always measured with the same start and end events.
Three repair events take 30, 60 and 90 minutes. Total repair time is 180 minutes. MTTR = 180 ÷ 3 = 60 minutes.
For a repairable system with 1,200 operating hours and three failures, the simple MTBF estimate is 1,200 ÷ 3 = 400 operating hours. Use operating time rather than silently adding downtime. The calculation describes past observations, not a countdown until the next failure.
If a question supplies the simple availability model, availability = MTBF ÷ (MTBF + MTTR). With MTBF 400 hours and MTTR one hour, that is 400 ÷ 401 ≈ 99.75%. Convert both to the same unit first. This model doesn’t capture every cause of outage.
During an outage investigation, event correlation and endpoint evidence help establish the incident timeline used to interpret recovery durations.
A restored service still needs its required protocols and allowed ports to be available.
What mistakes should I check before selecting an answer?
Check the units, percentages, event rate and requested term before selecting an answer. Convert 25% to 0.25; convert once in four years to 0.25 per year; keep hours and minutes consistent.
A target such as RTO can be missed by an observed recovery time. An average such as MTTR doesn’t become the recovery objective simply because it has the same unit.
For the wider business decision behind these figures, read how risk assessment differs from security testing.
In a performance-based task, identify whether the requirement concerns downtime, lost data or an observed average before choosing a value.
