Every holding reports a recovery target and most report meeting it, so the portfolio signal worth ranking on is the gap between that target and what has been restored end to end.
A target is a declaration, and the portfolio rolls up declarations
Portfolio reporting makes recovery readiness look comparable long before the evidence supports a comparison. Each holding states a recovery time objective. Most status updates say the target remains achievable. The portfolio view aggregates those statements into what reads as a consistent picture of operational resilience.
A target describes an intention. It says very little about whether a holding can bring back the service that carries its revenue after identity systems, infrastructure and backup access have been compromised at the same time. A software holding and a manufacturing business can report the same 24-hour objective and sit at opposite ends of actual capability. Treating the two numbers as equivalent hides the one difference that should drive intervention: the distance between what each holding declares and what it has demonstrated.
A large recovery dataset puts that distance in plain view
Fenix24’s first State of Recoverability report, published on 15 September 2026 and covered by Infosecurity Magazine, measured that distance across its client base. Of more than 800 clients assessed, four, or 0.5%, came close to their own 24 to 48-hour ransomware recovery targets, and even those only for partial business operations. None reached full operational capacity until several weeks after the incident. The report draws on more than 500 ransomware recoveries, and it describes the same failure each time: plans that looked sound on paper and came apart once an attacker was inside.
The scope deserves care. Jason Soroko, senior fellow at Sectigo, pointed out in the same coverage that the figures describe Fenix24’s engagements, not every business. They are not a failure rate to apply to a portfolio. They are a strong reason to ask, holding by holding, whether confidence in a recovery target rests on evidence or on expectation.
Compare holdings on the evidence behind the target
The comparable measure across holdings is not the target. It is the evidence under it, and four questions capture most of that evidence on one basis:
- When was the most revenue-critical service last restored end to end, and how long did it take?
- Was identity recovery part of that test, or was a working directory assumed?
- Can backups be reached if the production directory is lost?
- Does a dependency map exist for that service, third parties included?
These questions set one standard without pretending the businesses are alike. For a services platform the critical service may be scheduling, customer records and billing together. For a manufacturing business it may be production systems and the services that make them usable. The service differs; the obligation to show it coming back does not.
Reporting then needs three states rather than one: demonstrated, estimated and unknown. A holding with no qualifying test does not have a small gap. It has an unmeasured one, and that should stay visible on the page instead of disappearing into a green status.
The same failures recur, so one protocol can cover every holding
What makes a portfolio-level response practical is that the failure points in the report are not company-specific. They are architectural, and they repeat.
In Fenix24’s client population, 99.2% had no documented identity recovery plan, and none of the plans that did exist survived contact with the threat actor. Active Directory was usually the first major system to fall, and 94% of clients had tied their backup systems to the very directory the attacker seized. Roughly 20% of the opening two days went on identity alone, spent getting one authentication source clean enough to trust. Reaching minimum viable infrastructure took at least another 72 hours. Meanwhile 95% had no meaningful multifactor controls on critical infrastructure consoles, against 15% at network ingress.
The consequence for testing is direct. A restore exercise that starts from a working directory skips the dependency most likely to break the actual recovery. A holding can pass that exercise every year and still have no path back. Because the pattern is common, the fix can be common too: one restore test protocol for the portfolio, run against each holding’s own critical service, and required to begin from a compromised identity layer rather than a healthy one.
Rank the gap against the revenue behind it
A recovery gap does not carry the same weight in every holding. It matters most where revenue is concentrated in the service that has not been proven, which is the revenue-days-at-risk measure set out in Fewer Claims, Larger Losses. The Value Creation Plan Explains Both. Put the two side by side and the ranking changes.
Consider a software holding whose central platform carries most of its revenue and which restores its application cleanly every quarter, but always with identity already in place. Set it beside a services platform with a slower declared target that has restored its critical service through the full sequence, directory included. On a dashboard the software holding looks stronger. On evidence, it carries the larger unproven exposure, and it is where management attention belongs first.
So the portfolio signal is neither the shortest target nor the fastest isolated restore. It is the mismatch between the recovery a holding promises and the recovery it has shown, weighted by how much revenue waits on it. Where evidence is missing, the first intervention is simply to run the test. Where a test exposes a gap, remediation is sequenced against whatever held up the revenue-critical path.
Close remediation on restore time, not on purchases
Buying something is weak evidence of recovery progress, and the report shows why. In 38% of engagements where backups came through the attack intact or nearly so, they still could not carry the recovery: some sets predated anything usable, some were corrupt or partial well before the intrusion, and some were the wrong format or slower to restore than a rebuild. Some carried an immutable label on hardware that could not deliver it. Storage ran short in 82% of engagements, and in 38% the network could not move data at recovery scale. Not one client knew its full application and dependency picture.
A new backup appliance, extra storage or a freshly drawn dependency map may each address a cause. None of them closes the action. Closure is a repeat test showing that the critical service now comes back inside the intended window. If the restore time has not moved, the remediation has not landed, whatever was bought.
Getting to that evidence is rarely a matter of sending a questionnaire. The useful review walks the failed restore path with the holding’s own management: what blocked progress, which dependency surfaced late, and what the next test has to prove. That conversation produces better numbers than any self-assessment, because the people who run the service know where the restore stalled.
Where in the hold period to ask for fresh evidence
At entry, separate the inherited target from demonstrated capability. The baseline names the revenue-critical service, its dependencies, the evidence that exists and the assumptions still waiting for a test.
Before any identity or directory integration, bring recovery evidence into the design decision. Joining environments changes backup access, administrative dependencies and the order in which things have to come back, and an earlier test result may no longer describe the architecture that follows. Re-test after the change goes live, not at the next annual cycle.
Before exit, make sure the evidence is recent enough to survive a buyer testing the claim. A documented target supported by an old or partial exercise leaves the question open, and a buyer’s diligence will ask it.
Across all three points the change to portfolio reporting is small: one recovery evidence standard, one restore test protocol, and a ranking by recovery gap against revenue concentration. It replaces the question of whether each holding has a target with a more useful one: which holding has the largest distance between the recovery it declares and the recovery it has shown.