MSP business impact analysis template: set RTO and RPO with the client before the outage

Get the client to sign their recovery targets before anything breaks. A business impact analysis (BIA) is the one-hour meeting where that happens.

Picture the call. It's 7:10 on a Monday, the file server is encrypted, and the owner asks your account lead one question: "When are we back?" If nobody ever agreed on an answer, your team is now making it up live, and whatever number they say becomes the promise.

The fix is boring and it works. Sit down with the client once a year, list the business processes that matter, and write down how long each one can be down and how much data it can lose. The client owns those numbers. Your MSP owns proving whether the current setup can hit them.

This post gives you the interview questions, a worksheet you can copy, three starting tiers, a worked example, and a sign-off block. It sits upstream of the backup and BDR scope template, which prices the service once the targets exist.

The four terms, in plain words

NIST's contingency planning guide, SP 800-34 Rev. 1, is the cleanest public source for these definitions. Here they are without the federal phrasing:

• Business impact analysis (BIA): a structured look at which business processes depend on which systems, what an outage costs the business, and which things get recovered first.
• Maximum tolerable downtime (MTD): the total outage the business owner is willing to accept for a process before the damage is unacceptable.
• Recovery time objective (RTO): how long a system can stay down before it pushes the process past that limit.
• Recovery point objective (RPO): how much data the process can afford to lose, measured back from the moment of the outage to the last good copy.

One rule from the guide does most of the work: the RTO normally has to be shorter than the MTD. Recovery doesn't end when the server boots. Someone still has to re-enter the lost transactions, check the data, and tell staff they can work again. That time lives inside the MTD too.

NIST also splits the BIA into three steps: identify the processes and how critical they are, identify the resources each one needs, and set recovery priorities. The worksheet below follows that order.

Why the client signs, and your MSP doesn't pick the number

Your engineers can tell you what the backup stack can do. They can't tell you what a day without billing costs a 30-person engineering firm. Only the client knows that.

When the MSP picks the targets, two things go wrong. The targets drift toward whatever the current backup product happens to deliver, so every gap disappears on paper. And when an outage runs long, the client remembers the number your team said on the phone, with no record of who chose it.

When the client picks the targets, the conversation changes. A four-hour RTO on the accounting system becomes a business requirement with a price. If the client decides the price is too high, they choose a longer target, and that choice is in writing.

Run the BIA interview in about an hour

Book the owner or general manager plus whoever runs operations or finance. The vCIO or account manager leads. Bring a senior technician who knows the current backup and recovery setup, and keep them quiet until the last section.

Ask these questions for each business process, in this order:

1. What does the business do every day that stops or slows if this system is gone?
2. Who notices first, and who would call us?
3. What happens after four hours down? After one business day? After three?
4. Are there hard dates that make it worse, like payroll, month-end close, a filing deadline, or a seasonal peak?
5. If we restored it to how it looked yesterday at 6 PM, what work would be lost and who would have to redo it?
6. Is there a manual workaround, and how long can people live with it?
7. What else has to work first? Identity, internet, a vendor portal, a license server?

Questions three and five give you the MTD and the RPO. Write the client's words next to the number. "We can't invoice, and the bank line review is on the 20th" is more useful at renewal time than "Tier 1."

Copy the BIA worksheet

Paste this into the client record, one block per business process:

Client:
BIA date:
Business owner who set the targets:
MSP lead (vCIO or account manager):

Business process:
Systems it depends on:
Process owner at the client:
What stops if it is down:
Hard dates or peaks:
Manual workaround and how long it lasts:

Maximum tolerable downtime (MTD):
Recovery time objective (RTO):
Recovery point objective (RPO):
Check: RTO is shorter than MTD (yes/no)

Dependencies that must recover first:
Current protection (backup method, frequency, copy location):
Last restore test (date, scope, measured time):
Can current setup meet RTO? (tested / designed but untested / gap)
Can current setup meet RPO? (tested / designed but untested / gap)

Gap:
Client decision: Fund / Schedule (date:      ) / Accept the risk
Decision owner:

The "last restore test" line is the one teams skip. A backup that has never been restored to the target hardware, in the target time, is a design. Mark it "designed but untested" and say so out loud.

Start with three tiers, then let the client move things

Most clients have never thought in hours. Give them a starting point and let them argue with it. These defaults are ours, written for a small professional-services client. They come from no standard, so replace them with the client's answers.

Two habits keep the tiers honest. First, ask the client to place each process before you show them what each tier costs, so the answer reflects the business. Second, cap Tier 1. If eight of ten processes land there, nothing is prioritized, and your team can't recover eight things first.

A worked example

The client and numbers below are fictional. They show how a finished page reads.

A 30-person civil engineering firm with Microsoft 365, a project accounting app on an on-premises server, CAD files on a NAS, and a hosted phone system. The managing partner and the controller sat in.

The summary line for the managing partner: 4 processes reviewed: 1 meets target, 2 need a funded fix, 1 depends on a vendor.

That one sentence is the QBR conversation. The accounting row needs more frequent backups and a timed restore test. The CAD row needs either a faster recovery path for a full site loss or a longer RTO that the partner signs. The phone row needs the vendor's own recovery commitment in the file. For the email row, the Microsoft 365 Backup vs third-party backup comparison covers restore scope, cost and testing.

Turn every gap into a client decision

A gap row with no decision is a liability your MSP is carrying for free. Each one should end in one of three answers:

1. Fund it. Approve the backup change, the restore test, or the faster recovery path.
2. Schedule it. Pick a date and an owner, so it comes back on purpose.
3. Accept it. The client chooses a longer target or keeps the gap, and signs the row.

This is the point where the BIA turns into project work. Each gap is an assessment finding with a business reason attached, and the next step is scope. In Scopable, those findings sit in the client's assessment and scoping workflow, where they become reviewable scope before anyone builds the quote.

Bring the gap rows to the next review with the rest of the client's open decisions. The MSP QBR scorecard has a row for recommended work the client hasn't funded, and BIA gaps belong there.

The sign-off block

Put this at the bottom of the worksheet and get a name on it:

I reviewed the recovery targets above for [client]. They reflect the
downtime and data loss the business can accept for each process.

Where the current setup does not meet a target, I chose one of:
fund the fix, schedule it by the date shown, or accept the gap.

Name:
Title:
Date:
Next review date:

Signed targets also help with paperwork the client already has. Cyber insurance questionnaires commonly ask whether backups are tested, and the cyber insurance requirements guide covers what underwriters look for. A client WISP or incident response plan can point to the BIA for its recovery priorities.

When to rerun it

Once a year is the floor. Rerun the affected rows sooner when:

• The client adds or replaces a line-of-business app.
• They move a workload to the cloud or back on premises.
• Headcount changes enough to change what a day of downtime costs.
• The cyber insurance renewal comes up.
• A restore test misses its RTO.

Keep the old worksheet. When a target changes, the history shows who changed it and why.

Prove the targets with a restore test

The BIA sets the target. A restore test shows whether you can hit it. Time the whole job, from the moment someone declares the outage to the moment the process owner confirms people can work. A restore that "finished in two hours" after a three-hour wait for the right engineer took five hours.

The backup and BDR scope template has a restore-test record that matches the statuses in this worksheet: tested, designed but untested, and gap. If you're also choosing the backup product, read the Datto BCDR vs Acronis comparison after the BIA. The client's targets tell you which features matter.

If you'd like the gap rows to land in a client record that carries into scope and the quote, start Scopable for free.

Who owns what

The client owns the targets and the decision on every gap. Your MSP owns the honest answer about current capability, the restore tests, and the scope for the fixes. If that split is still fuzzy for this client, the shared responsibility matrix template puts it in writing.