Business Continuity Planning

Atlassian's April 2022 incident is the canonical case study for business continuity failure. A maintenance script deleted production data for around 400 customer sites. The company had backups. They had replicas. They had a disaster recovery plan. What they did not have was a pre-built framework for deciding which customers to restore first when everything was broken simultaneously.

The recovery team had to invent restoration priorities during the active outage. Enterprise customers with contractual SLAs? High-revenue accounts? Customers in regulated industries who faced their own compliance deadlines? The answers to these questions should have existed before the incident, not during it.

Business continuity planning is the discipline that produces those answers in advance. DR focuses on restoring technology. BCP focuses on keeping the business running, which includes technology but extends to organizational decision-making, communication, vendor management, and regulatory compliance. A complete BCP answers a question that DR alone cannot: when the building is on fire, what do we save first and in what order?

The distinction matters because pure DR thinking optimizes for system recovery. BCP thinking optimizes for business survival. The two sometimes produce different answers. Restoring the most complex technical system first may not be the right choice if a simpler system carries higher revenue or regulatory exposure.

Every continuity program starts with the same question: which systems can we lose for an hour without anybody noticing, and which ones cost a million dollars a minute? The answer is not obvious and it changes every quarter as the business evolves.

A Business Impact Analysis is the structured exercise that produces this answer. The output is a ranked list of business processes with measurable downtime costs attached to each. Atlassian's April 2022 outage postmortem is a public case study in what happens without one: a maintenance script deleted production data for around 400 customers and the recovery took 14 days because nobody had pre-ranked which customer tiers should be restored first. The team rebuilt restoration order on the fly while the outage was active.

The analysis walks every revenue-producing process and asks four questions. What does it cost per hour of downtime in lost revenue, contractual penalties, and customer trust? Which upstream services and data stores must be available for it to run? What is the maximum tolerable downtime before the business is materially harmed? What is the maximum tolerable data loss before regulatory or contractual obligations are violated?

What This Means in Production

The output is usually a spreadsheet, not a fancy tool. What matters is that every row has a dollar figure attached to one hour of downtime. Stripe publicly references tier definitions like this in their resilience writing: tier zero is checkout and webhooks, tier one is dashboard, tier two is reporting. Each tier has its own RTO budget and its own paging policy.

Costs must be measured, not guessed. Revenue per minute is straightforward for transactional businesses. Contractual penalties live in SLA documents and require legal review. Trust costs are estimated from churn data after past incidents. Skipping the measurement step produces a BIA that nobody trusts and nobody uses.

The BIA gets refreshed every six to twelve months. New products, new contracts, and new data residency requirements all change the math. Teams that treat it as a one-time exercise watch their tier rankings drift out of date until the next outage proves the rankings wrong.