Business Continuity Posture: 4 Documents to Request Before a Crisis Hits
Your IT firm’s business continuity posture will never appear on their website – but it will define your recovery when something goes wrong. Every vendor claims to have a plan. Most have a document. Very few have a tested, living program that will hold up at 11 PM on a Wednesday when ransomware locks your files. This guide shows you how to find out which kind you have – before you need to know. You will learn the four specific documents to request, what good looks like in each one, and what vague or missing answers are really telling you.
- Why the Plan on Paper Is Never the Whole Story
- Document 1: The Recovery Time Objective Statement
- Document 2: The Tested Restore Log
- Document 3: The Communication Protocol
- Document 4: The Business Impact Analysis
- What Vague Answers Actually Mean
- How to Use This to Make a Better Decision
Why Your IT Vendor’s Business Continuity Posture Is Never the Whole Story
Business continuity is one of the most over-marketed and under-delivered promises in IT services. A vendor who has never managed a real incident at scale can still produce a polished continuity document – one that checks every box on your due diligence list and still falls apart completely when it counts.
The right question is not whether your IT firm has a continuity plan. It is whether that plan has been stress-tested, whether it contains specific and provable commitments, and whether the people responsible for executing it during a crisis actually know their roles.
The four documents below are built to surface that difference. Each one reveals a different dimension of operational readiness. Together, they give you a picture no sales presentation will ever provide.
For background on what a complete continuity framework should include, the CISA Business Continuity Planning Suite is a useful reference when you are building your evaluation criteria.
Document 1: The Recovery Time Objective Statement
A recovery time objective – RTO – is a specific commitment: if your systems go down, how long will it take to restore operations? A real RTO is not a range. It is not “as quickly as possible.” It is a number, expressed in hours, tied to a specific scenario and a specific set of systems.
When you request this document, look for three things:
- A defined RTO for each critical system category – email, file storage, line-of-business applications, network access
- The conditions under which that RTO applies and what changes it – a localized hardware failure is a different scenario from a full ransomware event
- The recovery method – failover to a secondary environment, cloud-based restore, bare-metal recovery, or a combination
What good looks like: a document that lists systems, assigns each one an RTO, and explains the recovery path. The vendor should be able to walk you through it verbally without hesitating.
What a vague answer looks like: “We prioritize getting you back up as fast as possible.” That is not a commitment. It is a marketing sentence. If your vendor cannot give you a number, they have not designed a recovery process – they have described an aspiration.
A related metric worth asking about is the recovery point objective – how much data you could lose expressed in time. “Up to four hours of data” is a very different exposure than “up to 24 hours.” Both numbers together define the outer boundary of what you are actually agreeing to when you sign a contract.
Document 2: The Tested Restore Log
This is the document most vendors will not volunteer. It is also the single most revealing piece of evidence you can request when assessing a vendor’s business continuity posture.
A tested restore log is a record of actual backup restoration tests – date performed, which systems were tested, who ran the test, how long the restore took, and whether it succeeded or failed. A mature continuity program runs these tests on a scheduled cadence and keeps records of every result, including the failures.
Why does this matter more than the continuity plan itself? Because backups fail silently. A backup job can appear to run successfully every night while the backup file is corrupted, incomplete, or incompatible with the restore environment. You will not find out until someone tries to recover from it.
When you request this document, look for:
- Tests conducted at least quarterly – ideally monthly for critical systems
- Documentation of what was tested and what the outcome was – not just “backup verified” but “restored to test environment and confirmed functional”
- Evidence that failed tests were treated as learning events, with corrective action noted
- Consistency across multiple clients, not a one-off test staged for your audit request
What good looks like: a log with dates, systems, testers, outcomes, and notes. It will not look perfect – some tests will have had issues. That is a positive sign. It means the program is real and problems are being caught before they cost you anything.
What a vague answer looks like: “We test our backups regularly.” No log. No dates. No specifics. That means the testing is either not happening or not being documented. Either way, the claim is unverifiable – and unverifiable claims are not a foundation you want to build recovery on.
Document 3: The Communication Protocol
When something goes wrong, who calls whom, in what order, and through what channel? This sounds simple. It is rarely documented with the precision it requires.
A communication protocol defines the chain of notification, the expected timing of updates, the escalation path when the primary contact is unavailable, and the method of communication when your primary systems – including email – may be down.
That last point is where most vendors have a gap. If your email server is what went down, your vendor cannot reach you by email. If the outage happens at 2 AM on a Saturday, does the protocol change? If your primary contact at the IT firm is unreachable, who steps in?
When you request this document, look for:
- A named escalation chain with roles, not just names – so it survives personnel changes
- Defined update intervals during an active incident – for example, “status update every 30 minutes until resolution”
- An out-of-band communication method – typically a cell number or a secondary platform that does not depend on your primary infrastructure
- Clarity on who owns communication to your leadership, your board, or your clients if the incident has external implications
What good looks like: a one-to-two page document that reads like a runbook – specific, role-based, and not dependent on any single person being available.
What a vague answer looks like: “You can always reach us.” That is a reassurance, not a protocol. During an actual incident, reassurances without structure produce chaos. A vendor who cannot produce this document has not thought through the moments when their clients are most stressed and most dependent on them.
Document 4: The Business Impact Analysis
A business impact analysis is the foundational document that all the others depend on. It identifies which of your systems and processes are most critical, what the financial and operational cost of downtime is for each one, and how long each can realistically be offline before the impact becomes severe.
A vendor managing your IT without a business impact analysis for your organization is guessing at what matters most. They may be protecting the wrong things first, or assigning recovery timelines that do not match what your business actually needs to survive.
When you request this document, you are looking for something specific to your organization – not a generic template. A real business impact analysis will reference your specific applications, your revenue-generating processes, your regulatory obligations, and your operational dependencies.
- It should be updated at least annually, or when your business changes significantly
- It should rank systems by criticality, with a defined maximum tolerable downtime for each
- It should be the document that drives the recovery timelines in Document 1 – if those two are inconsistent, that is a problem
- It should reflect input from your leadership, not just the IT team’s assumptions
What good looks like: a document built with you, referencing your specific business context, reviewed within the last 12 months.
What a vague answer looks like: a generic PDF with placeholder language, or a vendor who says they “factor your business needs into our standard process” without producing anything specific to your organization.
What Vague Answers Actually Mean
When an IT vendor cannot produce one of these four documents – or produces a version that is generic, untested, or out of date – there are only two explanations. Either the program does not exist in any meaningful way, or it exists but no one has treated it as a priority.
Both should concern you. A continuity program that is not maintained is not a program. It is a document that was written once to satisfy a procurement requirement and has not been touched since.
The vendors who push back hardest on these requests are often the ones who have the least to show. Confidence in a strong business continuity posture looks like a vendor who sends you the documents before you finish asking, walks you through the test log, and asks whether your own recovery requirements have changed recently.
Defensiveness, vague reassurances, or documents that clearly came from a template – that is information. It is showing you what the experience of a real incident would look like. And that is not the experience you want.
At Xact IT, our managed IT services are built around documentation-first continuity planning, because you should never be surprised by what your IT environment can and cannot do under stress. You can also explore our cybersecurity services to see how we layer resilience across every part of your infrastructure.
How to Use This to Make a Better Decision
You do not need to be an IT expert to evaluate these documents. You need to ask for them, read them carefully, and notice whether they answer specific questions or restate general commitments.
Start the conversation before a contract is signed. A vendor who is serious about their business continuity posture will welcome the request. A vendor who stalls or deflects is showing you something important about how they operate under pressure.
Ask the vendor to walk you through a specific scenario: “If ransomware encrypted our file server at midnight tonight, what happens in the first two hours – exactly?” The answer to that question, held against the four documents above, will tell you more than any sales deck ever could.
You are not looking for a vendor who claims nothing ever goes wrong. Problems happen in this industry. You are looking for a vendor whose program is built to contain the damage, restore operations on a timeline your business can survive, and communicate clearly while recovery is underway. That kind of vendor does not need to tell you their continuity posture is strong. The documents will say it for them.
Ready to see how your current environment holds up? Book a Free Business Continuity Strategy Call and we will walk through exactly where you stand.
Let’s Talk About Your IT Strategy
If anything in this post raised a question about your own environment, the fastest path to an answer is a 20-minute strategy call. We’ll look at your specific situation and tell you what we’d actually do about it.