Fail-closed by default: backups and deletion in a regulated database platform

The most dangerous moment for regulated data is usually not an attack. It is a routine deletion that should not have happened, or a backup everyone assumed was running and was not. A platform’s defaults decide how those moments end. Here is what “fail-closed” means for a database platform, and why it is the only defensible default for production data.

Fail-closed versus fail-open

A fail-open system does the destructive thing when a safeguard cannot answer: it deletes even though the backup check timed out, because proceeding was the default. A fail-closed system refuses. For the deletion of a production database, fail-closed is the only safe posture, because the cost of a wrong “yes” is unrecoverable and the cost of a wrong “no” is a retry.

What a safe delete looks like

A destructive delete should be gated behind two things: a verified final backup, and an out-of-band confirmation such as an emailed one-time code. If the backup fails or times out, the data is preserved rather than removed. The only path that proceeds anyway is an explicit, recorded consent bypass, so a deletion is always either safe or a deliberate, logged decision.

Backups that are actually restorable

A backup you have never restored is a hope, not a control. Each engine has its own correct way to take a consistent, restorable backup, so a generic dump is not enough. A platform should give every engine a validated backup-and-restore path into a dedicated store, and the only way to know it works is that restoring has been exercised.

Retention, and an audit trail that outlives the data

Regulators care about how long evidence is kept and whether it can be altered. An audit log that is immutable and survives even the deletion of the organisation it belongs to means the record of what happened does not disappear with the data. Deletion should be provable, not silent.

How Nothi does it

Nothi provides a guarded deletion flow with backup checks and emailed confirmation. Where the backup guard applies, failure blocks the normal path; an explicitly authorized bypass is a separate, recorded decision. Confirm the engine and tier’s backup support before treating deletion as recoverable. Each of its engines has its own validated backup-and-restore path, and every mutation is written to an immutable audit log that survives organisation deletion. Safe defaults are the point, not an add-on.