Et SIEM-produkt er et vigtigt produkt i klasse I. Et værktøj, der samler logfiler og viser dem på et enkelt dashboard, anses ifølge Kommissionen generelt ikke for SIEM, fordi det hverken korrelerer data eller giver anvendelige sikkerhedsindsigter.
Grænsen afgør, om en klasse I-procedure gælder, og den skal kunne begrundes i den tekniske dokumentation. Reglerne for klasserne finder anvendelse fra 11. december 2027.
Kategorien
SIEM står i bilag III, klasse I, punkt 7. Gennemførelsesforordning (EU) 2025/2392 beskriver kategorien som produkter, der indsamler data fra flere kilder, analyserer og korrelerer dem og præsenterer dem som anvendelige oplysninger til sikkerhedsformål. Formålene er fx detektion af trusler og hændelser, kriminaltekniske analyser eller håndhævelse.
Beskrivelsen har ingen eksempelliste, som mange af de andre kategorier har. Den har til gengæld fire led, der tilsammen afgrænser kategorien:
- indsamling fra flere kilder
- analyse og korrelation
- præsentation som anvendelige oplysninger
- et sikkerhedsformål
Under kategorien: logindsamling og dashboards
Kommissionens vejledning (eksempel 60) beskriver værktøjer til logindsamling og visualisering med enkle dashboards. De når ikke SIEM, fordi de ikke korrelerer data eller giver anvendelige sikkerhedsindsigter. De anses generelt ikke for SIEM.
Ordet “generelt” er vigtigt. Et logværktøj, der efterhånden har fået regler for korrelation, alarmer om mistænkelige mønstre og sikkerhedsrapporter, kan have flyttet sig. Afgørelsen hviler på produktets væsentligste funktionalitet, som den er i dag.
Over kategorien: SOAR
I den anden ende ligger SOAR-software til orkestrering, automatisering og respons. Betragtning 5 i gennemførelsesforordningen, Kommissionens FAQ (punkt 3.4) og vejledningens eksempel 59 forklarer, at SOAR kan udføre SIEM-funktioner, men at dens væsentligste funktionalitet går videre, fx til hændelsesrespons. SOAR anses derfor generelt ikke for SIEM.
Det følger af den generelle regel, hvor en enkelt evne ikke placerer et produkt, når dets hovedfunktion ligger et andet sted. Reglen er gennemgået i vigtigt produkt eller ej.
At SOAR ikke er SIEM, siger intet om, hvorvidt produktet hører til en anden kategori. Den vurdering skal laves for sig.
Moduler i en suite
Mange sikkerhedsprodukter sælges som suiter. Kommissionens eksempel 61 i vejledningen er en sikkerhedssuite med et SIEM-modul, et modul til indtrængningsdetektion og et analysemodul. Sælges modulerne hver for sig, klassificeres de hver for sig: SIEM-modulet i klasse I, indtrængningsdetektionen i klasse II og analysemodulet i standardkategorien. Leveres de kun samlet, klassificeres suiten på helhedens niveau.
For et softwarehus med et logprodukt og et tillægsmodul til korrelation kan det betyde, at hovedproduktet er i standardkategorien, mens tillægsmodulet er SIEM. Eksemplet er vores anvendelse af reglen. Reglen for moduler med egen licens er beskrevet i tillægsmoduler solgt særskilt.
Begrundelsen i den tekniske dokumentation
Kommissionen forklarer (vejledningen punkt 144), at produktet kun har én væsentligste funktionalitet i denne sammenhæng, og at den bør stå tydeligt i den tekniske dokumentation. Hvordan begrundelsen bygges op, er praksis. En begrundelse, der holder, kan følge de fire led i beskrivelsen:
- Kilder · Spørgsmål: Indsamles data fra flere kilder? · Tænkt svar for et logværktøj: (Ja, fra servere og applikationer)
- Korrelation · Spørgsmål: Analyseres og korreleres data på tværs? · Tænkt svar for et logværktøj: (Nej, data vises pr. kilde uden sammenkædning)
- Indsigt · Spørgsmål: Præsenteres resultatet som anvendelige sikkerhedsoplysninger? · Tænkt svar for et logværktøj: (Nej, rå hændelser og grafer over mængder)
- Formål · Spørgsmål: Er formålet sikkerhed? · Tænkt svar for et logværktøj: (Primært drift og fejlfinding)
Et nej på korrelation og indsigt peger mod Kommissionens eksempel 60. Står der ja hele vejen ned, peger det mod SIEM.
Hvad klassen betyder i praksis
Er produktet SIEM, er det i klasse I. Efter artikel 32, stk. 2, kan fabrikanten da kun bruge egenkontrol efter modul A, hvis den fuldt har anvendt harmoniserede standarder, fælles specifikationer eller certificering på mindst niveauet “betydeligt” for de relevante krav. I modsat fald går vejen gennem et bemyndiget organ og modul B og C eller H.
Kommissionens side om standardisering, læst 13. november 2026, nævner ingen offentliggjort reference til en harmoniseret CRA-standard, og vi har ikke fundet en. Et SIEM-produkt, der skal i handlen efter 11. december 2027, skal derfor planlægges med et bemyndiget organ, indtil det ændrer sig. Er produktet derimod et logværktøj i standardkategorien, kan fabrikanten bruge modul A. Forskellen mellem de to veje er stor nok til, at klassificeringen bør være afklaret tidligt. Se tidsplanen i klasse I uden harmoniseret standard.
Markedsføringen tæller med
Ifølge vejledningen (punkt 143) må en fabrikant ikke give et skævt billede af produktets hovedfunktion for at slippe for en procedure. Et tydeligt misforhold mellem reklamen, brugsanvisningen og den tekniske dokumentation nævnes som tegn. Et logværktøj, der sælges med ordene “trusselsdetektion” og “sikkerhedsanalyse”, men dokumenteres som driftsværktøj, kan få svært ved at forklare forskellen.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skrevet begrundelse for klassen, der følger beskrivelsens fire led, og en gennemlæsning af produktside og salgsmateriale. Begrundelsen skal tages op igen, når produktet får nye analysefunktioner. Daterer I den og skriver, hvilken version den gælder for, kan en senere læser se, hvornår vurderingen sidst blev lavet, og hvad produktet kunne dengang.
Uden begrundelsen kan klassificeringen ikke forsvares over for en myndighed eller et bemyndiget organ. Er produktet SIEM og vurderet efter modul A uden fuldt anvendt standard, er proceduren forkert.
Det skal I lade være med
- At klassificere efter produktets navn · beskrivelsens fire led afgør.
- At sælge sikkerhedsanalyse og dokumentere et driftsværktøj · uoverensstemmelsen er et tegn på misvisning.
- At glemme klassen, når der kommer korrelation på · produktet kan flytte sig.
Det skal auditten kunne vise
- ☐ En skrevet begrundelse for klassen efter beskrivelsens fire led.
- ☐ Overensstemmelse mellem salgsmateriale og teknisk dokumentation.
- ☐ En særskilt klassificering af moduler, der sælges hver for sig.
- ☐ Ny vurdering, når produktet får analyse- eller korrelationsfunktioner.
Kilder
- Forordning (EU) 2024/2847, dansk udgave, artikel 7 og bilag III, klasse I, punkt 7, læst 13. november 2026.
- Kommissionens gennemførelsesforordning (EU) 2025/2392, betragtning 5 og bilag I, klasse I, punkt 7, læst 13. november 2026.
- Europa-Kommissionen, vejledning C(2026) 5252, punkt 143-145 og eksempel 59-61, læst 13. november 2026.
- Europa-Kommissionen, FAQs on the Cyber Resilience Act, version 1.4, punkt 3.4, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Besvar de fire spørgsmål i tabellen for jeres logprodukt og læg svarene ved den tekniske dokumentation.
Læs også: Sikkerhedslogning som produktkrav · Styresystemer, hypervisorer og firewalls
→ Kontakt · Tlf. 70 13 63 23 · Cyber Resilience Act hos Nielco IT
