Event, issue, incident, attack: the word you choose has consequences

Every attack starts as one or more events. Most events are harmless. Some reveal a weakness. A few become incidents. Very few turn out to be confirmed attacks.

Four words, four meanings, four sets of consequences. Teams that use them interchangeably create problems that have nothing to do with the technical situation.

The four words

EVENT, “something happened.” Any observable activity on a system or a network: a login, a reboot, a patch, an alarm, a locked account. Thousands a day. An event is not a small incident. It is just something that occurred, and almost all of them are normal operation. The word is neutral. Use it freely.

ISSUE, “a door could be opened.” A weakness that has been found: an unpatched machine, a weak configuration, a missing control. It describes a state, not an activity. Nobody is doing anything. You remediate it (patch, close, reconfigure) and the risk goes away.

INCIDENT, “someone may have opened the door.” Evidence suggests a weakness is being exploited, or that malicious activity is under way. It is a suspicion, not a certainty, and it starts an investigation.

ATTACK, “the door was opened, and the attacker is inside.” Malicious activity is confirmed. Response starts at once, and any external communication follows the defined process.

Or, in four short sentences: Something happened. A door might be open. Someone may have opened it. The door is open and someone is inside.

One warning before this scale leaves the site. It is an internal working scale, not the law’s. Under the NIS 2 Directive an incident is an event compromising the availability, authenticity, integrity or confidentiality of data or services (Article 6(6)), and a near miss is one that could have done so but did not materialise (Article 6(5)). Becoming aware of a significant incident starts the 24-hour early warning (Article 23(3) and 23(4)). What this scale calls an incident — a suspicion — is not yet an incident in that sense, and what it calls an attack usually is. Write that correspondence into the glossary entry itself, or the scale that keeps a shift leader precise will make the notification late.

Most incidents are false positives, and that is good news

Most incidents never get past the incident stage. They turn out to be a maintenance job nobody announced, a new tool generating unfamiliar traffic, a misconfiguration.

That is the detection chain doing its job, not failing at it. A system that only ever raises confirmed attacks is not a sensitive system. It is one that misses things.

There is a management consequence. If “incidents closed as false positive” is tracked as a failure, people stop raising them. Under-reporting is the most expensive outcome on offer, and it is usually produced by a well-meant dashboard.

The asymmetry

This is why the choice of word is more than vocabulary.

Going from event to attack is easy. Walking back from attack to event is not.

Once “attack” is written in an email, a ticket, a bridge call or a message to a customer, it leaves the technical conversation. Account managers repeat it to customers. Insurers may treat it as a notification. Contracts may have clauses it triggers. Someone repeats it outside the company. And the correction sent three days later never travels as far as the first message.

Calling the organisation “attacked” when what you have is an unconfirmed incident creates confusion, reputational damage you did not need, and possible legal exposure, including towards customers and partners who acted on what you told them.

Hence the working rule: if in doubt, say EVENT. It is neutral, accurate at that moment, and commits you to nothing.

The limit of that rule

The rule has a limit, and it has to be written down or it becomes dangerous.

“If in doubt, say event” is a rule about accuracy. It is not a rule about playing things down.

Under NIS2, the 24-hour clock for the early warning starts when the organisation becomes aware of a significant incident (Article 23(4)), not when someone says the word “attack”. Facts and assessment start the clock; vocabulary does not. Picking a smaller word does not stop it. It only means the clock runs while nobody acts.

The two errors do not weigh the same in law either. Over-classifying is a communication problem: embarrassing, correctable. Under-classifying to avoid an obligation is a regulatory one, and that is the version that ends badly. A classification deliberately talked down, visible later in the ticket history, is far worse than a cautious escalation.

So: use the word that matches the evidence you have, upgrade it as evidence comes in, and never pick a word for its consequences.

Making it work in practice

Four habits turn this from a slide into behaviour.

• Write the four definitions into the incident response procedure, each with an example from your own site. A definition without a local example does not get used.
• Say who may use which word, and where. Anyone can report an event. Classifying it as an incident or an attack belongs to a defined function. External communication has one voice, always.
• Do not make the person who noticed carry the classification. An operator who sees an unexplained stop or an unfamiliar device should report what they saw, in plain words, and never have to decide whether it is an incident. If reporting needs a judgement they are not trained to make, they will not report.
• Watch the shorthand. “We got hit” in a chat channel becomes “they were attacked” at the next meeting. Informal language reaches formal channels faster than anyone expects.

Why it matters more on an industrial site

On a plant, the first signal is rarely a security alert. It is a line that stopped, a batch that failed, a controller that will not answer. Those are events, and most of the time they are exactly what they look like: equipment events. The PLC lost its I/O rack, the sensor cable was crushed by a forklift.

The discipline is to keep them as events while they are investigated, to escalate on evidence rather than on nerves, and to have a path that gets a real answer fast enough that the question does not sit open for three days. Picking the wrong word is rarely the real failure. Picking one and never coming back to it is.

“Attack” is not a label. It triggers response, notification, communication and liability. Use it when the evidence supports it, not before, and never avoid it when the evidence does.

References

• Directive (EU) 2022/2555 (NIS2), Article 23, reporting obligations: eur-lex.europa.eu.