IT emergency management: incident response and crisis management

IT Incident Management is the organized preparation for, response to, and recovery from IT security incidents. The difference between a disaster and a successfully managed incident often lies solely in the existence of a good plan.

The NIST Incident Response Framework

The NIST (National Institute of Standards and Technology) defines 4 phases:

Phase 1: PREPARATION
  → Create an incident response plan
  → Define the team, clarify roles
  → Provide tools (forensic software, backup systems)
  → Conduct regular drills (tabletop exercises)

Phase 2: DETECTION & ANALYSIS
  → Detect the incident (SIEM alert, user report, external report)
  → Assess scope and severity
  → Back up logs (do not overwrite!)
  → Document timestamps

Phase 3: CONTAINMENT, ERADICATION & RECOVERY
  (Containment, Eradication & Recovery)
  → Stop the spread of damage
  → Remove the attacker from the system
  → Gradually restore systems

Phase 4: POST-INCIDENT ACTIVITIES
  → Root Cause Analysis
  → Lessons Learned
  → Improve processes
  → Finalize regulatory reports

The Incident Response Plan

Core Elements of an IR Plan

1. Incident Classification Matrix

Severity Levels:

P1 - CRITICAL:
  Ongoing ransomware attack
  Complete system/network failure
  Active APT compromise
  → Immediate escalation to C-level
  → Fully activate crisis team

P2 - HIGH:
  Compromised admin account
  Loss of sensitive data
  Malware on multiple systems
  → Notify IT management and CISO
  → Activate forensic service provider

P3 - MEDIUM:
  Compromised standard user account
  Malware on a single endpoint (isolated)
  Phishing email opened
  → Standard IT security process

P4 - LOW:
  Spam campaign, no clicks
  Suspicious email reported
  → Documentation, standard response

2. RACI Matrix (Roles and Responsibilities)

Person/Role          Detect Decide Communicate Remediate
─────────────────────────────────────────────────────────────
IT Administrator      R/A       I           I             R
CISO/IT Manager        I         R/A         R             A
Executive Management    I         A (P1/P2)   R (external)    I
PR / Communications    I         I           R/A (external)  I
Data Protection Officer I         R (GDPR)   R (authorities)  I
Forensic Service Provider I        C           I             R/A
Legal Department       I         C           R (legal)     C

R=Responsible, A=Accountable, C=Consulted, I=Informed

3. Contact List (24/7)

Internal:
  CISO/IT Manager:      [Name] [Mobile] [Signal]
  CEO:     [Name] [Mobile]
  Data Protection Officer:  [Name] [Mobile]
  IT Emergency Hotline:   [Number] (24/7)

External - On-call (contractual):
  Forensics/IR Service:  [Company] [Number] [SLA: 4-hour response]
  Cyber Lawyer:        [Law Firm] [Contact Person]
  Cyber Insurance:  [Policy No.] [Claims Hotline]

Authorities:
  BSI / CERT-Bund:     0800 274 1000 (toll-free)
  LKA Cybercrime:      [relevant LKA]
  Data Protection Authority:  [enter state authority]

The First 72 Hours - Timeline

Hours 0-1: Detection and Initial Response

0:00 - Alert received (SIEM, user, external report)
0:05 - IT administrator notified → Initial assessment
0:15 - CISO/IT director notified
0:20 - Determine scope: How many systems? What data?
0:30 – Decision: Severity level P1/P2/P3/P4?
0:45 – P1/P2: Convene crisis team, notify management
1:00 – Initial containment measures (isolate affected systems)

Hours 1–4: Containment

First goal: Stop the spread, don’t fix it!

For ransomware/malware:
  ✓ Disconnect affected systems from the network (physically disconnect cables)
  ✓ DO NOT shut down (forensic data in RAM will be lost)
  ✓ Back up logs BEFORE isolating systems
  ✓ Change passwords for all affected accounts
  ✓ Lock admin accounts → recreate with new credentials

For compromised accounts:
  ✓ Deactivate account (do not delete—forensic evidence)
  ✓ Invalidate all sessions
  ✓ Check all of the user’s devices
  ✓ What data did the account have access to? → Define scope

Hours 4–24: GDPR Reporting Obligation

GDPR Art. 33:
  24h: Initial assessment of whether personal data is affected
  72h: If affected → Report to data protection authority

Report form includes:
  → Type of incident (ransomware, data breach, etc.)
  → Categories and approximate number of affected individuals
  → Likely consequences
  → Measures taken

If unclear: Preliminary notification ("precautionary notification") is possible
  "Incident detected, scope still unclear, update to follow"

Hours 24–72: NIS2 reporting obligation (for affected companies)

NIS2 Art. 23:
  24h: Early warning to BSI
    → Incident type, initial assessment
    → No full report required
  72h: Full report
    → Cause, if known
    → Impact and countermeasures
  30 days: Final report

Reporting office: BSI / CERT-Bund (online portal)

Forensics: Securing evidence

Important: Secure forensic evidence before systems are cleaned or reset.

Artifacts to be secured:

Memory (RAM):
  → Memory dump before shutdown (contains running processes, credentials)
  → Tools: DumpIt, WinPmem, LiME (Linux)

Hard drives:
  → Forensic copy (bit-for-bit copy) BEFORE cleaning
  → Hash value (SHA256) for chain of evidence
  → Tools: dd, FTK Imager, EnCase

Logs:
  → Windows Event Logs (System, Security, Application)
  → PowerShell logs (Module Logging, Script Block Logging)
  → Firewall logs, proxy logs, DNS logs
  → SIEM export for the last 30–90 days

Network:
  → All outbound connections from the last few hours/days
  → PCAP captures if available

Business Continuity During the Incident

Questions that must be answered immediately:

Communication:
  → How does the company communicate during the incident?
  → Email may be compromised → Signal/Threema as a backup?
  → External communication: who speaks with customers, the press, and authorities?

Operations:
  → Can critical processes continue to run manually?
  → Which systems are critical vs. non-critical?
  → Are there hot-standby systems?

Backup:
  → When was the last clean backup?
  → Have backups also been encrypted by the attacker?
  → Recovery Time Objective (RTO): When must operations be back up and running?

Tabletop Exercise - Practicing Incident Response

The best preparation is practice—before things get serious:

Tabletop Exercise Format:
  Duration: 2–4 hours
  Participants: IT, management, communications, legal
  Format: Scenario is read aloud; team discusses response

Sample Scenario:
  "Monday, 6:30 a.m. Employees call in: all servers display
   encrypted files and a ransom demand.
   What will you do in the next 60 minutes?"

Evaluation:
  → How long did it take until the first alert?
  → Were all contacts reachable?
  → Did everyone know their role?
  → What gaps in the plan were discovered?

Lessons Learned and Continuous Improvement

After each incident (P1-P3):

Post-Incident Review (within 1–2 weeks):
  → Reconstruct the incident timeline
  → Root Cause Analysis: How did the attacker gain access?
  → What worked? What didn’t?
  → What controls could have prevented this or detected it earlier?

Typical findings:
  "MFA was missing on the VPN → Immediate action: Implement MFA"
  "SIEM had no rule for this attack → Create new SIEM rule"
  "Backup restoration took 8 hours → RTO not met → Revise backup strategy"
  "Communication paths unclear → Update RACI"

IT incident management is not a one-time project—it is a continuous process consisting of preparation, practice, response, and improvement.