Recovery vs Remediation: Reframing MTTR for Healthcare

Security teams use MTTR constantly, but the acronym hides an important ambiguity. In many vulnerability and IT workflows, MTTR means Mean Time To Remediation: the elapsed time between identifying a problem and closing the work associated with it. PatientLock uses MTTR differently in this paper: Mean Time To Recovery, meaning the time required to return the affected system to a trusted operational state.

The distinction matters because a ticket can close before a hospital has recovered. A patch can be pushed without confirmation that every in-scope system received it. A compromised account can be disabled without proving that persistence is gone. A server can be restored without demonstrating that required controls, identity state, backups, and clinical dependencies are again trustworthy. In each case the work item may be complete while the operating state remains uncertain.

Healthcare cannot afford to confuse administrative completion with operational recovery. Clinical systems are connected to care delivery, revenue cycle, pharmacy, imaging, diagnostics, scheduling, supply chain, and patient communication. A technical action is only one part of restoring confidence that the hospital can safely resume normal operation.

NIST SP 800-61 Rev. 3 treats incident response as part of cybersecurity risk management and explicitly includes recovery among the activities organizations must make effective. ISO/IEC 27035 similarly treats incident management as a structured lifecycle rather than a ticket-closing exercise. The standards do not require PatientLock's recovery metric, but their process framing points in the same direction: response is not over merely because an individual technical task has been marked complete.

A defensible recovery measure should answer four questions. First, was the intended state restored? That requires re-observation. If endpoint protection was damaged, identity access was abused, a vulnerable service was exposed, or a backup process failed, the organization needs evidence of the resulting state after intervention.

Second, did proof continuity recover? Evidence created before the incident may no longer describe the environment. Recovery therefore includes fresh proof for the controls and systems that matter. A hospital should be able to show not only that it acted, but what was observed after the action and when that observation occurred.

Third, did the material exposure actually fall? Recovery is not achieved if the primary ticket closes but an equivalent path remains open. That means vulnerability applicability, exposed service state, identity privilege, endpoint coverage, or another relevant risk path has to be checked against the corrected environment.

Fourth, can the organization trust the restored state? Trust restoration is broader than availability. A system that is online but unverified may still require containment. A restored application with stale identity grants may still be unsafe. A recovered database whose backups cannot be demonstrated may still leave the hospital exposed to the next failure.

These conditions turn Recovery into a measurable operating concept: restoration, re-observation, evidence continuity, exposure reduction, and a decision that the system is again trustworthy for its intended use. The exact instrumentation varies by asset class, but the finish line stays consistent.

Consider an illustrative ransomware event affecting a hospital's revenue-cycle environment and a subset of clinical workstations. At 02:10 the security team isolates the affected segment. At 03:05 it disables a compromised privileged account. By 06:30 it has deployed a corrected endpoint policy and begun restoration of affected services. At 09:15 the primary incident ticket is moved to resolved because containment and the assigned remediation tasks are complete.

Measured as Mean Time To Remediation, the event may appear to have a seven-hour recovery profile. That number is attractive because it is easy to obtain from the ticketing system. It is also incomplete.

Suppose the hospital does not finish verifying endpoint coverage until 12:40. Identity review finds two stale privileged grants at 13:05 and removes them at 13:32. A clean restore test for the affected financial workload finishes at 15:10. Fresh control evidence is collected by 15:45, and the incident commander records the return to trusted operational state at 16:00.

The Recovery measure is therefore almost fourteen hours, not seven. Nothing about the first number was fabricated; it simply answered a narrower question. For workforce management, seven hours may be useful. For patient-safety exposure, claims defensibility, and the hospital's real operating risk, the fourteen-hour answer is more meaningful.

The gap between those two numbers is exactly where many post-incident disagreements begin. Security says the issue was remediated. Operations says systems were still being validated. Finance says claims and cash flow remained impaired. The carrier asks when the insured was actually restored. A Recovery measure creates one declared finish condition rather than allowing each group to infer a different one.

Cyber insurance ultimately cares about loss, duration, evidence, and causation. A remediation metric can help explain the speed of technical work, but Recovery is more closely aligned with the duration of operational impairment and the quality of the record available after the event.

For loss adjustment, Recovery provides a defensible sequence of state changes. An adjuster can distinguish the time of detection, containment, technical remediation, verification, restoration, and return to trusted operation. That is more useful than a single ticket-close timestamp when evaluating business interruption, extra expense, restoration work, or the reasonableness of response actions.

For defensibility, Recovery creates evidence that the insured did what it says it did. Fresh observations, signed or tamper-evident receipts, identity changes, restore tests, and exposure retests establish a record that can be reviewed later. That record can reduce ambiguity without requiring the carrier to accept the insured's narrative on faith.

For subrogation, a better timeline can clarify third-party contribution. If a vendor service, identity provider, managed service, or software component played a role, the difference between remediation and verified recovery can help establish what remained impaired, when external dependencies were restored, and which actions changed the state.

None of this means a carrier should price solely on one Recovery number. It means Recovery is a better operating measure than ticket closure for a risk whose cost is often driven by duration, failed restoration, repeated compromise, and evidentiary uncertainty.

Start by defining the system or service being recovered. A hospital cannot measure one universal MTTR across every technology and expect it to mean the same thing. An identity incident, a compromised endpoint, an unavailable clinical application, a biomedical device segment, and a backup failure each need a defined trusted state.

Then define the required evidence for that object. For an endpoint cohort, that may include agent presence, EDR state, disk encryption, firewall state, local-administrator posture, vulnerability applicability, and a fresh attestation after the remediation. For an identity event, it may include disabled credentials, revoked sessions, corrected group membership, privileged-role review, and re-observation of the authority plane.

Next, capture the timestamps that matter: first observation, containment, authorization, actuation, technical remediation, re-observation, proof completion, service restoration, and declared return to trusted operation. The metric should be computed from evidence, not manually typed into a dashboard after the incident.

Finally, retain the record. Recovery becomes valuable when the hospital can show the same timeline to clinical leadership, the board, the auditor, the broker, and the carrier. If each audience receives a different reconstructed story, the organization has measured activity rather than recovery.

The measurement principle is straightforward: connect observed state, authorized action, re-observation, and durable evidence, then declare recovery only when the trusted-state conditions are satisfied. This paper defines that discipline; it does not present a deployed VitalSec Recovery score or customer Recovery dataset.