Retention Policy

What retention actually does

Retention provisions a second, genuinely separate storage account or container — the vault — and locks it using your cloud provider’s own real immutability mechanism: AWS S3 Object Lock in Compliance mode, or Azure’s locked time-based immutability policy. Once a file lands in the vault, the cloud provider itself refuses any request to delete or modify it — not BYOVault, not your own account administrator, not anyone — until the retention period you chose has fully elapsed.

What gets moved, and when

A file becomes eligible for the vault the same way it becomes eligible for archiving: once its real, source-side last-modified date (not the date BYOVault backed it up) has gone stale past your configured threshold. Archiving decides when a file moves; once it lands in the vault, the provider’s own lock decides how long it stays protected. There is no separate database-level “retention day count” anchored to your backup date — the old design that anchored retention to when BYOVault first backed up a file (rather than the file’s real history) has been retired.

A file placed under Preserve is excluded from moving into the vault entirely — Preserve and vault-locking apply at different stages of a file’s lifecycle, so check that page for the exact distinction.

When your primary storage and your vault are on the same cloud provider, this move happens via that provider’s own native copy mechanism — the file travels directly between your two accounts, never through BYOVault’s own servers. See Storage Credentials for exactly what that involves on each provider. A primary/vault pair split across providers always moves the original way, through BYOVault’s own servers — either way, the retention guarantee itself is identical.

This is irreversible, by design

Once your tenant’s vault is locked, it cannot be turned off. This is not a limitation — it is the mechanism that makes the guarantee real. A protection an administrator could quietly disable is not a real guarantee at all: it would mean the exact person a compliance control exists to constrain could simply turn the control off first. Both AWS and Microsoft engineer their locked/Compliance-mode states the same way, for the same reason.

Extending the retention period

You can lengthen — never shorten — a locked vault’s retention period at any time. The two supported cloud providers behave differently here:

• Azure: extending the policy automatically re-applies to every file already sitting in the vault, not just new ones — Azure recalculates each file’s unlock date as its own arrival time plus the current policy length. Limited to 5 lifetime increases per vault.
• AWS: extending only affects files uploaded after the change. Files already in the vault keep their original retention period unless extended individually. No limit on the number of extensions.

Retrieving a file that’s in the vault

Restore works exactly the same whether a file is in Hot storage or already in the vault — self-service restore never waits on a multi-hour rehydration, because the vault is never configured with a slow-to-retrieve archive tier (see Archiving for why). The vault is a genuinely separate account with its own credentials, but BYOVault resolves this automatically per file; there is nothing different an end user needs to do to request a restore of a vaulted file.

Once the lock naturally expires

Nothing happens automatically when a file’s retention period ends — it simply becomes an ordinary, unlocked file again, sitting in the same place in the vault. BYOVault does not delete data on your behalf. If you want to remove a file once its lock has expired, that is done directly in your own Azure or AWS account:

• Azure: once expired, a normal delete works exactly like deleting any other blob.
• AWS: because Object Lock permanently requires S3 Versioning, a plain delete only hides the file behind a delete marker — the underlying data and its storage cost remain until you specifically delete that exact object version (DELETE ?versionId={id}, or the equivalent version-specific delete in the S3 console’s Versions view). A simple delete click alone will not free the storage.