Provisioning a Retention Vault

Before you start

The Retention Vault page only becomes available once the tenant has answered “No” to whether the client already has their own lifecycle/retention policy on their primary storage. That question lives on the Archiving page — if it is still unset or set to “Yes,” the Retention Vault page shows a message pointing back to Archiving instead of the wizard, and the question must be answered there first.

Have ready a genuinely separate storage account or bucket from the tenant’s everyday primary backup storage — its own name, its own credentials. Using the same account as primary storage for the vault is not supported. Everything below walks through getting each value the wizard asks for, split by provider.

Getting every value the wizard asks for

Pick your provider below — each tab is a short, self-contained checklist of exactly where to get every field the wizard will ask for.

Step 1 — Configure the vault’s storage account

The wizard opens with Step 1 active. Choose Azure Blob Storage or AWS S3 as the vault’s provider, then fill in:

• Container / bucket name — required before the step can be saved.
• Region — optional.

For Azure, two separate credential groups are requested:

• Storage account credentials (data-plane) — account name and account key, the same shape used for ordinary primary storage.
• Management-plane (ARM) credentials — subscription ID, Azure AD tenant ID, resource group name, service principal client ID, and client secret. The wizard states plainly why this second, larger credential is required: locking the vault is an ARM operation (creating and locking a time-based immutability policy), not a data-plane one, so the account key alone is not sufficient.

For AWS, only the access key ID and secret access key are requested — a separate management credential is not needed on this provider.

Clicking Save vault storage validates the credentials before anything is written. A mistyped key or secret is rejected here, at Step 1, rather than surfacing later as a failure during the irreversible lock step.

Once saved, Step 1 collapses to a static “Configured” line with an Edit link — the storage account can still be corrected by reopening it, for as long as the vault has not yet been locked.

Step 2 — Acknowledge that locking is irreversible

Step 2 stays disabled until Step 1 is complete. It presents this exact statement:

Once enabled, this cannot be turned off. Files that are locked cannot be deleted by anyone — including BYOVault — until the retention period you choose has passed. This is not a database setting; it is enforced by the cloud storage provider itself.

A checkbox below it reads “I understand this is irreversible and have confirmed this with the client”. Checking it and clicking Acknowledge and continue opens a second, modal confirmation — the same type-the-tenant-name pattern used elsewhere in BYOVault for other irreversible or destructive actions.

The exact tenant name must be typed into a text field before Confirm and continue becomes clickable.

Only after that confirmation does the consent get recorded, with a timestamp and the acknowledging operator’s own email — never a value typed into the request itself.

Step 3 — Choose the retention period and lock

Step 3 stays disabled until both Step 1 and Step 2 are complete. It presents a single numeric field, labeled Retention period, in days, defaulting to 2,555 — the field’s own helper text notes this is approximately seven years. Any positive number of days is accepted.

Clicking Lock vault now (irreversible) submits the chosen retention period. The button is styled distinctly (in the same red used elsewhere for destructive actions) and is the only remaining action on the page once Steps 1 and 2 are done.

On submission:

1. The vault’s status moves to Provisioning, and the wizard shows a “Locking in progress…” indicator in place of the retention field and button.
2. BYOVault creates the provider-side immutability configuration and locks it — enabling Object Lock in Compliance mode and setting a bucket-default retention rule for AWS, or creating and then locking a container-level time-based retention policy for Azure.
3. If this fails, the vault’s status becomes Failed and the wizard surfaces the reported error directly above Step 1 — a vault in this state is never treated as locked, and Step 1 reopens automatically for editing since a bad credential is the most common cause.
4. If it succeeds, the vault’s status becomes Locked and the whole wizard is replaced by a single summary card: the retention period, the date it became active, and which storage account and provider it is locked against.

After locking — extending the period

Once locked, the summary card exposes a single remaining control: Extend retention period, a numeric field constrained to a value greater than the current retention days, since the period can only be lengthened, never shortened.

See Extending a Retention Period for the full mechanism, including the limited number of times an Azure vault’s policy can be extended over its lifetime.

Vault history and starting a new generation

Viewing vault history

Once a tenant has more than one vault generation, a Show vault history link on the locked summary card lists every generation the tenant has ever had, each with its provider, container/bucket name, status, and — for locked generations — its retention period.

Starting a new generation

A collapsed link, “Need new files to go to a different storage account?”, opens the escape hatch for starting a new vault generation. The wizard is explicit that this is uncommon — most tenants only ever need one vault.

Starting a new generation freezes the current vault exactly as it is: still locked, and still independently enforcing its own retention period. It opens a fresh Step 1 for a different storage account. Files already in the current vault never move to the new one.

For more detail on what each of these three steps does — including what a locked policy actually looks like at the provider level — see How the Vault Is Provisioned & Locked.