What it means
A ransomware incident disables a customer portal. A server comes online in two hours, but customers cannot use the portal until data integrity and access controls are verified.
Cyber incident recovery time measures how long it takes to restore a defined service to an agreed safe level after an incident. NIST's guide to cybersecurity event recovery distinguishes recovery planning from execution, and NIST SP 800-61 Revision 3 situates incident response within risk management.
NIST also defines a recovery time objective separately from actual recovery time. A target is not proof that recovery occurred.
Define the incident, the clock start and the clock end before measuring. Use an agreed threshold for a reportable security event so that a routine maintenance restart is not mixed with a verified attack, and state whether the clock starts at detection, first harmful event or service outage.
A server booting is not always restored service, so require functional, security and data-integrity checks appropriate to the service. Set the service scope and record partial service separately.
One application may recover while downstream identity or payment systems remain broken, and internal monitoring can show green while users still cannot log in, so test an end-to-end journey. Read-only access or a temporary manual process may reduce harm but is not necessarily full recovery, and manual workarounds need controls and expiry dates because they can add error, privacy or security risk.
The recovery time objective is a planned maximum tolerable interruption, while the recovery point objective concerns acceptable data loss measured in time, so restoring quickly from an old backup may fail the data requirement. Restoring before removing malicious persistence can cause reinfection, and a backup may be encrypted, corrupted or incomplete, so test restoration and verify records.
Identity, network, cloud provider and DNS dependencies may decide when a portal truly works, so map them beforehand and confirm what third parties control. Duration alone misses the number of customers, transaction volume and safety consequences, so pair time with severity and compare only comparable events, because payroll, emergency service and a marketing site may deserve different targets.
Normalise time zones, report an uncertain onset as a known detection-to-recovery interval rather than inventing a start, and track recurrence, since a system restored fast but compromised again is not a healthy result. Run recovery exercises, record lessons, and report targets honestly: if the objective was missed, explain the causes and never change the target afterwards to erase the miss.
In practice
Real-world examples.
Example
A retailer's portal is restored for customer login six hours after detection and validated with test transactions, so the reported recovery time is six hours. The security team records the two-hour server restart as a separate milestone rather than the headline figure. This keeps the metric tied to what customers can actually do.
Example
A server reboots after two hours but encrypted data keep the service unusable, so the clock keeps running. Operations and security agree that the restart is only a partial milestone because functional and data-integrity checks have not passed. The eventual figure reflects the later validated restoration.
Example
A manual workaround keeps orders flowing while the full system is still under repair, so the team logs the workaround start as a partial-service milestone. Staff apply extra checks and an expiry date because manual handling adds error and privacy risk. Full recovery is reported only when the normal system passes validation.
Formula
Calculation
Illustrative actual recovery interval = validated service restoration timestamp - defined start timestamp. A 09:00 detection and 15:00 validated restoration gives six hours under that definition; onset could be earlier.
Worked example with milestones. Suppose a fictional service is detected as down at 09:00, the server reboots at 11:00, a clean backup is restored and tested by 14:00, and end-to-end customer login passes validation at 15:00. The server restart interval is 11:00 - 09:00 = 2 hours, but the validated recovery interval is 15:00 - 09:00 = 6 hours. If the recovery time objective for the portal was 4 hours, the actual time exceeded it by 6 - 4 = 2 hours, and the report should say so plainly.Case study
Seen in the real world.
This entirely fictional example follows Bluewater Retail. Its checkout system was isolated after a security event. Responders restored a clean backup, validated payment and access controls, and logged the end-to-end usable-service time rather than the earlier server restart. The case does not imply that forensic investigation ended when checkout resumed.
Afterwards Bluewater compared the six-hour validated figure with its four-hour objective and recorded the gap as a miss instead of revising the target. It found that waiting for a clean backup and re-checking payment access took longer than planned, so it scheduled a recovery exercise and assigned owners to the slow steps. The illustrative lesson is that an honest measured time, reported with its start and end definitions, shows where the next improvement should come from.
Watch out
Common mistakes.
- Ending the clock at server restart without testing the user journey.
- Confusing actual recovery time with the target RTO.
- Restoring from an unverified backup and causing a repeat incident.
Questions
People also ask.
When does the clock start?
Use the documented incident, detection or outage milestone and state which.
When does it stop?
When the defined service is safely usable under validated checks.
Is a fast restart enough?
No. Function, data integrity and containment may still be unresolved.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%