Destructive-change protection

Attackers who reach an administrator account go for the backups first: delete the restore points, shorten retention, switch off the lock. In BackupVision360 none of that can be done by one person.

What counts as destructive

• Deleting a restore point
• Shortening retention (any rule, including how long points of deleted resources are kept)
• Removing or redirecting a copy rule or a vault copy, or weakening or removing a lock
• Deleting a policy or a storage target that still holds restore points
• Changing a cloud account’s roles, credentials or vault while it holds recovery points, or disconnecting it
• Rotating a target key held in your own KMS
• Closing BackupVision360 managed storage, or exporting it to your own bucket

How it works

1. Someone with the destructive changes right asks for the change and confirms with their authenticator. It appears under Restore → Restore requests, and on Home for the people who can approve it.
2. A different person with the same right approves it, also with a fresh authenticator check. Service-provider staff can never ask for or approve these changes.
3. Retention cuts wait 24 hours after approval before they take effect, with a notification, so a mistake or an attack can still be stopped.
4. Everything is recorded in the hash-chained audit trail.

Making things safer (longer retention, an extra copy, a new lock) applies at once and needs no second person.

Locks still win

Approval doesn’t override a storage lock. A restore point under a locked retention policy (managed storage, S3 Object Lock, Azure immutable blobs, GCS bucket lock, an EBS snapshot lock) can’t be deleted by anyone until the lock expires. Deleting BackupVision360 managed storage keeps the data until every lock has expired, then crypto-shreds the keys.