IT Emergency Handbook: Structure, Content, and PDF Template

Why an IT emergency handbook is indispensable

Monday morning, 7:45 AM. The IT manager is on vacation, his deputy is sick. The helpdesk employee discovers that all servers are unreachable. Alarms are flashing on the firewall console, and the first employees are reporting they cannot work. What now?

If there is an emergency handbook for this situation, the helpdesk employee knows whom to call, what immediate measures to take, and which escalation level applies. If there is no emergency handbook, chaos begins: Frantic phone calls, information gaps, lost time.

The IT emergency handbook is not a theoretical document for filing away. It is an operational tool that must function in a crisis situation. It answers the questions that nobody can answer under stress: Who is responsible? What is the external service provider's number? From when must executive management be informed? Does the incident need to be reported to an authority?

For mid-market companies that fall under NIS2, there is a regulatory dimension: The reporting obligation for significant security incidents starts from the moment of becoming aware. 24 hours for the initial report to the BSI. Anyone who is still searching for the phone number during this time and wondering who is supposed to file the report has already lost.

Delineation: Emergency handbook vs. emergency plan vs. recovery plan

These terms are frequently used interchangeably but describe different documents with different focuses.

The emergency handbook is the overarching document. It is the central information source that bundles all relevant content or references it. Think of it as a reference work that is opened in an emergency.

An emergency plan describes the response to a specific scenario: What to do in case of ransomware? What to do in case of a server room fire? What to do in case of a data leak? Emergency plans are part of the emergency handbook.

The recovery plan describes the systematic restoration of normal operations after an incident. It is activated after the initial response (emergency plan) is complete. It is also part of the emergency handbook or is referenced from there.

The emergency handbook thus contains the emergency plans and the recovery plan - or provides structured references to them. It is the bracket that holds everything together.

Structure of the IT emergency handbook

A good emergency handbook follows a clear structure that can be quickly navigated in an emergency. The following sections have proven effective in practice.

1. Cover page and document control

The cover page contains the basic metadata:

• Document title: "IT Emergency Handbook [Company Name]"
• Version and date: e.g., "v3.1, as of: March 2026"
• Responsible publisher: Name and function
• Confidentiality level: Typically "Confidential" or "Internal"
• Distribution list: Who has a copy (printed and digital)?
• Next review date: When is the next review scheduled?

Directly on the second page belongs a change history that records every change with date, author, and description. This is not bureaucracy but vital: In an emergency, it must be clear whether you have the current version in hand. In ISMS Lite, versioning is automatically tracked, and changes to contact data or scenarios immediately flow into the emergency handbook.

2. Table of contents with quick access

The table of contents must be designed so that someone under stress can find the right section in seconds. Color-coded tabs or colored page margins help in the printed version. In the digital version, linked bookmarks are mandatory.

A proven quick access on the first content page:

EMERGENCY CONTACTS ........................ Page 5
ESCALATION LEVELS ........................ Page 8
REPORTING PATHS (BSI / GDPR) ............. Page 12
SCENARIO: Ransomware ..................... Page 15
SCENARIO: Server Failure ................. Page 22
SCENARIO: Data Loss ...................... Page 28
RECOVERY PLAN ............................ Page 35

3. Emergency contact list

The contact list is the most-used section of the handbook. It must be complete and current. An outdated phone number in an emergency is worse than none, because it costs time and creates false confidence.

Internal contacts:

External contacts:

Authorities:

4. Escalation chains

The escalation chain defines who is informed when and who may make which decisions. Without clear escalation, one of two things happens: Either executive management is pulled out of every meeting for every minor incident, or they learn about a critical incident only after 12 hours.

Three-level escalation model:

Level 1: Disruption (resolvable by IT internally)

• Trigger: Single system impaired, workaround possible, no impact on core processes
• Examples: Printer failure, single workstation defective, performance issue with non-critical application
• Who is informed: IT team internally
• Who decides: IT team lead / helpdesk lead
• Timeframe for resolution: Within normal SLA (e.g., 8 business hours)

Level 2: Significant disruption (escalation to IT management)

• Trigger: Multiple systems or users affected, core process impaired, no simple workaround
• Examples: Mail server down, VPN unreachable, ERP performance severely degraded
• Who is informed: IT manager, affected department heads
• Who decides: IT manager
• Timeframe for resolution: Within 4 hours, external service provider engaged if needed

Level 3: Emergency / Crisis (escalation to executive management)

• Trigger: Business-critical system completely down, security incident (ransomware, data leak), physical damage (fire, water)
• Examples: Ransomware encryption, total ERP failure > 2 hours, data leak with personal data, server room fire
• Who is informed: Executive management, IT manager, possibly DPO, ISB, external service providers, cyber insurance
• Who decides: Executive management (in coordination with IT management and crisis team as applicable)
• Timeframe: Immediate convening of crisis team, check reporting obligations

5. Reporting paths

Reporting paths describe how information flows from the person who discovers the incident to the right decision-making level. Especially in mid-market companies without a 24/7 SOC, this is critical.

Reporting path for an IT security incident:

Incident discoverer
    |
    v
IT Helpdesk / IT Hotline (initial intake)
    |
    |-- Level 1? -> IT team handles
    |
    v Level 2 or 3?
IT Manager (assessment within 30 min)
    |
    |-- Level 2? -> IT Manager coordinates resolution
    |
    v Level 3?
Executive Management + Crisis Team (immediate notification)
    |
    |-- BSI reporting obligation? -> Initial report within 24h
    |-- GDPR reporting obligation? -> Report within 72h
    |-- Criminal complaint? -> Police / State Criminal Police
    +-- Cyber insurance? -> Claim notification

Important: The reporting path must also function outside business hours. If the helpdesk is only staffed until 5 PM, you need alternative availability. This can be an on-call rotation, a forwarded hotline number, or at minimum, the IT manager's mobile number known to all employees.

6. Immediate measures checklist

A general checklist to work through for every IT security incident - regardless of the specific scenario:

[] Document the incident: What was observed when and by whom?
[] Identify affected systems: Which systems are affected or potentially at risk?
[] Containment: Isolate affected systems (disconnect from network, DO NOT shut down!)
[] Determine escalation level and escalate accordingly
[] Evidence preservation: Do not make changes to affected systems, take screenshots
[] Communication: Inform affected employees (what works, what does not, workarounds)
[] Check reporting obligations: BSI (24h), Data protection authority (72h)?
[] Contact external service provider (if needed)
[] Keep a log: Document all measures with timestamps
[] Regular situation updates to crisis team / executive management

The note "DO NOT shut down" for containment is deliberately highlighted. A common reflex with ransomware is to immediately shut down affected systems. But this can destroy forensic traces (RAM contents, running processes) that are important for later evidence preservation. Network disconnection is the better first measure.

7. Scenario-specific response plans

The core of the emergency handbook: For the most likely and most consequential scenarios, there is a dedicated response plan for each. Which scenarios you include depends on your company. The following four cover the most common cases in the mid-market.

Scenario 1: Ransomware attack

Description: Malware has encrypted data. Ransom demand has been received.

Immediate measures (first 60 minutes):

1. Disconnect affected systems from the network immediately (pull cables, disable Wi-Fi)
2. Check whether the encryption is still spreading (further systems affected?)
3. Do not communicate with the attackers and do not pay ransom (without coordination with executive management and possibly authorities)
4. Change all passwords for administrative accounts (from a clean system)
5. Check backup integrity: Are backups reachable and not also encrypted?
6. Trigger Level 3 escalation

Further measures (hours 1-24):

1. Contact forensics provider (if under contract)
2. Prepare BSI initial report (if NIS2-obligated)
3. Inform cyber insurance
4. Determine the extent of encryption: Which systems, which data?
5. Check whether personal data is affected (GDPR reporting obligation)
6. Decision on restore strategy: Restore from backup or decryption tool available?

Recovery: -> Reference to recovery plan, Section [X]

Scenario 2: Total data center failure

Description: All servers in the local data center are unreachable (hardware defect, power outage > UPS runtime, physical damage).

Immediate measures:

1. Clarify cause: Power? Cooling? Hardware? Physical damage?
2. In case of fire/water: Evacuate the building, call fire department, THEN IT measures
3. Check whether cloud services (email, cloud backup if applicable) are still available
4. Inform employees about the outage and expected duration
5. Activate manual workarounds for core processes
6. Level 3 escalation

Further measures:

1. Engage external IT service provider
2. Procure replacement hardware (if needed)
3. Check whether offsite backups are available for restore
4. Set up alternative working environment (if building is unusable)

Scenario 3: Data leak / data exfiltration

Description: There are indications that confidential or personal data has been unlawfully exfiltrated.

Immediate measures:

1. Determine the type and scope of affected data
2. Identify and close access paths (lock compromised account, adjust firewall rule)
3. Inform data protection officer
4. Check whether personal data is affected
5. Document affected data and systems

Reporting obligations:

• GDPR: Report to the supervisory authority within 72 hours if personal data is affected and a risk to those affected exists
• NIS2: Initial report to the BSI within 24 hours if the incident is classified as significant
• Affected individuals: Inform affected persons if a high risk to their rights and freedoms exists

Scenario 4: Internet connection failure

Description: The company's internet connection fails. Cloud services (email, online banking, cloud backup) are unreachable. VPN for remote employees fails.

Immediate measures:

1. Call provider's outage hotline and report the issue
2. Check whether a redundant connection (second provider, LTE failover) is available
3. Inform employees: Email only local (cache), cloud services unavailable
4. Check which business processes depend on internet and activate workarounds
5. Inform remote employees: Work directly in the office or phone as an alternative

8. Recovery plan (referenced or integrated)

The emergency handbook either contains the complete recovery plan or clearly references it. The choice depends on the scope. If the recovery plan is 15 pages, it can be integrated. If it is 50 pages, a reference with storage location is more practical.

When referencing, the storage location must be redundant: "Recovery Plan IT Infrastructure v2.3, Storage: SharePoint Online [URL], Printed: Safe Room 102, Mobile: IT Manager's company phone"

9. Appendices

Everything that might be needed in an emergency:

• Network diagram: Current network topology with IP ranges, VLANs, firewalls
• Server overview: All servers with function, IP, location, responsible person
• Password access: Not the passwords themselves, but access to the password manager (e.g., "KeePass database on USB stick in safe, master password with CEO")
• Licenses and contracts: Important license numbers, contract numbers, SLA agreements
• Forms: Template for BSI initial report, template for GDPR notification
• Crisis team meeting checklist: Agenda and minutes template

Availability: Printed, digital, and via QR code

An emergency handbook that only exists digitally on the file server may not be reachable in an emergency. The file server itself can be part of the outage. Therefore: At least three independent availability paths.

Printed version

Sounds old-fashioned but is worth its weight in gold in an emergency. When the network completely fails and the cloud is unreachable, you reach for the binder in the safe.

Requirements for the printed version:

• Color-coded tabs for quick finding
• Laminated cover page with version number
• Storage at a defined location known to all participants
• At least two copies: One with the IT manager, one in executive management's safe
• With every update: Collect old version, distribute new one

Digital version

• Cloud storage: SharePoint, Google Drive, or another service independent of your own infrastructure
• PDF on company phones: The responsible persons (IT manager, deputy, CEO) have the current version on their work phone
• USB stick in safe: Encrypted USB stick with the handbook and the most important appendices

QR code for quick access

A QR code at strategic locations - at the server room, at the helpdesk, in the IT manager's office - that leads directly to the digital version is a simple and effective addition. The QR code points to the cloud version, which is always current.

Prerequisite: The QR code must point to a URL that is reachable without VPN and without internal infrastructure. A link to the internal file server is useless.

Practical tip: Create the QR code for a permanent URL (e.g., a SharePoint page) and only change the linked document there when you update. This way the QR code never needs to be reprinted.

Keeping the emergency handbook up to date

An emergency handbook that is not maintained becomes less valuable with every month. New employees, changed phone numbers, new IT systems, expired contracts - all of this must flow into the handbook.

Event-driven updates

The handbook is updated immediately when:

• An employee with an emergency role leaves or changes positions in the company
• Phone numbers or availability change
• New IT systems are introduced or existing ones retired
• Contracts with external service providers change (new provider, new SLA)
• Regulatory requirements change (new reporting obligations)
• After a real incident: Lessons learned flow into the plan

Regular review

Independent of event-driven changes, the handbook should be fully reviewed at least once annually. A proven method: Link the review with a tabletop exercise. During the exercise, it automatically becomes apparent whether information is outdated.

Checklist for the annual review:

[] All contact data checked and current?
[] Escalation chains still correct? (Roles and people)
[] External service providers and SLAs still current?
[] Network diagram current?
[] Server overview current?
[] Reporting paths and reporting obligations still correct?
[] Scenarios still relevant? New scenarios needed?
[] Recovery plan still current?
[] Printed copies distributed and current?
[] QR code works?
[] All participants know where the handbook is located?

Versioning

Every change gets a new version number and is documented in the change history.

Versioning scheme:

• Minor version (v3.1 -> v3.2): Update of contact data, small details
• Major version (v3.2 -> v4.0): New scenario, fundamentally changed infrastructure, new escalation chains
• Every version is recorded with date and author in the change history

Template: IT emergency handbook table of contents

The following template shows the recommended structure for a mid-market company. You can use it as a framework and adapt it to your circumstances.

IT EMERGENCY HANDBOOK [Company Name]
Version [x.x] | As of: [Date]

PART A: FUNDAMENTALS
  A.1  Purpose and Scope
  A.2  Document Control and Change History
  A.3  Terms and Abbreviations
  A.4  Escalation Levels Overview

PART B: CONTACTS AND COMMUNICATION
  B.1  Emergency Contact List (internal)
  B.2  External Service Providers and Hotlines
  B.3  Authorities and Reporting Offices
  B.4  Escalation Chains (Level 1/2/3)
  B.5  Reporting Paths and Reporting Deadlines
  B.6  Communication Plan (internal and external)

PART C: GENERAL IMMEDIATE MEASURES
  C.1  First Response Checklist for IT Security Incidents
  C.2  Evidence Preservation
  C.3  Documentation and Logging

PART D: SCENARIOS AND RESPONSE PLANS
  D.1  Scenario: Ransomware Attack
  D.2  Scenario: Total Data Center Failure
  D.3  Scenario: Data Leak / Data Exfiltration
  D.4  Scenario: Internet Connection Failure
  D.5  Scenario: Compromised Administrator Account
  D.6  Scenario: DDoS Attack
  [additional company-specific scenarios]

PART E: RECOVERY
  E.1  Recovery Plan IT Infrastructure
  E.2  Prioritized Asset List with RTO/RPO
  E.3  Recovery Steps per Asset

PART F: APPENDICES
  F.1  Network Diagram
  F.2  Server Overview (Name, IP, Function, Location)
  F.3  Password Manager Access
  F.4  Licenses and Contract Numbers
  F.5  Form Templates (BSI Report, GDPR Report)
  F.6  Crisis Team Meeting Checklist

Common mistakes and how to avoid them

Mistake 1: Too long and too complex

An emergency handbook with 200 pages will not be read in an emergency. It must be as short as possible and as detailed as necessary. Use references to detail documents instead of putting everything into one document. The ransomware response plan needs 2-3 pages, not 20.

Mistake 2: Only theory, no concrete action instructions

"In the event of a ransomware attack, appropriate measures should be taken" - that helps nobody. Every scenario needs concrete steps: Who calls whom? Which systems are isolated first? Where do I find the backup console?

Mistake 3: Outdated contact information

The classic. Mr. Meier has not been with the company for six months but is still listed as IT manager in the handbook. The external service provider's hotline has changed. The BSI reporting office has a new URL. Every single piece of outdated information costs time in an emergency.

Mistake 4: Only digitally available

When the network fails, the handbook on the file server is unreachable. When cloud access runs through SSO and Active Directory is not functioning, nobody can reach the SharePoint version. Physical copies and offline access are mandatory.

Mistake 5: Nobody knows it exists

The best emergency handbook is useless if employees do not know it exists and where it is located. New IT employees should be introduced to the handbook during onboarding. It is actively used during tabletop exercises. The location of the printed version should be visibly posted in the server room.

The emergency handbook in ISMS Lite

In ISMS Lite, you maintain the base data for the emergency handbook directly in the application: assets, contacts, escalation chains, scenarios, and recovery plans. When a contact changes, you update it once, and all documents referencing that contact are automatically current.

The PDF export generates a complete, print-ready emergency handbook with table of contents, color-coded sections, and all appendices. You can choose whether to export the entire handbook or individual scenarios.

ISMS Lite also generates the QR code for quick access. It points to a password-protected page that is reachable without VPN and always shows the current version.

Next steps

If you do not yet have an emergency handbook, start with the most important building blocks:

1. Create the contact list - this is the quickest win. Even if you have nothing else: A current contact list with all relevant numbers saves hours in an emergency.
2. Define escalation chains - who is informed when? Three levels suffice to start.
3. Develop two scenarios - ransomware and total data center failure cover the most common cases.
4. Ensure availability - a printed version and a PDF on the company phone.
5. Plan a tabletop exercise - walking through the handbook in an exercise reveals where gaps exist.

Further reading

• Creating a recovery plan: Guide with template for SMEs
• Creating an incident response plan: Template and practical example
• Planning and conducting a tabletop exercise: How to test your emergency plan
• Backup strategy and restore tests: Because backups alone are not enough
• Conducting a Business Impact Analysis (BIA): Evaluating business processes

For the BIA as a foundation, the business impact analysis article is recommended, and for the recovery plan as the operational core, you will find a detailed guide in the recovery plan article.