Set Backup Retention From Ransomware Dwell Time

Quick answer

Retention must exceed plausible detection delay plus investigation and recovery-point uncertainty. A simple 30-day policy can fail when attacker activity began earlier or clean-point analysis takes days. Use multiple retention tiers and preserve older periodic points so short-term churn does not erase all pre-compromise history.

How to frame the decision

Operational confidence comes from repeatable evidence: logs, timestamps, restored-object counts and application checks. A successful backup job is an input to testing, not proof of recoverability.

For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.

What has been observed in practice?

The following field notes are anonymized and dated so that practitioner experience is not confused with current product documentation or a universal benchmark.

Firsthand field note2025–2026 advisory work

Count days you can return to, not labels in a console

The historical seven-generation rule was often a business convention: one week back was thought sufficient for users to validate the data. Ransomware challenged that assumption because compromise may be discovered after the window has moved.

Express policy as recoverable days at defined point density, not only generations.
Fourteen days is a practitioner starting point from these conversations, not a universal detection statistic or compliance requirement.
Historically, weekly full plus daily differential patterns were common; modern cloud recovery points may appear full while underlying storage is incremental or deduplicated.

Evidence boundary: The 7-to-14-day pattern is anonymized practitioner observation, not a measured industry average. Organizations must set retention from their own detection, investigation and business requirements.

Decision table

The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.

Factor	Practical guidance	Evidence to retain
Detection delay	Use incident history and threat assumptions to define a plausible lookback period.	A documented range rather than one optimistic number.
Retention tiers	Keep dense recent points plus weekly or monthly long-tail points under protected retention.	A policy export showing independent tiers and expiry.
Hold capability	Allow investigators to preserve relevant points without weakening normal immutability.	A tested legal or incident hold workflow.

Validation procedure

Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.

Collect machine-readable evidence rather than relying on a green dashboard.
Translate the requirement into a pass/fail test for set backup retention from ransomware dwell time.
Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.

A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.

Common failure modes

These conditions can make a compliant-looking design unusable during an actual recovery.

Retention equals the business RPO and ignores detection delay.
All older points expire in the same short window.
Incident holds require disabling immutable retention globally.

Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.

Evidence checklist

Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.

Assign an owner and closure date to every failed assertion.
A tested requirement exists for: Detection delay.
A tested requirement exists for: Retention tiers.
A tested requirement exists for: Hold capability.
Evidence includes a date, environment, operator and reproducible procedure.
The exception path identifies who can accept residual risk.

Editorial note. This guide separates design guidance from vendor claims. Product, licensing and regional availability must be rechecked against dated official documentation and validated in the reader’s own environment. Review cadence: review quarterly and after every failed or partial restore.

Frequently asked questions

These answers state the decision in plain language and preserve the conditions that can change it.

Are fourteen backup generations enough for ransomware?

Fourteen daily recoverable points can be a useful starting discussion, but the correct window must exceed the organization’s plausible detection and investigation delay. Also test whether every advertised point can actually be restored after retention and lifecycle processing.

Why is recoverable days better than generation count?

Generation count hides schedule gaps, failed jobs and multiple same-day points. Recoverable days state the business outcome directly and can be tested against a calendar of valid recovery points.

Does a cloud full backup store another complete copy each day?

Not necessarily. Services can present a full point-in-time restore while storing only changed blocks or deduplicated data underneath, so distinguish the logical recovery point from physical storage consumption.