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.
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
| Component | Content |
|---|---|
| Alert chain | Who notifies whom, in which order, via which channel; private mobile numbers on paper |
| Roles and deputies | Emergency lead, IT coordination, communication, business units; every role with a deputy |
| Criticality | Which processes and systems must run again first |
| Communication plan | Internal and external information, reporting duties, pre-written texts |
| Recovery order | Which systems start in which sequence; reference to the emergency manual |
| External contacts | Service 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
- Assign responsibility: Management names a person who creates and maintains the plan.
- Record processes and systems: List business processes, assign systems, note the tolerable downtime.
- Select scenarios: Ransomware, power cut, internet outage, failure of a service provider, loss of a key employee.
- Define roles and alert chain: Who leads, coordinates, communicates, deputises. Put contact details on paper.
- Formulate immediate actions: Short, as instructions, with clear stop rules such as “do not switch off” or “do not pay”.
- Add communication plan and reporting duties: Audiences, text modules, deadlines, responsibility.
- Agree the recovery order: Derive the start sequence from criticality and link it to the emergency manual.
- 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.
This article comes from the DEVACON blog and was editorially revised for the new website.