Incident Management

What is Incident Management?

Incident Management is the process an organisation uses to detect, record, prioritise, analyse and resolve disruptions in IT and OT systems, with the aim of restoring normal service or production as quickly as possible and limiting the damage. An incident is any unplanned interruption to, or reduction in the quality of, a service, system or process. Incident Management is an established practice in ITIL and appears in ISO 27001, IEC 62443 and the Dutch Cybersecurity Act. In a plant it covers not only a frozen server, but also a PLC that loses its connection or an HMI that stops responding.

🧠 What exactly is an incident?

ITIL 4 defines an incident as an unplanned interruption to a service or a reduction in the quality of that service. A fault that no user notices yet, such as a failed redundant power supply, therefore also counts: quality has dropped, because the spare capacity is gone.

Not every alert is an incident. It helps to keep the terms apart:

Monitoring and logging produce thousands of events a day. Incident Management starts when an event, reported by a user, a SIEM or an alarm, is judged to be a genuine disruption.

🎯 What is the purpose of Incident Management?

• Minimal impact - production, safety and service delivery suffer as little as possible
• Fast restoration - a low MTTR and predictable response times, so recovery is quick
• Standardised approach - every incident follows the same route, regardless of who is on duty
• Records - data for analysis, compliance, audits and improvement
• Coordination - IT, OT, security, maintenance and operations work from one shared picture

Restoration comes first, not the cause. A workaround that gets the line running again is a successful incident resolution, even if the underlying fault still exists.

🔁 Which steps does an incident go through?

1. Detection - the incident is noticed by a user, operator, monitoring or a SIEM
2. Registration - recorded in a ticketing system or log book with time, reporter and affected systems (ideally linked to the CMDB)
3. Classification and prioritisation - determining category, impact and urgency
4. Diagnosis - initial analysis, checking the knowledge base and known errors
5. Escalation - functional to second or third line, the vendor or the OT or security team; hierarchical to management for a major incident
6. Resolution or workaround - restoration, possibly temporary, and checking that the service really works again
7. Closure - feedback to the reporter, documentation and, where needed, hand-over to problem management

When a security incident is suspected, handling moves to Incident Response after step 3: containment, preserving evidence and eradication then take precedence over a quick restart, because a restart can wipe traces.

📊 How do you prioritise an incident?

The common method is a matrix of impact (how many users, installations or how much production is affected) and urgency (how quickly the damage grows). Each is rated from high to low, and the combination gives the priority.

These times are illustrative; the actual targets are set in the SLA with the internal IT department or the vendor. In OT, the impact on safety and the environment weighs more heavily than the number of affected users: a single frozen operator station in a continuous process is often a P1.

🏭 How does Incident Management differ in OT environments?

• Safety before restoration - an incident can directly affect production, safety, the environment or product quality; the process is brought to a safe state first
• No blind restarts - restarting a PLC or SCADA server can upset the process, so it only happens in agreement with operations
• Different sources - many OT incidents start as a process alarm; good alarm management in line with ISA-18.2 keeps a real fault from drowning in an alarm flood
• Mixed causes - physical defects, network problems and cyberattacks such as malware or a DDoS attack often show the same symptoms
• More parties - production, maintenance, IT, security, vendors and sometimes the system integrator must work together, often outside office hours
• Link to safety studies - recorded incidents feed HAZOP, LOPA and change management; when an incident touches a SIS, functional safety rules apply as well
• Continuity - Incident Management is the first link of Disaster Recovery and Business Continuity: in a major incident the team decides whether to invoke the continuity plan

IEC 62443-2-1 (second edition, 2024) requires asset owners to define this in their security programme: security program element 7 covers event and incident management, from detection and reporting through to handling.

📚 Which standards and frameworks describe Incident Management?

🔄 How does it differ from Problem Management and Incident Response?

Problem management uses root cause analysis to prevent recurring incidents. Incident response is the specialised branch for cyber incidents. The Dutch CSIR guideline, which Rijkswaterstaat and the water authorities use to apply the BIO and IEC 62443 to objects such as pumping stations and locks, also builds on standards in which incident handling is a fixed element. All three processes share one record, so that a pattern in tickets can grow into a problem or a security investigation.

🛠️ How do you set up Incident Management in practice?

1. Fix definitions and priorities - what is an incident, what is a major incident, and which matrix applies to IT and to OT
2. Choose one point of registration - one ticketing system or log book for IT and OT, linked to the CMDB or asset inventory
3. Arrange availability - on-call rotas, vendor contact details and an escalation ladder, including nights and weekends
4. Write a major incident procedure - who leads, who communicates, when the continuity plan is invoked
5. Link to reporting duties - under the Dutch Cybersecurity Act, in force since 15 August 2026, an essential or important entity reports a significant incident within 24 hours (early warning), 72 hours (incident notification) and one month (final report), see Cybersecurity Act Incident Reporting; a personal data breach goes to the Dutch Data Protection Authority within 72 hours where feasible under the AVG (GDPR)
6. Practise - a tabletop exercise tests whether IT, OT and management know the procedure
7. Measure and improve - review every major incident and track a few KPIs

Common metrics are MTTA (mean time to acknowledge a report), MTTR (mean time to restore), the percentage of incidents resolved within the SLA, the number of reopened tickets and the number of incidents per installation. Combined with MTBF, this shows whether an installation fails more often or is down for shorter periods. Smaller companies often outsource monitoring to a SOC or OT SOC, but the decision to shut down or restart an installation stays with the organisation itself.

❓ Frequently asked questions

What is the difference between an incident and an event?

An event is any observable occurrence, such as a log entry, login attempt or process alarm. An incident is an event that interrupts a service or process unexpectedly or reduces its quality. Incident Management therefore filters the genuine disruptions out of the large stream of events.

What is a major incident?

A major incident is an incident with such a large impact that it needs an immediate, coordinated response with a dedicated lead and its own communication line. Examples are a production line at a complete standstill or a failed SCADA system at a water treatment plant. Major incidents have shorter escalation paths and usually a mandatory review afterwards.

Is Incident Management the same as Incident Response?

Incident Management is the broad process for all disruptions, from a broken printer to a stopped machine. Incident response is the specialised handling of security incidents, where containment and preserving evidence come before fast restoration. In a mature organisation, Incident Management hands a suspected cyber incident straight over to the incident response team.

When must an incident be reported to a regulator?

An organisation covered by the Dutch Cybersecurity Act reports a significant incident with an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. If personal data is involved, the GDPR duty to notify the Dutch Data Protection Authority applies as well. Ordinary disruptions without significant impact do not need to be reported, but are still recorded internally.

Which KPIs belong to Incident Management?

The main KPIs for Incident Management are MTTA, MTTR, the percentage of incidents resolved within the agreed SLA and the number of reopened incidents. In OT environments, downtime per installation is often tracked as well. Together these figures show whether incident handling is becoming faster and more reliable.

Why is Incident Management harder in OT than in IT?

Incident Management in OT is harder because recovery actions directly affect a physical process, the safety of people and the environment. Restarting a server in IT is usually harmless, but restarting a PLC can disrupt a batch or an entire installation. That is why operations and engineering decide together, and a safe process state always comes before fast restoration.

📌 In summary

Incident Management provides a fixed, fast approach to every disruption, so that systems and production are running again with as little damage as possible. Distinguishing events, incidents, problems and security incidents, a clear priority matrix and sound agreements between IT, OT and vendors make the difference, especially now that the Dutch Cybersecurity Act imposes strict reporting deadlines.