A backup job reporting success proves a file was written. It does not prove the file can be read, is uncorrupted, or contains what you think. This log records the only thing that answers that question: an actual restore, timed and verified.
Most DR plans are written to satisfy an auditor and are unusable in an actual disaster: too long, structured by system rather than by sequence, and assuming the authors are available. This one is ordered the way the event unfolds.
Most backup policies describe a schedule and stop. The clauses that decide whether you recover from ransomware are the ones usually missing: an immutable copy, an offline or logically-separated copy, and a stated obligation to test restores.
Ransomware recovery differs from ordinary disaster recovery in one decisive way: the environment you restore into may still be compromised. This playbook sequences containment and credential reset before restoration, so you do not recover twice.
A BIA exists to decide the order you recover things in when you cannot recover everything at once. That makes the useful output a ranked list, not a document, and ranking requires scoring impact at several time horizons, because impact is rarely linear.
RTO and RPO are usually set by asking the business what it wants, which reliably returns 'zero'. This worksheet sets them the other way round: measure what you can currently deliver, price the gap, and let the business choose knowingly.
Disaster recovery restores the systems. Business continuity answers what people do in the meantime, and that gap is where most organisations have nothing written down, because it belongs to departments rather than to IT.
Nobody plans to leave a system unbacked up. It happens because a service was spun up outside the normal process, or because everyone assumed the SaaS vendor handles it. This matrix exists to make the gaps visible rather than discovering them during a restore.