What is incident management?
Incident management takes in disruptions to IT services, assesses them and resolves them until the service runs as agreed again. An incident is any unplanned interruption or noticeable degradation of a service: a failed mail server just as much as an application that has been responding much more slowly since the morning. What counts as normal operation is set by the service level agreement (SLA), where one exists.
In IT service management, the ITIL framework describes the discipline; ITIL 4 lists incident management as one of its management practices. In German the discipline is also called Störungsmanagement or Vorfallmanagement.
Incident, problem, service request and security incident
The distinction decides who is responsible and whether a statutory deadline is running.
| Term | What it is | Goal | Example |
|---|---|---|---|
| Incident | unplanned interruption or degradation of a service | restore the service quickly | VPN gateway unreachable |
| Problem | cause of one or more incidents | find and remove the cause | faulty firmware update on the gateway |
| Service request | planned request with no disruption | deliver the service within the agreed scope | new VPN access for an employee |
| Security incident | impairment of the confidentiality, integrity or availability of information | limit damage, preserve evidence, check reporting duties | login to the gateway with stolen credentials |
A security incident that impairs a service is also an incident. The reverse does not hold: whether the failure of a defective hard drive also counts as a security incident depends on the classification you have set. The entry on incident response covers the security-specific handling.
The process in eight steps
- Detect and report: users, the service desk or monitoring report the disruption.
- Log: a ticket records the time, the affected service, the symptoms and the person reporting.
- Categorize: assign service, component and type of disruption and check for a security link.
- Prioritize: priority follows from impact (how many users, which business process) and urgency (how fast the damage grows).
- Diagnose: first level analyzes and checks against known errors and workarounds.
- Escalate: functionally to second or third level, hierarchically to the incident manager or management when a deadline or the impact requires it.
- Resolve and restore: the service runs again, if necessary through a workaround, and the person reporting confirms it.
- Close and review: document the solution and open a problem for recurring or severe disruptions.
For disruptions that exceed the standard procedure, set a major incident procedure in advance, with its own lead and a mandatory post-incident review.
The security check in step 3
Statutory reporting deadlines run from awareness of the incident, not from when the ticket is closed. Step 3 therefore needs fixed check questions. If one applies, a separate assessment with its own clock runs alongside the ticket.
| Check question at categorization | If yes | Deadline |
|---|---|---|
| Is the confidentiality, integrity or availability of information impaired, for example by an unauthorized login, malware or data exfiltration? | security incident: start incident response, involve the information security officer | as set internally |
| Is personal data affected? | assessment as a personal data breach under Article 33 GDPR | without undue delay and, where feasible, within 72 hours of becoming aware |
| Is the organization a particularly important or important entity, and could the incident be significant? | assessment under § 32 of the German BSI Act (BSIG) | early first report without undue delay, at the latest 24 hours after awareness; report without undue delay, at the latest after 72 hours |
| Is the organization a financial entity under DORA? | classification under Article 18 DORA instead of § 32 BSIG (§ 28(6) no. 1 BSIG) | if classified as major: initial notification within 4 hours of classification, at the latest 24 hours after awareness |
The DORA deadlines are set in Article 5 of Delegated Regulation (EU) 2025/301. If an incident is classified as major only after 24 hours, the four-hour deadline runs from the classification (Article 5(2)). Under § 28(5) BSIG, § 32 BSIG also does not in principle apply to operators of public telecommunications networks and providers of publicly available telecommunications services. The same holds for energy companies subject to §§ 5c to 5e of the Energy Industry Act (EnWG).
Fictional example: the VPN gateway fails at 8:10. After a restart it runs again, and the ticket is closed at 9:30. During the review the next day, the login log shows a login with stolen credentials shortly before the failure. Had step 3 checked the log, the security incident assessment would have started that morning.
Record in the ticket who answered the check questions and when.
Roles: service desk, support levels, incident manager
| Role | Task |
|---|---|
| Service desk (first level) | takes reports, logs, categorizes, resolves standard cases |
| Second-level support | specialist teams for network, applications or workplace; deeper diagnosis |
| Third-level support | development, manufacturers, external service providers |
| Incident manager | owns the process, prioritization, escalation and metrics |
| Major incident team | leads severe disruptions and coordinates technology, communication and management |
| Information security officer | assesses, where there is a security link, whether a security incident exists |
Which metrics are used?
| Metric | What it measures |
|---|---|
| MTTA (mean time to acknowledge) | time from the report to acceptance by a responsible person |
| MTTD (mean time to detect) | time from the occurrence of a disruption to its detection |
| MTTR (mean time to resolve or restore) | time to restoration; the abbreviation is expanded in different ways, so state the definition in the report |
| First-contact resolution rate | share of incidents first level resolves without handing them on |
| SLA compliance | share of incidents handled within the agreed response and resolution times |
| Reopen rate | share of closed tickets that are reopened |
Derive target values from SLAs and the criticality of the service. The entry on security metrics and KPIs describes how to prepare metrics for management.
What ISO 27001, the BSIG and DORA require
None of these frameworks prescribes an ITIL process. They require a defined way of handling security incidents, which can build on the existing incident process.
| Framework | Provision | Core requirement |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 5.24 to 5.28 and 6.8 | plan incident handling, assess events, respond, learn from incidents, preserve evidence; staff report events through defined channels |
| BSIG | § 30(2) sentence 2 no. 2 BSIG | handling of security incidents as a risk management measure |
| DORA | Article 17 of Regulation (EU) 2022/2554 | a process to detect, manage and notify ICT-related incidents; record all incidents; identify, document and address root causes |
| BSI IT-Grundschutz | module DER.2.1 "Behandlung von Sicherheitsvorfällen" (handling security incidents) in the IT-Grundschutz Compendium (Edition 2023) | handling of security incidents |
The guide to implementing an ISMS shows how incident handling, reporting channels and post-incident reviews fit into an ISMS.
Incident management in Rizzqo
When an incident affects a system, such as a VPN gateway, Rizzqo shows which processes depend on it, whether it holds personal data and who is responsible for it. You record the follow-up actions from the post-incident review as tasks that sync both ways with Jira, and see how much each one lowers the risk.