"Immutable backup with Object Lock: what actually protects you"

Modern ransomware is not content with encrypting production data. The operator goes for the backup first — because an intact backup makes the ransom unnecessary. If they delete your copies before encrypting, the negotiation starts with you having no alternative.

That is what immutability is for. And it is why how it is configured matters more than the fact that it is on.

What Object Lock actually does

S3 Object Lock prevents an object version from being deleted or overwritten until a given date. It requires versioning and is set at bucket creation — you cannot turn it on later for a bucket that already exists.

There are two modes, and the difference between them is the most important thing in this article:

Governance mode. The object is protected, but anyone holding the specific permission to bypass retention can remove that protection. It defends against mistakes, faulty automation and a compromised low-privilege credential.

Compliance mode. Nobody removes the protection before the deadline. Not the administrator. Not the root account. Not AWS at the account holder's request. It defends against an attacker who has already taken administrative control.

The choice is real and cuts both ways. Compliance mode genuinely protects against the worst case — and also means a mistake of yours is final. Wrote 500 TB with a ten-year retention by accident? You will pay for ten years. There is no undo button, and that is precisely what makes it effective.

Where the protection usually leaks

Turning Object Lock on and considering the matter closed is the most common error. Protection depends on what surrounds it:

Retention has to outlast detection time. Compromises go unnoticed for weeks. Seven-day retention does not protect you against an intruder who has been in your network for a month — by the time you notice, the window has passed and the protected versions can be deleted.

Lifecycle can delete what retention would protect. An expiration policy configured independently sits badly next to retention. The result is usually discovered late: data that should exist, and does not.

Whoever writes should not be able to delete. If the same credential that ships the backup holds delete permission, compromising it takes down both ends. Writing and deleting should be different identities.

Governance without restricting the bypass permission is theatre. Governance mode only means something if the permission to bypass retention is genuinely restricted. If everyone on the infrastructure team has it, you have a warning, not a protection.

Immutable does not mean recoverable

This is the point that costs the most. Immutability guarantees the data was not altered. It does not guarantee it is useful.

A backup can be perfectly protected against deletion and still be worthless because:

• the encryption key was lost — and without it, immutable data is protected noise;
• the index that says where each file lives was never tested;
• nobody knows how to run the recovery without the person who is on holiday;
• recovery takes longer than the business can stay down.

The right question is not "is the data immutable?". It is "how long does it take me to get this file back, and have I actually timed it?".

The encryption key is the single point of failure

If the backup is encrypted — and it should be — the key becomes as critical as the data. Losing it produces the same practical result as losing the backup, with the added insult of still paying for the storage.

Two rules cover most cases:

1. The key does not live only on the machine that performs the backup. If it dies with the server, the backup dies with it.
2. The key's copy is tested. Storing it in a vault and never checking that the copy works is the same class of error as never testing recovery.

Honest checklist

• Object Lock enabled, with versioning — and the mode chosen deliberately, knowing that compliance has no way back.
• Retention longer than your realistic detection time, not your desired one.
• Write identity without delete permission.
• Bypass-retention permission limited to a few people, with usage logged.
• Lifecycle policy reviewed together with retention, not separately.
• Encryption key stored outside the backup server, with a tested copy.
• Recovery exercised end to end, timed, with the real identity.
• Audit trail of who asked for what — including retrievals.

None of these items is expensive. What is expensive is discovering one of them missing on the day the backup is the only thing between you and paying a ransom.

NubliVault writes with Object Lock enabled, separates write and delete identities, records every action in an audit trail, and runs on the customer's own infrastructure, with their keys. See the security page.