A ransomware recovery estimate is only as credible as the slowest dependency tested on the path back to a working business service.
Infosecurity Magazine reported on 24 September 2026 that the newly formed ransomware group n0n, identified by CyberXTron researchers, “make explicit threats to encrypt or destroy backups and shadow copies of data.” CyberXTron first spotted its activity on September 18; by September 22, its leak site listed over a dozen victims. The threat is designed to make victims fear they cannot recover without paying. An advisor reading that headline has an obvious response: add a “backups destroyed” branch to the ransomware scenario.
Keep that branch. But Infosecurity Magazine’s account of Fenix24’s first State of Recoverability report, published 15 September 2026, presents the harder modelling problem. In 38% of engagements where backups came through the attack intact or nearly so, the backups still could not carry the recovery. Some predated anything usable, some were corrupt or partial before the intrusion, and others were in the wrong format or slower to restore than a rebuild. Backup survival says little about when a business service returns.
Put recovery on the right side of FAIR
In FAIR, risk combines Loss Event Frequency and Loss Magnitude. Both are distributions, so report ranges rather than points. The analyst first defines the asset, threat community and effect, then elicits calibrated minimum, most likely and maximum values before running a Monte Carlo analysis.
Recovery capability primarily changes Loss Magnitude. It does not, by itself, prevent the threat actor from causing the loss event. In the FAIR model, as Jack Freund and Jack Jones set it out in their book on the method, disaster recovery and business continuity processes, efficient incident response, and redundancy contain Primary Loss Magnitude. A restore plan therefore belongs on the consequence side of the model, not under Vulnerability.
For this scenario, the direct loss forms most exposed to recovery duration are Productivity and Response. Productivity is the organisation’s lost ability to deliver products or services. Count revenue actually lost, not revenue merely delayed; employee idle time alone is not a substitute for the service loss. Response includes the effort of investigating, containing and restoring. Replacement may also matter where systems must be rebuilt. Secondary Loss belongs in its own conditional calculation, through Secondary Loss Event Frequency and Secondary Loss Magnitude.
The weak parameter is often duration. An advisor asks for the recovery time objective (RTO), or asks whether backups survived, and places the answer at the most likely point of the Productivity and Response ranges. Yet an RTO is a target in a document. It does not demonstrate that identity can be trusted, restored data has somewhere to land, or the network can move it. If a directory rebuild alone is expected to take days, a two-day RTO cannot be the most likely duration for the dependent service. At best, an untested RTO describes the optimistic end of the range.
Build the duration from dependencies
Start with the business service, then trace its recovery path backwards with the people who operate it. What identity and directory services must be clean before administrators can restore systems? Can the backup catalogue be reached without the compromised directory? Are the required copies complete, current and restorable? Is there storage capacity for restored data while preserving evidence? Can the network move that data at recovery scale? Which applications, integrations and third parties must return before the service can deliver?
Give each link a minimum, most likely and maximum duration, plus an evidence grade: demonstrated in an end-to-end restore test, documented only, or assumed. Record prerequisites as well as elapsed time. Some work can run in parallel; other work must wait for a trustworthy identity system or restored platform. The service duration follows the critical path through those dependencies. Its slowest binding link sets the practical pace, while uncertain links widen the tail.
The Fenix24 observations show why each link deserves its own question. Active Directory was usually the first major system to fall; 94% of clients had tied their backup systems to the very directory the attacker seized. The firm said 99.2% of clients arrived with no documented identity recovery plan, and none of the plans that did exist survived contact with the threat actor. Roughly 20% of the opening two days went on identity alone; reaching minimum viable infrastructure took at least another 72 hours. A backup may be intact while the credentials needed to use it are unavailable.
Physical capacity and service knowledge impose separate limits. Storage ran short in 82% of engagements; in 38% of cases the network could not move data at recovery scale. Not one client knew its full application and dependency picture. A successful file restore does not show that the target service can authenticate users, reach its integrations and resume transactions.
The n0n scenario still needs a destroyed-backups branch, with its own rebuild path and duration range. But its intact-backups branch cannot inherit the RTO as its most likely value. It must also pass identity, backup integrity, storage, network and application-dependency checks. If storage is the binding link, hardening backup copies alone does not shorten the outage. If identity is binding, faster storage alone buys no duration reduction.
Treat incident data as a map, not a base rate
Fenix24’s report draws on more than 500 ransomware recoveries. Those are an incident response firm’s own engagements, organisations that brought in outside recovery help, so the findings do not establish the probability that another organisation will encounter each failure. As Jason Soroko, senior fellow at Sectigo, put it in the Infosecurity Magazine article: “These figures describe Fenix24’s engagements, not every business, but they identify a failure organizations should test for.” Use the findings as a catalogue of plausible broken links, then obtain evidence for the service under analysis.
The headline measure makes the same point about evidence. Only four out of more than 800 clients (0.5%) assessed by Fenix24 came close to their own 24 to 48-hour ransomware recovery targets, and then only for partial business operations. None reached full operational capacity until several weeks after the incident. Those figures do not belong as a generic likelihood in a FAIR model. They do make a documented target a poor proxy for demonstrated capability.
A credible elicitation separates what was timed under attack-like conditions from what was written down and what is assumed. An end-to-end restore test should show the service functioning, not merely a backup job reporting success. Where a link has never been exercised, its duration range should reflect that uncertainty. The documented RTO can remain at the optimistic end; the most likely value should follow the demonstrated critical path. Because duration feeds both lost service and response effort, moving that value shifts the Loss Magnitude distribution.
Give the client a testable priority
Fenix24 recommends choosing the most revenue-critical business service, mapping its complete dependencies including third parties, and running the full restore path end to end against current targets. It called simulations and untested plans the same answer. That map requires infrastructure, identity, application and business owners working through the restore sequence together.
The advisory output should name the binding link, its evidence grade, and the test that could change the duration estimate. Then compare what happens if that link is repaired with what happens if a different link is improved. A heat-map line reading “backup maturity: amber” cannot answer that question. The useful answer directs the next restore test and shows whether the proposed fix can move the critical path.
A backup is evidence that data may exist; recovery is evidence that the business can use it again.