secria.eu

Incidentregistratie in de installatiebranche: wat legt u vast als het misgaat?

Een storing, een gestolen sleutel of een verkeerd account bij een klant: wat een installatiebedrijf vastlegt als er iets misgaat, en waarom dat meer is dan een foutmelding in een ticketsysteem.

Een incident in de installatiebranche is niet altijd een gehackte laptop. Het is net zo vaak een monteur die met een verkeerd account inlogt op het gebouwbeheersysteem van een klant, een sleutelkluis die niet goed is afgesloten, of een planningsmedewerker die op een phishinglink klikt waarna een klantwachtwoord is blootgesteld. Wat u vastlegt, is voor elk van die situaties in de kern hetzelfde: wanneer het is ontdekt, wat er precies is gebeurd, wie er bij betrokken was, welke toegang er in het geding was, welke actie is genomen en wie ervan op de hoogte is gebracht.

Die vastlegging is iets anders dan het melden bij een toezichthouder. Een intern incidentregister is een doorlopend logboek dat u zelf bijhoudt, ongeacht of een incident meldingsplichtig is. Voor organisaties die zelf onder de NIS2-richtlijn vallen, hoort dit register bij de zorgplicht uit artikel 21. Voor de veel grotere groep installatiebedrijven die niet zelf plichtig is maar wel als leverancier wordt beoordeeld, is het register vaak precies waar een securityvragenlijst van een opdrachtgever naar vraagt: kunt u laten zien dat u incidenten herkent, vastlegt en opvolgt? Of u zelf onder de wet valt of alleen via de keten wordt geraakt, kunt u nagaan met een paar vragen die uw positie in de keten laten zien.

Wat hoort er in het register

Een bruikbaar incidentregister bevat per gebeurtenis een datum en tijdstip van ontdekking, een korte beschrijving van wat er is gezien of gemeld, en de naam van degene die het heeft opgemerkt of gemeld. Daarnaast noteert u welk systeem, welke locatie of welke klant is geraakt, en welke toegang daarbij een rol speelde: een gedeeld wachtwoord, een fysieke sleutel, een toegangspas, een VPN-verbinding naar het netwerk van de klant. Vervolgens legt u vast welke actie is ondernomen, wie daarvoor verantwoordelijk was, en of en wanneer de klant of de eigen organisatie is geïnformeerd. Tot slot een regel over de afsluiting: is het incident opgelost, en is er iets veranderd naar aanleiding ervan.

Die laatste regel wordt vaak overgeslagen, terwijl toezichthouders en opdrachtgevers juist daarnaar kijken. Een register dat alleen meldingen optelt, zegt weinig. Een register waarin te zien is dat een terugkerend probleem heeft geleid tot een aanpassing in de werkwijze, laat zien dat de organisatie ervan leert.

De specifieke situatie van monteurs op locatie

Wat de installatiebranche onderscheidt van bijvoorbeeld een softwarebedrijf, is dat toegang zelden alleen digitaal is. Een monteur die bij een klant naar binnen moet, heeft vaak zowel een fysieke sleutel of pas als een digitaal account voor het gebouwbeheersysteem, het alarm of de klimaatinstallatie. Een incident kan dus ontstaan doordat een sleutel kwijtraakt, doordat een account van een oud-medewerker niet is ingetrokken, of doordat een laptop met opgeslagen inloggegevens uit een bus wordt gestolen. In het register maakt dat onderscheid niet zoveel uit: het gaat steeds om dezelfde vraag, namelijk wie op welk moment toegang had en of dat nog terecht was.

Dit raakt direct aan toegangsbeheer: wie mag bij welke systemen en sleutels, en is dat overzicht actueel. Een incidentregister zonder een lopend toegangsoverzicht is lastig compleet te krijgen, omdat u dan bij elk incident opnieuw moet uitzoeken wie waarbij mocht. Een lopend overzicht van maatregelen, statussen en eigenaren, zoals een cyber-dossier dat bijhoudt, maakt die uitzoekklus overbodig.

Niet elk voorval hoeft dezelfde behandeling

Materialiteit speelt ook hier: een verloren wachtwoordbriefje dat meteen is opgemerkt en gewijzigd, weegt anders dan een onbevoegd bezoek aan een klantsysteem dat pas na weken aan het licht komt. De richtlijn en de nationale wetgeving onderscheiden ernstige incidenten van kleinere voorvallen, en toezichthouders kijken daarbij naar de impact op de dienstverlening en op de klant. Een vast onderdeel van uw eigen beoordeling is dan ook: raakt dit incident alleen de eigen bedrijfsvoering, of ook de systemen of gegevens van een klant. Bij het laatste ligt een verplichting tot informeren van die klant al snel voor de hand, los van de vraag of er ook een wettelijke meldplicht geldt.

Welke termijnen en drempels daarbij precies gelden, verschilt per situatie en per land waarin u actief bent. Voor de exacte tekst en de vindplaats verwijzen wij naar de officiële bronnen, en voor de eigen situatie naar een jurist of de bevoegde toezichthouder. Een overzicht van hoe wij bronnen bijhouden en waar die vandaan komen, staat op de pagina waar onze werkwijze wordt uitgelegd.

Waar dit in de praktijk toe leidt

Een installatiebedrijf dat kan tonen hoe het incidenten vastlegt en opvolgt, geeft een opdrachtgever iets concreets in handen bij het beantwoorden van een securityvragenlijst, en heeft zelf een naslagwerk voor het moment dat het weer eens misgaat. Wie nog geen vaste vorm heeft voor dit register, vindt een startpunt en de bijbehorende uitleg bij het overzicht van onderwerpen per situatie, en veelgestelde vragen over wat wel en niet in zo'n register hoort staan verzameld op de pagina met antwoorden op terugkerende vragen.

Begin desgewenst met de gratis quick-scan: in een paar vragen ziet u of uw organisatie zelf onder de wet valt, via de keten wordt geraakt, of geen van beide, met een toelichting per uitkomst.

Dit artikel is algemene informatie en geen juridisch advies.