IT down? An emergency plan for when it happens

An IT emergency plan decides in advance who gets to call the shots on which systems come back online first, and how everyone involved reaches each other when the very communication channels you normally rely on are the ones that are down. Without a plan like this, every IT outage becomes an organisational problem on top of a technical one: who calls whom, who's allowed to decide that a system gets shut down, and how does an external provider even know how the network is built – questions that cost valuable time in an emergency if they're only being asked for the first time once it's already happening.

Who decides when the IT is down

The first and often most underestimated point in an emergency plan is clear ownership: who decides to take a system offline, who informs management, and who's authorised to bring in an external IT provider to respond? Without that clarity, the first hour of an incident often turns into a standstill – not because nobody wants to act, but because nobody is sure they're allowed to. An emergency plan settles these responsibilities in advance, including a backup person for when whoever's normally responsible can't be reached.

Which systems need to come back first

Not every system is equally critical, but in the rush of an outage the loudest problem often gets tackled before the most important one. A priority order set in advance prevents that: it defines which systems stop the business cold if they go down, and which can wait a while without seriously threatening operations.

• Name the critical systems that would stop the business immediately if they went down (e.g. inventory management, production control, phone systems)
• For every critical system, record who runs it, where the credentials are kept, and who gets contacted in an emergency
• Document dependencies – for example a server that has to be up before another system can even start
• Fix the order of recovery steps in advance rather than improvising it during the actual emergency

Contact chains: why "we'll call someone" isn't enough

In an emergency, the communication channels you normally rely on often go down along with everything else: the internal email system, the IP phone system, the shared chat tool. A contact chain defines in advance who reaches whom, and by which alternative route, when the usual one doesn't work – and not just for your own IT, but for external providers, insurance, and, where relevant, customers who need to be told about a disruption.

• Maintain a contact list with alternative reachability (a personal mobile number, not just a work extension) and keep it up to date
• Keep the contact chain available in physical form (printed or offline), not only digitally on a system that might itself be down
• Anchor your external IT provider and their after-hours contact details firmly in the plan
• Clearly define who informs customers or partners in an emergency, so that doesn't happen multiple times in an uncoordinated way

Testing the plan before you need it

An emergency plan that only exists on paper tends to reveal its gaps exactly when there's no time left to fix them. A regular drill – even just a one-hour tabletop simulation where everyone involved walks through the process together – surfaces exactly the spots that sound plausible in theory but don't hold up in practice: an outdated phone number, an access nobody has any more, a step waiting on another step that was never actually documented.

• Run a simulation at least once a year, even if it only covers a single scenario
• Deliberately include a failure of the usual communication channels in the drill
• Actually feed what you learn from the drill back into the plan, rather than just noting it down
• Actively bring new staff with emergency responsibilities into the plan and the next drill

Documentation as the foundation for any emergency plan

An emergency plan is only as good as the documentation it rests on. If nobody besides one single person knows how the network is built, where each configuration lives, and which password belongs to which system, even the best plan is of little use the moment that exact person can't be reached in an emergency. Complete, up-to-date infrastructure documentation therefore isn't a separate task alongside the emergency plan – it's what the plan is built on.

• Keep the network diagram and system overview up to date, not just created once at the original build
• Store credentials securely, but reachable for authorised backup people in an emergency
• Keep contracts and contacts for critical providers (internet, hosting, software) in one central, well-known place
• Update the documentation after every major infrastructure change, not only after the next incident

The emergency plan as a living document

An emergency plan that gets written once and then forgotten in a drawer loses its value the moment the infrastructure changes – a new server, a new provider, a rebuilt part of the network, and parts of the plan are already out of date. A fixed rhythm for reviewing the plan and checking it against the current infrastructure makes sense, ideally paired with at least a rough drill of how a recovery would actually play out. Tying the review to a fixed date each year, for instance alongside planned maintenance that's happening anyway, makes sure the update doesn't get left to chance. That way, the plan stays what it's meant to be in an emergency: a guide you can follow, not a document you first have to understand and bring up to date.