Allt fler organisationer befinner sig i en situation där två stora EU-regelverk träffar dem samtidigt, fast från olika håll. NIS2, eller Cybersäkerhetslagen i svensk implementering, reglerar dem som entitet: hur deras egen verksamhet hanterar cyberrisk. Cyber Resilience Act reglerar dem som tillverkare: hur deras produkter med digitala element är säkra på marknaden. Många bolag är båda delarna samtidigt, ofta utan att ha tänkt på det. En industrikoncern som tillverkar uppkopplad utrustning är CRA-tillverkare för produkterna och verksamhetsutövare under cybersäkerhetslagen för sin egen verksamhet. En SaaS-leverantör i ICT-tjänstesektorn likaså. Detsamma gäller flera medtech-bolag, fintech-aktörer, och hela bredden av nordisk industri som på senare år har digitaliserat sina produkter.
För dessa organisationer är frågan inte om de ska bygga compliance-program för båda regelverken, det måste de, utan om de bygger två parallella spår eller ett integrerat. Skillnaden är stor: parallella spår skapar duplicerat arbete, inkonsekventa positioner och dubbla kostnader. Ett integrerat program utnyttjar de strukturella överlappen, och de är betydande. Den här texten är skriven för ledningar i organisationer som träffas av båda regelverken, och som behöver förstå var integration faktiskt sparar arbete och var de två regimerna måste hållas isär.
Två regelverk, olika objekt
Innan vi går in på överlappen är det värt att vara tydlig om vad som faktiskt skiljer regelverken åt. Förvirring kring denna distinktion är källan till många implementationsmissar.
NIS2, och dess svenska implementering Cybersäkerhetslagen, reglerar entiteter. Lagstiftningen riktar sig till verksamhetsutövare i ett antal kritiska sektorer som överstiger en storlekströskel, klassificerade som väsentliga eller viktiga. För dessa verksamhetsutövare ställs krav på riskhantering, incidentrapportering, styrning och leverantörshantering. Den nationella samordningen hanteras av Myndigheten för civilt försvar (MCF, tidigare MSB), med tillsynen sektorsvis fördelad mellan myndigheter som Energimyndigheten, Livsmedelsverket, PTS, Transportstyrelsen och Integritetsskyddsmyndigheten beroende på sektor. Sanktionerna kan uppgå till 10 miljoner euro eller 2 procent av global omsättning för väsentliga verksamhetsutövare.
CRA reglerar produkter. Förordningen riktar sig till tillverkare, importörer och distributörer av produkter med digitala element som placeras på EU-marknaden. Den ställer krav på produktens egenskaper och på tillverkarens processer för sårbarhetshantering. Tillsynen utövas av marknadsövervakningsmyndigheter. Sanktionerna kan uppgå till 15 miljoner euro eller 2,5 procent av global omsättning.
De två regelverken är alltså i grunden komplementära, inte överlappande. Det ena reglerar hur ni driver er verksamhet, det andra reglerar vad ni säljer. Men för en organisation som gör båda sakerna sammanfaller många operativa aktiviteter, och det är där integrationen sker.
Sårbarhetshantering: den största strukturella överlappen
NIS2:s riskhanteringsåtaganden inkluderar uttryckligen en åtgärd som handlar om säkerhet i utveckling, anskaffning och underhåll av nät- och informationssystem, inklusive sårbarhetshantering. CRA:s krav på tillverkarens processer kräver i sin tur en formaliserad sårbarhetshanteringsprocess: identifiering, dokumentation, åtgärdande, distribution av uppdateringar och koordinerat avslöjande.
För en organisation som omfattas av båda regelverken är detta i praktiken samma operativa förmåga, tillämpad på olika objekt. NIS2 kräver att ni hanterar sårbarheter i de system ni använder, CRA kräver att ni hanterar sårbarheter i de produkter ni släpper. Många av processerna, verktygen och kompetenserna är desamma. Ett SBOM-program byggt för CRA stöder direkt NIS2-åtagandet om kunskap om de komponenter som ingår i den egna miljön. En process för koordinerat sårbarhetsavslöjande som etableras för produktsidan kan utvidgas till att täcka även de interna systemen.
Den vanligaste designmissen här är att bygga separata team. CISO-funktionen tar NIS2-sårbarhetshanteringen, produktorganisationen tar CRA-sidan, och de delar varken verktyg, processer eller terminologi. Efter ett par år finns två parallella sårbarhetsprogram med olika SLA, olika rapporteringsformat och olika prioriteringskriterier. Det är dyrt, det är ineffektivt, och det skapar inkonsekvent säkerhetsposition mot myndigheter och kunder.
En integrerad arkitektur, där ett gemensamt sårbarhetshanteringsramverk täcker både den interna miljön och produktportföljen med olika tillämpningar för olika objekt, är väsentligt billigare och i regel också säkrare. Den enskilda viktigaste integrationspunkten är beslutet om vem som äger sårbarhetshanteringen som funktion: CISO-funktionen med produktorganisationen som intressent, eller produktorganisationen med CISO-funktionen som intressent. Båda kan fungera, men beslutet måste fattas medvetet.
Incidentrapportering: där integrationen är operativ, inte bara strategisk
Ingen del av de två regelverken kräver mer operativ disciplin än incidentrapporteringen. Båda regelverken innehåller aggressiva rapporteringsfrister, inklusive initial rapportering inom 24 timmar i flera situationer, följt av mer substantiella rapporter inom 72 timmar och en slutrapport inom en månad. Regimerna är funktionellt lika men inte identiska. NIS2 träffar betydande incidenter som påverkar verksamhetsutövarens egen tjänsteleverans. CRA träffar aktivt utnyttjade sårbarheter i produkten samt allvarliga incidenter som påverkar produktens säkerhet, vilket är en bredare kategori som bland annat fångar in supply chain-kompromisser och kompromettering av signeringsnycklar.
Rapporterna går till olika myndigheter genom olika kanaler. NIS2-rapporter går till CERT-SE som en del av MCF, för närvarande genom IRON-portalen och senare genom den dedikerade portal som väntas vara i drift under 2026. CRA-rapporter går till den CSIRT som är utsedd som koordinator i den medlemsstat där tillverkaren har sitt huvudsakliga etableringsställe, vilket för svenska tillverkare också är CERT-SE, via den centrala rapporteringsplattform som etableras under CRA och vars praktiska detaljer fortfarande utvecklas inför ikraftträdandet i september 2026. Den enskilda samordningsbestämmelse som finns mellan regelverken, där en rapport under ett regelverk anses uppfylla skyldigheten under det andra, gäller för DORA och NIS2, inte för CRA och NIS2.
För en organisation som är både CRA-tillverkare och verksamhetsutövare under cybersäkerhetslagen innebär detta att ett och samma underliggande händelseförlopp kan utlösa rapporteringsskyldigheter under båda regelverken parallellt, med olika fokus. En komprometterad uppdateringskanal som leder till att produkten används för obehörig åtkomst hos kunder är, i värsta fall, en CRA-rapporteringsskyldighet (sårbarhet aktivt utnyttjad i produkten), en NIS2-rapporteringsskyldighet (betydande incident i den egna verksamheten) och en GDPR-rapporteringsskyldighet (om personuppgifter berörs).
Tre rapporter, tre regelverk, snäva och delvis parallella tidslinjer. Det är operativt mycket krävande, och i praktiken svårt att hantera väl utan förberedelse.
Den integrerade lösningen är inte att försöka konsolidera rapporteringen som sådan, det går inte juridiskt, utan att bygga en gemensam incidenthanteringsprocess som genererar de olika rapporterna från samma underliggande incidentregister. Det innebär konkret en gemensam runbook som identifierar vilka regelverk som potentiellt triggas av varje incidenttyp, fördefinierade trösklar för respektive regelverks rapporteringsgrunder, förauktoriserade roller med beslutskompetens att utlösa rapportering vid varje tidpunkt på dygnet, och testade rutiner för båda portalerna. Den första gången någon i organisationen loggar in i CRA-plattformen eller MCF:s portal får inte vara under en pågående incident.
Tabletop-övningar som testar runbooken under press är inte ett uttryckligt lagkrav i någondera regelverket, men de är i praktiken nödvändiga för att en organisation ska kunna leverera flera samtidiga rapporter inom 24 timmar utan att tappa kontroll över själva incidentresponsen.
Leverantörshantering: överlap men inte identitet
NIS2 kräver att verksamhetsutövare hanterar leverantörsrelaterad cyberrisk, både genom direkta leverantörer och, där det är relevant, indirekta. Detta omfattar inledande bedömning, riskklassificering, kontraktuella krav och löpande uppföljning. CRA, å sin sida, lägger på tillverkaren ansvaret för säkerheten i de komponenter som ingår i produkten, vilket i praktiken kräver att tillverkaren kan kräva motsvarande disciplin av sina egna leverantörer av tredjepartskomponenter.
För en organisation som är både och, sammanfaller stora delar av leverantörshanteringen. Samma leverantörsregister kan användas. Samma riskklassificeringsmetodik kan tillämpas. Samma kontraktsmallar kan, med viss anpassning, täcka båda regelverkens krav. Samma due-diligence-processer kan användas för båda syftena.
Det som inte sammanfaller är vilken leverantör som är kritisk under vilket regelverk. En leverantör av en kontorsapplikation kan vara helt oviktig ur CRA-perspektiv men kritisk för NIS2 om den hanterar drift av kritiska system. En leverantör av en mikrokontroller kan vara helt oviktig för den interna driften men avgörande för CRA-compliance på en produktlinje. Klassificeringen måste därför göras dubbelt, även om infrastrukturen runt klassificeringen är gemensam.
Det praktiska arbetet här är ofta längre och mer underskattat än organisationer förväntar sig. Att skriva om en stor leverantörsbas av kontrakt för att lägga in cybersäkerhetsrelaterade klausuler kan ta 12–24 månader, beroende på portföljens storlek och leverantörernas förhandlingsvilja. Ledningen bör räkna med detta som ett separat arbetsspår, inte som något som “blir gjort” som biprodukt av compliance-programmet.
Riskbedömning som gemensamt underlag
Båda regelverken kräver dokumenterad, levande riskbedömning. NIS2 kräver en sådan på entitetsnivå, med en bredare “all-hazards”-ansats som omfattar inte bara cyberattacker utan även insiders, fysiska hot, naturkatastrofer, infrastrukturfel och mänskliga misstag. CRA kräver en riskbedömning per produkt, fokuserad på produktens hot- och säkerhetsprofil.
Dessa kan, och bör, bygga på en gemensam metodik. Många organisationer använder ISO/IEC 27005 eller en liknande etablerad ansats, vilket fungerar väl som grund för båda regelverken. Men de resulterande dokumenten är olika: NIS2-riskbedömningen ligger på entitetsnivå, CRA-riskbedömningen ligger per produkt och åtföljer den tekniska dokumentationsfilen.
Den praktiska rekommendationen är att etablera en riskmetodik, ett sätt att uttrycka risk i kvalitativa eller kvantitativa termer, ett sätt att förvalta riskregister och uppdateringscykler. Sedan kan dokumenten anpassas till respektive regelverk. Att börja med två olika metodiker, för att senare upptäcka att de ger inkonsekventa positioner på likartade risker, är en av de vanligaste men mest dolda designmissarna.
Styrning: en strukturell skillnad värd att förstå
Här finns en distinktion som inte alltid uppmärksammas men som spelar roll på ledningsnivå. NIS2:s artikel 20 ålägger ledningsorganet, alltså styrelsen eller motsvarande, ett personligt ansvar för att godkänna riskhanteringsåtgärderna och övervaka deras implementering. Ledningen ska också genomgå cybersäkerhetsutbildning. Detta är en av de mer ovanliga inslagen i NIS2 och innebär att styrelsen själv blir en compliance-faktor.
CRA har inte motsvarande uttryckliga konstruktion. Förordningen ålägger tillverkaren som juridisk entitet skyldigheterna, utan att specifikt utpeka ledningsorganet eller kräva styrelseutbildning. I praktiken kommer många av besluten, supportperiod, klassificering, budgetering, ändå att kräva ledningsbeslut, men det är inte ett formaliserat lagkrav på samma sätt.
För en organisation som är båda delarna innebär detta att styrelsen under alla omständigheter måste engageras i cybersäkerhetsstyrningen för NIS2-syften, och att man då med fördel kan låta detta engagemang sträcka sig till CRA-frågor också. En integrerad styrningsstruktur, där styrelsen får en samlad rapport om cybersäkerhetsstatus för både den egna verksamheten och produktportföljen, är mer effektiv än två separata styrningsspår. Den utbildning som NIS2 kräver kan med fördel breddas till att täcka även CRA-relevanta beslutspunkter, exempelvis supportperiod-strategin.
Vad som inte integreras
Trots de många överlappen finns områden där integration är farligt eller olämpligt. Klassificering är ett. NIS2-klassificeringen som väsentlig eller viktig verksamhetsutövare är en helt annan analys än CRA-klassificeringen av enskilda produkter i standardkategorin, viktiga produkter eller kritiska produkter, och att förväxla dem leder snabbt fel.
Rapporteringskanalerna är ett annat. Som beskrivits ovan finns ingen substitutionsregel mellan CRA och NIS2 motsvarande den som finns mellan DORA och NIS2. Ett försök att rapportera en CRA-händelse till MCF i tron att det “räknas som” NIS2-rapportering uppfyller varken det ena eller andra regelverket.
Sanktionerna är formellt separata. Ett bolag kan bötfällas under båda regelverken för samma underliggande händelse, om händelsen samtidigt utgör en överträdelse mot båda. Den praktiska sannolikheten varierar med myndigheternas koordinering, men de juridiska riskerna ackumuleras inte automatiskt bort av att man har ett integrerat compliance-program.
En arbetsmodell för ledningen
Ett integrerat compliance-program för CRA och NIS2 har i praktiken samma struktur som ett rent CRA-program eller ett rent NIS2-program, men med några tillkommande element.
En regelverkskarta upprättas tidigt. För varje verksamhetsdel identifieras vilka regelverk som tillämpas, vilka roller organisationen har under varje, och var de operativa beröringspunkterna finns. Detta dokument anchrar all efterföljande diskussion och uppdateras löpande.
En gemensam exekutiv sponsor utses, snarare än separata sponsorer för CRA och NIS2. Programmet får då en samlad väg in i ledningen, och konflikter mellan spåren kan hanteras innan de manifesteras som inkonsekventa beslut.
En gap-analys genomförs som täcker båda regelverken parallellt, med en kolumn för var arbetet kan delas och var det måste hållas isär. Detta dokument blir programmets centrala styrartefakt.
Operativ kapacitet, särskilt incidentresponsen, byggs som en gemensam förmåga med differentierade rapporteringsspår. Detta är där integration ger störst utdelning per investerad krona.
Leverantörshanteringen byggs som en gemensam plattform med dubbel klassificering.
Styrningen byggs som en sammanhållen ledningsfunktion med en gemensam rapporteringscykel mot styrelsen.
För en ledning som överväger om resurser ska delas eller hållas isär är det användbart att ställa en konkret fråga: om en kvalificerad granskare, en regulator, en revisor eller en kund med egna NIS2- eller DORA-skyldigheter, sätter sig in i hur ni hanterar både er egen cybersäkerhet och era produkters cybersäkerhet, vad skulle de se? Ett spår där samma sårbarhetshantering, samma incident-runbook och samma riskmetodik tillämpas konsekvent på båda objekten är inte bara billigare, det är också mer trovärdigt. Två parallella spår med separata team, separata verktyg och olika positioner på liknande frågor ger det motsatta intrycket.
CRA och NIS2 är, för organisationer som träffas av båda, en möjlighet att bygga en cybersäkerhetsfunktion som är mer mogen och mer integrerad än vad någondera regelverket ensamt skulle ha drivit fram. För ledningen är detta inte i första hand en compliance-fråga utan en arkitekturfråga: var ska era resurser sitta, hur ska de organiseras, och vem ansvarar för att se till att den egna verksamheten och de egna produkterna håller samma säkerhetsstandard.