Cybersecurity Incident Management Policy
Principles for detecting, classifying, handling and reporting incidents
1. Purpose and Scope
This policy defines the principles for managing cybersecurity incidents in the organisation, including their detection, classification, handling, documentation and reporting to competent authorities – in particular to the competent CSIRT in accordance with NIS2 requirements.
⚠️
Statutory obligation: Art. 23 NIS2 imposes on essential and important entities the obligation to have the capability to detect incidents and report them to the competent CSIRT within strictly defined deadlines (early warning: 24 h, notification: 72 h, final report: 1 month).
2. Definitions and Incident Classification
2.1 Definitions
| Term | Definition |
|---|---|
| Event | Any observed occurrence in a system or network indicating a possible security breach |
| Incident | An event having an actual adverse effect on the security of network and information systems |
| Significant incident | An incident causing major disruption or likely to cause major disruption to key/important services (see significance criteria in section 2.3) |
| Supply chain incident | An incident at a supplier or third party affecting the organisation |
| Vulnerability | A weakness in a system that could be exploited by a threat |
| CSIRT | Competent Computer Security Incident Response Team (National CSIRT / Sector CSIRT) |
2.2 Classification by severity
| Level | Name | Description | Examples | Response time |
|---|---|---|---|---|
| P4 | Low | Limited impact, no service disruption | Single malware on a workstation, unsuccessful phishing attempt | ▸ [8h]within 24h |
| P3 | Medium | Moderate impact, limited disruption | DDoS on auxiliary systems, unauthorised access to unclassified data | ▸ [4h]within 8h |
| P2 | High | Significant impact, disruption of important services | Ransomware on back-office systems, personal data breach, privileged account compromise | ▸ [2h]within 4h |
| P1 | Critical | Significant incident under NIS2, disruption of key services | Ransomware on OT/SCADA, attack on critical infrastructure, large-scale data breach | ▸ [1h]within 2h |
2.3 Significance criteria – "significant incident" threshold (NIS2)
⚠ Critical – organisation defines thresholds per NIS2 / ENISA guidelines
An incident is considered significant (requiring notification to CSIRT) when at least one of the following conditions is met:
| Criterion | Organisation's threshold | NIS2 minimum requirement |
|---|---|---|
| Duration of key service unavailability | ▸ [e.g. more than 30 min]threshold per sector | Per implementing regulation for the sector |
| Number of affected users | ▸ [e.g. more than X users] | Per implementing regulation |
| Financial loss (estimated) | ▸ [e.g. above X currency] | — |
| Personal data breach | Any personal data breach | GDPR Art. 33 (DPA notification 72h) |
| Impact on critical infrastructure | Any event affecting OT/ICS | Art. 23(3) NIS2 |
| Geographic scope | ▸ [e.g. cross-border incident, min. 2 EU member states] | Art. 23(6) NIS2 – notification to ENISA |
3. Reporting Obligation and Deadlines – NIS2 Requirement
🕐
Deadlines are statutory and non-negotiable. Failure to comply risks administrative fines.
| Reporting stage | Deadline | Recipient | Content |
|---|---|---|---|
| Early warning | 24 hours from detection |
Competent CSIRT ▸ [National CSIRT / sector CSIRT] |
Information on occurrence of a significant incident or suspicion; indication of cross-border impact (if applicable) |
| Incident notification | 72 hours from detection |
Competent CSIRT | Incident assessment, initial severity classification, IoCs, remediation actions taken |
| Intermediate report (if required) |
At CSIRT's request | CSIRT / supervisory authority | Current handling status, incident evolution |
| Final report | 1 month from notification or from incident closure |
Competent CSIRT | Full incident description, root cause analysis (RCA), remediation measures taken, lessons learned |
| Personal data breach (GDPR) |
72 hours from detection |
DPA | DPA notification: nature of breach, number of persons affected, possible consequences, measures taken |
3.1 Escalation and notification path
Any employee who detects or suspects an incident is required to immediately notify:
- Their line manager AND
- CISO / Person responsible for cybersecurity via:
- Telephone: ▸ [24/7 emergency number]
- E-mail: ▸ [[email protected] or dedicated address]
- Ticketing system: ▸ [system name, e.g. ServiceNow / Jira]
⚠️
Do not destroy evidence! An employee who detects an incident must not take any action that could destroy evidence (logs, files). They should only report the event and – if necessary – disconnect the device from the network.
4. Incident Categories
| Category | Type | Examples |
|---|---|---|
| MAL | Malicious software | Ransomware, virus, trojan, spyware, rootkit, cryptominer |
| PHI | Phishing / Social engineering | Spear phishing, vishing, smishing, BEC (Business Email Compromise) |
| NET | Network attacks | DDoS, scanning, man-in-the-middle, brute force, port scanning |
| WEB | Web application attacks | SQL injection, XSS, CSRF, RFI/LFI, API attack |
| ACC | Access control breach | Unauthorised access, account takeover, privilege escalation |
| DAT | Data breach | Data leak, exfiltration, unauthorised disclosure, lost media |
| INS | Insider threat | Deliberate employee action, sabotage, IP theft |
| SUP | Supply chain | Supplier software compromise, hardware backdoor |
| PHY | Physical | Equipment theft, unauthorised access to server room |
| OTH | Other | Unauthorised configuration change, misconfiguration, OT anomaly |
5. Roles and Responsibilities in Incident Management
Detailed RACI matrix for incidents in DOC-004. Key responsibilities below:
| Role | Responsibilities during an incident |
|---|---|
| Every employee | Immediate reporting of suspicious events; do not destroy evidence; disconnect device if necessary |
| CISO / IR Coordinator | Assessment and classification; activating response procedure; CSIRT notification; Board escalation; documentation |
| IT Administrator | Collecting logs and forensic evidence; system isolation; implementing countermeasures; recovery |
| Board | Crisis decision-making; authorisation of extraordinary actions; external communications (media, regulators) |
| Legal Counsel / DPO | Legal obligation assessment; DPA notification (if applicable); legal documentation |
6. Incident Register
The organisation maintains a central Incident Register. Every incident (regardless of level) must be registered. The register is maintained by the CISO and retained for ▸ min. 5 yearsmin. 5 years – NIS2.
▸ Organisation completes – register tool
Tool: ▸ [e.g. SIEM / ticketing system (ServiceNow / Jira) / dedicated spreadsheet]
Location: ▸ [path / URL to register]
Access: ▸ [who has access to the register]
Minimum register entry content:
| Field | Description | Required? |
|---|---|---|
| Incident ID | Unique identifier (e.g. INC-2024-001) | YES |
| Date and time of detection | Timestamp of first detection | YES |
| Category (see section 4) | MAL / PHI / NET / WEB / ACC / DAT / INS / SUP / PHY / OTH | YES |
| Severity level (P1–P4) | See section 2.2 | YES |
| Event description | What happened, which systems affected | YES |
| Affected systems / services | List of systems/assets | YES |
| Root cause (RCA) | After incident closure | YES (after closure) |
| Actions taken | Chronological action log | YES |
| Was CSIRT notified? | YES/NO + date and time of notification | YES (if P1) |
| Was DPA notified? | YES/NO + date | YES (if applicable) |
| Closure date | Timestamp of incident closure | YES |
| Lessons learned | What to improve | YES (after closure) |
7. Lessons Learned and Improvement
A Post-Incident Review (PIR) is conducted after every P1 and P2 incident, and selected P3 incidents, within ▸ [5 business days]max. 2 weeks of incident closure.
The PIR answers:
- What happened and why (root cause analysis – RCA)?
- Did the procedures work correctly?
- Was CSIRT notified on time?
- What security changes should be implemented?
- Is an update to the Risk Register (DOC-003) needed?
PIR findings are passed to the CISO and implemented as corrective actions with a specified deadline and owner.
8. Testing Response Capabilities
The organisation regularly tests incident management procedures:
| Test type | Frequency | Scope | Responsible |
|---|---|---|---|
| Tabletop exercise (simulation) | ▸ min. once a yearmin. 1/year – NIS2 | P1 incident scenario with Board and CISO | ▸ CISO |
| Emergency communication test | ▸ [quarterly] | Verification of reporting channels and contact numbers | ▸ CISO / IT Admin |
| CSIRT notification test | ▸ [once a year, within exercise] | Verification of forms, CSIRT communication channels | ▸ CISO |
9. Change History
| Version | Date | Author | Description | Approved by |
|---|---|---|---|---|
| ▸ 1.0 | ▸ DD/MM/YYYY | ▸ | ▸ Initial release | ▸ Board |
DOC-005 Incident Management Policy | v1.0 | NIS2/ISMS