Skip to content
Cybersecurity

Creating an IT Emergency Plan: Step by Step

IT emergency plan: alert chain, roles, immediate actions for ransomware and outages, reporting duties and recovery order, built in eight steps.

Published on 4 min read

Five connected tiles in graded shades of blue on a white wall, an empty office chair in front.

An IT emergency plan is not a hundred-page binder but a document that quickly reaches the right people and sets out the first actions. The emergency is not only a cyber attack, but equally a power cut, a severed fibre line or a service provider that can no longer be reached.

Emergency plan and emergency manual

The two terms are often mixed up but have different purposes. The emergency plan is the operational document for the first hours: alert chain, roles, immediate actions per scenario and communication plan. It is short, exists on paper in several places and is written for people under pressure.

The emergency manual contains the technical recovery plans: restoring the domain controller from backup, the start order of the virtual machines, where licence keys and firewall configurations are kept. It is aimed at administrators and is updated with every change to the infrastructure.

BSI Standard 200-4 on business continuity management describes the complete structure of emergency management but is usually too extensive for smaller companies. For a business with a few dozen employees, ten to fifteen pages are usually enough.

What belongs in the emergency plan

ComponentContent
Alert chainWho notifies whom, in which order, via which channel; private mobile numbers on paper
Roles and deputiesEmergency lead, IT coordination, communication, business units; every role with a deputy
CriticalityWhich processes and systems must run again first
Communication planInternal and external information, reporting duties, pre-written texts
Recovery orderWhich systems start in which sequence; reference to the emergency manual
External contactsService providers, insurer, lawyer, authorities, with contract numbers and hotlines

The alert chain must work without IT. If the mail server, Teams and the phone system are encrypted or without power, the contact list on the intranet is useless. The plan belongs printed in the safe, in the managing director’s office and at the homes of everyone holding a role.

Immediate actions and reporting duties

  • Ransomware: Disconnect affected systems from the network but do not switch them off, so evidence is preserved. Protect backups from access, change administrator passwords, no ransom negotiations without legal advice, alert the incident response provider.
  • Power or internet: Check the runtime of the uninterruptible power supply and shut down servers in an orderly way. Activate the mobile fallback and contact the utility or provider using the fault number from the plan.
  • Service provider or software vendor: Check which processes are affected and whether manual fallbacks exist; reach the vendor via the recorded escalation routes.

The communication plan defines who informs which group and when. Employees need an early instruction, such as not switching on computers and not giving information to outsiders.

Two statutory deadlines belong in every plan. For a personal data breach, the GDPR requires notification of the supervisory authority within 72 hours. Companies within the scope of Germany’s NIS2 implementation act, in force since 6 December 2025, report significant incidents to the BSI within 24 hours as an early warning and within 72 hours in full. Both deadlines run from awareness, so responsibility for reporting must be settled in advance.

Building the plan in eight steps

  1. Assign responsibility: Management names a person who creates and maintains the plan.
  2. Record processes and systems: List business processes, assign systems, note the tolerable downtime.
  3. Select scenarios: Ransomware, power cut, internet outage, failure of a service provider, loss of a key employee.
  4. Define roles and alert chain: Who leads, coordinates, communicates, deputises. Put contact details on paper.
  5. Formulate immediate actions: Short, as instructions, with clear stop rules such as “do not switch off” or “do not pay”.
  6. Add communication plan and reporting duties: Audiences, text modules, deadlines, responsibility.
  7. Agree the recovery order: Derive the start sequence from criticality and link it to the emergency manual.
  8. Distribute, exercise, maintain: Hand the plan to all role holders, schedule an exercise, set a review interval.

An exercise should take place at least once a year. A tabletop walkthrough is enough to begin with: a scenario is read out, and each role describes what it does now. Outdated phone numbers and missing deputies reliably come to light. In a second step, a server is actually restored from backup.

Key points

  • The emergency plan is short, exists on paper and governs alerting, roles and immediate actions; the technical detail sits in the emergency manual.
  • The GDPR and NIS2 reporting deadlines run from awareness, so responsibility must be settled beforehand.
  • A plan that is never exercised has unknown gaps.

DEVACON supports the recording of processes, dependencies and scenarios as part of IT consulting and strategy.

Topics IT emergency plan Business continuity Ransomware NIS2 BSI Standard 200-4

This article comes from the DEVACON blog and was editorially revised for the new website.