Backup and Restore: What to Demand Before You Sign

A finance director asked us last month why their “fully managed” host could not produce a restore report newer than fourteen months. Backups ran nightly; dashboards showed green. During a ransomware tabletop, nobody knew whether the off-site copy was reachable without the compromised admin account. The contract mentioned “industry-standard backup” — which, in practice, meant a checkbox on a sales deck.

Backup is where managed IT deals often look cheapest and fail most expensively. This guide is for owners, CFOs, and IT leads who need to evaluate proposals without becoming backup engineers — but who still want evidence, not hope.

What “backup included” should mean in scope

Clarify what is backed up: operating system only, application data, databases with consistent snapshots, SaaS tenants, or virtual machines whole-stack. Clarify where copies live: same datacentre, partner site, object storage in another region, offline tape. Clarify who can delete or overwrite them — shared admin with production is a common failure mode.

Good scope documents list systems by name or tier, not “all servers”. They state retention (daily/weekly/monthly), encryption in transit and at rest, and whether you receive restore files directly or only through the provider.

RPO and RTO — written, tied to business systems

Recovery Point Objective (RPO) is how much data you can afford to lose — four hours of orders, one business day of finance postings. Recovery Time Objective (RTO) is how long restore may take before the business stops waiting.

Demand a small table in the contract or service description:

• Tier-1 (ERP, email, customer-facing apps): RPO ___ / RTO ___
• Tier-2 (internal tools, reporting): RPO ___ / RTO ___
• Tier-3 (archives, dev): RPO ___ / RTO ___

If the vendor gives one number for everything, they have not thought about your business. If they refuse to put numbers in writing, assume worst case.

Restore tests — the only proof that matters

Scheduled backups that never restore are inventory, not insurance. Ask:

• When was the last successful restore test for a client with similar size and stack?
• Who witnessed it — provider only, or customer too?
• How long did full restore take versus RTO?
• Is there a signed report or ticket export you can file?

Quarterly restore of at least one tier-1 system is a reasonable minimum for mid-market firms. Annual “we restored a random file” is not enough when ERP must come back whole.

Ransomware-specific questions

Modern incidents encrypt production and backups together. Before signing, ask:

• Are backup repositories immutable or WORM-protected for a defined window?
• Is there an air-gapped or offline copy on a schedule you can audit?
• Do backup credentials differ from domain admin and cloud tenant owner?
• What is the documented restore path if Active Directory or Entra ID is compromised?

Link this to your incident runbook — NIS2 and insurance questionnaires increasingly ask for backup integrity after attack, not just existence.

Red flags in proposals

“Unlimited retention” without storage cost model. Restore priced per hour with no cap. Backups stored only on the same SAN as production. No mention of database-consistent snapshots for SQL or PostgreSQL. “Cloud backup” that is really the same vendor’s second folder. Migration offered free but backup scope excluded from SLA.

One-page checklist before signature

• Scope list by system/tier with retention and encryption stated.
• RPO/RTO table signed or attached to SLA.
• Last restore test report (< 90 days for tier-1, or explain gap).
• Ransomware section: immutability, separate creds, AD recovery note.
• Named backup owner on provider side + escalation path.
• Exit clause: how you receive backup data if you leave.

How to run a restore drill in one afternoon

You do not need a disaster to learn whether backups work. Pick a non-production twin of one tier-1 system — a copy of the ERP database, a file share, or a VM that finance does not need that day. Book four hours. Named roles: one person from the provider (or your backup owner), one from the application, one from IT who can create a throwaway restore target. The drill has four clocks:

1. Locate — time from “start” to “we have the right restore point and we can authenticate to the repository without production admin.” If this exceeds 20 minutes, credentials or documentation are already a finding.
2. Restore to isolated target — not overwrite production. Record GB restored and minutes elapsed.
3. Application smoke — can a user log in, open a known document or post a dummy journal? “The VM pinged” is not a pass.
4. Sign the report — date, RPO achieved (gap between last good copy and “now”), RTO achieved, gaps, owner of each fix. File it where legal and insurance can find it without the backup admin.

We have seen “green backup dashboards” fail at step 1 because the immutable repository used the same domain admin that ransomware would steal. The drill exists to find that before the tabletop, not during it.

Numbers we actually see in mid-market contracts

These are not standards — they are ranges that survive a board conversation in firms of 50–200 people in Poland and Germany. Adjust to your risk, then write them down.

• Mail / M365 — RPO 1–4 hours if you pay for a third-party backup of Exchange/SharePoint/OneDrive; native recycle bins are not a restore strategy for ransomware. RTO: hours, not days, for a mailbox; a tenant-wide recover is a different sport.
• ERP (Comarch, Enova, SAP B1, custom) — RPO often 4–24 hours depending on log shipping. RTO 8–24 hours for a consistent database plus application server is honest; “two hours” without a tested runbook is theatre.
• File / CAD / production docs — RPO nightly is common and often too loose if Friday’s drawings are Monday’s shipment. Ask operations, not IT, how many hours of work they can afford to redraw.
• Retention — 14–30 daily, 8–12 weekly, 12 monthly is a starting point. “Unlimited” without a storage price is a future invoice.

If the vendor quotes one RPO/RTO for everything, they have not sat with your month-end or your shipping window.

3-2-1-1-0 without the poster

Three copies, two media, one off-site, one immutable or offline, zero errors on the last restore test. In practice for a mid-size firm: production disk + backup repository on a different array or object store + a copy the compromised admin cannot delete (immutability window of 7–30 days is typical) + a restore report younger than 90 days for tier-1. Tape is not mandatory. A second vendor account that production AD cannot reach often is.

Technicians: consistent SQL/PostgreSQL snapshots (VSS or dump, not crash-consistent only), separate backup service account, MFA on the backup console, and a break-glass path if Entra ID or AD is down. If your only restore path requires the same IdP that just got phished, you do not have a ransomware plan — you have a hope.

What insurers and auditors ask in 2026

Cyber questionnaires no longer stop at “do you have backups?” They ask for immutability, last restore date, whether backups are reachable with production credentials, and who signs the restore report. NIS2 readiness reviews ask the same, then ask where the report lives. Put a copy in the same evidence pack as your incident runbook — see what must be in the NIS2 runbook. If you cannot answer those four questions in one sitting, do not sign a new “managed backup” clause until you can.

What to do next

Pull your current contract and highlight every sentence that says “backup” without numbers. Request a restore drill on one non-critical system before renewal — or before migrating tier-1 workloads. Our Secure Public Cloud Infrastructure practice designs backup and restore with tested runbooks, not dashboard theatre — aligned with how auditors and regulators actually ask questions.

More from this topic

Cloud RFP: How to Compare Three Vendors Without the Deck

Three proposals, three logos, zero comparability. A scoring matrix for mid-market firms: scope, SLA, restore proof, admin model,…

ERP Migration: When Cloud — and When to Stay On-Prem

“Move ERP to cloud” is not a strategy. Decision criteria for mid-market: downtime tolerance, integration with shopfloor, licensing,…

How to Choose Managed Cloud When You Have 50–200 Employees

You are past “a server in the office” but not ready for a 15-person platform team. A plain-language…