WHEN SOMETHING
GOES WRONG.

How much data you can afford to lose, and how long you can afford to be down. Every recovery decision follows from those, and an organization that has not chosen them has chosen them implicitly and badly.

A log that is never updated or deleted is far easier to reason about after an incident: recovery is replaying events rather than reconciling a mutable state nobody can reconstruct. The financial ledger has the same property by design.

Restoration has to be practiced, on a schedule, to a real environment. Almost every serious data-loss incident involves a backup that existed and could not be used.

The database is managed with provider-level backups, and the record structure is append-only, which meaningfully limits what a bad write can destroy. A documented recovery plan with tested objectives is not in place, and saying so is more useful to somebody assessing risk than a paragraph implying one.