The Outage You Can't Fix
Most business continuity plans are written for outages you can control. The scariest one is the one you can only watch happen.
Open a typical business continuity plan and you will find a very detailed answer for what happens when your database crashes or your office loses power. Runbooks. Contact lists nobody has checked since the plan was written. All of it assumes the failure happens inside your own walls, where you still get to decide what happens next.
None of that helps on the day your payment processor or the one SaaS tool your entire workflow depends on quietly stops responding and keeps not responding for six hours. The failure lives in someone else's infrastructure, and you were never invited to their incident call.
You can page your on-call team at 2am. You can open a war room and order emergency pizza. None of it helps, because the broken thing was never yours to fix. For as long as the incident lasts, you are a customer. A worried, powerless customer standing in a line you did not know you had joined.
Your RTO is a number you invented
Ask most engineering teams for their recovery time objective on an internal system and they will give you a figure down to the minute, backed by a test they ran last quarter. Ask the same team for their critical vendor's RTO during a full platform outage and watch the room go quiet. Someone will eventually mention “99.99% uptime,” recited like a magic spell that wards off further questions. An uptime percentage tells you almost nothing about the outage itself. Is that missing 0.01 percent a five-minute blip once a year, or one nine-hour blackout that lands on your biggest sales day of the quarter? Nobody knows, because nobody asked, and the marketing page was never going to volunteer the answer.
If you cannot state your vendor's real recovery target, you do not have an RTO for that dependency. You have a guess wearing a spreadsheet, presented at the quarterly risk review as though it settles something.
The queue you did not know you joined
During a small hiccup, a competent vendor answers your ticket within a few hours and everyone moves on. During a major outage, your ticket lands behind ten thousand others from customers exactly as panicked as you are, and the support queue turns into a lottery that pays out slowly, if at all. The status page says investigating. It keeps saying that for a long time. Your account manager, normally quick to reply, goes silent, because they are reading the same internal update thread as everyone else and have nothing new to add.
Companies usually discover, right about here, that their contract has a service level agreement with a refund clause and no communication commitment worth the name. A partial credit on next month's invoice does not un-cancel the orders you lost, or un-lock the accounts your own customers could not reach.
Nobody asks the awkward question before signing
How many procurement processes ask a vendor for its own continuity plan before a contract gets signed? Skip the security questionnaire gathering dust in a shared drive and the SOC 2 badge on the website. Ask one direct question instead: what happens to us if you disappear for a day, and how fast do you come back? Almost nobody asks it. Buyers interrogate pricing tiers and data residency for weeks, then treat a vendor's own disaster recovery plan like an impolite question nobody wants to be the one to raise.
Most businesses cannot fund a fully redundant backup for every dependency, fair enough. But very few have built anything better than refreshing the status page and hoping, and hope is a coping mechanism dressed up as a plan.
Start small. Get the vendor's real recovery target in writing instead of the number from the pitch deck. Ask what their own failover actually looks like, and whether it has been tested under real load rather than assumed. Build one manual workaround for the single tool your business would genuinely struggle without, even if it is embarrassingly analog. A spreadsheet and a phone tree beat nothing. You will not cover every dependency this way, and that is fine. Coverage was never realistic. Effort is the point.
Outsourcing a function also means outsourcing its outages. You do not get a vote on when they happen, how long they last, or which number ticket you are in the queue. The least you can do is ask, before you sign anything, whether the vendor holding your business hostage for a day has any plan at all to let it go.