Fem regelverk, ett problem: hur GDPR, NIS2, DORA, CRA och AI Act faktiskt hänger ihop
En vägledning för svenska aktiebolag som försöker förstå var de står i det nya EU-regulatoriska landskapet
Få frågor skapar lika mycket onödig förvirring i svenska företagsledningar just nu som denna: vilka regelverk gäller egentligen för oss, och hur förhåller de sig till varandra? Diskussionen tenderar att bli en uppräkning av förkortningar, GDPR, NIS2 (Cybersäkerhetslagen i sin svenska form), DORA, CRA, AI Act, utan att någon förklarar den underliggande logiken som binder ihop dem. Det är synd, eftersom logiken faktiskt finns. När man väl ser den blir landskapet betydligt mindre skrämmande, och compliance-arbetet betydligt mer effektivt.
Den här texten är ett försök att rita upp den kartan. Den är inte en sammanfattning av de fem regelverken, sådana finns det gott om. Den handlar i stället om hur de skiljer sig från varandra strukturellt, var de överlappar, och vad det får för praktiska konsekvenser för ett svenskt aktiebolag som omfattas av flera samtidigt.
Den första insikten: regelverken reglerar olika saker
Det första som måste sägas är att de fem regelverken inte är fem versioner av samma sak. De reglerar fundamentalt olika objekt, och det är där all begreppslig klarhet börjar.
GDPR reglerar personuppgifter. Skyddsobjektet är den enskilda individens dataintegritet. Den utlöses så snart personuppgifter behandlas, oavsett bransch eller systemtyp.
NIS2, som i Sverige genomförs genom Cybersäkerhetslagen och tillhörande föreskrifter, reglerar organisationer. Närmare bestämt deras cybersäkerhetsstyrning. Den utlöses av att verksamheten är en väsentlig eller viktig entitet i en kritisk sektor.
DORA reglerar finanssektorn. Den är en sektorspecifik regim för digital operativ motståndskraft hos finansiella entiteter och deras kritiska IT-leverantörer.
CRA reglerar produkter. Inte organisationer, inte personuppgifter, utan själva produkten med digitala element som sätts på EU-marknaden. Det är en tillverkarregim.
AI Act reglerar AI-system. Klassificerade efter risk, från förbjudna till minimal risk. Den är i grunden horisontell och inte sektorsbunden, även om hög-risk-kategoriseringen i Annex III i praktiken aktiveras genom specifika användningsområden som ofta är sektorskopplade.
Detta är inte semantik. Skillnaden i regleringsobjekt avgör allt det praktiska som följer, vem som är skyldig att göra vad, vilken myndighet som är behörig, vilka tidsfönster som gäller, och var ansvaret hamnar i en händelse. En företagsledning som inte har internaliserat den här skillnaden kommer återkommande att hamna i fel diskussion. “Är vi inte redan GDPR-compliant, räcker det inte?” Nej, eftersom GDPR och NIS2 inte handlar om samma sak. “Vi är inte en bank, så DORA gäller inte oss.” Möjligen sant, men ni kanske är en kritisk IT-leverantör till en bank, vilket utlöser DORA på en helt annan grund.
Den andra insikten: tillverkare, organisationer och AI-system kan vara samma bolag
Eftersom regimerna reglerar olika objekt kan ett och samma företag träffas av flera samtidigt. Inte för att lagstiftaren är överambitiös, utan för att bolaget faktiskt är flera saker på en gång.
Ett konkret exempel. Tänk ett svenskt SaaS-bolag som säljer en HR-analysprodukt med inbyggd AI-funktion till sjukvårdssektorn. Vad gäller? GDPR gäller, eftersom produkten behandlar personuppgifter om anställda. Cybersäkerhetslagen kan gälla, om bolagets egen organisation kvalificerar som ICT-tjänsteleverantör, eller om kunderna är väsentliga entiteter och bolaget är en relevant tredje part. CRA kan gälla beroende på hur tjänsten är konstruerad. Räckvidden för moln- och SaaS-tjänster är fortfarande föremål för tolkning, men en SaaS-lösning som tillhandahåller fjärrdatabehandling integrerad i en produkt kan falla inom regimens tillämpningsområde, och i takt med att kommissionsvägledningen utvecklas bör varje SaaS-leverantör göra en egen bedömning. AI Act kan gälla, eftersom AI-funktionen kan klassificeras som högrisk då HR-analys faller inom Annex III. DORA gäller inte direkt, men om kunderna inkluderar finansiella entiteter och bolaget bedöms som en kritisk IT-tredjepartsleverantör, då också DORA.
Det här är inte ett konstruerat undantagsfall. Det är vad en normal, växande svensk tech-leverantör kan se framför sig om några år. Att förstå att regimerna stackar, inte ersätter varandra, är en av de viktigaste praktiska insikterna i hela det nya landskapet.
Den tredje insikten: regelverken speglar samma underliggande problem från olika håll
Det är frestande att se de fem regelverken som ett virrvarr. Men de följer faktiskt en sammanhängande logik som är värd att förstå.
EU-lagstiftaren har under det senaste decenniet stegvis byggt ut ett cyber- och digitalregulatoriskt ekosystem. Varje regim adresserar en specifik lucka i föregående. GDPR från 2018 reglerade hur organisationer hanterar personuppgifter, men sa lite om operationell motståndskraft eller om de produkter som behandlade uppgifterna. NIS2, från 2023 och i Sverige från 2026, fyllde ett av dessa hål genom att adressera organisationers cybersäkerhetsstyrning i kritiska sektorer. Men NIS2 reglerar inte specifikt finanssektorn, och inte produkterna i sig. DORA, tillämplig från januari 2025, tog hand om finanssektorn där den unika kombinationen av systemrisk och teknikberoende motiverade en egen, mer detaljerad regim. CRA, tillämplig från december 2027, adresserar det kvarvarande hålet, nämligen produkterna själva. Tidigare bar användarorganisationerna ansvaret för cybersäkerhet hos produkter de inte hade byggt, en strukturell asymmetri som CRA är designad att korrigera genom att flytta ansvaret tillbaka till tillverkarna. AI Act, gradvis tillämplig 2025 till 2027, reglerar slutligen en specifik klass av system där traditionella regelverk inte räcker eftersom AI-system ofta är probabilistiska, svåra att förutse fullt ut, och i vissa fall adaptiva över tid.
Sett så här är det inte fem konkurrerande regimer utan fem komplement. Varje regim löser ett problem som de tidigare lämnade öppet. Det betyder också att de är designade för att stacka, inte för att ersätta varandra. Det är därför en organisation kan vara skyldig att rapportera samma incident under flera regimer parallellt. Regimerna ser olika aspekter av samma händelse.
Den fjärde insikten: var regimerna faktiskt överlappar
Detta är där det praktiska arbetet sker. Överlapp betyder dubbelt arbete om man hanterar regimerna i silo, men det betyder också möjlighet till integrerad compliance om man hanterar dem genomtänkt.
Incidentrapportering är den mest synliga överlappspunkten. En enda allvarlig incident, säg ett ransomware-angrepp på ett bolag som behandlar personuppgifter i en kritisk sektor, kan utlösa upp till fyra parallella rapporteringsskyldigheter med olika tidsfönster och olika mottagare. GDPR kräver anmälan inom 72 timmar till Integritetsskyddsmyndigheten. NIS2 och Cybersäkerhetslagen kräver tidig varning inom 24 timmar och en mer fullständig anmälan inom 72 timmar, med en central intagsfunktion hos Myndigheten för civilt försvar (MCF) som koordinerar och vidarebefordrar till respektive sektors tillsynsmyndighet, exempelvis PTS, Energimyndigheten, Livsmedelsverket, IMY eller Transportstyrelsen. För finansiella entiteter går rapporten i stället direkt via Finansinspektionen, som är tillsynsmyndighet både under Cybersäkerhetslagen och under DORA. CRA, för tillverkare, kräver rapportering inom 24 till 72 timmar till EU:s gemensamma rapporteringsplattform via den nationella CSIRT-koordinatorn, vilket för svenska tillverkare är CERT-SE. AI Act kräver rapportering av allvarliga incidenter med högrisksystem inom upp till 15 dagar till relevant nationell myndighet. Dessa skyldigheter ersätter inte varandra. De aktiveras parallellt, ofta utlösta av samma händelse, och med olika myndigheter som mottagare.
Riskhantering är den mest substansmässiga överlappspunkten. Alla fem regimer kräver riskbaserade angreppssätt. GDPR genom Article 32 och DPIA, NIS2 genom Article 21:s tio minimimått, DORA genom omfattande ICT-riskhanteringskrav, CRA genom essential requirements, och AI Act genom Article 9:s riskhanteringssystem för högrisksystem. Detta är inte en slump utan en designprincip, och det betyder att en gemensam riskhanteringsmetodik som identifierar och bedömer risk på ett konsekvent sätt kan tjäna flera regimer samtidigt.
Leverantörsstyrning är den ofta underskattade överlappspunkten. NIS2 kräver styrning av leverantörsrisker. CRA kräver hantering av komponenter och underleverantörer i produktens supply chain, inklusive SBOM. DORA kräver detaljerad styrning av kritiska IT-tredjepartsleverantörer. AI Act kräver styrning av GPAI-leverantörer och underleverantörer av AI-system. En organisation som bygger fem separata leverantörsregister gör ett misstag. En som bygger ett, klassificerat så att rätt regimkrav appliceras per leverantör, gör det rätt.
Ledningens ansvar är den mest underskattade överlappspunkten. NIS2 kräver styrelsens och ledningens aktiva engagemang. DORA gör samma sak för finanssektorn. AI Act lägger till krav på AI-kompetens hos personalen. GDPR förutsätter ansvarstagande på högsta nivå. Detta är inte fem olika styrningskrav, det är samma styrningskrav från fem håll, vilket innebär att en styrelse som tar cybersäkerhetsstyrning på allvar i grunden tillfredsställer ett brett spann av regimkrav på samma gång.
Den femte insikten: regimerna har olika rättskaraktär, vilket spelar roll
En subtil men praktiskt viktig poäng är att regimerna inte är juridiskt likadana, och det får följder för hur ett svenskt bolag ska tänka.
GDPR, DORA, CRA och AI Act är förordningar. De gäller direkt i Sverige utan nationell genomförandelagstiftning. Texten är densamma i alla EU-länder. Det innebär att ett svenskt bolag kan luta sig mot kommissionsvägledning, ENISA-material och harmoniserade standarder utan att behöva navigera 27 nationella implementationer.
NIS2 är ett direktiv. Det kräver nationell transponering, vilket Sverige har gjort genom Cybersäkerhetslagen, vars stödjande föreskrifter rullas ut stegvis under 2026. Det innebär att en svensk verksamhet inte står direkt under NIS2 utan under Cybersäkerhetslagen och dess föreskrifter. Och om bolaget verkar i flera EU-länder måste det förstå varje lands nationella genomförande separat.
Detta är inte en akademisk distinktion. Det påverkar var rättsosäkerheten ligger, störst för NIS2 just nu eftersom föreskriftspaketet inte är klart, vilken myndighet som är ytterst behörig, och hur bolaget ska följa rättsutvecklingen.
Det praktiska rådet: börja med en regimkarta, inte med en regim
Det vanligaste misstaget i svenskt compliance-arbete just nu är att ta regimerna en i taget, i den ordning de blir akuta. Bolag som hanterade GDPR-projekt 2017 till 2018 startar nu NIS2-projekt 2026, planerar CRA-projekt för 2027, och kommer någon gång att vakna upp inför AI Act. Varje projekt bemannas separat, dokumenteras separat, granskas separat.
Detta är inte fel, men det är ineffektivt, och det skapar dessutom inkonsekvens. När samma riskbedömning görs av tre olika team för tre olika regimer slutar de inte sällan med tre olika slutsatser om samma sak.
Den genomtänkta ansatsen ser annorlunda ut. Den börjar inte med en regim utan med en regimkarta för verksamheten. För varje affärsaktivitet, produkten, tjänsten, dataflödet, kundsegmentet, identifieras vilka regimer som träffar. Sedan designas compliance-arkitekturen så att överlappspunkterna exploateras. En gemensam riskhanteringsmetodik, en gemensam incidentrespons-runbook med multi-regim-output, ett integrerat leverantörsregister, en gemensam ledningsförankring.
Detta är arbete som kräver att någon har överblick över alla fem regimerna samtidigt, inte en GDPR-specialist, en NIS2-konsult och en AI Act-jurist som var och en arbetar i sin tunnel.
En kort observation om sekvensering
Det är värt att säga något om när arbetet bör göras, eftersom regimerna har olika ikraftträdandedatum.
GDPR är sedan länge i kraft. DORA tillämpas från januari 2025. Cybersäkerhetslagen har sitt anmälningssystem öppet sedan februari 2026, med föreskrifter som rullas ut stegvis under året. AI Act:s förbud gäller redan från februari 2025, men huvuddelen av högrisk-obligationerna tillämpas först från augusti 2026 för Annex III respektive augusti 2027 för Annex I. CRA tillämpas fullt ut från december 2027.
Den oerfarna instinkten är att jobba i kronologisk ordning, med fokus på det som börjar gälla först. Den bättre instinkten är att jobba i beroendeordning, att bygga den infrastruktur som tjänar flera regimer samtidigt, riskmetodik, incidentrespons, leverantörsregister, ledningsförankring, och först sedan addera de regimspecifika lagren ovanpå. Då blir CRA-arbetet 2027 inte ett separat projekt utan en påbyggnad på det som redan finns.
Avslutningsvis
De fem regelverken, GDPR, NIS2, DORA, CRA och AI Act, är inte fem separata problem. De är fem perspektiv på samma underliggande problem, hur ett digitaliserat samhälle ska skydda data, organisationer, finansiell stabilitet, produkter och AI-system samtidigt, med behållen ansvarsutkrävning.
För ett svenskt aktiebolag är det rätt sätt att möta det här landskapet inte att se det som en serie compliance-projekt utan som en sammanhängande styrningsfråga. Den frågan har inget enkelt svar, men den har en användbar utgångspunkt. Börja inte med en regim. Börja med att förstå vad ert företag är, vilka produkter ni säljer, vilka data ni behandlar, vilken sektor ni verkar i, vilken AI ni använder. Det avgör vilka regimer som träffar er. Det avgör hur de stackar. Och det avgör vilken compliance-arkitektur som faktiskt kommer att hålla.
Komplexiteten är reell, men den är inte slumpartad. Den följer en logik. Och när man väl ser den logiken är det svåra inte att förstå reglerna, det är att bygga en organisation som kan leva med dem under lång tid.