I still see immutable used as shorthand for recoverable. In Rubrik architecture, that skips over several different controls that protect different parts of the recovery problem.
Rubrik uses immutable storage, SLA Domain retention lock, quorum authorization, threat analysis, and orchestrated recovery as separate mechanisms. Each protects a different part of the recovery path, which makes it possible to be precise about what immutability proves and where the recovery design still has work to do.[1][2][7][8][11]
Rubrik Has More Than One Immutability Boundary
Rubrik's data protection architecture uses an immutable file system for protected data on Rubrik infrastructure.[1] RSC also exposes retention lock through SLA Domains, and immutable archive behavior can be enforced by storage services such as Rubrik Cloud Vault, Azure Blob Storage, or Amazon S3 depending on the deployment and version.[2][4][5][6][14]
Those controls are related, but they are not one universal lock applied the same way everywhere.
Documented A retention-locked SLA Domain protects snapshots from premature deletion and constrains changes that would weaken frequency or retention.[2][3] Governance mode allows some less restrictive changes only with quorum authorization. Compliance mode is stricter: retention and frequency cannot be decreased, the lock cannot be disabled, and a compliance-mode SLA Domain cannot be changed back to governance mode.[3]
Retention lock protects policy and retention behavior. The immutable file system underneath a Rubrik cluster and WORM enforcement at an object-storage destination are separate mechanisms.
Cloud-native workloads use a different enforcement model. Rubrik documents retention lock for AWS, Azure, and GCP cloud workloads only in governance mode. For those workloads, RSC provides immutability for snapshots at the archival location rather than at the source, and Instant Archive must be enabled for the archived snapshots to receive that immutability protection.[4]
Microsoft 365 has another implementation. When RSC creates the Azure storage account used by a Microsoft 365 deployment, Rubrik uses Azure immutable blob storage with a time-based WORM policy.[5] Rubrik separately warns that with customer-hosted Microsoft 365 storage, administrators can access the snapshot storage location and can perform damaging operations despite the SLA Domain retention lock.[6]
I would not put one box labeled immutable backup on a design and assume all of those deployment models have identical enforcement. The architecture should identify what is immutable, where the lock is enforced, how long it applies, and which administrative path can still affect the copy.
Retention Lock Protects the Recovery Point, Not the Application State
Retention lock answers a very specific question: can the protected snapshot or its governing policy be weakened or deleted before the required period expires? For governance mode, quorum authorization adds another approval boundary around actions that would reduce protection.[3][7]
Retention lock and quorum authorization can make snapshot deletion and policy weakening harder. They still say nothing about the state captured inside the snapshot.
A server can be backed up successfully after an attacker has established persistence. A database can be captured in a technically valid state after bad application data has already been committed. A file server can contain an encrypted or malicious file before the event becomes obvious. Immutability preserves the point that was written. It does not rewrite history and make the contents trustworthy.
Threat Monitoring scans snapshots for indicators of compromise. Anomaly Detection examines file-system behavior and content for suspicious change. Threat hunts scan backups for user-defined indicators and can help identify the snapshots in which those indicators appear.[8][9][10]
Threat analysis answers a different question from storage integrity. A snapshot protected from deletion or modification does not certify the workload state captured inside it.
Rubrik Separates Data Survival From Recovery Execution
RSC Recovery Plans store resource mappings used during recovery and can map the compute, storage, and network resources required at the target. Recovery Plans also store boot order so dependent virtual machines can be started in sequence.[11]
The Cyber Recovery workflow adds the same requirements even when a Recovery Plan is not used. RSC requires the operator to choose the snapshots, define target resources for the recovery environment, and specify boot order. For VMware workloads, post scripts can also be used after a virtual machine starts.[12]
Documented Rubrik's cyber recovery guidance for an isolated environment explicitly calls out infrastructure services such as DNS and authentication as services that may need to be present for recovered objects to function.[13]
The immutable copy may be intact, but recovery still needs compute, storage, networks, name resolution, administrative access, and whatever application dependencies are required to make the service usable.
Immutability does not build those resources. It makes sure you still have protected data to bring into them.
Quorum Authorization Protects Actions, Not Availability
Quorum authorization is another control that can be mistaken for recovery readiness if its scope is not clear. RSC uses quorum authorization to require additional approvals before protected data-management or system-configuration actions can proceed. Rubrik documents policies that can cover actions such as deleting snapshots, changing SLA Domain protection, removing retention lock, and modifying protected configuration.[7]
Requiring another approval reduces the authority of one compromised or mistaken account. Quorum authorization controls what an operator is allowed to change.
A recovery design still needs to know how the approval path behaves during an incident. The required reviewers need access. The identity path used by the recovery team needs to work. The team has to know which actions are protected and which emergency procedure applies when the normal administrative path is unavailable.
A quorum-approval control and an immutable snapshot protect different failure modes. Both can belong in the design without pretending one substitutes for the other.
A Surviving Copy Can Still Be in the Wrong Failure Domain
Immutability is usually discussed in the context of ransomware, but location still matters. A recovery point can be immutable and still be unavailable because the site, Rubrik cluster, archive service, network path, or cloud account needed to reach it is unavailable.
Rubrik's retention-lock documentation warns that Rubrik cannot guarantee against data loss when an attacker gains access to a non-immutable or cascading archival location.[2] The source snapshot may still be governed by a retention-locked SLA Domain while the protection of the copy at the next location depends on the properties of that destination.
Current RSC documentation describes immutable RCV behavior by workload type, cloud provider, and Rubrik CDM version. Newer supported data-center RCV configurations use blob-level or object-level immutability tied to SLA Domain retention, while older configurations can use container-level or bucket-level lock behavior with different operational constraints.[14]
For the failure being modeled, the architecture review should ask where each surviving point actually lives. If the primary site disappears, can the team still reach the protected copy? If the Rubrik cluster is gone, is there another supported path to the data? If the archive account is compromised, does the archive enforce its own immutability? If the network edge is down, what path remains? Copy protection only helps when the surviving location is still usable under the failure being modeled.
Recovery Readiness Has Separate Proofs
RSC can schedule periodic tests of disaster and cyber Recovery Plans for supported vSphere and AHV virtual machines. Rubrik says those tests are intended to expose issues in the recovery environment that could affect an actual disaster or cyber recovery.[15]
The scheduled workflow performs prechecks, runs the plan, records the recovery outcome, performs cleanup, and can generate a recovery report.[15] None of those steps are implied by the snapshot being immutable.
Not every protected workload needs one Rubrik Recovery Plan, and one orchestration product does not prove the whole business service. The recovery claim should match the proof. If the claim is only the backup cannot be deleted during the lock period, immutability can prove that control. If the claim is we can recover this application after a destructive incident, the design needs evidence from the recovery path itself.
I would keep those two statements separate in every architecture review.
What Each Rubrik Control Actually Proves
| Rubrik control | What it protects or provides | What it does not prove by itself |
|---|---|---|
| Immutable Rubrik storage | Protects backup data from modification or deletion through the protected storage design.[1] | That the captured workload state is safe to return to service. |
| SLA Domain retention lock | Prevents or constrains actions that would prematurely delete snapshots or weaken retention, depending on lock mode.[2][3] | That the snapshot is the correct recovery point. |
| Quorum authorization | Requires additional approval for configured sensitive actions.[7] | That reviewers, identities, and administrative access will be available during recovery. |
| Threat Monitoring and threat hunts | Scan snapshots for indicators of compromise and help identify affected snapshots.[8][10] | That application dependencies or the target recovery environment are ready. |
| Anomaly Detection | Identifies suspicious file-system behavior and content changes in supported workloads.[9] | That every malicious condition is detected or that a recovery point is business-ready. |
| Recovery Plans and Cyber Recovery | Define target mappings, snapshot selection, boot order, and recovery workflow for supported objects.[11][12] | That the plan will work under the failure conditions you care about until it is exercised. |
| Scheduled recovery testing | Executes supported Recovery Plans periodically and records outcomes that can expose recovery-environment issues.[15] | That every workload or every external business dependency is covered by the tested scope. |
The controls complement one another because they answer different questions. I would rather see each one assigned a clear job than have the entire design summarized as Rubrik is immutable.
Review Immutability as Part of the Recovery Path
When someone says a Rubrik design is ready because the backups are immutable, I would work through these questions before signing off:
- Which copy is immutable: local Rubrik data, a replica, an archive, a cloud-native archived snapshot, Microsoft 365 storage, or another destination?
- Which mechanism enforces the lock at that location?
- Is the SLA Domain using governance or compliance mode, and what changes are still possible under that mode?
- Does weakening protection require quorum authorization?
- How long does the immutability or retention lock actually apply to the copy we expect to use?
- Does another copy or archive inherit the same protection, or does that destination have its own immutability requirements?
- What evidence will be used to decide which surviving recovery point is a candidate for recovery?
- Which Rubrik cluster, archive service, account, and network path are required to access that point?
- What compute, storage, network, DNS, authentication, and administrative resources have to exist at the recovery target?
- Which recovery operation will be used for this workload?
- Has that recovery path been executed recently enough to expose broken mappings, missing permissions, or unavailable infrastructure?
- What recovery claim did the test actually prove: snapshot access, VM recovery, application startup, or usable business service?
Rubrik gives architects strong controls for preserving protected data. The immutable file system, retention lock, immutable archival options, and quorum authorization can make destructive change substantially harder. Threat analysis, recovery mappings, and recovery execution remain separate parts of the design.
I want immutability on the design. I also want the recovery point selection method, surviving access path, target infrastructure, and recovery evidence written next to it. Until those exist, the design has protected data. It has not yet proved recovery readiness.
Key Takeaways
- Rubrik immutability is implemented through different mechanisms depending on the workload, storage location, SLA Domain mode, and deployment model.
- Retention lock protects snapshot retention and policy behavior. It does not certify the application state captured inside the snapshot.
- Rubrik separates immutability from threat analysis, quorum authorization, recovery mappings, cyber recovery, and scheduled recovery testing because those controls solve different recovery problems.
- Cloud-native and Microsoft 365 designs have immutability behavior that differs from data-center workloads, so one generic immutability statement is not enough for an architecture review.
- Recovery readiness should be proven from a surviving point through the actual recovery path, not inferred from the presence of a lock icon.
Source Notes
Product behavior changes. These sources were checked against Rubrik primary documentation available on October 5, 2026.