Four. Out of more than eight hundred. That is the number of engagements in which the attacked company came close to the recovery objective it had written down itself — the classic 24 or 48 hours — according to the first annual report of a US firm that does this and nothing else. And none of the more than eight hundred, the same report says, reached full operational capacity until several weeks later. The number does not say those companies had no backups. It says something worse: the plan was measuring something that was not what happened.
Where the number comes from, and what it does not prove
From Fenix24's State of Recoverability 2026, published on 15 September 2026. This is field data, not survey answers: more than 500 ransomware recoveries and 800 client engagements. The sentence reads: "only four came close to the 24- to 48-hour recovery time objective typically documented in advance".
The sample is biased by definition: these are companies that had to call an external recovery team, the industry's worst days rather than a snapshot of the business landscape. And Fenix24 sells recovery, so a report in which almost nobody knows how to recover suits them. Both push the number in the same direction.
That said, the bias does not stretch that far. For four out of eight hundred to be statistical noise you would have to believe that companies which do meet their documented RTO never need outside help, and that is not how this works: when your production gets encrypted you call somebody even with an impeccable plan. Bias would explain 30% instead of 60%. It does not explain 0.5%.
Two columns: what gets declared and what gets found
The same question, measured by a survey and measured in the field:
Before subtracting: the two columns do not measure the same thing and do not ask the same people. The 60% are already-attacked organisations telling a pollster whether their crisis plan includes an Active Directory procedure. The 99.2% are clients arriving at an actual recovery with an external team in front of them and the folder open. The table is a contrast of method — declared against observed — not a subtraction.
The temptation is to read this as people lying in surveys. What happens is that under one question — do you have an identity recovery procedure? — three different questions are hiding, and only the third one is worth anything: does a document exist?, is it somewhere readable when the directory already belongs to the attacker? and has anybody executed it end to end? The first gets a yes in perfectly good faith. The other two almost never get asked. It is the same mechanism we ran into reading the Uptime Institute outage report: what fails is not the absence of documentation, it is a procedure nobody has rehearsed.
The clock does not start at the backup. It starts at identity
A fifth of the first 48 hours of a typical engagement goes to the identity plane and to nothing else. Standing up one authentication source healthy enough to prove that control is yours again. One, not the whole directory.
It makes complete sense once you think about it in order. Until there is a clean identity nothing can be authorised: not standing up a backup repository, not giving access to an engineer arriving from outside, not approving an emergency change, not trusting that the account you are restoring with is yours and not theirs. Identity is not one more system on the list. It is the piece the permission to do all the others hangs from. And very often it is what the backup server hangs from too: the backup server joined to the domain is the circular dependency that turns an incident into a week.
Do the subtraction with your own number. If your written RTO is 24 hours and field experience says a fifth of the first 48 — about nine and a half hours, if they were spread evenly — goes to identity alone, the plan is not missed through a slow restore or a lack of bandwidth. It is missed on page one, before a single byte of data is touched. And the same report sets the floor for what comes next: rebuilding infrastructure to minimum viability takes 72 hours or more.
The backup was intact and still did not work
Immutability does not close the problem either: in 38% of engagements where backups came through the attack largely intact, they still could not carry the recovery. The reasons given are four: too old, incomplete, the wrong type, or slower to restore than rebuilding the system outright.
The fourth one stings most, because it is the only one of the four you cannot see from the backup console. That restoring is slower than reinstalling is something you only know if you have once timed a full restore for real, stopwatch in hand, onto hardware that is not the original. If nobody has done it, the number in the plan is an estimate that has never been through a stopwatch. On where that number comes from when it is worked out properly, we wrote this in August: how RTO and RPO are actually calculated.
The plan is well written and measures the wrong thing
This is where the second report comes in, looking at the same thing from the other side. On 23 September 2026 Cohesity published its Global Cyber Resilience Report, run by Vanson Bourne with 3,200 IT and security decision-makers across twelve countries and organisations of more than a thousand employees, fieldwork in July 2026. Its main finding reframes the question: 78% aim their recovery at restoring systems rather than at keeping the business operating during the attack.
They are two different objectives and they produce two different plans. One orders by systems and asks when does everything come back?; the other orders by processes and asks what has to keep working in the meantime? The report gives the second one a name: minimum viable company, narrowing the scope of recovery to what must be restored first so the business does not stop. 37% have it documented. Documented and tested, 22%.
The crack between 37 and 22 is the same one that separated the two columns in the table above: very different in size, identical in cause. Of those who documented and tested it, 92% say it influenced their recovery priorities — self-reported, with the usual caveat: people who have put in the effort tend to say it was worth it.
What a minimum viable company looks like when you are forty people
The report definitions are written for organisations of more than a thousand employees, so they need bringing down to size. In a forty-person company, a minimum viable company is not a list of servers. It is a list of four or five processes — invoice, get paid, deliver what you sell, look after the customers you already have — and, for each one, three things: which identity source it depends on, which data it depends on and which third party it depends on.
The first time somebody fills that table in, the same thing almost always happens: the identity column comes out identical on all five rows. One tenant and one way in. That is not wrong in itself — it is the sensible thing to build — but it means all five processes share a single point of failure, and that you do not get to choose the recovery order: that column chooses it.
And then there is the part nobody wants to write, which is the part that actually defines the document: a minimum viable company is, above all, the list of what you have decided NOT to recover first. That is why it is hard, and why it is not a technical exercise: it is about deciding who you are going to tell to wait, and about that decision being taken by the owner of the process rather than by whoever happens to be on call.
The scope grows while you are writing it
One detail from the Cohesity report worth designing around from the start: among the organisations that did suffer a materially impactful attack, 70% saw the perimeter of affected systems grow beyond the initial assessment. On day one you do not yet know what has been touched. And within that same group, 60% hit identity and access problems after restoring: the same identity-plane story, told by a completely different sample.
The practical consequence is counter-intuitive: recovery order is not written by criticality, it is written by dependency. A plan ordered by criticality — most important first — breaks as soon as the perimeter grows, because the most important thing turns out to depend on something you did not yet know was encrypted. A plan ordered by dependency holds, because each step only needs the previous one to be done.
And the other half is missing — we covered it a week ago with the Semperis data: recovering fast and evicting the attacker are not the same job, and doing the first without the second signs you up for the second attack. The minimum viable company says what you stand up first; it does not say you can stand it up before you know the house is yours.
The six lines we ask for before discussing RTO
It is what we put on the table in the first session, and it fits on one page. It does not replace a continuity plan; it tells you whether the one you have measures anything:
- The four or five processes that, stopped for a week, take the year down with them. With the name of the person who says so, not the department. If you end up with twelve, you have not prioritised: you have made an inventory.
- Which identity source each one depends on. If the answer is the same on every row, that is your bottleneck and the first stretch of your clock.
- For each process, how it is done by hand and how many days it holds that way. Invoicing by hand holds for a few days; shipping software does not. If a process has no degraded mode, write that down anyway: that answer is the one that explains your real RTO.
- How long the last full restore you timed actually took. Timed, not estimated, and onto hardware other than the original. Without that number there is no RTO.
- Where the plan gets read if the directory already belongs to the attacker. Paper, another tenant, an out-of-band copy. A PDF on the corporate SharePoint does not count: it lives inside the thing that has gone down.
- And who authorises an emergency change when nobody's identity can be verified. You need a name and a deputy, reachable through a channel that does not run over the network that has just gone down.
All six get answered in a single session. The slowest is the fourth, and not because it is hard to measure: because it is usually the first time anybody has asked whether it is measured.
When this is not your problem
If you are ten people, everything lives in Microsoft 365 and you have one line-of-business application, you do not need a continuity programme. You need three things: a backup somebody has actually restored at least once, the phone number of whoever restores it, and an emergency admin account that does not depend on the normal access path. Running a formal minimum-viable-company exercise there is paperwork with a nice name, and it shows on page one.
It changes when you run your own production, when customers sign a service level agreement, or when a week of downtime costs you the contract of the year. There the exercise pays for itself. And we say this knowing full well that the second case is what we invoice for: which is exactly why the case where it is unnecessary deserves to be written down too.
Where this fits into what we do
We run managed backups with Proxmox Backup Server and Veeam, on a 3-2-1 philosophy with immutable copies. The part of our work closest to this article is the conversation beforehand, the one about deciding what has to stay standing. That is compliance and continuity — the plan, the scope, the rehearsal and the evidence that it exists — and its other half is disaster recovery, which brings the hardware and the minutes. If you want us to go through those six lines against your own case, write to us. We will measure the fourth one ourselves if needed.
Sources. The field data (four out of more than 800 engagements close to the 24-48 hour objective, 99.2% with no documented identity recovery plan, a fifth of the first 48 hours on the identity plane, 72 hours or more to minimum infrastructure viability, and 38% of intact backups that could not carry the recovery) come from Fenix24's The State of Recoverability 2026, built on more than 500 ransomware recoveries and 800 client engagements: press release of 15 September 2026 (the report PDF lives on fenix24.com, but their server returned a 403 when we tried to download it on 27 October, so we link only the release). The survey data (78% aiming recovery at restoring systems, 37% with a documented minimum viable company, 22% documented and tested, 92% of those saying it influenced their priorities, 70% seeing the perimeter grow beyond the initial assessment and 60% hitting identity and access problems after restoring) come from Cohesity's Global Cyber Resilience Report, published on 23 September 2026, conducted by Vanson Bourne with 3,200 IT and security decision-makers across twelve countries in organisations of more than 1,000 employees, fieldwork July 2026. Mind the denominator: the 70% and the 60% are not of the whole sample but of the organisations that suffered a materially impactful attack. The 60% with documented Active Directory recovery procedures comes from Semperis's Ransomware Risk Report 2026 (1,200 professionals across nine countries, all from organisations already successfully attacked), which we used in the linked post of 20 October. A warning about the comparison: the three sources measure different populations — recovery engagements, large organisations and ransomware victims — and two of the three come from vendors selling into this market; the percentages are not directly comparable and the two-column table is offered as a contrast of method (declared versus observed), not as a subtraction. The nine and a half hours in the calculation are ours: they come from applying the fifth of 48 hours Fenix24 publishes, which does not give that figure in hours. Ours — the six lines, the criterion of ordering by dependency rather than criticality, and the case where the exercise is unnecessary — is how we work, not a recommendation from any of the reports cited. Photo: "EmergencyPowerGenerator.jpg" by Raysonho @ Open Grid Scheduler / Grid Engine, Wikimedia Commons, CC0 1.0, cropped by us.
Microsoft 365
ES 
CAT 
EN