Vault Integrity Checks
A daily, per-tenant check that re-verifies every already-vaulted file against reality in your own storage account — not just against what BYOVault's own catalog says should be true.
Why this exists
Moving a file into the retention vault and locking it is a one-time event. Nothing about that event guarantees the file stays exactly as it was a day, a month, or a year later from BYOVault’s point of view.
The vault account is still a real Azure or AWS account, and the provider’s own tooling still allows certain destructive operations against it outside BYOVault’s own code path — for example, a blob hidden behind a soft-delete marker by someone with delete permission on the account.
The underlying bytes and the provider’s lock can remain intact underneath, while BYOVault’s own listing calls would still fail to find the file. Without a re-check, this kind of divergence would go unnoticed until a client actually tried to restore the file.
The vault integrity check closes that gap by re-verifying every vaulted item against the storage provider’s own answer, on a fixed daily cadence, rather than trusting the catalog indefinitely once a file has moved.
What runs, and when
The check begins automatically for a tenant the first time that tenant’s vault is provisioned and locked.
Every vaulted file is checked every day. There is no sampling and no age-based skipping: every file in the tenant’s vault is covered on every run.
What is actually checked
For each vaulted item, the check issues a single metadata-only request against the object in the vault account, on either AWS or Azure. The file’s content is never downloaded or read. The response is compared against the catalog on three points:
- Existence — the blob is still present in the vault storage account at its recorded path.
- Size — the size the provider reports still matches the size recorded in the catalog at the time the file was vaulted.
- Lock status — the provider still reports the object’s immutability lock as active.
A transient failure on the request itself — a network error or an authentication failure against the storage account — is not treated as an integrity finding. It is retried automatically; only a successful response that disagrees with the catalog counts as a real mismatch.
What happens when something does not match
A healthy file produces no output at all: no log entry, no audit record, nothing written anywhere. Silence is the expected, passing result.
This is a deliberate design choice — a check that writes something for every file it examines becomes noise, and noise is what eventually gets ignored.
A genuine mismatch is any of the following:
- A missing blob
- A size that no longer matches
- A lock the provider reports as no longer active
Any of these writes a permanent entry to the tenant’s audit log (retention_vault.integrity_check_failed), recorded under the system actor rather than any human operator, since this check runs unattended with no one in the loop.
The specific item, its path in your storage account, and the reason for the mismatch are all recorded on that entry. See the Audit Log Event Reference for the full list of events BYOVault records.
Cost at scale
Because each check is a single metadata-only request per file rather than a data transfer, cost scales with the number of vaulted files, not with the volume of data they contain.
At current AWS request pricing, checking every vaulted file once a day costs roughly $12–24 per month per million files on the client’s own AWS bill.
This is a cost incurred on the customer’s own storage account, the same as any other request made against it — it does not appear as a separate BYOVault charge.
Where this fits
Vault integrity checks only apply to files that have already moved into the locked retention vault via archiving. A file still sitting in Hot storage is not covered by this check, because it is not yet subject to the provider-enforced lock described in Retention Policy.