När kraven på cybersäkerhetsrapportering ökar behöver svenska IT-leverantörer samtidigt bli bättre på att skilja mellan sårbarheter, säkerhetsincidenter och personuppgiftsincidenter. Annars riskerar ökad transparens att leda till onödiga krisorganisationer hos både leverantör och kund.
För CIO, CISO och DPO är detta en central insikt: NIS2 kräver mer och tidigare informationsdelning – men inte att varje säkerhetshändelse hanteras som en personuppgiftsincident. Rätt klassificering och tydliga eskaleringsspår gör incidenthanteringen mer träffsäker, minskar onödig akuthantering och stärker både kundförtroende och operativ skalbarhet. Lästid: cirka 5 minuter.
NIS2 och den nya cybersäkerhetsregleringen förändrar inte bara vilka säkerhetsincidenter som behöver hanteras. Den förändrar också hur mycket och hur tidigt information behöver kunna delas mellan leverantörer, kunder och andra aktörer i leveranskedjan.
För CIO:er och CISO:er innebär det en praktisk utmaning.
En leverantör vill kunna informera en kund tidigt om en teknisk sårbarhet eller säkerhetshändelse. Kunden kan behöva informationen för sin egen riskhantering eller för att bedöma sina skyldigheter enligt NIS2. Men samma information kan hos mottagaren snabbt hamna hos dataskyddsombud, jurister och incidentorganisation och uppfattas som en rapporterad personuppgiftsincident enligt GDPR.
Resultatet kan bli att en relativt begränsad säkerhetshändelse omedelbart aktiverar den mest resursintensiva incidentprocess organisationerna har: möten på ledningsnivå, GDPR-bedömningar, krav på omfattande informationspaket, diskussioner om anmälan till IMY och frågor om kommunikation till registrerade.
Det är varken en effektiv eller hållbar modell. Problemet bör därför inte lösas genom att organisationer delar mindre information. Lösningen är att klassificera information bättre och låta olika regulatoriska trösklar löpa parallellt.
En säkerhetshändelse är inte automatiskt en personuppgiftsincident
GDPR och NIS2 angriper delvis samma verklighet från olika håll.
En personuppgiftsincident enligt GDPR förutsätter en säkerhetsincident som leder till oavsiktlig eller olaglig förstöring, förlust eller ändring av personuppgifter eller till obehörigt röjande av eller obehörig åtkomst till sådana uppgifter.
Cybersäkerhetsregleringen har ett bredare perspektiv. Där är även tjänstens tillgänglighet, autenticitet, riktighet och konfidentialitet centrala.
Därtill kommer sårbarheter. En sårbarhet kan vara viktig att identifiera, åtgärda och i vissa sammanhang kommunicera utan att den har exploaterats och utan att någon incident över huvud taget har inträffat.
En modern incidentmodell behöver därför åtminstone skilja mellan:
Sårbarhet → en svaghet eller brist som skulle kunna utnyttjas.
Säkerhetsincident → en faktisk händelse som påverkar eller äventyrar tjänstens eller informationens säkerhet.
Betydande säkerhetsincident → en incident som når den relevanta högre tröskeln enligt tillämplig cybersäkerhetsreglering.
Personuppgiftsincident → en incident som uppfyller den särskilda definitionen i artikel 4.12 GDPR.
Dessa kategorier kan överlappa. Men de är inte synonymer.
Det är den distinktionen som behöver genomsyra både incidentprocessen och avtalen.
Transparens får inte bli en automatisk eskaleringsmekanism
Det finns annars en olycklig incitamentsstruktur.
Om varje tidig säkerhetsnotis möts av samma krav som en konstaterad personuppgiftsincident lär sig organisationen snabbt att tidig transparens är dyr.
Det är precis motsatt beteende mot vad en modern cybersäkerhetsregim bör främja.
En leverantör ska kunna säga:
Vi har identifierat en sårbarhet. Vi utreder och åtgärdar den. Vi har i nuläget inte identifierat att den har exploaterats eller påverkat personuppgifter.
Eller:
Vi utreder en säkerhetsincident som påverkar tjänsten. Påverkan på personuppgifter är ännu inte identifierad.
Det är värdefull säkerhetsinformation. Men inget av uttalandena bör i sig läsas som:
Vi har konstaterat en personuppgiftsincident enligt GDPR.
För att detta ska fungera behöver organisationerna införa en uttrycklig non-equivalence principle: rapporteringen av en sårbarhet eller säkerhetsincident innebär inte i sig att en personuppgiftsincident har konstaterats.
Ett event – flera regulatoriska bedömningar
Den effektiva modellen är inte att bygga separata incidentorganisationer för GDPR, NIS2, kundavtal och teknisk incidenthantering.
Organisationen bör ha ett incident management-system men flera regulatoriska klassificeringar.
En och samma händelse kan därför utvecklas ungefär så här:
T0 – tekniskt fynd:
En potentiell sårbarhet identifieras. Den hanteras inom ordinarie vulnerability management.
T1 – verifierad säkerhetshändelse:
Utredningen visar faktisk påverkan på tjänsten. Händelsen omklassificeras till säkerhetsincident.
T2 – regulatorisk bedömning:
Incidentens omfattning innebär att den når relevant tröskel för NIS2-relaterad rapportering eller kundinformation.
T3 – personuppgiftspåverkan konstateras:
Utredningen visar exempelvis obehörig åtkomst till personuppgifter. Först då aktiveras personuppgiftsincidentsspåret enligt GDPR.
I andra fall stannar processen vid T0, T1 eller T2.
Det är inte en brist i incidenthanteringen. Det är korrekt klassificering.
”Ett meddelande, korrekt addresserat”
Samma princip bör användas externt.
Om en händelse berör flera regelverk finns normalt inget egenvärde i att kunden får tre parallella e-postflöden från samma leverantör. Ett samordnat informationsflöde är ofta bättre.
Men varje underrättelse bör tydligt ange vad leverantören faktiskt rapporterar vid den aktuella tidpunkten.
En praktisk incidentmall kan exempelvis inledas med:
Classification at time of notice
- Vulnerability
- Security Incident
- Significant Security Incident
- Personal Data Breach – GDPR Article 4(12)
- Assessment ongoing – no Personal Data Breach established at this stage
Därefter bör personuppgiftspåverkan klassificeras separat:
Personal data impact: Confirmed / Not identified / Under investigation.
Den sista distinktionen är viktig.
”Under investigation” betyder inte ”suspected personal data breach”.
Det betyder att utredningen ännu inte ger ett tillräckligt faktaunderlag för slutsatsen.
Klassificeringen är heller inte statisk. Ny teknisk information kan innebära att den behöver ändras. Incidentprocessen ska därför stödja successiv omklassificering utan att den tidigare, korrekta klassificeringen betraktas som ett fel.
Lägg inte samma klocka på GDPR och NIS2
En annan vanlig källa till problem är att avtalen försöker lösa alla incidentregimer med samma notifieringsfrist.
Det bör undvikas.
För personuppgiftsbiträden innehåller GDPR redan den centrala tröskeln: när biträdet får vetskap om en personuppgiftsincident ska den personuppgiftsansvarige underrättas utan onödigt dröjsmål.
Det finns normalt ingen anledning att ersätta detta med en generell avtalsregel som exempelvis säger ”alla incidenter inom 24 timmar”.
Cybersäkerhetsspåret kan samtidigt kräva ett snabbare och mer stegvis informationsflöde. En tidig varning kan behöva lämnas innan en fullständig teknisk utredning är möjlig.
Just därför är separationen viktig.
Tidigare information behöver inte innebära en tidigare GDPR-klassificering.
Organisationen kan kommunicera vad den faktiskt vet om en säkerhetsincident och samtidigt ange att någon personuppgiftsincident ännu inte har konstaterats.
Börja redan vid vulnerability management
Även sårbarheter behöver en egen plats i modellen.
Att en penetrationstestare, säkerhetsforskare, kund eller intern scanner identifierar en sårbarhet betyder inte att sårbarheten har exploaterats. Det betyder ännu mindre att personuppgifter har röjts.
Organisationens process bör därför skilja mellan:
finding → verified vulnerability → exploited vulnerability/security incident → confirmed personal-data impact.
Det betyder inte att sårbarheter ska bagatelliseras. Tvärtom kan en kritisk sårbarhet kräva omedelbar teknisk åtgärd.
Men teknisk severity och regulatorisk klassificering är två olika dimensioner.
En CVSS-kritisk sårbarhet utan exploatering kan kräva en intensiv patchprocess men ingen GDPR-incidentprocess. En tekniskt begränsad händelse där personuppgifter faktiskt skickats till fel mottagare kan däremot vara en personuppgiftsincident.
En mogen organisation måste kunna hålla båda tankarna samtidigt.
DPA:t behöver stödja incidentmodellen
Det räcker därför inte att CISO bygger en bra runbook om företagets personuppgiftsbiträdesavtal fortfarande säger att kunden ska underrättas om varje ”security incident” enligt en enda odifferentierad process.
Avtalen och den operativa incidenthanteringen behöver tala samma språk.
Ett modernt biträdesavtal (DPA) bör därför ha separata bestämmelser för:
- säkerhetsåtgärder,
- sårbarhetshantering,
- säkerhetsincidenter,
- betydande incidenter och NIS2-relaterad informationsdelning,
- personuppgiftsincidenter,
- klassificering och samordnad notifiering, och
- regulatoriskt bistånd till kunden.
En särskilt viktig avtalsregel är att en underrättelse om en sårbarhet eller säkerhetsincident inte i sig innebär ett konstaterande av personuppgiftsincident, obehörig åtkomst till personuppgifter eller annan personuppgiftspåverkan.
Leverantören bör samtidigt åta sig att klassificera informationen utifrån vad som är känt vid tidpunkten och uppdatera klassificeringen när utredningen utvecklas.
Det skapar inte en möjlighet att ”avtala bort” GDPR. Om artikel 4.12-tröskeln faktiskt är uppfylld gäller GDPR-processen fullt ut.
Det skapar däremot ett gemensamt språk för perioden innan man vet det.
Den resursintensiva akutfasen ska reserveras för rätt händelser
Det finns också en ren managementfråga här.
En full incidentorganisation är dyr. Säkerhet, IT, produkt, legal, DPO, kommunikation och ledning kan snabbt involveras. Hos en SaaS-leverantör med många kunder multipliceras belastningen dessutom när varje kund aktiverar sin egen incidentorganisation och skickar separata frågebatterier.
Det är motiverat när händelsen kräver det.
Det är dålig resursstyrning när samma apparat aktiveras för varje vulnerability advisory eller tidig NIS2-relaterad informationsdelning.
Målet bör därför inte vara lägre incidentberedskap, utan bättre triage:
Vulnerability
→ vulnerability management.
Security/NIS2 incident
→ security incident management, regulatorisk bedömning och relevant informationsdelning.
Personal Data Breach
→ GDPR-spåret aktiveras och personuppgiftsansvariga får det underlag de behöver för sina skyldigheter enligt artiklarna 33 och 34.
Vid en allvarlig händelse kan samtliga tre spår naturligtvis vara aktiva samtidigt.
NIS2 bör leda till mer och inte mindre transparens
Det finns en större poäng bakom modellen.
NIS2 och den bredare utvecklingen inom cybersäkerhetsregleringen innebär att leverantörer behöver bli bättre på att dela relevant säkerhetsinformation med sina kunder. Om organisationernas avtal och processer inte samtidigt moderniseras finns risken att varje sådan informationsdelning behandlas som ett möjligt GDPR-larm.
Det skapar brus, binder specialistresurser och kan i förlängningen göra leverantörer mer försiktiga med tidig informationsdelning.
Den bättre modellen är den motsatta:
Dela information tidigt. Klassificera den tydligt. Eskalera när fakta motiverar det.
För CIO och CISO innebär det att NIS2-anpassningen inte bör begränsas till rapporteringstider, SOC-processer och nya säkerhetskontroller. Se samtidigt över DPA, kundavtal, incidentmallar och interna eskaleringsregler.
Det är först när dessa delar använder samma taxonomi som organisationen kan vara både transparent mot kunder och disciplinerad i sin incidenthantering.
Är er incidentmodell anpassad för den nya verkligheten?
NIS2-anpassning handlar inte bara om nya rapporteringsfrister. Incidentklassificering, DPA/PUB-avtal, kundkommunikation och interna eskaleringsrutiner behöver fungera tillsammans. Annars finns en risk att ökad säkerhetstransparens i praktiken leder till fler onödiga GDPR-eskaleringar och en incidentorganisation som går upp i akutfas för ofta.
Kontakta oss om ni vill stämma av er nuvarande modell. Vi hjälper teknikbolag att granska och optimera gränssnittet mellan NIS2, GDPR, kundavtal och den operativa incidenthanteringen – med fokus på en modell som fungerar när en incident faktiskt inträffar.