secria.eu

Incidentregistrering inom installationsbranschen: vad dokumenterar du när något går fel?

En störning, en stulen nyckel eller ett felaktigt konto hos en kund: vad ett installationsföretag dokumenterar när något går fel, och varför det är mer än en felrapport i ett ticketsystem.

En incident i installationsbranschen är inte alltid en hackad laptop. Det är lika ofta en montör som loggar in med ett felaktigt konto på en kunds byggnadsstyrningssystem, en nyckelskåp som inte är korrekt låst, eller en planeringsmedarbetare som klickar på en phishing-länk varefter ett kundlösenord exponeras. Det du dokumenterar är i grunden detsamma för var och en av dessa situationer: när det upptäcktes, vad exakt som hände, vilka som var inblandade, vilken åtkomst som var relevant, vilken åtgärd som vidtogs och vem som informerades.

Denna dokumentation skiljer sig från rapportering till en tillsynsmyndighet. Ett internt incidentregister är en löpande logg som du själv upprätthåller, oavsett om en incident är anmälningspliktig. För organisationer som själva faller under NIS2-direktivet hör detta register till omsorgsplikten enligt artikel 21. För den mycket större gruppen installationsföretag som inte själva är skyldiga men granskas som leverantörer, är registret ofta exakt vad en säkerhetsenkät från en uppdragsgivare frågar om: kan du visa att du identifierar, dokumenterar och följer upp incidenter? Oavsett om du själv faller under lagen eller endast påverkas via leverantörskedjan kan du kontrollera din position genom några frågor som visar din position i leverantörskedjan.

Vad ska registret innehålla

Ett användbart incidentregister innehåller per händelse ett datum och tid för upptäckt, en kort beskrivning av vad som observerades eller rapporterades, och namn på den person som märkte det eller rapporterade det. Dessutom noterar du vilket system, vilken plats eller vilken kund som påverkades, och vilken åtkomst som spelade en roll: ett delat lösenord, en fysisk nyckel, ett åtkomstkort, en VPN-anslutning till kundens nätverk. Sedan dokumenterar du vilken åtgärd som vidtogs, vem som var ansvarig för den, och om och när kunden eller den egna organisationen informerades. Slutligen en anteckning om avslutningen: är incidenten löst, och ändrades något till följd av den?

Den sista anteckningen utelämnas ofta, medan tillsynsmyndigheter och uppdragsgivare just tittar på den. Ett register som endast räknar rapporter säger lite. Ett register som visar att ett återkommande problem ledde till en förändring i arbetssätt visar att organisationen lär sig av det.

Montörers särskilda situation på plats

Det som skiljer installationsbranschen från till exempel ett mjukvaruföretag är att åtkomst sällan är endast digital. En montör som måste ta sig in till en kund har ofta både en fysisk nyckel eller kort och ett digitalt konto för byggnadsstyrningssystemet, larmet eller klimatanläggningen. En incident kan alltså uppstå genom att en nyckel försvinner, genom att ett konto för en tidigare anställd inte återkallades, eller genom att en laptop med sparade inloggningsuppgifter stjäls från en bil. I registret spelar den skillnaden ingen större roll: det handlar varje gång om samma fråga, nämligen vem som hade åtkomst när och om det fortfarande var berättigat.

Detta påverkar direkt åtkomsthanteringen: vem får tillgång till vilka system och nycklar, och är denna överblick aktuell. Ett incidentregister utan en löpande åtkomstöversikt är svårt att hålla fullständigt, eftersom du då måste utreda på nytt för varje incident vem som fick vara var. En löpande överblick över åtgärder, status och ansvariga, som ett cybersäkerhetsdossier upprätthåller, eliminerar detta utredningsarbete.

Inte varje förekomst behöver samma hantering

Väsentlighet spelar även här en roll: ett förlorat lösenordsmeddelande som omedelbar upptäcktes och ändrades väger annorlunda än en obehörig åtkomst till ett kundsystem som först uppdagades efter veckor. Direktivet och den nationella lagstiftningen skiljer mellan allvarliga incidenter och mindre händelser, och tillsynsmyndigheterna bedömer dessa utifrån påverkan på tjänsteleveransen och på kunden. En fast del av er egen bedömning är därför: påverkar denna incident endast er egen verksamhet, eller även kundens system eller data. I det senare fallet föreligger ofta en skyldighet att informera kunden, oberoende av frågan om det också finns en lagenlig anmälningsskyldighet.

Vilka tidsfrister och gränsvärden som gäller varierar beroende på situation och i vilket land ni är verksamma. För den exakta texten och källan hänvisar vi till de officiella källorna, och för er specifika situation till en jurist eller tillsynsmyndigheten. En översikt över hur vi hanterar källor och var de kommer från finns på sidan där vår arbetssätt förklaras.

Vilka praktiska konsekvenser detta får

Ett installationsföretag som kan visa hur det registrerar och följer upp incidenter ger en uppdragsgivare något konkret i händerna när man besvarar en säkerhetsfrågelista, och har samtidigt en uppslagsverk för när det går snett igen. Den som ännu inte har en etablerad form för detta register hittar en startpunkt och tillhörande förklaringar på översikten över ämnen per situation, och vanliga frågor om vad som bör och inte bör ingå i ett sådant register är samlade på sidan med svar på återkommande frågor.

Börja gärna med den kostnadsfria snabbkontrollen: i några frågor ser ni om er organisation själv omfattas av lagen, påverkas via försörjningskedjan, eller inget av detta, med en förklaring för varje resultat.

Den här artikeln är allmän information och inte juridisk rådgivning.