Cyber Resilience Act: alle værktøjer og artikler
Forordning (EU) 2024/2847, bilag I · ISO/IEC 27001:2022, bilag A
CRA's væsentlige krav, kortlagt til ISO 27001
En fabrikant med et certificeret ISMS stiller først ét spørgsmål: Hvor meget af den tekniske dokumentation har jeg allerede? Svaret har tre dele. For de 14 krav i del I, produktets egenskaber, driver ISMS'et processen, og produktet leverer beviset. For 3 af de 8 krav til håndtering af sårbarheder i del II er ISMS-registreringen beviset. Og for 4 af de 22 leverer intet i bilag A det, forordningen beder om.
- Hvem det gælder for
- En fabrikant med et certificeret ledelsessystem for informationssikkerhed, som spørger, hvor meget af den tekniske dokumentation den allerede har.
- Datoerne
- Før I går i gang med sagen, for svaret afgør, hvad I skriver, og hvad I henviser til.
- Det ene, der skal gøres
- Læs kortlægningen række for række: hvad jeres system allerede dokumenterer, hvad det dækker halvt, og hvad ingen sikkerhedsforanstaltning frembringer.
Et ledelsessystem er ikke et produkt
ISO 27001 certificerer, hvordan en organisation styrer informationssikkerhed. Cyber Resilience Act regulerer et produkt: hvad det gør, hvordan det bygges, og hvordan dets sårbarheder håndteres i supportperioden. De to mødes i udviklingsforanstaltningerne i bilag A, som styrer, hvordan produktet bygges, og i foranstaltningerne til håndtering af sårbarheder, som styrer, hvad der sker efter frigivelsen. De mødes ikke i produktets egne egenskaber: Ingen ISMS-registrering viser, at et produkt leveres med en sikker standardkonfiguration. Det viser produktets dokumentation og test.
Tre svar, ikke én score
| Grundlag | Krav | Hvad det betyder |
|---|---|---|
| ISMS-registreringen er beviset 3 | 3 | Den registrering, foranstaltningen frembringer, er det, den tekniske dokumentation henviser til: sårbarhedsregistret, afhjælpningsloggen, testrapporterne. |
| ISMS'et driver processen, produktet leverer beviset 15 | 15 | Foranstaltningen fastlægger kravet, princippet, kodningsreglen eller testen; beviset for, at produktet opfylder det, er produktets eget, pr. version. |
| Leveres ikke af bilag A 4 | 4 | Intet i bilag A offentliggør noget, udarbejder en stykliste over et produkt eller forpligter sig til gratis opdateringer. Det skrives til forordningen. |
Del I: produktets egenskaber
Punkt 1 er den generelle pligt, baseret på risikovurderingen. Punkt 2 opregner tretten egenskaber, hver gældende på grundlag af den vurdering, så en egenskab, der vurderes ikke at finde anvendelse, udelukkes med en begrundelse i dokumentationen. For dem alle leverer ISMS'et processen: de sikkerhedskrav, produktet skal opfylde, de principper, det er designet efter, kodningsreglerne, testene før frigivelsen. Beviset for hver egenskab er produktets.
I.1 Passende cybersikkerhedsniveau gennem design
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- Afsnit 6.1.2
- A.5.8
- A.8.25
Hvad dokumentationen stadig mangler: En cybersikkerhedsrisikovurdering af selve produktet (artikel 13, stk. 2 og 3), opbevaret i den tekniske dokumentation efter bilag VII, punkt 3. ISMS'et vurderer organisationens risici; produktets er en særskilt registrering.
I pakken med teknisk dokumentation: Cybersecurity risk assessment
I.2.a Ingen kendte udnyttelige sårbarheder ved frigivelsen
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.8
- A.8.29
Hvad dokumentationen stadig mangler: Kontrollen sker pr. frigivelse og pr. leveret komponent, og resultatet bliver hos den version. En scanning af organisationens egne systemer er en anden registrering.
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.b Sikker standardkonfiguration
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.9
- A.8.26
Hvad dokumentationen stadig mangler: Den sikre standardkonfiguration og nulstillingen til den er produktets egenskaber, vist ved dets dokumentation og test, ikke ved en konfigurationsbaseline for organisationens systemer.
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.c Sikkerhedsopdateringer
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.8
- A.8.32
Hvad dokumentationen stadig mangler: En opdateringsmekanisme i produktet, automatisk som standard med mulighed for, at brugeren fravælger den, og en meddelelse til brugerne, når en opdatering er tilgængelig: en funktion, ikke en proces.
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.d Beskyttelse mod uautoriseret adgang
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.5
- A.5.15
- A.5.16
- A.5.17
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.e Fortrolighed af data
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.24
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.f Integritet af data, kommandoer og konfiguration
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.24
- A.8.9
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.g Dataminimering
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.5.34
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.h Tilgængelighed af væsentlige og grundlæggende funktioner
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.6
- A.8.14
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.i Ingen negativ indvirkning på andre enheder og netværk
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.27
- A.8.20
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.j Begrænset angrebsflade
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.27
- A.8.9
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.k Reduceret indvirkning af hændelser
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.27
- A.8.28
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.l Sikkerhedslogning og overvågning
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.15
- A.8.16
I pakken med teknisk dokumentation: Standards applied and test evidence
I.2.m Sikker og enkel sletning af data og indstillinger
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.26
- A.8.10
I pakken med teknisk dokumentation: Standards applied and test evidence
Del II: håndtering af sårbarheder i supportperioden
Otte krav til fabrikanten, hvoraf ingen kan udelukkes. Det er her, et ISMS er tættest på forordningen, og her de konkrete huller ligger: styklisten, den offentlige oplysning, politikken, kontaktadressen og de gratis opdateringer.
II.1 Identificere og dokumentere sårbarheder og komponenter, med en SBOM
ISMS-registreringen er beviset
Processen, i bilag A
- A.8.8
- A.5.9
Hvad dokumentationen stadig mangler: En softwarestykliste i et almindeligt anvendt, maskinlæsbart format, der mindst dækker produktets afhængigheder på øverste niveau. Ingen foranstaltning i bilag A beder om en stykliste over et produkt.
I pakken med teknisk dokumentation: Software bill of materials procedure
II.2 Afhjælpe sårbarheder uden ophold
ISMS-registreringen er beviset
Processen, i bilag A
- A.8.8
- A.8.32
Hvad dokumentationen stadig mangler: Sikkerhedsopdateringer leveret adskilt fra funktionsopdateringer, hvor det er teknisk muligt: en frigivelsespraksis, som bilag A ikke nævner.
I pakken med teknisk dokumentation: Security updates and support statement
II.3 Regelmæssige test og gennemgange
ISMS-registreringen er beviset
Processen, i bilag A
- A.8.29
- A.8.8
- A.5.35
I pakken med teknisk dokumentation: Vulnerability handling process
II.4 Oplyse om afhjulpne sårbarheder
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: Offentlig oplysning om hver afhjulpet sårbarhed, når opdateringen er tilgængelig: beskrivelse, berørte produkter, indvirkning, alvorlighed og hvordan brugerne afhjælper. Bilag A har ingen foranstaltning, der offentliggør noget.
I pakken med teknisk dokumentation: Vulnerability handling process
II.5 Politik for koordineret oplysning om sårbarheder
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: En politik for koordineret oplysning om sårbarheder, indført og håndhævet. Bilag A kræver en hændelsesproces, ikke en offentliggjort politik for eksterne indberettere.
I pakken med teknisk dokumentation: Coordinated vulnerability disclosure policy
II.6 En kontakt til indberetning af sårbarheder
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: En offentliggjort kontaktadresse til indberetning af sårbarheder i produktet og i dets tredjepartskomponenter, og en måde at modtage dem på.
I pakken med teknisk dokumentation: Coordinated vulnerability disclosure policy
II.7 Sikker og rettidig distribution af opdateringer
ISMS'et driver processen, produktet leverer beviset
Processen, i bilag A
- A.8.24
- A.8.32
Hvad dokumentationen stadig mangler: Distributionsmekanismen er produktets: opdateringer signeret, leveret sikkert og rettidigt, automatisk hvor det er relevant.
I pakken med teknisk dokumentation: Security updates and support statement
II.8 Gratis sikkerhedsrettelser med meddelelser
Leveres ikke af bilag A
Hvad dokumentationen stadig mangler: Gratis sikkerhedsopdateringer i supportperioden, uden ophold, med en meddelelse til brugerne. En forretningsmæssig forpligtelse og en offentliggørelse, som bilag A ikke nævner nogen af.
I pakken med teknisk dokumentation: Security updates and support statement
4 ting, som bilag A ikke leverer
Skrevet ud, så en certificeret fabrikant ved, hvad der skal skrives, ikke kun hvad der kan henvises til. Hver af de 4 lander i et af 3 dokumenter i pakken med teknisk dokumentation, og de dokumenter udarbejdes ud fra produktregistreringen, ikke ud fra ISMS'et.
II.4 Oplyse om afhjulpne sårbarheder
Offentlig oplysning om hver afhjulpet sårbarhed, når opdateringen er tilgængelig: beskrivelse, berørte produkter, indvirkning, alvorlighed og hvordan brugerne afhjælper. Bilag A har ingen foranstaltning, der offentliggør noget.
II.5 Politik for koordineret oplysning om sårbarheder
En politik for koordineret oplysning om sårbarheder, indført og håndhævet. Bilag A kræver en hændelsesproces, ikke en offentliggjort politik for eksterne indberettere.
II.6 En kontakt til indberetning af sårbarheder
En offentliggjort kontaktadresse til indberetning af sårbarheder i produktet og i dets tredjepartskomponenter, og en måde at modtage dem på.
II.8 Gratis sikkerhedsrettelser med meddelelser
Gratis sikkerhedsopdateringer i supportperioden, uden ophold, med en meddelelse til brugerne. En forretningsmæssig forpligtelse og en offentliggørelse, som bilag A ikke nævner nogen af.
Hvad denne side ikke er
Ikke en dækningsscore. Her beregnes ingen procent, og det bør der heller ikke. Et krav, hvis proces ligger i ISMS'et, og hvis bevis endnu ikke ligger i dokumentationen, er ikke en delvist dækket brøk; det er et dokument, der skal skrives.
Ikke en overensstemmelsesformodning. Kun en harmoniseret standard, der er offentliggjort i EU-Tidende, giver en (artikel 27), og ISO 27001 er ikke, og bliver ikke, den standard. Hvor de harmoniserede standarder står, og hvad deres fravær betyder for hvert niveau
Ikke NIS2-kortlægningen. NIS2 regulerer organisationen, og dens foranstaltninger er skrevet ud fra ISO 27001, hvilket er grunden til, at den kortlægning ligger tættere på. NIS2-gennemførelsesforordningen kortlagt til ISO 27001
Læs derefter
CRA bilag 1: de 22 væsentlige krav som tjekliste, 14 produktkrav og 8 til håndtering af sårbarheder
Hvad jeres produkt skal opfylde fra den 11. december 2027, og hvad den tekniske dokumentation skal vise: del I, 14 produktkrav, hvoraf 13 'hvor det er relevant' på grundlag af jeres risikovurdering; del II, 8 krav til håndtering af sårbarheder, der altid gælder.
Hvad der hører til i den tekniske dokumentation efter CRA: bilag VII, punkt for punkt
Fra den 11. december 2027 skal ethvert produkt med digitale elementer, der bringes i omsætning på EU-markedet, have teknisk dokumentation før omsætningen, opbevaret i ti år eller supportperioden, alt efter hvad der er længst.
Harmoniserede standarder for CRA: ingen citeret endnu, 41 bestilt, de første to forfaldt den 30. august 2026
Standardiseringsanmodning M/606 af 3. februar 2025 beder CEN, CENELEC og ETSI om 41 standarder: to horisontale senest den 30. august 2026, de vertikale for produkter i bilag III og IV senest den 30. oktober 2026, de generiske krav senest den 30. oktober 2027.
Selvvurdering efter CRA: hvad modul A faktisk kræver, fra bilag VIII og Kommissionens FAQ
De fleste softwareprodukter vil aldrig se et bemyndiget organ.
CRA-cybersikkerhedsrisikovurderingen: hvad artikel 13 faktisk kræver, og det ene resultat, den skal levere
Artikel 13, stk. 2 til 4, i Cyber Resilience Act gør risikovurderingen til det dokument, alle andre CRA-pligter hænger på.
Kræver CRA en SBOM? Ja, og her står præcis, hvad den siger
Bilag I, del II, punkt 1 i Cyber Resilience Act kræver en softwarestykliste i et almindeligt anvendt, maskinlæsbart format, der mindst dækker afhængighederne på øverste niveau.
Den politik for koordineret offentliggørelse af sårbarheder, som CRA kræver: tre bestemmelser, og en politik på én side, der opfylder dem
Bilag I, del II, punkt 5, i Cyber Resilience Act kræver, at enhver omfattet fabrikant indfører og håndhæver en politik for koordineret offentliggørelse af sårbarheder.
Cyber Resilience Act for en lille softwarefabrikant, i tolv trin
Alt, hvad en virksomhed på ti personer, der leverer installeret software eller en enhed, skal gøre efter CRA, i den rækkefølge, det skal gøres: fastlæggelsen af anvendelsesområdet, trinnet, CSIRT'et og håndhæveren, den anmeldelsesprocedure, der har gjaldt siden den 11. september 2026, derefter den tekniske dokumentation, de 22 krav, SBOM'en, supportperioden, CE-mærkningen og erklæringen med frist den 11. december 2027.
Næste skridt: den tekniske dokumentation, elleve dokumenter, udarbejdet i jeres organisation.
Dokumenter på e-mail; føj dem til et gratis arbejdsområde, når du vil.
Eller start gratis og registrér et produkt
Eller få det gjort sammen med os: CRA-parathed, 1.500 €, 10 arbejdsdage
Bilag I finder anvendelse fra den 11. december 2027. Foranstaltningerne er de 93 i bilag A til ISO/IEC 27001:2022, citeret ved reference; kortlægningen er vores og ikke ISO's eller Kommissionens. Dette er ikke juridisk rådgivning, og forordningen er den tekst, der skal læses: Forordning (EU) 2024/2847.