Ransomware dwell time matters because the most recent backup may already contain changes made by an attacker. Choosing backup retention means keeping enough history to reach a recovery point before the relevant compromise, while leaving time to investigate and test it. A policy based only on when encryption began can discard the copies you need most.
The practical question is how far back your team may need to go, and whether those recovery points will still be available when the investigation reaches them. That decision connects security monitoring, backup schedules, storage protection and application recovery. It also requires an explicit choice about how much recent business activity you can reconstruct if an older copy becomes necessary.
What is ransomware dwell time?
Ransomware dwell time generally describes the interval between an attacker gaining access and the organization detecting the intrusion. Reports sometimes use different endpoints, including ransomware deployment, so check the definition before using a published figure. Initial access, detection and encryption can occur on different dates.
During that interval, an attacker may steal credentials, establish persistence, move between systems or change configurations. Backups can capture those changes while jobs continue to report success. A successful backup confirms that a job completed under its configured checks; it does not establish that the source was free from compromise.
The relevant timeline can also differ by workload. An attacker might compromise an identity server before reaching a database or file share. Security teams therefore need to assess which systems and data were affected, rather than assign one supposedly safe restore date to the entire environment.
Before encryption does not necessarily mean clean
Consider an application server backed up the night before ransomware encrypts its files. The backup may preserve readable data but also include a malicious service installed a week earlier. Restoring the complete server could reintroduce that persistence.
Recovering selected application data into a rebuilt environment may allow a different recovery point from restoring the original operating system. That choice depends on evidence about the data and the application, including whether records, scripts or configuration files were altered. Backup age alone cannot make that decision.
Why an average dwell time cannot set retention
A published median describes the middle of an observed group of incidents. It does not establish the longest intrusion your organization might experience or how quickly your team will recognize its scope. Setting retention just above a median leaves longer incidents outside the design assumption.
Your own visibility matters more to the policy. A well-monitored application with retained audit logs may support a more precise investigation than a legacy system with limited telemetry. Where visibility is weak, the uncertainty around the earliest compromise should be part of the retention decision.
Investigation also takes time after detection. Teams must establish a timeline, identify candidate recovery points and test them before returning systems to production. Unless the incident process preserves those candidates, normal expiration can remove older backups while responders are still determining which ones they need.
Build retention around the recovery decision
For each important workload, define a planning window that covers the following components. This is a method for documenting assumptions, not a universal retention standard or a guarantee against every intrusion.
| Component | What the policy must account for |
|---|---|
| Suspected compromise window | How far before detection the relevant compromise could have begun |
| Investigation and validation time | How long responders need to select, restore and assess a candidate |
| Recovery-point spacing | The gap between retained copies, including missed jobs |
| Uncertainty margin | Additional history for incomplete evidence or a revised timeline |
The oldest required candidate must remain available through the recovery decision. In a simple daily-backup policy, that means retention needs to exceed the assumed compromise window plus the time needed to validate a candidate, with allowance for scheduling gaps and uncertainty. Use elapsed time and actual expiration timestamps when checking the result.
Preserving selected backups immediately after detection can stop normal expiration from narrowing the options. However, that process cannot retrieve a copy that expired before the incident was discovered. It also needs a named owner and a supported preservation mechanism that covers all required backup dependencies.
A worked example: When 30 days leaves too little room
Assume an organization keeps daily recovery points for 30 days. On June 30, it detects ransomware, and investigators initially place the relevant compromise around June 5. They choose June 4 as a candidate for testing because it precedes that suspected activity.
At detection, that candidate is already 26 days old. Under a simple 30-day rolling policy, it has approximately four days left before expiration. If investigation and isolated recovery testing take seven days, the candidate can disappear before validation finishes.
For this illustrative scenario, the team budgets 26 days to reach the candidate, seven days to validate it and seven more days for uncertainty. That creates a 40-day planning window. The team might round up to a 45-day policy for operational simplicity, while also implementing immediate preservation of incident-related backups.
Neither 40 nor 45 days is a general recommendation. If evidence later moves the compromise into May, that policy may still be insufficient. The useful result is a documented assumption that can be challenged and tested, instead of a retention number chosen without a recovery timeline.
Separate retention, immutability and backup frequency
Backup retention determines how long recovery points are kept. Immutability protects stored backup objects against specified changes or deletion for a defined period. Backup frequency determines how closely spaced your recovery options are.
These settings must work together. A recovery point retained for 90 days but protected from deletion for only part of that period does not have the same protection throughout its life. Conversely, extending object locks can retain underlying data beyond the backup application’s normal expiration schedule, increasing capacity requirements.
For Scality ARTESCA deployments, S3 Object Lock and configurable retention provide storage-side controls for immutable backups. The operational check is whether the backup application’s retention and dependency handling produce the protected recovery history you intended. The storage setting alone does not establish that every required recovery point can be restored.
Review the full chain: backup data, metadata, catalogs, encryption keys and the configuration needed to recover. Some components may require separate protection or documented reconstruction procedures. Retained objects are useful only if the recovery team can locate, decrypt and assemble the required data.
Keep older history at a useful level of detail
Many policies keep frequent recent backups and fewer older copies. This can preserve a longer history without retaining every daily recovery point indefinitely. However, the spacing between older copies determines how precisely you can choose a recovery date.
Suppose daily copies expire after one month, while weekly copies remain for three months. If investigators later place the compromise six weeks ago, the available candidate may be several days earlier than the suspected start. Those additional days represent business activity that may need to be reconstructed.
Monthly copies create wider gaps. They may be appropriate for some historical recovery needs, but they cannot provide the same date selection as daily copies. Document both the age of the oldest retained point and the spacing across the entire history.
Retention depth also differs from the recovery point objective, or RPO. A service may normally tolerate only an hour of lost data, yet a cyber incident may require assessment of much older recovery points. The response plan needs a way to reconcile that gap, such as validated transaction replay or recovery of selected data into rebuilt systems.
Choose policies by workload and available evidence
One retention policy across every application is easy to administer, but it can obscure different recovery requirements. An identity service, a transactional database and an archive have different dependencies and different consequences if an older version is restored. Group workloads by those characteristics before assigning retention periods.
For an identity service, rebuilding trusted infrastructure may be central to recovery. For a database, transaction consistency and the integrity of replayable logs may determine how much recent activity can be recovered. For an archive, preserving older versions may matter more than retaining closely spaced full-system images.
Bring the application owner, security team and backup administrator into the same decision. The application owner explains the effect of missing records, security explains the evidence needed to assess compromise, and the backup administrator establishes what can actually be restored. Record the assumptions and the person authorized to accept the resulting business impact.
Budget for retention changes before an incident
Longer retention usually increases stored backup data, but the increase is not always proportional to the number of days. Change rate, full-backup schedules, compression, deduplication and backup-chain dependencies affect consumption. Object-lock expiration can also delay reclamation after a recovery point expires in the backup application.
Use measured repository growth and the behavior of your backup software to model a proposed policy. Include room for new backups while older incident-related copies are preserved. An emergency retention hold can increase occupancy at the same time that recovery testing creates demand for additional storage.
Recovery capacity is a separate consideration. You may need space to restore several candidates into isolation before selecting one, especially if the intrusion timeline changes. A repository with enough room to retain history does not automatically provide enough space or throughput for that validation work.
Test an older recovery point, not only the latest backup
A restore test of yesterday’s backup demonstrates only part of the policy. To evaluate ransomware retention, select a candidate near the oldest date your design intends to support. This exposes missing dependencies, expired keys and retrieval delays that a recent restore may not reveal.
Run the test in an isolated recovery environment and involve both security and application teams. Security checks should use the incident scenario’s indicators and relevant configuration evidence; application checks should establish that the recovered service and its data behave as expected. A malware scan is one input, not proof that the environment is safe.
Record the candidate’s timestamp, the dependencies used, the time required to make it available and the validation outcome. Also record how much recent business data would be absent and whether it could be reconstructed from other trusted sources. Those results let you assess the policy against actual recovery needs.
An especially useful exercise moves the assumed compromise date further back after testing begins. Ask the team to select another candidate and preserve it before expiration. This tests whether the process can adapt when the first recovery assumption proves wrong.
Define what happens to expiration after detection
The incident playbook should specify who can preserve candidate backups, how that action is performed and how the team confirms it succeeded. Include dependent objects and separately managed recovery materials. Removing a backup job from its schedule is not evidence that every retention or lifecycle action has stopped.
Continue protecting new data where it is safe and appropriate, while preserving the historical candidates needed for investigation. Monitor available capacity and document any changes to retention or lock periods. The team should understand which actions can be reversed and which commit storage for a longer period.
Once recovery and investigation requirements are resolved, review the preserved copies through the agreed release process. Avoid leaving temporary incident measures undocumented and permanent. The policy should state who approves the return to normal expiration.
Make the retention decision defensible
A defensible ransomware retention policy explains how far back recovery may need to reach, how long validation may take and which copies remain protected during that work. It also identifies the evidence needed to select a candidate and the business impact of using it. Those are more useful commitments than an unexplained number of days.
Start with one critical workload and test its oldest required recovery point. If the team cannot restore it, validate it and account for the missing business activity, adjust the policy or recovery design. Longer history helps only when it preserves options your team can actually use.