Backup after 3-2-1: immutability modes, drill cadence, and the evidence an auditor accepts
3-2-1 describes the shape of a backup estate but says nothing about its blast radius. This memo settles four decisions: compliance-mode retention over governance mode, two retention tiers sized separately, a second party on destructive operations, and a drill that leaves a dated artefact behind.
The 3-2-1 rule still describes the right shape for a backup estate. What it no longer describes is the blast radius of one compromised administrator, and that is what a DORA or NIS2 auditor asks first. This memo settles four decisions: the retention mode the immutable copy runs in, how the retention tiers are sized, who approves a destructive change, and what artefact the restore drill leaves behind.
Where 3-2-1 stops applying
The rule dates from the early 2000s, when the threat was mechanical: a drive dies, a disc scratches, a building burns. Three copies on two media with one off site defeats all three, because none of those events goes looking for the second copy.
The rule stops applying at the moment one credential can reach all three copies. In a 2026 estate, "off site" usually means an object bucket or a cloud vault behind the same identity plane as production: off site geographically, on site in terms of authorisation. A backup admin with Owner or root privilege can shorten retention, disable soft delete, or delete the vault, and no amount of copy-counting changes that.
Veeam formalised the extension most people now quote, 3-2-1-1-0: one offline, air-gapped or immutable copy, and zero errors in recovery verification. That last digit is where the engineering starts, because "immutable" is a setting with more than one value.
Recommendation
- Put the immutable copy in compliance-mode retention. Governance mode is defeated by any principal holding the bypass permission, which includes the admin an attacker is most likely to reach.
- Run two retention tiers, sized separately. A long compliance tier at your regulatory retention period, and a shorter tier that cannot be deleted at all, sized to exceed the time you could go without noticing corruption.
- Require a second party before a destructive operation, and use the control the platform actually has. Azure Multi-User Authorization with a Resource Guard in a different subscription or tenant is a real per-operation approval. AWS Backup ships no equivalent, so separate the authority instead: a Service Control Policy attached from the Organizations management account denying
backup:DeleteRecoveryPointandbackup:DeleteBackupVaultLockConfiguration, which AWS documents as binding on member-account roles including that account's root user, plus a cross-account copy the backup admin cannot reach. Vault Lock in compliance mode is an irreversibility control, not an approval control. - Keep the immutable tier and the fast-recovery tier separate. The air-gap winner and the restore-speed winner are rarely the same medium.
- Decide the Microsoft 365 question on retention and blast radius, not on whether a first-party product exists. It does now.
- Make every drill produce a dated report with a named human signature recording the recovery point used, the measured elapsed time, and the findings.
Immutability has two modes and only one of them holds
Object immutability comes in two modes on every control below, and the reversible one is usually the console default.
| Control | Reversible mode | Irreversible mode |
|---|---|---|
| Amazon S3 Object Lock | GOVERNANCE: any principal with s3:BypassGovernanceRetention can remove the lock by sending the bypass header, which the S3 console sends by default. | COMPLIANCE: AWS documents that no user, including the account root user, can overwrite or delete the object version, and the retention period cannot be shortened. The only exit before expiry is closing the AWS account. |
| AWS Backup Vault Lock | Governance mode: removable by users with sufficient IAM permissions. | Compliance mode: a grace time of at least 3 days (72 hours) that you choose, during which the lock can still be removed. After it expires AWS documents that the vault and its lock cannot be changed or deleted by any user or by AWS. |
| Azure Backup immutable vault | Enabled: blocks retention reduction and recovery-point deletion, and can be switched off again. | Enabled and locked: WORM storage, and Microsoft states the lock is irreversible. |
Azure adds a control with no S3 equivalent, because immutability alone does not stop a compromised Owner from deleting the vault before the lock is made irreversible. Multi-User Authorization pairs the vault with a Resource Guard that Microsoft recommends placing in a different subscription or tenant, in the same region. Two operations can never be exempted from that guard: disabling soft delete, and removing MUA protection itself. Approval is granted just in time, through Microsoft Entra Privileged Identity Management in Microsoft's recommended pattern. The backup admin keeps a standing Reader role on the guard, which is what lets them attach it to the vault, and holds no standing Contributor, Backup MUA Admin or Backup MUA Operator role. Backup MUA Operator is activated per operation and retracted when the approved window ends.
The check that tells you which mode you actually have
Read-only, five checks against the account and tenant holding the copy of last resort.
#!/usr/bin/env bash
set -euo pipefail
BUCKET="${1:?s3 bucket holding backup objects}"
AWS_VAULT="${2:?aws backup vault name}"
RSV="${3:?azure recovery services vault name}"
RG="${4:?azure resource group}"
# 1. Object Lock default retention. COMPLIANCE holds against everyone. GOVERNANCE does not.
aws s3api get-object-lock-configuration --bucket "$BUCKET" \
--query 'ObjectLockConfiguration.Rule.DefaultRetention.{Mode:Mode,Days:Days,Years:Years}'
# 2. Customer-managed policies that name the bypass action explicitly. A floor, not a clearance:
# this loop reads neither AWS-managed policies, nor inline policies, nor wildcard grants.
for arn in $(aws iam list-policies --scope Local --query 'Policies[].Arn' --output text); do
ver=$(aws iam get-policy --policy-arn "$arn" --query 'Policy.DefaultVersionId' --output text)
if aws iam get-policy-version --policy-arn "$arn" --version-id "$ver" \
--query 'PolicyVersion.Document' --output json | grep -q 'BypassGovernanceRetention'; then
echo "bypass named by: $arn"
fi
done
# 3. Vault Lock. Locked=true with a LockDate in the past means the grace time is over.
aws backup describe-backup-vault --backup-vault-name "$AWS_VAULT" \
--query '{Locked:Locked,LockDate:LockDate,Min:MinRetentionDays,Max:MaxRetentionDays}'
# 4. Azure immutability state: Disabled, Unlocked (reversible) or Locked (irreversible).
az backup vault show --name "$RSV" --resource-group "$RG" \
--query 'properties.securitySettings.immutabilitySettings.state' --output tsv
# 5. Multi-User Authorization. No mapping means no second approver.
az backup vault resource-guard-mapping show --name "$RSV" --resource-group "$RG" \
--output tsv --query 'name' || echo "no Resource Guard mapping: MUA is off"
Expected output on an estate that passes: Mode: COMPLIANCE, Locked: true with a LockDate already in the past, Locked from the Azure query, and a named Resource Guard mapping. Step 2 is a floor, not a clearance: a silent result leaves AWS-managed policies such as AdministratorAccess, inline policies and wildcard grants untested, and all three carry the bypass permission without naming the action. Only COMPLIANCE mode settles the governance-bypass question. Anything else is a finding, worth dating and writing down.
Two retention tiers, sized separately
A single retention number cannot serve both purposes; conflating them is how estates end up with a seven-year archive an attacker deleted last Tuesday. Split it:
- Compliance tier. Length is set by whatever obligation applies to the data class. Nothing about ransomware enters this calculation.
- Ransomware tier. Shorter, and absolutely non-deletable. Size it from your own numbers: the interval between integrity checks, plus the lag you are willing to accept before corruption is noticed, plus the time it takes to obtain approval and complete a restore. If those three add to 41 days for your estate, a 30-day lock is decorative and a 60-day lock is the floor.
That second figure is yours to compute. Any article that hands you a number for it has guessed at your monitoring interval.
Microsoft 365: the first-party product now exists
The claim that Microsoft offers only a soft-delete window stopped being true. Microsoft 365 Backup covers Exchange Online, OneDrive and SharePoint. Per Microsoft's published feature summary, retention is one year for all three workloads. Recovery points run every 10 minutes for the prior two weeks then weekly out to 52 weeks for OneDrive and SharePoint, and every 10 minutes for the full 52 weeks for Exchange. Billing is pay-as-you-go at USD 0.15 per GB per month for protected data, with restores free.
Microsoft is also precise about what the storage is. It describes the backups as append-only rather than immutable, states that deletion is deliberately not blocked so customers retain GDPR control and the ability to offboard, and provides a fixed 90-day grace period to recover backups after offboarding. Data stays inside the Microsoft 365 trust boundary.
Three honest reasons remain to buy a third-party product on top: retention beyond the one-year ceiling, a copy outside the tenant and its credential domain, and a restore path that survives losing access to the tenant. Cost per seat is a weaker reason, and worth pricing rather than assuming.
Drill cadence and the evidence an auditor accepts
| Tier | Cadence | What the drill restores |
|---|---|---|
| Production databases and primary line-of-business apps | Monthly | Full restore of one representative workload into an isolated environment, with application-level validation |
| Collaboration, mailboxes, file shares | Quarterly | One granular item restore plus one bulk restore of a whole site or mailbox |
| Development and internal tooling | Twice a year | Sampled restore with automated verification |
| Archive and compliance retention | Annually | Sample restore plus proof that the retention lock is still in the state the script above expects |
The artefact matters as much as the exercise. A defensible restore report names the recovery point used, the isolated environment it was restored into, the measured elapsed time against the documented recovery time objective, every finding raised, and the person who signed it, with a date. "Signed" means a named human accepting the result in a dated document, not a cryptographic signature; claiming one you do not produce is a worse audit finding than having no report.
DORA, Regulation (EU) 2022/2554, puts backup in Article 12, not Article 11. It requires a documented backup policy whose scope and minimum frequency follow the criticality of the information, restoration procedures and their periodic testing, and, when restoring with your own systems, ICT systems physically and logically segregated from the source. Article 12 also ties recovery time and recovery point objectives to whether the function is critical or important. NIS2, Directive (EU) 2022/2555, Article 21(2)(c) lists "business continuity, such as backup management and disaster recovery, and crisis management" among the minimum measures.
Two free references carry the rest. CISA's #StopRansomware Guide, revised October 2023, is the checklist an auditor recognises, and NIST SP 800-34 Rev. 1 (May 2010, updated 11 November 2010) supplies the structure of the contingency plan document.
Costing it without inventing a number
Every figure below is a formula, because a euro amount published in July is wrong by October. Fill it from your own inventory and your vendor's current price list.
- Collaboration data: protected GB times the first-party rate of USD 0.15 per GB per month times 12, or seats times the third-party per-seat list price times 12, priced over the same protected volume.
- Immutable object storage: locked GB times the provider's per-GB-month rate, scaled by the retention period rather than the drill interval. A compliance-mode object cannot be deleted early to save money.
- Restore traffic: the GB you expect to move in a full recovery times the egress rate. Microsoft's table lists restores as free for its own product; most others do not.
- Drill labour: hours per drill times drills per year times the loaded hourly rate of whoever runs them.
The number that decides the budget sits outside this list: revenue per hour multiplied by the recovery time objective you can actually meet today. Until that is written down, the backup spend has no denominator. The backup and disaster recovery service page covers the design side.
Trade-offs
- Compliance mode removes the escape hatch, on purpose. A seven-year lock on the wrong bucket is seven years of storage you cannot delete. Use the AWS Backup grace time, which AWS sets at a minimum of 3 days (72 hours), to verify the window before the lock becomes permanent. On S3 Object Lock, AWS separately suggests governance mode for testing retention-period settings before creating a compliance-mode period.
- Multi-party approval costs minutes in an emergency. A Resource Guard in a separate tenant means a legitimate 03:00 operation waits for an approver. That is the point, and it needs an on-call rota or it becomes an outage of its own.
- A Service Control Policy is blunter than an approval. It removes the operation until someone in the management account edits the policy, which is easier to leave switched off after an incident. AWS also documents that SCPs have no effect inside the management account, so the vault must not live there.
- Air gap and recovery speed pull in opposite directions. Tape is the strongest air gap available and the slowest restore for a full estate. Counting tape as the immutable copy while committing to a same-day recovery time objective is a promise you cannot keep.
- Account-level risk outranks vault-level controls. AWS documents that when an account is closed, backups survive a 90-day suspension and are then deleted even where Vault Lock was in place.
Limitations
This memo is written for an EU company of roughly 50 to 300 seats running Microsoft 365 or Google Workspace with some infrastructure in a hyperscaler and some workloads still on-premises. Above that size, tiering has to be done per application against a business impact analysis, and the cadence table here is too coarse to survive that.
DORA binds financial entities and their critical ICT third-party service providers. Outside that scope, Article 12 is a well-drafted template, not a legal obligation, and citing it at an auditor assessing you against something else will not help.
The compliance-mode advice does not apply unaltered where a data-erasure duty conflicts with it. An object locked in compliance mode cannot be deleted on request for the life of its retention, which is why Microsoft chose append-only storage over blocked deletion for its own product. Personal data carrying an erasure obligation needs a design decision before the lock goes on: per-subject encryption keys that can be destroyed, or exclusion from the locked tier.
Vendor limits, prices and product names were read on the date below and will move. Nothing here covers transaction-consistent recovery of distributed databases, replication as a substitute for backup, or the infrastructure-as-code and identity configuration a total-loss rebuild also needs.
Last verified 2026-07-28. Checked against the AWS docs for S3 Object Lock, Backup Vault Lock and Organizations service control policies, the Azure Backup immutable vault and Multi-User Authorization articles on Microsoft Learn, the Microsoft 365 Backup overview, and the DORA and NIS2 texts on EUR-Lex.
Sources and further reading
- Amazon S3 Object Lock: retention modes and required permissions
- AWS Backup Vault Lock: governance and compliance modes
- AWS Organizations service control policies (SCPs)
- AWS Backup API: DeleteRecoveryPoint
- Immutable vault for Azure Backup (Microsoft Learn)
- Configure Multi-user authorization using Resource Guard in Azure Backup
- Overview of Microsoft 365 Backup (retention, recovery points, billing)
- Regulation (EU) 2022/2554 (DORA), Articles 11 and 12
- Directive (EU) 2022/2555 (NIS2), Article 21(2)
- CISA #StopRansomware Guide (revised October 2023)
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (updated 11 November 2010)
- Veeam: the 3-2-1 backup rule and its 3-2-1-1-0 extension
Turn the trade-off into a scoped brief.
Share the constraints that differ in your environment. Michal will identify the next check needed before a delivery decision.
Start a scoped briefMore from Ops Log
Running Prometheus, Loki and Alertmanager on one VM: configuration, retention and cost
A single-VM Prometheus, Loki, Alertmanager and Grafana deployment that starts on the first attempt: the retention flags that belong on the command line, the disk-sizing formula that decides the machine class, alert rules with the false-page guards in place, and a cost model built from published list prices instead of asserted savings.
An incident-response playbook for a team without a security operations centre
A first-hours runbook for a 4 to 15 person technical team on Microsoft 365: the three EU reporting clocks and the event that actually starts each one, a containment sequence that captures evidence before it cuts access, and the documented side effects and rollback for every high-blast-radius action.