An incident registration in the metal and manufacturing industry describes at minimum four things: what happened, which systems were affected, who intervened and when the situation was back under control. That sounds straightforward, but in a production environment an additional layer comes into play: alongside office automation, control systems for machines, CNC equipment and production lines operate here, which often run on the same networks as office IT.
Whoever falls under the NIS2 due diligence obligation or is asked by a client to demonstrably show how incidents are handled cannot make do with a loose Excel file that only tracks IT outages. A production standstill caused by an encrypted server, a control cabinet that no longer responds, or a supplier who logs in remotely to a machine and inadvertently opens access: these are all events that belong in the same registration, even if the cause is not immediately clear.
Why this is more than a helpdesk ticket
Incident registration is one of the measures that flow from the due diligence obligation of the NIS2 Directive, for organizations that are themselves essential or important. For companies affected through a client, it is now also simply a question in the questionnaire: how do you record what happened, and can you demonstrate it. An overview of how this measure relates to the other obligations from the due diligence obligation can be found in the overview of all topics, with a short answer for each theme and the location in the official text.
The difference between a company that has this in order and a company that does not usually lies not in the technology. It lies in the habit of writing something down as soon as it happens, instead of reconstructing afterwards exactly what occurred.
Production systems require a different perspective
An office incident is relatively straightforward: a laptop, a mailbox, a shared drive. In the metal and manufacturing industry, production systems often run for years without anyone looking at them again, with access for the machine supplier, a maintenance company or a technical service provider who monitors remotely. This sometimes makes it difficult to distinguish between a fault and a security incident at the moment it happens: is a line down due to wear, a faulty update, or because someone has gained unauthorized access.
This is precisely why it is useful to have a separate field in the registration for the type of system: office automation, a production system connected to the company network, or a system managed remotely by a third party. This categorization helps not only with the analysis afterwards, but also with answering the question that a client often asks: how is your production environment separated from your office IT.
What must minimally be in the registration
A useful registration describes the moment when the incident was noticed and by whom, a brief description of what was observed, which systems or production lines were actually affected, which steps were taken to limit the damage, and the moment when normal operations were restored. This also includes a brief conclusion: was this a security incident, a technical fault, or did it remain unclear what the cause was. That last category may well exist; not every incident can be explained within a day, and an honest registration states that too.
The difference between recording and reporting
Recording is different from reporting. Organizations that are themselves essential or important under the NIS2 Directive face a reporting obligation to their competent authority, with timeframes set out in the legislation itself. For the precise timeframes and the manner of reporting, we refer you to the official text and to the competent authority in your country; this is deliberately not an assessment we make here. Those affected through the supply chain typically have no statutory reporting obligation, but often a contractual agreement with the contracting entity to report incidents within an agreed timeframe. Good record-keeping is the starting point in both cases: without documentation, there is nothing to fall back on when someone asks for an explanation.
Who manages this in your organization
In many installation and manufacturing companies, responsibility for production systems rests with production management, while the IT manager focuses primarily on office automation. This makes it important to determine in advance who owns the incident record as a whole, and who is called first in a specific incident. A record kept in two separate systems, one for IT and one for production, creates delays at the moment it matters most.
What secria does and does not do for you
Secria helps you set up the dossier in which this record has a fixed place, with a status, supporting documentation and an owner for each measure, and with prepared texts for when a report is needed. What we do not do is resolve the incident itself: no incident response, no SOC, no forensic investigation. That remains specialized work, and we prepare so that when the time comes, you do not start from scratch. Learn more about how we obtain our information and what sources we use on the page about how it works. The cost of the dossier and templates is listed on the pricing page.
Do you first want to know whether and how your organization fits into this picture, as an essential or important entity or as a supply chain-affected supplier? Take the free NIS2 check and see in a few questions where you stand, or continue reading in the knowledge base for more background on this topic.