Object Lock Backups: Test Deletion Resistance

Before calling a backup immutable, identify every route that can make it unusable. Deleting its files is one route. Deleting an encryption key, losing the recovery account or retaining an incomplete database copy can leave the business in the same position.

For a small organisation, the useful outcome is specific: an attacker controlling the production server and its normal backup credentials cannot remove every usable recovery point. That is a boundary to demonstrate, not a feature name to put in a tender response.

Start with the protected object version

Amazon S3 Object Lock applies retention to individual object versions. New versions and delete markers can still be created, so an apparently missing object does not necessarily mean its protected version has disappeared. Recovery procedures must know how to find the required version. AWS explains this distinction in its Object Lock documentation.

Governance mode permits a specifically authorised identity to bypass retention. Compliance mode prevents shortening the retention period or deleting the protected version through ordinary object operations, including by the account root user. Choose deliberately: a retention mistake in compliance mode can leave unwanted data and its storage cost in place until expiry.

Write down the intended period in business terms. It must cover a plausible delay between corruption and discovery, followed by investigation and recovery. A seven-day policy is inadequate if a damaged monthly process is normally noticed three weeks later. There is no universal correct number.

Separate the jobs and their permissions

Review the identities used for four different jobs: producing backups, administering retention, reading backups during recovery, and maintaining the storage account. Putting all four permissions on the production server defeats much of the intended separation.

The backup application may need more than simple object upload permission. It can maintain indexes, locks and metadata, and its cleanup process may expect to remove old objects. Check its documented compatibility with the chosen object-lock mode. Do not discover during an incident that retention prevented the application from completing normal repository maintenance.

Ask these questions against the actual policy:

• Can the production credential bypass retention or change the default for future objects?
• Can it delete unprotected metadata needed to interpret protected data?
• Can the same compromised administrator change lifecycle rules, identity policies or key permissions?
• Does the recovery operator have a separate, tested route to read historical versions?

These are permission-review questions. They do not imply that every storage provider implements S3 semantics identically.

Protect the decryption dependency

AWS explicitly states that Object Lock does not protect against losing or deleting the encryption key. A locked object can survive while becoming unreadable. Its Object Lock considerations describe this limitation.

Record whether encryption is controlled by the backup application, the storage service, a customer-managed key service, or several layers together. Identify who can disable each layer and where its recovery information lives. Alerting on object deletion alone misses this failure mode.

For customer-managed AWS KMS keys, scheduled deletion has a waiting period and can be cancelled before deletion completes. Treat a deletion request as a recovery-threatening event requiring investigation. Do not shorten that window merely to tidy the console. AWS documents the deletion lifecycle and its irreversible consequences.

Run a disposable retention exercise

Use a separate test bucket or repository with synthetic files. Record the account, policy, retention mode, expiry and credentials used. Attempt the deletion paths relevant to your threat model with the backup identity, then confirm that the recovery identity can retrieve the intended historical version.

Next restore through the backup application. Opening one object in a storage console does not prove that the repository catalogue, application configuration and data all fit together. Include at least one representative application restore, with external integrations disabled in the test environment.

The evidence should show expected denials, successful retrieval, application acceptance checks and any dependency that still required the production environment. Record failures as work to complete; do not convert a partially successful exercise into a blanket claim of ransomware recovery.

Make the rollout supportable

Pilot a small backup set before applying long retention across the estate. Estimate storage growth, the cost of retrieving data and the effect on normal pruning. Keep the existing validated backup route until the replacement has passed a recovery exercise.

For tenant access, the separate Microsoft 365 emergency-account guide covers identity recovery. The storage account and encryption keys need the same explicit treatment, with their own dependencies recorded.

Name the owner who reviews retention, access and restore evidence after changes. A protected copy only helps if the next administrator can locate it, decrypt it and use it within the time the business can tolerate.

References

• AWS: Locking objects with Object Lock. Accessed 17 October 2026.
• AWS: Object Lock considerations. Accessed 17 October 2026.
• AWS: Delete an AWS KMS key. Accessed 17 October 2026.