Fyra regelverk, ett säkerhetssystem

Cyberresiliensförordningen, cybersäkerhetslagen, dataskyddsförordningen och AI-förordningen ställer krav på din verksamhet. Bygg ett säkerhetssystem som alla fyra beskriver från olika håll.

Bygger ni en lösning per regelverk får ni fyra riskanalyser, fyra incidentrutiner och fyra uppsättningar dokument som ska hållas i takt med varandra. Varje ändring i ett regelverk blir då fyra ändringar hos er. Bygger ni ett säkerhetssystem får ni en uppsättning artefakter där var och en svarar mot krav i flera regelverk, och ni kan visa vilka.

Den här sidan säger vad vart och ett träffar, var de går ihop, var de inte får slås samman, och vilken standard som bär vilken del.

Förvirringen börjar nästan alltid i objektet. Två av regelverken är produktlagstiftning och två riktar sig mot er som verksamhet.

Riskbedömningen

Alla fyra kräver en, och de kräver den av olika skäl. CRA artikel 13.2 kräver att bedömningen styr arbetet genom planerings-, utformnings-, utvecklings-, produktions-, leverans- och underhållsfaserna. NIS2 artikel 21.1 kräver åtgärder som står i proportion till risken, med beaktande av de senaste standarderna och genomförandekostnaderna. Dataskyddsförordningen artikel 35 kräver en konsekvensbedömning när en typ av behandling sannolikt leder till en hög risk för fysiska personers rättigheter och friheter. AI-förordningen artikel 9 kräver ett riskhanteringssystem som ska förstås som en kontinuerlig iterativ process som löper under hela livscykeln.

Objekten skiljer sig, disciplinen är densamma. Och samordningen är uttryckligen avsedd: från den 26 mars 2027 säger CRA artikel 13.4 i sin ändrade lydelse att cybersäkerhetsriskbedömningen får utgöra en del av riskbedömningen enligt en annan unionsakt.

Två av dem knyter dessutom bedömningen till driften. CRA låter fristerna börja vid kännedom, och kännedom är bevakningens utdata. AI-förordningen artikel 9.2 c kräver att ni utvärderar risker som framkommer ur data från övervakningen efter utsläppande på marknaden enligt artikel 72. Riskbedömningen är alltså inte färdig när produkten är levererad.

I metoden ligger den i preliminär riskanalys och systemriskanalys.

Informationsklassningen

Dataskyddsförordningen hör här. Personuppgifter är en tillgångstyp, och klassningen är det som gör dem synliga för resten av säkerhetssystemet. När klassningen är gjord följer skyddsåtgärderna av riskbedömningen, och frågan om en konsekvensbedömning behövs blir något ni kan svara på i stället för en utredning för sig.

Inbyggt dataskydd möter dessutom CRA redan i konstruktionen. Bilaga I del I led e kräver skydd av konfidentialiteten för lagrade, överförda och behandlade uppgifter, och led g att produkten endast behandlar uppgifter som är adekvata, relevanta och begränsade till vad som är nödvändigt för det avsedda syftet. Det är uppgiftsminimering, skriven som ett produktkrav.

Incidentrapporteringen

Upptäckten och utredningen är gemensam. Fristerna är det inte.

Två av regelverken delar klocka. CRA artikel 14 är byggd på NIS2 artikel 23 och har samma arkitektur: tidig varning utan onödigt dröjsmål och senast tjugofyra timmar från kännedom, anmälan inom sjuttiotvå timmar, delrapport på begäran och slutrapport inom en månad efter sjuttiotvåtimmarsanmälan. Slutrapportens innehåll är nästan ordagrant detsamma, inklusive kravet att ange den typ av hot eller grundorsak som sannolikt utlöste incidenten.

De två andra går i egen takt. Dataskyddsförordningen artikel 33 ger sjuttiotvå timmar till Integritetsskyddsmyndigheten utan tidig varning, och anmälan ska göras såvida det inte är osannolikt att incidenten medför en risk för fysiska personers rättigheter och friheter. Den tillåter dessutom en sen anmälan om den åtföljs av en motivering till förseningen, och den ventilen finns varken i CRA eller i NIS2. AI-förordningen artikel 73 ligger längst bort: femton dagar från kännedom, tio dagar om en person har avlidit, två dagar vid en utbredd överträdelse, och rapporten går till marknadskontrollmyndigheterna i de medlemsstater där incidenten inträffade.

Ni behöver alltså en tidslinje för de två första och flera bedömningar av samma händelse. Trösklarna mäts på fyra olika sätt, och det är där arbetet ligger. NIS2 mäter konsekvensen för verksamheten, CRA mäter produktens förmåga att skydda sina egenskaper, dataskyddsförordningen mäter risken för de registrerade, och AI-förordningen mäter orsakssambandet mellan systemet och skadan.

Dokumentationen

CRA artikel 31.3 kräver redan i dag en enda uppsättning teknisk dokumentation för produkter enligt artikel 12 som även omfattas av andra unionsakter med dokumentationskrav. Från den 26 mars 2027 utvidgas den bestämmelsen. Samma princip gäller uppåt i metoden: en kontextanalys, en policystruktur och ett bevis, inte en uppsättning per regelverk.

Programvaruförteckningen hör i säkerhetsbeviset, eftersom det är där den används som underlag för ett argument och inte bara förvaras som en fil.

Leveranskedjan

CRA artikel 13.5 kräver tillbörlig aktsamhet när ni integrerar komponenter från tredje part. NIS2 artikel 21.2 d kräver säkerhet i leveranskedjan. Dataskyddsförordningen artikel 28 kräver att ni bara anlitar personuppgiftsbiträden som ger tillräckliga garantier. En och samma leverantörsbedömning kan bära alla tre om den ställer frågorna i rätt ordning: vad komponenten gör, hur den underhålls, och vem som står bakom den.

Det sista ledet är inte en artighet. CRA skäl 58 säger att beroende av leverantörer med hög risk kan utgöra en strategisk risk, att riskerna hänger samman med leverantörens jurisdiktion, ägarförhållanden och kopplingar till ett tredjelands regering, och att myndigheterna ska beakta icke-tekniska riskfaktorer när de bedömer hur betydande en cybersäkerhetsrisk är.

Styrningen

CRA bilaga I del II riktar sig till tillverkaren och inte till produkten. Lydelsen är "Tillverkare av produkter med digitala element ska", följt av åtta punkter om sårbarhetshantering, provning, samordnat röjande och säker distribution. Det är ett ledningssystemkrav. NIS2 artikel 20 lägger ansvaret på ledningsorganet, dataskyddsförordningen artikel 24 lägger det på den personuppgiftsansvarige, med åtgärder som ska ses över och uppdateras vid behov, och AI-förordningen kräver ett kvalitetsstyrningssystem.

Och en rutin återkommer i två av dem nästan ordagrant. CRA bilaga I del II punkt 3 kräver effektiva och regelbundna provningar och granskningar av produktens säkerhet. Dataskyddsförordningen artikel 32.1 d kräver ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten hos åtgärderna. Det är samma rutin med två adressater.

Fyra krav på styrning, en säkerhetspolicy med kapitel som pekas ut av kraven.

Det här avsnittet avgör om samordningen håller. Den som lovar ett system som löser allt brukar fela här.

CRA har ett spår som de andra saknar. Den aktivt utnyttjade sårbarheten är ingen incident. Den har egna frister, med tidig varning inom tjugofyra timmar och slutrapport fjorton dagar efter att en korrigerande åtgärd finns tillgänglig. En incidentprocess som bara känner igen incidenter missar hela spåret.

Golvet och undantaget pekar åt olika håll. NIS2 artikel 21.2 räknar upp tio åtgärder som minst ska ingå, och det är ett obligatoriskt golv. CRA bilaga I del I punkt 2 är villkorad av riskbedömningen och kan uteslutas med motivering enligt artikel 13.4. Ni kan alltså inte fullgöra NIS2 genom att motivera bort en åtgärd, och inte CRA punkt 1 genom att bocka av en katalog.

Dataskyddsförordningen lägger till rättigheter. Registerutdrag, rättelse och radering är inte säkerhetsåtgärder, och inget säkerhetssystem hanterar dem. De hör i en annan process, och att dra in dem här gör båda sämre.

Efterlevnaden kontrolleras på två sätt. CRA och AI-förordningen kontrolleras genom marknadskontroll, som riktas mot produkten och kan börja med ett exemplar myndigheten själv köpt. Cybersäkerhetslagen och dataskyddsförordningen kontrolleras genom tillsyn, som riktas mot er och börjar hos er. Två regimer, olika befogenheter, och skillnaden försvinner lätt när man talar om efterlevnad i allmänhet.

Branschstandarderna för funktionssäkerhet, som ISO 26262 för fordon, IEC 61511 för processindustri och EN 50128 för järnväg, är specialiseringar av IEC 61508 och hör i samma spår.

Ingen standard fullgör punkt 1. Det är den viktigaste raden, och den står inte i tabellen. CRA bilaga I del I punkt 1 är målstyrd: produkter ska utformas, utvecklas och produceras på ett sådant sätt att de säkerställer en lämplig cybersäkerhetsnivå baserat på riskerna. Artikel 13.3 kräver dessutom att ni anger hur punkt 1 och del II tillämpas. Det är ett säkerhetsbevis i 61508:s mening, alltså ett argument om tillräcklighet som någon annan ska kunna granska.

AI-förordningen artikel 15.1 är byggd likadant. Ett AI-system med hög risk ska utformas och utvecklas så att det uppnår en lämplig nivå avseende riktighet, robusthet och cybersäkerhet och presterar väl i dessa avseenden under hela sin livscykel. Två av de fyra regelverken ställer alltså kravet som ett mål, och ett mål kan inte bockas av. Därför är beviset ett eget steg i metoden och inte en bilaga till de andra.

Processen har sex steg och ett fyrtiotal aktiviteter, och varje krav allokeras till ett processteg, ett policykapitel eller incidentprocessen. I dag är 252 krav allokerade: 85 befintliga, 143 förslag, 12 redan inlagda i modellen och 12 som är ISO-krav utan motsvarighet i den svenska föreskriften.

Sex steg, tre grupper. Tyngdpunkten ligger olika för olika regelverk, men stegen är desamma.

Leda och styra lägger grunden som alla fyra bygger på: kontexten som säger vad ni har och vem som ställer krav, den preliminära riskanalysen som pekar ut det kritiska, och säkerhetspolicyn där styrningen samlas.

Riskhantering är där produktkraven får sitt innehåll: systemriskanalysen, säkerhetskraven och säkerhetsbeviset.

Operativ säkerhet är där rapporteringsplikterna möts: omvärldsbevakning, incidenthantering och förbättring.

Hur arbetet går till steg för steg står i safety och security by design. Kraven i cyberresiliensförordningen står i CRA-artikeln, och de svenska kraven i cybersäkerhetslagen och MCFFS 2026:11.

Säkerheten är tredje pelaren i ramverket, där affärsmodellen och lagkraven är de yttersta kraven som allt annat ska kunna spåras till. Hur en lagtext blir krav i modellen, paragraf för paragraf, beskrivs under regelverk och lagar i arkitekturpelaren.