Business Continuity

While a company is small, an incident gets handled when it happens. The server goes down, whoever knows the system fixes it, and that's the end of the day. What decides the outcome isn't the size of the incident but the hour it starts. The same failure at 3pm on a Tuesday and at 4am on a Saturday takes several times longer to recover from in one case than the other.

So the same night keeps repeating. Someone notices data is gone and posts in the group chat, nobody can say for certain how old the backup is, and thirty minutes disappear into phone calls trying to reach the person who would know. The next day's write-up usually lands on the same sentence: there were backups, but nobody had ever checked how much of the system they could actually bring back.

Business continuity moves those decisions to before the incident. What can't be allowed to stop, how many hours it gets to come back, and what has to be maintained day to day to hit that number — all written down ahead of time. The assumption behind it is that what's needed at 4am isn't a clever decision but a sequence that already exists. Once a company has enterprise customers, the document stops being optional, because the security questionnaire that arrives before the contract has a field for the recovery time.

The preparation runs in four steps.

1. Pick what can't be allowed to stop. At Pagedeck, reading and editing documents makes that list; the usage statistics screen can be down for a day without the business stopping. Trying to protect everything protects nothing.
2. Set two numbers for each thing you picked. How many hours until it's restored is the recovery time objective (RTO). How many minutes of data you can afford to lose is the recovery point objective (RPO). Document editing might get four hours and fifteen minutes; the statistics screen might get 48 hours and a full day.
3. Put in place whatever those numbers demand. Once the two numbers exist, the means follow. Fifteen minutes of tolerable loss means backups every fifteen minutes. A four-hour recovery means somebody has to time how long restoring a backup file actually takes, and it means an on-call rotation so the person who can do it is reachable at 4am. On-call is the duty of taking failure calls during an assigned window.
4. Actually turn things off and fix what breaks. Once a quarter, fail over to the standby environment and time it. If the document says four hours and the measurement says eleven, one of the two — the preparation or the number on paper — is wrong. A plan nobody has run is closer to a hope.

What all four steps are aiming at is usually a single point of failure (SPOF): a place where one thing stopping stops everything. One server, one payment provider, one person holding deploy permissions — all the same shape. Building continuity mostly means finding those places and making them two: a second server in another region, a second payment integration, a second person with the same access. Every one of those doubles a cost, which is why step 1 exists — the list of what can't stop is also the list of what's worth paying twice for.

The term travels through three rooms.

1. Enterprise contracts — it comes up while filling in security questionnaires and writing the SLA, the service level a vendor commits to contractually, often as a monthly uptime figure like 99.9 percent. That figure allows 43 minutes of downtime a month, which a four-hour recovery process cannot honor. Contract review is where the gap between what sales promised and what exists gets discovered.
2. Investor diligence — investors walking through company risk ask what happens if a key person leaves and how many days a critical system takes to come back.
3. Internal operations — it's the document people open during an incident, meaning an event that affected the service. After the incident, the postmortem writes up causes and fixes, and those fixes come back into this document.

Running on the cloud doesn't solve it by itself. A provider gives you the option of spreading across regions; whether you actually spread, and how much extra you pay to do it, is still the company's call.

"This security questionnaire has a field for recovery time. What's our number?"

A customer is asking for something before signing, and the company has never set the value.

"We take backups every day, but we've never restored one."

The materials exist; the recovery time has never been verified.

"This is a continuity problem. That one person has the only access."

Naming concentrated permissions as a single point of failure.

Pagedeck first wrote this document because of an enterprise contract. Sofia brought back a security questionnaire with the recovery time and data loss fields blank, and when she asked Theo, the answer was that backups ran nightly but nobody had timed a restore. They timed one that week: nine hours.

Grace made two decisions from that number. Only document editing would target a four-hour recovery, with everything else allowed a full day, and the backup interval would move from daily to every fifteen minutes. Hitting four hours across the board would have meant running a second full standby environment, which the budget didn't support. Deciding what not to protect is what made the document usable.

The most common mistake is treating backups as continuity. If the data still exists, recovery feels like a matter of time. But the question continuity answers isn't whether data exists, it's when service returns. Backing up daily while a restore takes a full day is a declaration that a full day of downtime is acceptable, and most companies don't know they made that declaration until they test it. Backups nobody has restored can sit corrupted for months.

The second is handing the whole thing to engineering. Recovery and backups sound technical, so it's a natural assumption. But what gets restored first, how much money the preparation is worth, and what customers are told during the outage are not technical calls. When engineers decide by default, the order that comes out is the one that's cleanest technically, and nothing guarantees that matches the order that hurts the business most. Plenty of these documents also leave blank who handles customer communication while the service is down.