Your BIA Is Lying to You
You did the work. You identified your critical business functions. You assigned RTOs and RPOs. You got sign-off from the business. You filed the document somewhere a auditor can find it.
And then you migrated half your operations to SaaS platforms and never touched it again.
This is not a criticism. It is an epidemic.
The Business Impact Analysis was designed for a world where organizations controlled their own infrastructure. You owned the servers. You managed the applications. When something broke, your recovery was limited only by your own capability and preparation.
That world is gone. And most BIAs haven't gotten the memo.
What Your BIA Probably Still Assumes
Walk through your critical business function inventory and ask yourself whether each one reflects reality:
Procure to pay. Is this running on an ERP your team manages, or a SaaS platform with a 99.9% uptime SLA and a support queue you share with ten thousand other customers?
Inventory management. On-premise system with a documented recovery procedure, or a cloud-based platform where "recovery" means waiting for their engineering team to post an update?
HR and payroll. Your infrastructure or Workday's?
Customer service. Your CRM or Salesforce's?
The honest answer for most organizations is that the processes they've identified as critical are almost entirely dependent on platforms they don't control. Which means the recovery strategies documented in the BIA are, at best, incomplete, at worst, fiction.
The Three Questions Your BIA Needs to Answer Right Now
1. For each critical business function, who actually owns the recovery?
Not who owns the process. Who owns the recovery. If your procure-to-pay function runs on a SaaS ERP, your vendor owns the infrastructure recovery. You own the workaround. Do you have one? Has anyone tested it? Does anyone even know what it looks like?
2. What does your SLA actually guarantee, and what does it not?
Uptime SLAs are not recovery guarantees. A 99.9% uptime commitment means roughly 8.7 hours of allowable downtime per year before your billing credits start piling up. That number does not care about your RTO. Read the SLA. Find the carve-outs. Understand what your vendor is actually promising versus what you've been assuming.
3. What's your manual fallback?
"We don't have one!" When your SaaS platform is down and the status page says "investigating," what does your team actually do? If the answer is "sit and wait," that's your real RTO. Put it in the BIA.
What a Modern BIA Actually Looks Like
A BIA that reflects the current operating environment maps every critical business function to its dependency chain, not just the process owner, but the platform, the vendor, the SLA, the contractual remedies available, and the manual fallback procedure if the platform is unavailable.
It also gets reviewed when something changes. Not annually. When something changes. New SaaS contract? Update the BIA. Migration to a new platform? Update the BIA. Vendor acquisition that changes your support tier? Update the BIA.
The BIA is not a compliance artifact. It's an operational document, a playbook of what really matters in the organization. Treat it like one.
The Uncomfortable Truth
Most vendor contracts transfer risk to you the moment you sign them. The SLA compensates you for downtime with service credits. Service credits don't make payroll. They don't fulfill customer orders. They don't explain to your board why operations were down for eighteen hours.
Your providers' planning, or lack of it, is now your problem. The BIA is where you start accounting for that.
Update it before you need it.