About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
The copy you should restore is the one that an attacker was least able to change after they arrived, that you can still decrypt, and that you have checked. It is often not the newest copy, and it is not "trusted" in any absolute sense. Least untrusted is the honest label. NIST SP 800-184 asks a recovery playbook to carry a confidence level in the quality of the backups. That phrase, in a guide whose scenarios are fictional, is still the right posture: you are ranking evidence, not blessing a product.
NIST SP 800-61 Rev. 3 recommends verifying the integrity of backups and other restoration assets before use, and it says recovery actions should weigh precision and reliability, not only speed. Its example is restoring the affected files rather than everything. NIST IR 8374r1 says backups should have a copy stored offline, or otherwise kept so the attacker cannot reach them and ransomware cannot compromise them, and it repeats the integrity check for ransomware. The September 2023 #StopRansomware Guide tells you to restore from offline, encrypted backups, in an order based on critical services, and to keep unclean systems off the recovery network. It also says some cloud vendors offer immutable storage that can protect data without a separate environment, and to use that with caution because of regulations and the cost of a wrong setting.
Catalogue triage tells you which rows exist and which times are inside the intrusion. This article starts when more than one row is still standing, or when the only convenient row is the one you should not use. It does not rebuild a server.
Rank the failure, not the timestamp
A recovery point fails in different ways. Rank those ways before you rank the clock.
The attacker could change it after they had access. CISA's reason for offline copies is that crews look for accessible backups and delete or encrypt them. A point on a repository the compromised backup administrator could expire is a weaker point than the same job on media that had already left. IR 8374r1's "or otherwise" clause lets a logical control stand in for offline only when that control actually prevents access. If you cannot show the prevent, treat the copy as reachable. Unknown is not a pass.
The point is after the intrusion started. SP 800-184's fictional team records the time of infection so the corresponding backups can be identified and checked. A job taken after that time can be a perfect copy of already damaged data. Newer is then worse. The time is provisional and may move earlier. A choice made on Monday is reopened if Tuesday's hunt moves the line.
Nobody has checked it. RC.RP-03 is a gate, not a mood. Two candidates with equal access stories are not equal if only one has a recorded integrity result. A green job status is the product's own word, which you already used when you decided the row existed.
You cannot read it. The key, the catalogue, or the media is missing. An unreadable offline tape does not beat a readable online snapshot by romance. It is a gap. The decision record says "unreadable", and you either recover the key through the authority you planned or you leave that point out. You do not silently promote the readable, reachable job without writing that you did so.
It is the wrong kind of copy. CISA distinguishes golden images of systems from backups of data, and it says images are the more efficient rebuild while warning that some images will not land on different hardware. A golden deployment image describes a chosen system build. A full system backup image may also contain application data and attacker changes; the word image alone says neither clean nor data-free. Check the contents and provenance of each artefact. Using the image as if it contained last night's transactions, or using last night's data on a poisoned image, is a category error. Choose one of each, for the questions they can answer.
A short order for the people who must pick
This order is editorial. It is how the sentences above become a choice. It is not a procedure that was run, and it does not include product screens.
- List the copies that claim to hold the data the business named, including image and data as separate lines. Include the provider's copy if a provider holds one. SP 800-61 Rev. 3 says to consider that a provider with privileged access may itself be compromised. A second region in the same cloud account, reached with the same root identity, is not an independent copy. CISA's suggestion of a multi-cloud arrangement is about avoiding exactly that single-vendor blast radius. If both of your "clouds" trust the same identity provider the attacker is inside, write "same trust" on both lines.
- Strike, or demote below any alternative, every line the attacker could alter after the provisional start time. Demotion is allowed when the alternative is "no copy". It is recorded as a conscious acceptance of a weaker point, with a name next to it, not as a win.
- Strike lines after the start time unless the data set is one the hunt has a positive reason to call untouched. "The ransom note was later" is not that reason. CISA's warning about earlier droppers and sold access is why.
- Strike lines with no integrity result if another line has one. If none have one, the next act is the check, not the restore. IR 8374r1's ransomware application of RC.RP-03 is "verify before using".
- Among what remains, choose the point that loses the least data the business has already agreed it can lose. SP 800-61 Rev. 3 puts asset owners in the role list because they know that limit. A technician does not invent a four-hour tolerance in the call. If the best remaining point is older than that tolerance, leadership must choose an explicit loss or workaround strategy. Separately validated application logs or selective data salvage may sometimes narrow the loss; they need their own integrity and consistency assessment, rather than silently promoting a suspect whole-system image. Hiding them inside "we took the latest" is how the reachable copy returns.
- Pair the data point with an image or a build source that survives the same tests. CISA wants standard images where they work, and offline source or installers where the image will not fit the hardware. The pair is the restore. Either half failing sends the pair back to step 2.
Our recommendation, not a scoring formula from NIST: do not add weights and pretend the arithmetic is science. The strike rules are enough. A weighted score must not let convenience compensate for a missing mandatory integrity or access check. The record should show which rule eliminated which copy, in sentences a non-specialist can read at the leadership update SP 800-61 Rev. 3 asks you to give.
How the common pairs actually differ
Newest online job versus last night's disconnected media. A disconnected pre-intrusion copy may offer stronger evidence against later tampering. Mere network reachability does not prove the online copy was modified, and the complete chain, keys, consistency and freshness still matter. A post-intrusion point needs investigation; it is not automatically encrypted or unusable for every selective data-recovery purpose.
Object-lock bucket versus disconnected media. The lock helps only for the period and the accounts it actually constrains. CISA's caution, and IR 8374r1's "or otherwise", belong in the same cell of the record: state which control you are relying on, and whether the lock's administrators are the compromised ones. A lock the attacker can lift is a label. A lock they cannot lift, on a point taken before they arrived, can outrank a disconnected copy you cannot decrypt this week. Say that plainly if it is the case. Availability of the key is part of trust.
Provider recycle bin versus your own offline copy. The provider may be able to roll an object back, and may also be the path the attacker used. Use the provider's history as evidence of what changed. Use it as the restore source only if it survives the strike rules. SP 800-61 Rev. 3's shared-responsibility point is that the contract defines who may act. A support agent restoring "the latest good one" on a phone call is an unrecorded choice.
A replica that is still receiving updates. A replica that accepts destructive source updates can propagate encryption or deletion. Replication with independently protected version history may preserve earlier states; replication alone does not establish that. Identify the retained consistent generation and its complete recovery chain. If your design has no such point, the choice framework will return an empty set. That is a design finding. It is better found in an exercise, which IR 8374r1 says to run, than on the night of the incident.
An empty set is a result
Sometimes every copy fails a rule. The framework's job is to say so.
CISA still expects you to recover critical services, and it allows rebuilds from images and from infrastructure-as-code templates kept offline. An empty data set means those services may return empty, or may return from an older point you have consciously demoted. SP 800-184 discusses operational workarounds when a system will not be back inside its recovery-time objective, including alternate processing. The communications plan is how that workaround is told to the people who will feel it. Choosing a copy you struck, because the alternative is an awkward phone call, reintroduces the attacker to the recovery network CISA told you to keep clean.
Hypothetical, so the empty set is visible: online backups every hour, object lock for seven days, and a weekly tape. The hunt's first credible access is sixteen days ago. The retained week is inside the known intrusion window; the dates alone do not prove that every object is encrypted. The tape from three weeks ago is before the line, the key is in the offline pack, and the integrity check passes. The hourly jobs are faster and irrelevant. If the tape's key had been only on the encrypted backup server, the result would be an empty set plus a key-recovery problem, not a licence to restore this morning's snapshot.
Risks and limits
- No repository was compared for this article. The strike rules are a reading of the NIST and CISA sentences, labelled as editorial where they add an order the documents do not print as a flowchart.
- A check can pass and the data can still be the attacker's edit from before encryption. Least untrusted is not clean. Staging is still required before the system joins anything else.
- Business tolerance for data loss that was never agreed will be invented under pressure. If it is not written, say it is not written, and let the owner set it on the call. Do not borrow a figure from a contract you have not opened.
- Immutable storage's regulatory fit is uneven, on CISA's own warning. This article does not interpret a statute.
- SP 800-184's "confidence level" wording sits in guidance built around fictional scenarios. It is used here as a posture, not as a metric with a unit.
Research and verification
This article was drafted with AI assistance on 11 November 2026 and independently reviewed against public sources on 13 November 2026. It is source research, not a lab-validated recovery procedure or evidence of a NetLeverage product capability. No article commands or recovery operations were executed.
Sources
Independently reopened 13 November 2026.
- CISA, FBI, NSA, and MS-ISAC, #StopRansomware Guide (September 2023). Live official page independently reopened 13 November 2026.
- NIST IR 8374r1 (June 2026).
- NIST SP 800-61 Rev. 3 (April 2025).
- NIST SP 800-184 (December 2016).
This article was originally published on .