For a cybersecurity governance course, my team and I were asked to write a formal Disaster Recovery and Business Continuity Plan for a fictional internet service provider, as if presenting it to the company's own leadership for approval. The scenario behind it: the ISP had just been through a week-long outage that knocked out internet service for customers, losing 20% of its customer base and an estimated $2.3 million AUD, and needed a real plan so it never happened again.
There were ten possible disaster types on the table, everything from regulatory breaches to insider threats, but we scoped the plan specifically to network outages and disruptions, since that's what had actually hurt the company. Real incidents we could point to made the risk concrete: BGP misconfigurations taking down national networks, ISPs breached through zero-day vulnerabilities, whole regions losing service after a single core router failed.
We started by mapping the system itself: who's responsible for what during an incident, from the CISO down to the network engineers actually restoring equipment, and the technical architecture underneath it, redundant data centres (active, standby, backup, and a separate disaster-recovery site), SD-WAN and SDN controllers that can reroute traffic automatically, and firewalls and DMZs separating the public-facing network from internal systems.
From there we catalogued the assets worth protecting, matched them against realistic threats, natural disasters, DDoS-for-hire, power failures, insider misuse, fibre cuts, misconfiguration, and scored each one by likelihood and impact to work out what actually deserved investment first. For the top risks we worked out specific mitigations and priced them: solar and wind backup power for outages, an automated method for verifying router configurations so a routine upgrade doesn't accidentally take down the network, and a hybrid fallback (satellite, balloon-based Wi-Fi, portable base stations) to keep some service running if the main fibre link goes down entirely.
The recovery plans themselves are written as minute-by-minute timelines for three realistic scenarios: a natural disaster, a power outage, and a DDoS attack. Each one names exactly who acts, when, and what they hand off to the next person, from the first alert through to service being restored and the incident logged.
Separate from that, the business continuity side covers the ongoing work that keeps the whole plan from going stale: automated weekly configuration backups, an annual risk and business-impact review, quarterly redundancy testing, and monthly checks on firewall rules and DNS encryption, each with its own owner and schedule rather than being left to whoever remembers.
The point of the exercise was to produce something a company could actually act on, not just describe good practice in general terms. So the final recommendations were split into what needs approving immediately and what's a longer-term investment, each one costed and assigned to a specific role, the way it would need to be if a CEO actually had to sign off on it.