Vad NIS2 faktiskt kräver av din service management-plattform

Blogginlägg

NIS2 är inte ett IT-projekt. Det är ett lagkrav.

Sedan cybersäkerhetslagen, som genomför stora delar av NIS2-direktivet, trädde i omfattas ett stort antal offentliga och privata verksamhetsutövare av krav på riskhantering, säkerhetsåtgärder och rapportering av betydande incidenter.

Problemet är att NIS2 ofta diskuteras på ett abstrakt plan: ”vi behöver bli compliant.” Vad det faktiskt kräver i praktiken, och vad det ställer för krav på de IT-system som ska stödja arbetet, är mer sällan genomlyst.

Vilka berörs av NIS2?

Cybersäkerhetslagen delar in berörda organisationer i väsentliga och viktiga verksamhetsutövare.

Om er organisation verkar inom något av följande områden är ni troligen NIS2-berörda:

Offentlig förvaltning: kommuner och regioner omfattas i sin helhet; för statliga myndigheter gäller undantag för flera kategorier — kontrollera om er myndighet explicit inkluderas
Hälso- och sjukvård
Digital infrastruktur och digitala tjänster: molntjänster, datacenter, managed services och managed security services — inte ”IT-tjänster” i bred mening
Energi, transport, vatten och avfall

OBS: Var och en ansvarar för att avgöra om cybersäkerhetslagen gäller för sin organisation. Den här artikeln ger en praktisk övergripanede orientering, inte juridisk rådgivning.

Vad lagen konkret kräver och vad det innebär för er plattform

Cybersäkerhetslagen anger ett antal kategorier av säkerhetsåtgärder. Nedan mappar vi ett urval mot vad det innebär i praktiken och vad er service management-plattform kan bidra med.

De två sista raderna (*) är inte uttryckliga krav men ger viktigt praktiskt stöd för att leva upp till övriga krav.

NIS2-krav	Vad det innebär	Vad det kräver av er plattform
Riskanalys och riskhantering	Dokumenterade processer för att identifiera, bedöma och hantera cybersäkerhetsrisker löpande.	Stöd för att skapa och följa upp riskärenden. Länkning mellan risker, tillgångar och åtgärder. Dokumenterbara beslut med revisionsspår.
Incidenthantering	Systematisk hantering av incidenter — klassificering, eskalering och rapportering av betydande incidenter till behörig myndighet inom fastlagda tidsfrister.	Strukturerat flöde för att logga, klassificera och eskalera incidenter. Tidsstämpling och revisionsspår. Möjlighet att sammanställa händelseförlopp som underlag för myndighetsrapportering.
Kontinuitet och krishantering	Planer och rutiner för att upprätthålla verksamheten vid störningar — inklusive backup och återställning av kritiska system.	Möjlighet att hantera och följa upp åtgärder vid driftstörningar. Dokumenterade rutiner tillgängliga och sökbara i systemet.
Säkerhet i leveranskedjan	Säkerhetsnivån hos leverantörer och tjänsteleverantörer ska bedömas och hanteras — inklusive mjukvara och digitala tjänster.	Hantering av leverantörsrelationer och avtal. Möjlighet att koppla krav och uppföljning till externa parter i systemet.
Säker systemutveckling och underhåll	Säkerhet ska beaktas vid anskaffning, utveckling och underhåll av nätverks- och informationssystem.	Ändringsflöde med godkännandesteg och dokumentation — stödjer strukturerade processer kring systemförändringar, även om ändringshantering i sig inte är ett uttryckligt lagkrav.
Utbildning och kompetens	Ledningen ska genomgå utbildning om cybersäkerhetsrisker och kravens innebörd (2 kap. 4 § Cybersäkerhetslagen). För personal ingår utbildning som en av de säkerhetsåtgärder som ska vidtas.	Möjlighet att logga och dokumentera utbildningsinsatser, hantera policydokument och knyta kompetenskrav till roller i systemet.
Åtkomstkontroll och tillgångsförvaltning	Principer för behörighetshantering (least privilege, MFA) och inventering av kritiska tillgångar.	Rollbaserad behörighetsstruktur. Loggning av inloggningar och åtgärder. Integration med AD/LDAP.
Ändringshantering*	* Inte ett explicit krav i lagstiftningen, men ett naturligt stöd för riskanalys och kontinuitetskrav. Förändringar i kritiska system bör planeras, godkännas och dokumenteras.	Ändringsflöde med godkännandesteg och revisionsspår — ett praktiskt verktyg för att hålla samman säkerhetsarbetet internt.
Tillgångsinventering/CMDB*	* Inte ett explicit krav i lagstiftningen, men ett nödvändigt underlag för riskanalys och leverantörshantering. Utan kontroll på vilka system och tillgångar som finns är det svårt att leva upp till övriga krav.	CMDB-funktion för att registrera, klassificera och underhålla information om systemkomponenter och IT-tillgångar. Ger kontextunderlag för risk- och incidenthantering.

Incidentrapportering: tre steg och fasta tidsfrister

En av de tydligaste skyldigheterna i lagen gäller rapportering av betydande incidenter. Med ”betydande incident” avses en incident som orsakar eller kan orsaka allvarlig driftsstörning, ekonomisk skada, eller som påverkar eller kan påverka andra verksamheter eller personer genom betydande skada.

Lagen anger tre steg med fasta tidsfrister. Stegen är: upplysning/tidig varning, incidentanmälan och slutrapport. Om incidenten pågår när tidsgränsen för slutrapporten löper ut ska i stället en lägesrapport lämnas. Rapportering sker till behörig myndighet.

Det här gör strukturerad incidenthantering, tidsstämpling och sammanställningsmöjligheter till viktiga praktiska stöd för att kunna rapportera inom tidsfristerna. Slutrapporten ska bl.a. täcka incidentens allvar och påverkan, sannolik grundorsak och hottyp, vidtagna åtgärder samt vid behov gränsöverskridande påverkan.

En service management-plattform med strukturerad incidenthantering ger er det flödet men kontrollera att ni faktiskt kan exportera och sammanställa händelseförlopp på ett sätt som fungerar som underlag för myndighetsrapportering.

Leverantörssäkerhet: en fråga som gäller er plattformleverantör

Lagen kräver att ni hanterar säkerhetsrisker i er leverantörskedja och det inkluderar leverantören av er service management-plattform.

Det är en fråga som inte alltid ställs, men som lagen gör obligatorisk: vilken säkerhetsnivå har leverantören av de system ni är beroende av?

Konkret innebär det att ni bör kunna besvara följande om er plattformleverantör:

Var lagras era data fysiskt, och under vilken jurisdiktion verkar leverantören och dess ägarbolag?
Vilken åtkomst har leverantörens personal och eventuella underbiträden till era data?
Vad gäller om leverantören drabbas av ett säkerhetsincident som påverkar er?
Har leverantören dokumenterade rutiner för incidenthantering och kontinuitet, och kan ni få ta del av dem?
Finns beroenden till icke-EU-lagstiftning som kan påverka er kontroll över data eller er driftskontinuitet?

En konkret riskfaktor att bedöma är CLOUD Act: om leverantören, eller dess moderbolag, är underkastat US CLOUD Act kan amerikanska myndigheter under vissa omständigheter begära ut data från leverantörens system, oavsett var datan fysiskt lagras.

Det är inte ett NIS2-krav att lagra data i Sverige, men det är en risk som bör vägas in proportionerligt mot era beroenden, avtal och kontinuitetsbehov. Easit GO driftas lokalt i kundens miljö eller i vårt svenska datacenter.

Vad ni ska fråga er nuvarande eller blivande plattformleverantör

Oavsett vilket system ni använder bör ni kunna ställa och få tydliga svar på dessa frågor:

Om dataplats och juridik

Var lagras våra data fysiskt?
Är ni eller ert moderbolag underkastat CLOUD Act eller motsvarande icke-EU-lagstiftning?
Har ni en DPA (Data Processing Agreement)?

Om incidenter och tillgänglighet

Vad är er tillgänglighet (SLA) och vad händer om ni bryter den?
Hur hanterar ni en säkerhetsincident i er plattform som påverkar oss?
Vilka rutiner finns för att informera oss vid intrång eller dataläcka?

Om funktionalitet för NIS2-efterlevnad

Har plattformen strukturerad incidenthantering med revisionsspår och exportmöjlighet?
Kan vi hantera riskärenden, tillgångsinventering (CMDB) och ändringsflöden i samma system?
Loggas åtkomst och åtgärder på ett sätt som kan utgöra underlag vid revision?
Stödjer plattformen rollbaserad behörighetshantering?

Om er egna kontroll

Kan vi konfigurera och förvalta systemet internt utan att vara beroende av er som leverantör?
Kan vi exportera all vår data om vi väljer att byta leverantör?

Cybersäkerhetslagen som en anledning att se över er plattform, inte bara er policy

Många organisationer har börjat sitt arbete med policies och riskanalyser. Det är rätt. Men nästa steg, att säkerställa att de system som ska stödja arbetet faktiskt klarar vad kraven kräver, är lika viktigt.

En service management-plattform som saknar strukturerad incidenthantering, stöd för riskhantering, åtkomstkontroll och revisionsspår gör compliance-arbetet svårare, inte lättare. Och en plattform med oklara ägarförhållanden eller diffusa svar på frågor om dataplats skapar risker som bör hanteras aktivt.

Det är inte ett argument för att välja Easit GO framför alternativ. Det är ett argument för att ställa rätt frågor till den leverantör ni har, och till dem ni utvärderar.

Vill ni gå igenom hur Easit GO stödjer ert NIS2-arbete? Vi visar gärna hur incidentflöden, CMDB, ändringshantering och revisionsspår fungerar i praktiken.

Boka en genomgång

Läs mer

Varför svenska kommuner väljer en europeisk plattform
Om GDPR, NIS2 och CLOUD Act — och vad du faktiskt bör fråga din leverantör vid upphandling.

Vad kan du faktiskt göra med Easit GO?
Genomgång av bredden, flexibiliteten, automationerna och integrationerna i plattformen.

Vad är en CMDB — och varför behöver ni en?
Konfigurationshantering som underlag för riskbedömning och tillgångsinventering.

Så fungerar plattformstänket i Easit GO
Hur en service management-plattform täcker behoven i hela organisationen — inte bara IT.