Business Continuity and Disaster Recovery in IT Contracts: 4 Commitments That Actually Matter
Most business owners skim the continuity and recovery section of an IT services agreement. The language sounds thorough, the vendor sounds confident, and everyone at the table is ready to move on. That is exactly the wrong moment to stop paying attention. That section is where the difference between a firm with a real, tested plan and one that uses continuity language as a marketing claim gets written into your contract — the one you are about to sign. This post gives you a clause-by-clause framework so you know what to look for, what to push back on, and what a non-answer actually means.
- Why Contract Language Is the Real Operational Test
- Commitment One: Documented Recovery Time and Recovery Point Objectives
- Commitment Two: Tested Backups With Verifiable Results
- Commitment Three: A Clearly Defined Scope of What Is Actually Covered
- Commitment Four: A Named Communication Protocol for When Things Go Wrong
- Red Flags That Should Stop You Cold
- How to Use This Framework to Make Your Decision
Why Contract Language Is the Real Operational Test for Business Continuity and Disaster Recovery
A vendor’s website can say anything. A sales conversation can promise everything. A contract is a legal document — and what a firm is willing to commit to in writing tells you exactly how much operational depth sits behind their pitch. Firms that have invested in real continuity and recovery infrastructure are eager to put the specifics in writing. Firms that have not will default to vague, aspirational language designed to sound reassuring without creating any actual accountability.
This is not a cynical view of the industry. It is a practical one. Recovery commitments cost money to build and maintain. Testing costs time. Documentation requires discipline. Vendors who have done the work want you to know it. Vendors who have not done the work need you not to notice.
You do not need a law degree or a technical background to tell the difference. You need four specific questions answered in the contract language itself — and a clear sense of what a real answer looks like versus a placeholder.
The Cybersecurity and Infrastructure Security Agency (CISA) defines continuity planning as the process of creating systems of prevention and recovery to deal with potential threats to a company. Notice that definition centers on systems and process — not intention or aspiration. Your contract should reflect the same standard.
Commitment One: Documented Recovery Time and Recovery Point Objectives
Recovery Time Objective (RTO) is the maximum amount of time your business can be down before the damage becomes unacceptable. Recovery Point Objective (RPO) is the maximum amount of data loss your business can tolerate, measured in time. If your RPO is four hours, your backups run at least every four hours — and in a worst-case scenario, you lose no more than four hours of work.
A contract without specific RTO and RPO figures for your environment is not a genuine continuity and recovery contract. It is a general services agreement with recovery language dropped in for comfort. The numbers matter because they drive every downstream technical decision: how often data is backed up, where it is stored, how many copies exist, and how recovery is sequenced.
Your RTO and RPO should reflect your actual business — not a vendor’s defaults. A firm that runs payroll every two weeks has different tolerances than one that processes transactions in real time. A legitimate IT firm will have had a direct conversation with you about those tolerances before any number appears in a contract. If the figures in your agreement look like round defaults — the same ones that appear in every contract that vendor signs — ask exactly how they were determined.
Push for this language in the agreement: stated RTO and RPO targets, the specific systems they apply to, and the circumstances under which those targets may not be met. No honest vendor promises unconditional recovery. The ones who do should concern you more than the ones who acknowledge limits.
Commitment Two: Tested Backups With Verifiable Results
Backups that have never been tested are not backups. They are a theory of backups. This sounds harsh, but it is technically accurate. Backup jobs can run successfully for months while producing corrupted or incomplete restore sets. The only way to know a backup works is to restore from it in a controlled environment and confirm that the recovered data and systems are functional.
Your contract should commit to a testing schedule — at minimum quarterly, monthly for critical systems — and specify what documentation you receive as proof. That documentation should include the date of the test, the systems tested, the result, and what was done if anything failed. You should be receiving this as a standing report, not hunting for it on request.
This is one of the clearest separators between firms with operational depth and firms running on good intentions. Running a backup test and producing a written report requires process, personnel, and accountability. Firms that cannot describe their testing cadence in a contract conversation have not built that process. That is not a firm you want holding your recovery plan.
Ask directly: where are the backups stored? The answer should include offsite or cloud-based storage that is geographically separate from your primary systems. Backups stored on the same network or in the same physical location as the systems they protect will not survive the scenarios that most commonly require a full recovery — ransomware, fire, flood, or a building-level incident.
This approach, built over more than 20 years of managing client environments, is one reason Xact IT has maintained a zero client breach record since 2004. The managed IT services structure we use treats tested recovery capability as a baseline requirement, not an optional add-on.
Commitment Three: A Clearly Defined Scope of What Is Actually Covered
The most common source of post-incident disputes between businesses and their IT firms is not negligence. It is scope ambiguity. The vendor believed they were responsible for backing up the server. The client believed cloud applications were included. Neither assumption was written down. When something goes wrong, the gap between those two assumptions becomes a very expensive argument.
A strong continuity and recovery section will list, explicitly, every system and data category included in the plan. That list should cover:
- On-premises servers and workstations
- Cloud-hosted applications and the data stored within them
- Email systems and historical email archives
- Line-of-business applications (accounting software, CRM, industry-specific platforms)
- Network configurations that would need to be rebuilt after a failure
- Any systems managed by third-party vendors that the IT firm is coordinating recovery for
If anything in your technology environment is not on that list, it is not covered. Do not assume inclusion. Ask the vendor to add it explicitly, or get a written explanation of why it is excluded and what your options are for covering it separately.
The scope question also surfaces a related issue: third-party coordination. Most businesses use a mix of internally managed systems and vendor-managed cloud platforms. When something fails, someone needs to make the calls, manage the queue of recovery tasks across multiple vendors, and track what has been restored and what has not. Your contract should specify whether your IT firm is taking on that coordination role or whether you are expected to manage it yourself. To understand how scope and coverage are structured in professional engagements, visit our IT services overview.
Commitment Four: A Named Communication Protocol for When Things Go Wrong
The middle of a recovery event is the worst possible time to figure out who is supposed to call whom. Yet many IT agreements describe recovery processes in technical detail while saying almost nothing about how the vendor will communicate with you during an actual incident.
Your contract should answer these questions in plain language:
- Who is your named point of contact during a recovery event?
- How will that person reach you, and within what time frame after an incident is detected?
- How often will you receive updates while recovery is underway?
- What form do those updates take — phone call, email, a status dashboard?
- Who has the authority to make decisions during recovery if your primary contact is unavailable?
- What is the escalation path if recovery is running past the stated RTO?
Firms that have run actual recovery events know that communication is as important as the technical work. Business owners need to make decisions in real time: whether to activate a remote work protocol, whether to notify clients of a delay, whether to invoke business interruption insurance. None of those decisions can be made without timely, accurate information from the people running the recovery.
If the contract does not specify how that information flows to you, you will be operating blind at the worst possible moment. Recovery events are inherently chaotic. The firm managing your IT recovery plan should be the calm center of that storm — not an additional source of confusion.
Red Flags That Should Stop You Cold
Beyond the four commitments above, specific phrases and patterns in contract language should prompt you to slow down and ask harder questions before you sign.
- “Best efforts” as the standard for recovery: this phrase has no defined meaning and creates no real accountability. A vendor who commits to best efforts has committed to nothing.
- Recovery commitments that apply only to hardware replacement, not to data or application restoration: getting new servers is the easy part. Getting your data back onto them is the hard part. Make sure the contract covers both.
- Exclusions for “acts of God” or “third-party failures” so broad they would apply to ransomware: some exclusions are reasonable. Exclusions that let a vendor walk away from most real-world incidents are not.
- No mention of testing anywhere in the agreement: if testing is not in the contract, it is not happening on a schedule. It may not be happening at all.
- Continuity language in the marketing section of the proposal but not in the legal terms of the agreement: the proposal is a sales document. The signed agreement is what you can hold them to.
- A single backup copy stored in a single location: redundancy is not optional. A real recovery plan has at least two copies, at least one of which is offsite or in a geographically separate cloud environment.
How to Use This Framework to Make Your Decision
Take the four commitments above into your next vendor conversation as a working checklist. Ask each vendor to show you, in their standard agreement, where RTO and RPO targets are documented. Ask how often they test restores and what reporting you receive. Ask them to walk through the scope list and confirm what is and is not covered. Ask them to describe the communication protocol they follow during an active recovery event.
The answers will tell you more than any slide deck or reference call. Firms with real operational depth will answer these questions specifically and without hesitation. Firms that have not built that depth will redirect, generalize, or offer to add language after the fact. “We can add that” is not the same as “here is how we already do this.”
You are not looking for perfection. Every honest vendor will acknowledge scenarios where recovery takes longer than planned or where a specific system falls outside their standard scope. What you are looking for is specificity, honesty about limitations, and clear evidence that the firm has actually run these processes — not just described them in a contract.
A strong continuity and recovery commitment is a statement of professional seriousness. A vendor who has done the work will not be threatened by your questions. They will be glad you asked. If you want to understand how continuity planning fits into a broader security posture, explore our cybersecurity services — or Book a Free Strategy Call to talk through where your current plan stands.
Want a Walkthrough of Your Own Setup?
Twenty minutes on the phone with our team gets you specific recommendations you can use immediately — whether you hire us or not. No pitch, no pressure, just an honest read on where your business stands.