Destructive events

MFA stops the admin login being phished. It does not change what the admin login can do once somebody holds it, whether that is an attacker who got past MFA, a contractor whose access outlived the contract, or the admin themselves on a bad day. Prevention shrinks the number of ways to the admin login; it never shrinks what the login reaches. And on Ironwood's graph the admin login reaches the backups, because the backups are the account's own time travel and snapshots.

That is why the bench shows recoverable at zero all the way up to the logging rung, and why the "all prevention, no detection" over-correction still shows twelve: it includes immutable backups. Recovery is a property of where the copy lives and who can delete it, not of how hard the front door is to open.

• Time travel - the warehouse's ability to query or restore a table as it was at an earlier point inside a retention window. Superb for undoing a mistake. Held by the account.
• Snapshot - a point-in-time copy of a table or database inside the same platform. Also held by the account, also subject to the account's retention settings.
• Retention window - how far back time travel or snapshots reach. An account setting. Whoever can change the setting can shorten it to nothing.
• Immutability, object lock - a storage setting that makes an object undeletable and unmodifiable until its retention period ends, by anyone, including the account's own administrators. The cloud providers each name it differently; the property is the same.
• Separate account - a second cloud account or project whose credentials the warehouse administrator does not hold. The copy lives there.
• Restore drill - actually restoring a copy into a scratch location, on a schedule, and timing it. The only proof a backup exists.
• Recoverable - the bench's third number: whether an attacker who reaches the admin login can also destroy the copy you would restore from. Twelve tables, all or nothing.

• The twelve tables. A drop is one statement per table, or one per schema. Seconds.
• The retention window. Time travel and snapshot retention are account or object parameters, and the admin role sets them. Reducing retention to its minimum, or dropping the objects that hold the snapshots, purges the recovery window that the drop would otherwise have been undone from.
• The warehouse-side export jobs. If your nightly copy is written by a job that the same admin controls, to a bucket the same account owns, the job can be stopped and the bucket emptied from the same seat. The copy has to live where the admin cannot follow it.
• Not the object-locked copy in a separate account. This is the only item on the list the login does not reach, and it is the whole of tonight's control. The admin can still drop every table; on Monday morning the twelve tables come back from a copy the drop never touched.

Ransomware against a data estate follows one shape: drop or encrypt the tables, purge whatever the account can reach that would restore them, then demand. The second step is the one that decides whether the third step has any leverage. An estate whose only recovery is the account's own time travel has handed the attacker both the tables and the undo button.

On the bench, recoverable tables read 0 of 12 at every rung from nothing on through query logging, and 0 at the "perimeter firewall only" over-correction too. Immutable, restore-tested backups take it to 12 with paths still at three and undetected still at zero. The path count is untouched because the copy removes no way in; it removes the admin-to-backups edge, which was never a path to the crown jewels. It was the path to Monday.

The test is one question: can the credential that can destroy the original also destroy the copy? If yes, the copy protects against hardware failure, bad deploys and accidental deletes, all of which are real and worth protecting against. It protects against nothing that holds the admin login, because whatever dropped the table can delete the copy in the next statement.

The fourth row is the one teams stop at, and it is nearly right. A separate account whose own administrator can still delete the copy has moved the problem, not removed it. Object lock is what turns a second account into a backup: the delete is refused for everyone until the retention period ends.

• Immutable. Object lock, or the storage platform's equivalent, with a retention period. Until the period ends the object cannot be deleted or overwritten by anyone, including the account's own root or owner. Without this, the second property only moves the problem to whoever administers the second account.
• Separate. A different cloud account or project, with its own identities, that the warehouse administrator has no login to. The export job that writes the copy has write access to the destination and nothing else; the warehouse side can push and cannot list, read or delete. Without this, the warehouse admin credential reaches the copy through the account it already holds.
• Restore-tested. Restored into a scratch schema on a schedule, with the row count compared to the source and the elapsed time written down. Without this, the first two properties protect a file that may not load, may be missing a table, or may take three days to bring back when the business expected three hours.

A copy that nobody can delete for 30 days is a copy that you cannot delete for 30 days either. Your own mistakes, a copy that accidentally includes a column it should not, a table exported before a legal deletion request was honoured, all of them sit in the locked bucket until retention ends. That is not a flaw to engineer around; it is the property doing its job, and it is why the retention period is a governance decision with the data owner and whoever answers for privacy, not a platform default.

The practical shape: retention long enough that an intrusion discovered late still has a clean copy behind it, short enough that the storage cost and the deletion-request exposure are ones the business has agreed to. Thirty days is a common opening position. Write down who agreed and when.

Not everything, nightly. Twelve tables at Ironwood, of which one is the incident and the rest can be rebuilt from source systems and pipelines if the definitions survive. The immutable copy carries the crown jewels and the metadata needed to rebuild the rest: table definitions, pipeline code, the grants, the inventory file. Copying every table every night into a locked bucket is a storage bill with a retention period; copying what cannot be rebuilt is a backup.

• The crown jewels, full, nightly, in an open columnar format that any engine can read. The restore should not depend on the warehouse that was just dropped.
• The definitions: DDL for all twelve tables, the pipeline repository at the deployed commit, the role and grant definitions. Small, and the reason the other eleven tables come back.
• The inventory file itself, because after a destructive event it is the map of what existed.

The drill is the only proof. A backup that has never been restored is a hope with a storage bill. The drill is not a checkbox: it is a restore of last night's copy into a scratch schema, a row count compared against the source, and a stopwatch. The elapsed time is the number the business actually needs, because "we have backups" and "we can be back in four hours" are different promises. Do it monthly at first, quarterly once it is boring. The date of the last successful drill goes in the inventory file next to the edge it closes, and a drill date older than a quarter is a finding.