- NIS2 requires an initial notification within 24 hours and a full report within 72 hours. Without a documented policy, you will not meet these deadlines.
- The policy must cover four phases: preparation, detection and analysis, containment and eradication, and post-incident review.
- Clear escalation levels and decision-making authority are critical. In an emergency, there must be no debate about who is authorized to make decisions.
- Internal and external communication must be pre-defined: Who informs customers, authorities, and the press? Who approves the release of technical details?
- Lessons learned after every incident are mandatory. Without systematic post-incident review, the same mistakes will repeat.
Why you need an incident response policy
Security incidents are not a question of if, but when. Every organization that uses IT will sooner or later face an incident: ransomware, phishing attack, data leak, compromised credentials, DDoS attack, or a simple human error that exposes sensitive data.
The difference between a manageable incident and a catastrophe rarely comes down to technology. It comes down to preparation. Organizations that have a documented, rehearsed process for security incidents respond faster, more coordinately, and with less damage than those that must improvise in an emergency.
The incident response policy is this document. It defines what constitutes a security incident, who acts in which role, which steps are taken in which order, when and to whom escalation occurs, which reporting obligations exist, and how post-incident review ensures the organization learns from the incident.
From a compliance perspective, the policy is equally indispensable. ISO 27001 dedicates several controls to the topic: A.5.24 (Incident Management Planning), A.5.25 (Assessment of Information Security Events), A.5.26 (Response to Information Security Incidents), and A.5.27 (Learning from Information Security Incidents). NIS2 goes further with the reporting deadlines in Article 23, setting tight time windows that are virtually impossible to meet without prepared processes.
The four phases of incident response
The internationally recognized framework for incident response comes from NIST (SP 800-61) and divides the process into four phases. Your policy should address all four.
Phase 1: Preparation
Preparation takes place before the incident and forms the foundation for everything that follows. In the policy, you define:
Incident Response Team (IRT): Who is on the team? Typically IT management, system administrators, ISO, data protection officer, executive management, communications/PR, and external specialists (forensics provider, attorney) as needed. Each member has a defined role and a deputy.
Reachability: Contact lists with current phone numbers, email addresses, and alternative communication channels (what if email is compromised?). The contact list must also be available offline — printed and stored at a known location.
Tools and infrastructure: Which technical tools are available for analysis? Forensics software, log analysis tools, isolated investigation environment, secure communication channels for the IRT.
Contracts with external service providers: If your organization lacks in-house forensics capability (which is the case for most mid-market companies), a framework contract with a specialized provider must exist beforehand. In an emergency, you have no time to request quotes and negotiate contracts.
Exercises: The policy requires that the IRT practices regularly. Tabletop exercises (simulations) at least annually, practical exercises as needed. Only a team that has practiced will function under pressure.
Phase 2: Detection and analysis
Not every anomaly is a security incident, and not every security incident is a crisis. The policy must define how events are detected, assessed, and classified.
Definition: What is a security incident? The policy needs a clear definition. A security incident is any event that actually or potentially compromises the confidentiality, integrity, or availability of information or information systems. This includes successful and attempted attacks, technical failures with security relevance, and human errors with data exposure.
Detection sources: Where do reports come from? SIEM alerts, antivirus warnings, firewall logs, employee reports, customer or partner notifications, reports from external security researchers, information from CERTs. The policy must ensure that all these sources feed into the incident response process.
Reporting path for employees: Every employee must know how and to whom to report a suspicious event. The threshold must be low: better ten false alarms than one missed incident. The policy defines a simple reporting path (email address, phone number, ticket system) and makes clear that reports are welcome and will not lead to negative consequences.
Classification: The policy defines severity levels that determine which escalation level and response time applies.
| Severity | Description | Example | Response time |
|---|---|---|---|
| Critical | Acute threat to business operations or large-scale data loss | Ransomware infection, large-scale data exfiltration | Immediate, IRT activation within 1 hour |
| High | Significant impact or compromise of sensitive data | Compromised admin account, targeted attack | IRT activation within 4 hours |
| Medium | Limited impact, local impairment | Malware on a single workstation, phishing success without data exfiltration | Handled same business day |
| Low | Minor, no immediate threat | Suspicious login attempt, spam with malware attachment (blocked) | Handled within 72 hours |
The initial assessment is performed by the person who first handles the incident (first responder). The final classification is made by the IRT and can be adjusted up or down during the course of the analysis.
Phase 3: Containment, eradication, and recovery
Once an incident is confirmed and classified, the active response begins. The policy must define the fundamental principles of action, not the technical details of every conceivable scenario.
Containment: The goal is to stop the spread of the incident without causing additional damage. The policy distinguishes between short-term containment (e.g., isolating the affected system from the network) and long-term containment (e.g., temporary firewall rules until the root cause is eliminated).
Important: The policy must define who makes the decision to take a system offline. If a production system is affected, this decision has immediate business impact. The policy specifies that the IRT lead makes this decision in coordination with executive management and defines an expedited decision path for cases when management is unreachable.
Evidence preservation: Before you begin eradication, the evidence must be secured. Forensic copies of affected systems, securing logs, documenting timestamps. The policy must emphasize that evidence preservation comes before remediation, not the other way around. Anyone who immediately reimages a compromised system may destroy evidence needed for root cause analysis, authorities, or insurance claims.
Eradication: The root cause of the incident is identified and removed. Malware is cleaned, compromised credentials are reset, vulnerabilities are patched, unauthorized access is closed.
Recovery: Affected systems are returned to normal operations. The policy requires that recovery is done incrementally and that systems are monitored more closely after returning to production to ensure the attacker has not left a hidden backdoor.
Phase 4: Post-incident review (lessons learned)
Post-incident review is the phase most frequently skipped, even though it is the most valuable for long-term security. The policy must define it as mandatory, not as an optional appendix.
Post-incident review: Within two weeks of incident closure, the IRT conducts a structured review. What happened? When was the incident detected? How quickly was the response? What worked well? What didn't? What measures will prevent the same incident from recurring?
Documentation: The entire incident is documented without gaps: timeline, people involved, decisions made, technical analysis, impact, actions taken. This documentation serves as evidence for auditors and authorities.
Action plan: Concrete improvement measures with responsible parties and deadlines emerge from the review. Implementation is tracked.
Reporting obligations: NIS2 and GDPR
The incident response policy must concretely map the legal reporting obligations, because the deadlines are tight and leave no room for improvisation.
NIS2 reporting deadlines
NIS2 Article 23 defines a three-stage reporting procedure to the BSI:
Initial notification within 24 hours of becoming aware of a significant security incident. The initial notification does not need to contain a full analysis but must include at least an initial assessment of the incident and its possible cross-border impact.
Follow-up notification within 72 hours with an initial assessment of the incident, its severity and impact, and, where applicable, the indicators of compromise.
Final report within one month with a detailed description of the incident, root causes, measures taken, and cross-border impact.
GDPR reporting obligation
If personal data is affected, Article 33 DSGVO (GDPR) also applies: notification to the supervisory authority within 72 hours. Article 34 may require notification of affected individuals if there is a high risk to their rights and freedoms.
What the policy must define
The policy must specify who decides whether to file a report (typically the ISO plus data protection officer plus executive management), who technically executes the report, which information must be compiled, and where the reporting channels are documented. Pre-prepared reporting forms and text templates significantly accelerate the process.
Particularly important: The policy must clarify that the 24-hour deadline begins when the incident becomes known, not when the analysis is complete. You report even if you do not yet know exactly what happened.
Communication during an incident
A security incident is not only a technical event but also a communication event. The policy must define communication channels in advance.
Internal communication: Who informs executive management? How are affected departments informed? Through which channel if the usual communication systems are compromised? The policy should define an alternative communication channel (e.g., mobile phones, separate messaging service) that works even when internal IT fails.
Communication with customers and partners: If customers or business partners are affected, they must be informed. The policy specifies who is responsible for this communication (typically executive management or the communications department, not IT), what information may be shared, and what approval process such a notification must go through.
Press and public: In severe incidents, media interest can be significant. The policy defines who is authorized to speak to the press (typically only executive management or a designated spokesperson) and that technical details are not communicated without IRT approval.
Communication with authorities: Beyond reporting obligations, it may be necessary to cooperate with law enforcement (police, BKA, ZAC). The policy specifies who decides whether to file a criminal complaint and who manages communication with authorities.
Delineation from related documents
The incident response policy does not stand alone. It is embedded in a network of related documents, and the policy should clearly define the boundaries:
Incident response plan: While the policy defines the principles and framework, the plan contains the operational details: step-by-step instructions for specific scenarios (ransomware, data leak, DDoS), technical runbooks, and checklists.
Business continuity plan (BCP): The BCP governs maintaining business operations during major disruptions. The incident response policy defines when the transition from incident response to business continuity management occurs.
Emergency handbook: The emergency handbook contains operational instructions for IT emergencies. It is more detailed and practical than the policy and is used by the IRT as a working document during incidents.
Communication plan: Governs the details of internal and external communication during incidents. The policy references it; the communication plan contains the text templates and distribution lists.
Example outline for an incident response policy
- Purpose and scope
- Terms and definitions — Security event vs. security incident, IRT, severity levels
- Normative references — ISO 27001 A.5.24–A.5.27, NIS2 Art. 23, GDPR Art. 33/34
- Incident response team — Composition, roles, deputies, reachability
- Phase 1: Preparation — Tools, contracts, exercises
- Phase 2: Detection and analysis — Detection sources, reporting paths, classification
- Phase 3: Containment, eradication, recovery — Principles, decision authority, evidence preservation
- Phase 4: Post-incident review — Review, documentation, action plan
- Reporting obligations — NIS2 deadlines, GDPR deadlines, internal escalation
- Communication — Internal, customers, press, authorities
- Documentation and retention — Incident documentation, retention periods
- Responsibilities
- Interfaces to related documents — BCP, emergency handbook, communication plan
- Review and update
- Effective date and approval
Common mistakes in incident response policies
Vague classification
If severity levels are not clearly defined, a debate will begin in an emergency about whether the incident is "critical" or merely "high." Meanwhile, valuable time passes. Define severity levels with concrete criteria and examples, not abstract wording.
No deputy arrangements
The IRT lead is on vacation, the deputy is sick. Who decides now? Without documented deputy arrangements for every role in the IRT, the team is paralyzed. The policy must name at least one deputy for every role.
Outdated contact lists
Contact lists that have not been updated for two years contain phone numbers of employees who left the company long ago. The policy must require that the contact list is updated at least quarterly. Even better: every personnel change in the IRT automatically triggers an update.
No practice
A policy that has never been exercised is as useful in an emergency as a road map in a language you cannot read. Tabletop exercises at least once a year are mandatory. They uncover gaps before a real incident does. After every exercise, the policy is adjusted as needed.
No evidence preservation before remediation
The most common mistake in an actual incident: the compromised system is immediately reimaged before forensic copies are created. The policy must define the sequence unambiguously: first preserve, then remediate. This principle must be anchored so firmly that it is not forgotten even under time pressure.
From policy to living practice
An incident response policy gathering dust on SharePoint protects no one. For it to work in an emergency, it needs three things: awareness, practice, and regular updates.
All employees must know how to report a suspicious incident — the article on recognizing and reporting security incidents provides the foundation. The IRT must know its roles and rehearse them regularly in tabletop exercises. Contact lists must be current. The policy must be reviewed after every actual incident and at least annually.
ISMS Lite supports you throughout the entire policy lifecycle: creation (with AI support if desired), versioning with every change, digital acknowledgment by all participants, and legally compliant approval by management. This ensures that your incident response policy not only exists but is current, known, and effective.