IT down? An emergency plan for when it happens

An IT emergency plan settles in advance who makes the decisions during an outage, which systems come back in which order, and how everyone involved reaches each other when email and the phone system are down too. Without such a plan, every IT outage also becomes an organisational problem: nobody is sure who may shut a system down, and the external provider first has to piece the network together. Every emergency plan rests on up-to-date infrastructure documentation.

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. The list of critical systems is also a good basis for prioritising IT investments: whatever sits at the top in an emergency usually deserves budget and attention first.

• 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.

How NDVDL builds the emergency plan with you and keeps it current

An emergency plan isn't written at the provider's desk but in conversation with the people who will make the decisions when it counts. NDVDL comes to your premises, records the network, servers, access and dependencies, and works out with you which processes need to function first after an outage. From that you get a written proposal with roles, priorities, recovery order and contact chain – short enough to actually be read in an emergency.

During ongoing operations we keep the documentation and the plan up to date whenever something changes in the infrastructure, and we go through the plan with you at fixed intervals. You have one fixed point of contact who knows your setup and doesn't have to start by figuring out how your network is built when something goes wrong.