Estimate how long an identity-related security incident takes to detect, contain, restore access, and validate recovery. Account for tasks that can run in parallel and readiness improvements to compare raw work hours with expected elapsed recovery time and estimated downtime cost.
The main result is expected elapsed recovery time under the selected coordination and readiness assumptions.
Parallelism is capped at 75% because incident stages usually retain dependencies. Validate assumptions through exercises and actual incident timelines.
Stages totaling 40 hours, 25% parallel work, and 20% readiness reduction produce 24 hours of estimated recovery time and $360,000 downtime cost at $15,000 per hour.
This model starts with detection work. Add suspected dwell time to the detection input if it belongs in your recovery objective.
Detection, containment, restoration, and validation have dependencies, so the calculator prevents assuming that all work overlaps.
Yes, along with token revocation, account re-enablement, privilege review, and other access restoration tasks.
It can for scenario testing, but production recovery normally requires verification that access and controls work correctly.
No. It estimates performance from inputs; an RTO is a target established by the organization.
| Variable | Meaning | Unit |
|---|---|---|
| Stage hours | Detect, contain, restore, and validate effort | hours |
| Parallel share | Work overlap that shortens elapsed time | % |
| Readiness reduction | Time reduction from preparation and automation | % |
| Hourly cost | Business cost while recovery continues | USD/hour |