An incident in the installation sector is not always a hacked laptop. It is just as often an installer logging in with the wrong account to a customer's building management system, a key safe that has not been properly secured, or a planning coordinator who clicks on a phishing link after which a customer password is exposed. What you record is fundamentally the same for each of those situations: when it was discovered, what exactly happened, who was involved, what access was at stake, what action was taken and who was informed.
That recording is different from reporting to a regulator. An internal incident register is an ongoing log that you maintain yourself, regardless of whether an incident is reportable. For organisations that themselves fall under the NIS2 Directive, this register is part of the due diligence obligation under Article 21. For the much larger group of installation companies that are not themselves subject to the rules but are assessed as suppliers, the register is often exactly what a security questionnaire from a client asks for: can you show that you identify, record and follow up on incidents? Whether you yourself are subject to the law or are only affected through the supply chain, you can determine your position with a few questions that show your position in the supply chain.
What belongs in the register
A usable incident register contains for each event a date and time of discovery, a brief description of what was observed or reported, and the name of the person who noticed or reported it. You also note which system, which location or which customer was affected, and what access played a role: a shared password, a physical key, an access card, a VPN connection to the customer's network. Next, you record what action was taken, who was responsible for it, and whether and when the customer or your own organisation was informed. Finally, a note on closure: has the incident been resolved, and has anything changed as a result.
That last note is often skipped, while regulators and clients look specifically at it. A register that only counts incidents says little. A register that shows how a recurring problem led to a change in working method demonstrates that the organisation learns from it.
The specific situation of installers on site
What distinguishes the installation sector from, for example, a software company, is that access is rarely only digital. An installer who needs to get into a customer's premises often has both a physical key or card and a digital account for the building management system, the alarm or the climate installation. An incident can therefore arise because a key is lost, because an account of a former employee has not been revoked, or because a laptop with stored login credentials is stolen from a van. In the register, that distinction does not make much difference: it is always the same question, namely who had access at what time and whether that was still justified.
This directly relates to access management: who is allowed to access which systems and keys, and is that overview current. An incident register without an ongoing access overview is difficult to complete, because you then have to find out for each incident who was allowed where. An ongoing overview of measures, statuses and owners, as maintained by a cyber dossier, makes that detective work unnecessary.
Not every incident needs the same treatment
Materiality applies here too: a lost password note that is immediately noticed and changed has a different weight than unauthorized access to a customer system that only comes to light weeks later. The directive and national legislation distinguish significant incidents from minor occurrences, and supervisors look at the impact on service delivery and on the customer. A fixed part of your own assessment is therefore: does this incident affect only your own business operations, or also the systems or data of a customer. In the latter case, an obligation to inform that customer is quickly in sight, regardless of whether there is also a statutory notification obligation.
Which exact deadlines and thresholds apply varies depending on the situation and the country in which you are active. For the exact text and the location, we refer you to the official sources, and for your own situation to a lawyer or the competent supervisory authority. An overview of how we maintain sources and where they come from is set out on the page that explains our working method.
What this leads to in practice
An installation company that can demonstrate how it records and follows up on incidents gives a client something concrete to work with when answering a security questionnaire, and has itself a reference work for when things go wrong again. Anyone who does not yet have a fixed format for this register will find a starting point and the associated explanation at the overview of topics per situation, and frequently asked questions about what should and should not be included in such a register are collected on the page with answers to recurring questions.
If you wish, start with the free quick-scan: in a few questions you will see whether your organization is itself subject to the law, is affected through the supply chain, or neither, with an explanation for each outcome.