Direct answer
Ask who can shorten retention, delete the account, rotate or destroy keys, alter replication and use vendor support access. Require answers for each plan and storage tier. The word immutable is insufficient unless the vendor can explain the enforcement boundary and demonstrate failed destructive actions.
How to frame the decision
Vendor capabilities vary by edition, deployment model, region and contract date. Convert each material claim into a dated requirement, a contractual answer and a proof-of-concept result.
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.
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 |
|---|---|---|
| Retention enforcement | Identify the service or hardware boundary that rejects changes and every exception path. | Architecture documentation plus a live shortening/deletion attempt. |
| Support and account closure | Determine what vendor staff or account-level actions can remove data before retention ends. | Written escalation and account-termination behavior. |
| Replication behavior | Verify whether source deletion, policy change or key loss affects secondary copies. | A source-compromise test with destination validation. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Require a dated vendor response and a proof-of-concept result for material claims.
- Translate the requirement into a pass/fail test for questions to ask vendors about immutable backup.
- 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.
- Immutable means only that normal users cannot edit backup files.
- Closing the subscription can bypass the claimed retention period.
- A support override exists but is absent from security documentation.
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.
- Keep commercial claims separate from tested technical evidence.
- A tested requirement exists for: Retention enforcement.
- A tested requirement exists for: Support and account closure.
- A tested requirement exists for: Replication behavior.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
What should you ask about immutable backup?
Ask who can shorten retention, delete the account, rotate or destroy keys, alter replication and use vendor support access. Require answers for each plan and storage tier. The word immutable is insufficient unless the vendor can explain the enforcement boundary and demonstrate failed destructive actions. The deciding factors in this guide are retention enforcement, support and account closure, replication behavior.
Can vendors delete immutable backups?
Treat the answer as conditional on the actual environment and plan. Determine what vendor staff or account-level actions can remove data before retention ends. Retain written escalation and account-termination behavior.
Does account cancellation remove retained data?
Do not rely on the product label or a successful backup job alone. Test the requirement directly: verify whether source deletion, policy change or key loss affects secondary copies. Record the result with a date, operator and named exception owner.