Modul 10 – Bilagor och kopplingar: Tekniska krav, dokumentation och relation till andra regelverk

Översikt: Bilagor och koppling till andra EU-regelverk

I den här modulen knyter vi ihop kursen genom att:

• Orientera oss i bilagorna till cyberresiliensförordningen (CRA) – var hittar du vilka krav?
• Förstå hur bilagorna konkretiserar de väsentliga cybersäkerhetskraven i artiklarna.
• Se hur CRA samspelar med:
• NIS2-direktivet (kritiska och viktiga entiteter)
• DORA-förordningen (finansiell sektor)
• GDPR (personuppgifter)
• AI-förordningen (AI Act)

> Aktuell status (sett från mars 2026)

> - Cyberresiliensförordningen (CRA): antagen 2024, trädde i kraft 2024, med övergångsperiod innan full tillämpning (2–3 år, beroende på artikel).

> - NIS2: ska vara genomförd i nationell rätt senast oktober 2024, de flesta medlemsstater har nu (2025–2026) nationella lagar på plats.

> - DORA: trädde i kraft 2023 och ska börja tillämpas januari 2025 (alltså redan igång nu).

> - GDPR: fullt gällande sedan 2018.

> - AI-förordningen: antagen 2024, med successiv tillämpning (vissa delar redan gällande, andra under införande fram till 2026–2027).

I resten av modulen utgår vi från en typisk tillverkare eller leverantör av uppkopplad produkt/mjukvara och visar hur du kan:

1. Hitta rätt krav i bilagorna.
2. Översätta dem till tekniska och organisatoriska åtgärder.
3. Koppla ihop detta med NIS2, DORA, GDPR och AI-förordningen för en samlad efterlevnadsplan.

Kartbild: De viktigaste bilagorna i CRA

Cyberresiliensförordningen innehåller flera bilagor. De exakta numren kan skilja sig något mellan utkast och slutlig publicerad version, men strukturen är i huvudsak:

• Bilaga I – Väsentliga cybersäkerhetskrav

Här preciseras de grundläggande krav som produkten måste uppfylla, t.ex.:

• Säker utveckling och design
• Sårbarhetshantering
• Säker uppdatering
• Skydd mot obehörig åtkomst

• Bilaga II – Ytterligare/särskilda krav för vissa produktkategorier

T.ex. produkter med högre risk eller särskilda funktioner (liknar "klassificering" som i andra produktlagar).

• Bilaga III – Tekniska dokumentationskrav

Anger vilken dokumentation som behövs för att visa överensstämmelse, t.ex.:

• Teknisk beskrivning av produkten
• Riskanalys och riskhantering
• Testresultat och sårbarhetsskanningar
• Beskrivning av säker uppdateringsmekanism

• Bilaga IV – EU-försäkran om överensstämmelse

Mall/struktur för den deklaration som tillverkaren ska upprätta.

• Bilaga V – Märkning (inkl. eventuell cybersäkerhetsmärkning)

Regler för hur produkten ska märkas (t.ex. CE-märkning plus ev. särskild cybersäkerhetsmarkör).

> Visuell bild (i text)

> Föreställ dig ett lager-på-lager-diagram:

> - Längst upp: Artiklarna (t.ex. artiklarna om väsentliga krav).

> - Under: Bilaga I–II – förtydligar vad kraven betyder tekniskt.

> - Under: Bilaga III – visar hur du bevisar att du uppfyller dem.

> - Sidan om: Bilaga IV–V – hur du kommunicerar efterlevnaden (deklaration, märkning).

Kom ihåg: Vid en tillsyn eller marknadskontroll (från modul 8–9) blir bilagorna ofta första stället myndigheten tittar i för att bedöma om du har gjort rätt.

Bilaga I i praktiken: Från kravtext till tekniska åtgärder

Vi tar ett förenklat exempel på hur ett krav i Bilaga I kan se ut och översätter det till praktiska åtgärder.

> Fiktivt men typiskt formulerat krav i Bilaga I:

> "Produkten ska vara utformad, utvecklad och producerad på ett sådant sätt att den säkerställer ett adekvat skydd mot obehörig åtkomst, inklusive genom stark autentisering, åtkomstkontroll och skydd mot brute force-attacker."

Stegvis översättning till praktik

1. Designnivå

• Krav på arkitektur: separera användargränssnitt, affärslogik och datalager.
• Bestäm autentiseringsmetoder: lösenord + MFA, certifikat, FIDO2, etc.

1. Implementation

• Minimikrav på lösenord (längd, komplexitet, spärr efter X felaktiga försök).
• Logik för rate limiting och låsning vid misstänkt brute force.

1. Testning

• Genomför penetrationstester som simulerar brute force.
• Automatiserade tester som kontrollerar att kontolåsning fungerar.

1. Dokumentation (koppling till Bilaga III)

• I den tekniska dokumentationen:
• Beskriv autentiseringsflöden (t.ex. sekvensdiagram).
• Redovisa testresultat (t.ex. att brute force-blockering fungerar).
• Koppla varje teknisk åtgärd till relevant punkt i Bilaga I.

1. Samspel med andra regelverk

• NIS2: För en NIS2-reglerad organisation blir detta del av riskhanteringsåtgärder och åtkomstkontroll i NIS2-kraven.
• GDPR: Om personuppgifter behandlas är stark autentisering en del av lämpliga tekniska åtgärder (art. 32).
• DORA: För en bank blir detta en del av ICT risk management och säker åtkomst till finansiella system.
• AI-förordningen: Om produkten innehåller ett högrisk-AI-system blir autentisering en del av säker drift av AI-systemet.

På så sätt fungerar Bilaga I som en checklista: varje punkt ska kunna spåras till konkreta tekniska lösningar och dokumenterade bevis.

Övning: Hitta rätt bilaga för rätt fråga

Föreställ dig att du är produktansvarig för en uppkopplad industrisensor. Du ställs inför följande frågor. Försök avgöra vilken bilaga i CRA du främst går till först.

1. "Vilka minimikrav gäller för hur vi ska hantera säkerhetsuppdateringar till sensorn?"
2. "Vilka dokument ska ingå i vårt tekniska underlag inför CE-märkning enligt CRA?"
3. "Hur ska vår EU-försäkran om överensstämmelse se ut?"
4. "Hur ska produkten märkas så att det syns att den uppfyller CRA?"

> Fundera kort och skriv ner:

> - 1 → ?

> - 2 → ?

> - 3 → ?

> - 4 → ?

Bläddra sedan ner för förslag till svar.

---

Förslag på svar:

1. Bilaga I (och ev. II) – väsentliga krav, däribland krav på säker uppdatering.
2. Bilaga III – teknisk dokumentation.
3. Bilaga IV – EU-försäkran om överensstämmelse.
4. Bilaga V – märkningsregler.

Poängen med övningen är att du ska börja tänka: "Vilken bilaga är min primära referens för just den här frågan?"

Bilaga III: Tekniska dokumentationskrav – din beviskedja

Bilaga III är central för efterlevnad. Den besvarar frågan: "Hur visar vi att vi uppfyller kraven i artiklarna och Bilaga I–II?"

Typiska komponenter (förenklat, men i linje med CRA-strukturen):

1. Allmän produktbeskrivning

• Syfte, användningsområde, målgrupper.
• Hårdvaru- och mjukvarukomponenter, tredjepartsbibliotek.

1. Systemarkitektur och datflöden

• Arkitekturskisser (t.ex. komponentdiagram).
• Beskrivning av kommunikationsgränssnitt och protokoll.
• Dataflöden, särskilt där känslig data eller personuppgifter förekommer.

1. Cybersäkerhetsriskanalys

• Identifierade hot (t.ex. OWASP, ENISA hotkataloger).
• Bedömning av sannolikhet/konsekvens.
• Valda motåtgärder, kopplade till relevanta punkter i Bilaga I.

1. Sårbarhetshantering och uppdateringar

• Process för att ta emot sårbarhetsrapporter (t.ex. security.txt, bug bounty).
• Rutiner för patchar och säker uppdatering.
• Tidsramar för åtgärder vid kritiska sårbarheter.

1. Test- och verifieringsresultat

• Penetrationstester, kodgranskningar, automatiserade säkerhetstester.
• Testplaner och sammanfattning av resultat.
• Spårbarhet: vilket krav i Bilaga I verifieras av vilket test?

1. Överensstämmelse med andra standarder

• Lista över harmoniserade standarder eller andra erkända standarder som använts (t.ex. ISO/IEC 27001, 62443, ETSI EN 303 645).
• Detta kan förenkla bedömningen av överensstämmelse.

> Koppling till andra regelverk

> - NIS2: Dokumentationen kan återanvändas som underlag för NIS2-krav på riskhantering och säkerhetsåtgärder.

> - DORA: För finansiella aktörer kan CRA-dokumentationen integreras i DORA:s ICT risk management framework.

> - GDPR: Riskanalysen och datflödeskartläggningen kan användas i DPIA (konsekvensbedömning för dataskydd).

> - AI-förordningen: För högrisk-AI blir mycket av CRA-dokumentationen en del av AI-systemets tekniska dokumentation (t.ex. loggning, robusthet, cybersäkerhet).

Nyckelidé: En välstrukturerad Bilaga III-dokumentation minskar dubbelarbete mellan olika regelverk.

Quiz: Identifiera rätt dokumentationsdel

Testa din förståelse av Bilaga III och dess roll.

EU-försäkran om överensstämmelse och märkning (Bilaga IV–V)

När kraven i Bilaga I–III är uppfyllda behöver du formellt deklarera och märka produkten.

Bilaga IV – EU-försäkran om överensstämmelse

Typiska element i deklarationen (liknande andra produktförordningar):

• Identifiering av tillverkaren och ev. auktoriserad representant inom EU.
• Produktidentifiering (modell, version, serienummer etc.).
• Hänvisning till relevant EU-lagstiftning, t.ex.:
• Cyberresiliensförordningen (med exakt rätt nummer och årtal).
• Andra tillämpliga produktregler (t.ex. lågspänningsdirektivet, EMC-förordningen, radioutrustningsdirektivet).
• Hänvisning till harmoniserade standarder eller andra specifikationer som använts.
• Underskrift av behörig person, datum och plats.

Bilaga V – Märkning

Märkningen ska bl.a. säkerställa att:

• Produkten bär CE-märket (om CRA är integrerad i den övergripande CE-märkningen).
• Eventuella särskilda cybersäkerhetsmarkörer eller symboler följer bilagans krav (storlek, placering, läsbarhet).
• Nödvändig information om tillverkare, modell och version är tydligt synlig.

> Praktiskt exempel

> En uppkopplad router som redan omfattas av radioutrustningsdirektivet får nu även CRA-krav. Tillverkaren:

> - Uppdaterar den tekniska dokumentationen enligt Bilaga III.

> - Justerar EU-försäkran om överensstämmelse (Bilaga IV) så att CRA också listas.

> - Säkerställer att CE-märkningen och ev. cybersäkerhetsmärkning följer Bilaga V.

I modul 8–9 såg vi att marknadskontrollmyndigheten vid ett ingripande ofta begär:

1. Den tekniska dokumentationen (Bilaga III).
2. EU-försäkran om överensstämmelse (Bilaga IV).
3. Kontroll av märkning på produkt och förpackning (Bilaga V).

Samspel: CRA, NIS2, DORA, GDPR och AI-förordningen

Många organisationer omfattas av flera regelverk samtidigt. Det är viktigt att se överlapp och skillnader.

1. CRA ↔ NIS2

• CRA: Fokus på produkter med digitala element (design, utveckling, produkter på marknaden).
• NIS2: Fokus på organisationer/tjänster inom kritiska och viktiga sektorer (energi, transport, hälso- och sjukvård, digital infrastruktur m.m.).

Överlapp:

• Krav på riskhantering, incidentrapportering och sårbarhetshantering.
• Dokumentation i Bilaga III kan användas som underlag för NIS2:s säkerhetsåtgärder (policyer, rutiner, tekniska kontroller).

Skillnad:

• CRA riktar sig primärt till tillverkare, importörer och distributörer.
• NIS2 riktar sig till driftsansvariga organisationer (operatörer av viktiga tjänster, m.fl.).

2. CRA ↔ DORA

• DORA: Gäller finansiella entiteter (banker, försäkringsbolag, betaltjänstleverantörer m.fl.) och deras ICT-tjänsteleverantörer.
• Båda har krav på säker programvaruutveckling, sårbarhetshantering och testning.

Synergi:

• En bank som utvecklar egen mjukvara eller köper in produkter som omfattas av CRA kan:
• Återanvända CRA-dokumentation (Bilaga III) i sin DORA-ICT risk management-dokumentation.
• Ställa CRA-inspirerade krav i sina avtal med leverantörer.

3. CRA ↔ GDPR

• GDPR: Skydd av personuppgifter och registrerades rättigheter.
• CRA: Skydd av produkter och deras cybersäkerhet.

Överlapp:

• Tekniska och organisatoriska åtgärder (art. 32 GDPR) överlappar starkt med CRA:s väsentliga krav (Bilaga I).
• Loggning, kryptering, åtkomstkontroll, pseudonymisering m.m.

Skillnad:

• GDPR kräver även rättslig grund, transparens, rättigheter för registrerade – sådant finns inte i CRA.
• CRA gäller även produkter som inte behandlar personuppgifter.

4. CRA ↔ AI-förordningen

• AI-förordningen: Särskilda krav på AI-system, särskilt högrisk-AI (t.ex. i medicinteknik, kritisk infrastruktur, rekrytering).
• Innehåller krav på riskhantering, data- och datastyrning, loggning, transparens, mänsklig översyn, robusthet och cybersäkerhet.

Koppling:

• Om en produkt med digitala element innehåller ett högrisk-AI-system gäller både CRA och AI-förordningen.
• Cybersäkerhetsdelarna i AI-förordningen kan delvis uppfyllas genom åtgärder som redan krävs i CRA (Bilaga I + Bilaga III-dokumentation).
• Men AI-förordningen har även unika krav (t.ex. data governance, förklarbarhet) som inte täcks av CRA.

Sammanfattningsvis: CRA är produktcentrerad, medan NIS2, DORA, GDPR och AI-förordningen är mer organisations- eller systemcentrerade. En smart strategi är att designa en gemensam säkerhets- och dokumentationsstruktur som kan användas för flera regelverk.

Mini-case: Analys av samspel mellan regelverken

Tänk dig följande fiktiva organisation:

> "HealthConnect AB" utvecklar en molnbaserad plattform och uppkopplade medicintekniska enheter som övervakar patienters vitalparametrar i hemmet.

> - Kunder: sjukhus och regioner i flera EU-länder.

> - Plattformen använder AI för att flagga avvikande mönster (högrisk-AI).

> - HealthConnect AB driver också själva molnplattformen som en tjänst.

Uppgift:

Fundera (gärna i punktform) på:

1. Vilka regelverk träffar HealthConnect AB?

(Tänk på: CRA, NIS2, DORA, GDPR, AI-förordningen, ev. sektorsspecifika som medicinteknikförordningen – MDR.)

1. Hur kan Bilaga III-dokumentationen återanvändas tvärs över dessa?

Ge minst två exempel (t.ex. riskanalys, arkitekturbeskrivning).

---

Exempel på resonemang (facitförslag):

1. Regelverk:

• CRA: HealthConnect är tillverkare av produkter med digitala element (uppkopplade enheter, mjukvara).
• GDPR: Plattformen behandlar känsliga personuppgifter (hälsodata).
• AI-förordningen: AI-funktion för analys av vitalparametrar är sannolikt högrisk-AI.
• NIS2: Om HealthConnect klassas som viktig/essentiell entitet (t.ex. som leverantör till hälso- och sjukvårdssektor) omfattas de av NIS2-liknande krav.
• MDR (ej kursfokus men viktigt i verkligheten): Som medicinteknisk produkt gäller även medicinteknikförordningen.

1. Återanvändning av Bilaga III-dokumentation:

• Riskanalys och tekniska kontroller → används i GDPR (art. 32) och i DPIA, samt i AI-förordningens riskhanteringssystem.
• Arkitektur- och dataflödesdiagram → används för NIS2-efterlevnad (översikt över kritiska system och beroenden) och i AI-förordningen (beskrivning av AI-systemets placering i infrastrukturen).
• Sårbarhetshanteringsprocess → uppfyller delar av både CRA, NIS2 (incident- och riskhantering) och DORA (om företaget levererar till finanssektorn i ett annat scenario).

Bygg en enkel efterlevnadsplan – steg för steg

Använd insikter från hela kursen för att skissa en översiktlig plan för efterlevnad i en egen eller fiktiv verksamhet.

Välj en av följande typer av verksamhet (eller hitta på en egen):

• A) Tillverkare av smarta hem-enheter (t.ex. smarta lås, termostater).
• B) Leverantör av SaaS-plattform för logistikoptimering.
• C) Utvecklare av industriella IoT-sensorer för fabriker.

Uppgift: Skissa en 5-stegsplan

Skriv kort (punktlistor räcker) hur du skulle:

1. Identifiera tillämpliga regelverk

• Vilka av CRA, NIS2, DORA, GDPR, AI-förordningen, andra sektorsregler gäller?

1. Kartlägga produkter/tjänster och dataflöden

• Vilka produkter/tjänster omfattas av CRA?
• Var finns personuppgifter? Finns AI-komponenter?

1. Bygga upp teknisk dokumentation enligt Bilaga III

• Vilka dokument skapar du först (t.ex. arkitekturbeskrivning, riskanalys, testplan)?

1. Koppla dokumentationen till andra regelverk

• Exempel: Hur kan samma riskanalys användas för både CRA och GDPR/NIS2/DORA/AI-förordningen?

1. Förbereda EU-försäkran och märkning

• Hur säkerställer du att Bilaga IV–V följs? Vem signerar? Hur uppdateras deklarationen vid nya versioner?

> Tips: Försök hålla planen kort men konkret, som om du skulle presentera den för din chef eller projektledare.

Repetitionskort: Nyckelbegrepp

Använd korten för att repetera centrala begrepp från modulen. Försök först svara själv, vänd sedan kortet mentalt för att se definitionen.