IT Emergency Manual: Template for Alerting, Immediate Measures and Recovery

In the IT-Grundschutz module DER.4, the BSI describes an emergency manual with information on roles, immediate measures, alerting and escalation, as well as communication, business continuity, recovery and restoration plans. It should record responsibilities and authorities, be accessible even in an emergency and be checked regularly through tests and exercises (DER.4.A1). According to BSI Standard 200-4, the reactive BCMS is suitable as a starting point: first build the response organization and secure selected time-critical processes. Where legal requirements such as the NISG 2026 exist, the BSI recommends starting with the build-up or standard BCMS (ch. 2.6.1).

For essential and important entities, this is mandatory: § 32 para. 4 lit. c NISG 2026 requires business continuity, such as backup management and disaster recovery, and crisis management; since October 2026, the Annex to Implementing Regulation (EU) 2024/2690, including point 4.1.2, applies to them where appropriate (§ 2 NISV 2026 (Austrian NIS Regulation 2026)). For all other companies, the BSI and NIST requirements are recommendations.

Sample text: “This emergency manual applies to [Company] at the sites [Sites] and covers the IT systems and services listed in [Inventory]. It is applied as soon as an event is classified as an emergency or crisis according to Section 04. Version [Number], approved on [MM/DD/YYYY] by [Name, role]; next review on [MM/DD/YYYY]; storage: [digital] and [on paper].” Management approves the structure and staffing of the team (BSI Standard 200-4, ch. 5.1.6).

Strategic decisions remain with management; decision-making and financial authority should be delegated to the team (ch. 5.1.1), for example: [shut down systems, engage service providers, expenses up to amount]. One person can take on several roles (ch. 5.1.4); for external members of the team, regulate confidentiality and authority (ch. 5.1.3).

1. 1

   Detect and report

   To the reporting point, e.g. IT hotline [Number]: time and place, reporting person, those affected, possible cause, immediate measures taken, impact, facts separated from assumptions (BSI Standard 200-4, ch. 5.2.1).

2. 2

   Initial assessment

   The reporting point uses simple yes-no questions (Section 04) to check whether an emergency is imminent. When in doubt: better to report too much than too little (ch. 5.2.1).

3. 3

   Decision

   A central, trained and authorized decision-making body, often the team lead, classifies the event and documents the rationale and those involved; the team confirms or downgrades (ch. 5.2.2).

4. 4

   Alert the team

   Briefly and precisely, with a meeting point such as a crisis room or conference call; it is defined who alerts whom through which channels, including outside business hours (ch. 5.2.3).

Do not alert by email only: with asynchronous channels, it is unclear whether and when the message arrives; calls to mobile phones or alerting apps are better (ch. 5.2.1). Notification procedures during and outside business hours should be documented (NIST SP 800-34, Section 4.2.2). Keep channels ready that work without your own IT (ch. 5.2).

In an event, this means two questions must be answered: Is a time-critical business process affected, and is there an applicable plan? Guiding questions for the IT reporting point based on a BSI example (ch. 5.2.1, Table 10), to be adapted to your processes and worded so that they can be used without in-depth expertise. Sample text: “As soon as any question is answered with yes, notify the team lead immediately: [Name], phone [Number].”

• Is the affected system part of the security infrastructure, such as antivirus or firewall?
• Does the outage affect many users or core business operations?
• Is there a strong suspicion of manipulation of data or systems, data exfiltration, unauthorized exercise of rights or a targeted attack?
• Is the impact likely to last longer than [8] hours?
• Are customers, the media or supervisory authorities affected?

Link to NIS2: For entities in sectors outside Implementing Regulation (EU) 2024/2690, a cybersecurity incident under § 5 para. 1 no. 9 NISV 2026 is always considered significant if it has activated crisis management or disaster recovery plans (explanatory notes on § 5). If such an entity declares an emergency because of a cyberattack, the report under § 34 NISG 2026 must be assessed immediately. For managed service providers, cloud and data center services and the other providers covered by the Implementing Regulation, Art. 3 et seq. of the Implementing Regulation apply instead; this criterion is absent there, but the threshold of €500,000 or 5% of annual turnover is the same (Art. 3(1)(a)).

Immediate measures cannot be postponed. According to BSI Standard 200-4, they must be documented in the emergency manual and include rules for protecting life and health, which take priority over property; checklists are recommended (ch. 5.3). For all employees, for posting, based on the BSI IT emergency card:

• Stay calm and report the IT emergency immediately: [IT emergency number].
• State who is reporting, which system is affected, how you were working with it, what you observed, when it happened and where the system is located.
• Stop further work on the affected system and document your observations.
• Take action only when instructed.

For IT owners and service providers, a selection from the TOP 12 measures for cyberattacks by the BSI and partners; it is intended as a prompt, and you define the order yourself:

• Initial assessment: cyberattack or technical defect?
• Disconnect affected systems from the network and the internet, prevent unauthorized access.
• Stop backups and protect them from further interference.
• Forensically secure system logs, log files, notes, screenshots and storage media.
• Determine the extent, identify all attacked systems, keep time-critical processes in focus.
• Coordinate and document measures and communicate them to everyone responsible; after coordination, notify the police and authorities.
• Review access to affected accounts, for example new passwords and two-factor authentication.

TOMORIS recommendation: record the time of becoming aware in the log immediately. By law, the deadlines under § 34 para. 2 NISG 2026 run from that point, and under Art. 33(1) GDPR from becoming aware of the personal data breach.

In NIST SP 800-34, the RTO is the maximum time a system resource can be unavailable before unacceptable consequences occur for other resources, the supported processes and the maximum tolerable downtime (MTD) (Section 3.2.1). Define from when you calculate the RTO.

The order follows the dependencies; the total recovery time including dependent resources must not exceed the RTO. In the build-up and standard BCMS, every time-critical resource has a recovery plan that is specific enough for a competent third party to execute: scope, purpose and activation; roles and deputies with current contact details; required resources with RTO and documentation; prerequisites such as permissions and service providers; the steps with role and typical duration; a functional test and the handover to emergency operations (ch. 12 and 12.2).

Before restoring: check backups for indicators of compromise and damage, check restored systems again before productive use and fix the root cause (NIST SP 800-61r3, RC.RP-03 and RC.RP-05). The backup checklist 3-2-1-1-0 at tomoris.com/downloads shows how backups come back in an emergency.

Define in advance what employees learn and when, what they may say to the press and on social media, what the communication role publishes, how contact with the police and authorities works and which reporting obligations exist (BSI Standard 200-4, ch. 5.7.1). Employees should receive information no later than the public does (ch. 5.7.2); for press inquiries, appoint a spokesperson and a deputy (ch. 5.7.3).

Reporting obligations run in parallel: essential and important entities report significant cybersecurity incidents to the competent CSIRT, with an early warning within 24 hours and a notification within 72 hours (§ 34 para. 2 NISG 2026). The controller reports personal data breaches to the supervisory authority without undue delay and, where feasible, within 72 hours, unless they are unlikely to result in a risk (Art. 33(1) GDPR); the EU has not yet adopted a proposal for 96 hours (COM(2025) 837) (as of October 25, 2026). Details: NIS2 reporting obligations guide at tomoris.com/downloads.

The team logs all significant activities and decisions with basis, participants, time and status, keeping facts separate from rumors (BSI Standard 200-4, ch. 5.4). NIS2 entities log the response and collect evidence (Annex point 3.5.4 Implementing Regulation (EU) 2024/2690); personal data breaches must always be documented (Art. 33(5) GDPR).

• End the emergency: officially, according to defined criteria, through the same channels used to declare it (ch. 5.8); then work through backlogs, enter missing data and switch back to primary systems (ch. 2.3).
• Evaluate: analyze every incident promptly and with some distance (ch. 5.9); a final report records the incident, measures and lessons learned (NIST SP 800-61r3, RC.RP-06).

Only exercises and tests show whether plans work (BSI Standard 200-4, ch. 12.3). In the reactive BCMS, the standard requires regular crisis team and alerting exercises and recommends plan reviews and functional tests (ch. 13.1); annual exercise planning should cover at least twelve months (ch. 13.3). Anyone with a role in the contingency plan should be trained at least annually (NIST SP 800-34, Section 3.5.2).

The manual is reviewed regularly (DER.4.A1), contact details more often than the rest, and outdated versions are replaced at all storage locations (BSI Standard 200-4, ch. 4.4.3; NIST SP 800-34, Section 3.6). Contact lists contain personal data and must be protected (NIST SP 800-34, template in Appendix A.1).

The frequencies are BSI examples, not legal requirements. NIS2 entities test and review the contingency plan at planned intervals and after significant incidents or significant changes, and incorporate the lessons learned (Annex point 4.1.4 Implementing Regulation (EU) 2024/2690, § 2 NISV 2026). TOMORIS recommendation: review contact lists quarterly and the entire manual at least once a year, and keep a current paper copy outside your own IT.