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 — including BYOVault or a compromised administrator account — 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 — retention is anchored to the file’s real history at its source, not to when BYOVault first backed it up.

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.

How the file gets there

• Same cloud provider: when your primary storage and your vault are on the same provider, the 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.
• Split across providers: a primary/vault pair on different 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. An administrator cannot disable the control that constrains an administrator. 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.

A client’s own registered contacts get a heads-up 24 hours before any of their files move into the vault — see Notifications & Alerts for exactly when that email fires and what it says.

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.

• 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.