When we sit down with a new client and ask about their backup strategy, the answer is almost always the same: "Yes, we have backups." Sometimes there's a vendor name attached — Datto, Veeam, Acronis, something built into their server. The confidence in the room is usually high. Backups exist. The box is checked.
Then we ask the second question: "When did you last test a full recovery?" The room gets quieter. Sometimes the answer is "we ran a restore of one file last year." Sometimes it's "our previous IT provider handled that." Sometimes it's a long pause.
A backup that has never been tested for recovery is not a control. It's a belief. And beliefs don't hold up in front of a regulator — or a ransomware recovery scenario where your entire environment needs to be rebuilt from scratch in the middle of the night.
What backup health actually means
Modern backup platforms like Datto BCDR generate detailed health reports — sometimes called HERO reports — that show considerably more than "did the backup run last night?" A proper backup health report shows: which systems are protected and which are not, whether backup jobs are completing successfully or failing silently, the size and age of the most recent recovery point, estimated recovery time for each protected system, storage utilization trends, and the results of any recovery verification that's been performed.
Most organizations have never seen this report. Their IT provider sees it — or should be seeing it — but it rarely makes it to the desk of the leader who would actually use it in a crisis. This creates a dangerous asymmetry: leadership assumes the backup situation is fine because nobody has told them otherwise, while the backup environment may have silent failures, uncovered systems, or recovery times that would be operationally catastrophic.
RTO and RPO — the numbers your leaders should know
Recovery Time Objective (RTO) is how long it will take to get a system back online after an incident. Not how long the backup software says it should take — how long it actually takes in a real recovery scenario, with real data volumes, on real hardware, performed by real people under pressure.
Recovery Point Objective (RPO) is how much data you can afford to lose. If your backups run every 24 hours and your RPO is 24 hours, you've accepted that a failure at 11:59pm means you lose a full day of work. For a financial advisory firm processing trades, or a law firm billing by the hour, that's a number leadership should be making a deliberate decision about — not a number that was set by default when the backup software was installed.
Most leaders at regulated firms don't know their RTO or RPO. They've never been asked. Their IT provider set up the backup software at some point and the assumption is that it works. Whether the RTO is 4 hours or 4 days, and whether the RPO is 1 hour or 24 hours, is a business decision that gets made accidentally in most organizations.
What the regulator actually wants to see
Under HIPAA, the Security Rule requires covered entities to implement a data backup plan — but it also requires implementation of procedures to restore lost data and an emergency operations plan. The regulation expects not just that backups exist, but that recovery has been planned, tested, and documented.
Under Reg S-P's Regulation Systems Compliance and Integrity requirements, firms operating critical market technology must maintain backup and recovery capabilities. The expectation isn't just that the capability exists — it's that it's been demonstrated.
When an examiner asks about business continuity, "we have Datto" is not a complete answer. "We run Datto BCDR with daily backup jobs, verified monthly through our platform's recovery testing feature, with an RTO of 4 hours and RPO of 1 hour, last full recovery test performed in [date], documented here" — that's an answer.
The backup report as a client deliverable
One of the most underutilized practices in managed IT is providing clients with a regular, readable backup health report — not as a technical document for the IT team, but as a leadership document for the people who are ultimately accountable for business continuity.
A monthly backup report delivered to the managing partner or COO does several things: it creates accountability on both sides of the relationship, it ensures leadership understands their actual recovery posture rather than assuming it, it generates documentation that's immediately available for an audit or regulatory inquiry, and it forces a conversation when something is wrong before the wrong thing becomes a crisis.
Every production system protected — no gaps. Server by server, application by application, with documented coverage.
Backup jobs monitored continuously, not just reviewed when something fails. Silent failures are the most dangerous kind.
Monthly backup health reports delivered to firm leadership — readable, not technical, with clear pass/fail indicators.
Quarterly recovery tests — not file restores, but full system recovery simulations that validate your actual RTO.
Documented RTO and RPO for each critical system, reviewed annually and aligned with business requirements.
Immutable backup copies — stored in a way that ransomware cannot encrypt — to ensure recovery is possible even after a successful attack.
Offsite or cloud replication — so a physical event at your primary location doesn't take your backups with it.
Backup and recovery isn't the most exciting conversation in IT. It tends to get attention only when it fails — which is exactly when the attention is most expensive. The firms that treat backup health as a managed, reported, tested discipline are the ones that get through incidents. The firms that treat it as a set-and-forget configuration are the ones that find out what "probably works" actually means.