Audit Log Event Reference
Every action you or your team takes in BYOVault is recorded to your audit log, together with who performed it, which tenant it applied to, and when. This page lists what gets recorded and which of those actions also send you a notification email.
What an audit log entry contains
Each entry records the action that was taken, the account and (where applicable) tenant it applies to, the email address of whoever performed it, context details specific to that action, the originating IP address, and a timestamp.
Related actions are grouped by category — tenant connections, backup jobs, account settings, restores, and retention vault actions. That grouping is also what the notification toggles on your Operator Notifications & Digests settings apply to.
Actions that can send a notification email
The actions below are recorded to the audit log and, when you have that category’s notifications enabled, also send a notification email describing what happened.
- Connected a tenant
- Re-approved Microsoft permissions
- Changed backup scope
- Forced a full rescan
- Started a backup job
- Cancelled a backup job
- Paused a backup job
- Resumed a backup job
- Changed the session timeout
- Signed out a device remotely
- Updated notification preferences
- Updated the weekly digest schedule
- Downloaded a backed-up file
- Restored an email into a mailbox
- Restored a file into a drive
- Re-indexed Exchange metadata
Each action’s description becomes the subject line of the notification email sent for it (prefixed with “BYOVault: ”), and the email body carries whichever tenant, job, and other context applies to that particular action.
Retention vault actions
Retention vault actions are written to the audit log in full, with the same actor, tenant, and context details as any other entry. These include:
- consent acknowledgment
- storage configuration
- provisioning failure
- locking
- same-cloud copy-grant failure
- extension
- starting a new vault generation
These actions do not currently send a notification email; review them in the audit log directly.
Vault integrity check failure
A distinct, verified finding written by the vault integrity check.
Unlike every event above, it is generated automatically by the daily integrity check rather than by an operator action, and it is recorded under a system actor rather than a human email — this check runs unattended, with no operator or end user in the loop.
It is written only when a real mismatch is found; a clean check produces no entry at all.
Each entry identifies the specific vaulted item, its path in your storage account, and a reason describing exactly what did not match. The reason is one of three cases:
- the blob no longer exists in the vault storage account
- the size the storage provider reports no longer matches the size recorded in the catalog
- the storage provider reports the object’s immutability lock as no longer active
Notification settings never affect the audit log
Every entry above is written to the audit log regardless of any notification setting — the audit log itself is not configurable and is never suppressed. Whether a given entry additionally produces an email is a separate matter, controlled by the operator’s own notification toggles. See Operator Notifications & Digests for how those toggles are configured.