Et varsel om en sårbarhed har kun værdi, hvis det når en person, der kan vurdere det, og hvis vurderingen ender i en handling. Kontrollen består i at finde ud af, hvilke kanaler varslerne kommer ad, hvem der modtager dem, og om der kan vises et spor fra varsel til ændring for de varsler, der var relevante.
Varslerne kommer fra mange sider: myndigheder, producenter, driftsleverandører og den løbende nyhedsstrøm. Uden en fast vej ender de i en indbakke, hvor de bliver læst, når der er tid, eller slet ikke.
Hvad forordningen beder om
Flere punkter i bilaget til forordning 2024/2690 handler om varsler og binder de omfattede enheder. Punkt 6.10.1 beder enheden indhente oplysninger om tekniske sårbarheder, evaluere eksponeringen og håndtere dem. Punkt 6.10.2, litra a, beder enheden overvåge oplysninger gennem passende kanaler, fx meddelelser fra CSIRT’er, kompetente myndigheder og oplysninger fra leverandører eller tjenesteudbydere. Litra d beder om, at håndteringen er forenelig med ændrings-, patch-, risiko- og hændelsesstyringen.
Punkt 6.10.4 beder om, at kanalerne gennemgås med planlagte mellemrum. Og punkt 4.3.3 beder om en proces for forvaltning og anvendelse af oplysninger fra CSIRT’er og myndigheder om sårbarheder og trusler.
For virksomheder uden for forordningen er punkterne en målestok. De beskriver tilsammen en kæde: kanaler, modtager, vurdering og en kobling til den daglige ændringsproces.
DORA’s tekniske standard, artikel 10, siger det samme for finansielle enheder med andre ord. Enheden skal identificere og opdatere relevante og pålidelige informationsressourcer. Den skal også efterprøve, at tredjepartsudbydere håndterer sårbarheder og rapporterer kritiske sårbarheder rettidigt.
Kanalerne
Første skridt er en liste over de kanaler, varslerne kommer ad. Den kan have kolonnerne kanal, afsender, hvilke systemer den dækker, hvem der modtager, og hvordan. Et tænkt eksempel på rækker: den nationale CSIRT’s varsler, producentens sikkerhedsmeddelelser for firewallen, producentens meddelelser for styresystemet, driftsleverandørens kundemeddelelser og CISA’s KEV-katalog.
Listen afslører to slags huller. Systemer, der ikke er dækket af nogen kanal, fx et fagsystem, hvis producent sender varsler til en tidligere medarbejders mailadresse. Og kanaler, der lander hos en person, men ikke i et fælles sted, så de forsvinder, når personen er på ferie.
Afstem listen mod systemlisten. Hvert vigtigt system bør have mindst én kanal, der dækker det.
Modtageren og vurderingen
For hver kanal skal der være en modtager, der kan vurdere varslet. Vurderingen svarer på tre spørgsmål: Har vi det berørte produkt? I hvilken version? Og er sårbarheden relevant i vores opsætning?
Svaret skal skrives ned, også når det er nej. Et kort notat om, at varslet er læst, og at produktet ikke findes hos jer, er det bevis, gennemgangen kan bruge. Uden notatet kan ingen bagefter skelne mellem et varsel, der blev vurderet irrelevant, og et, der aldrig blev læst.
Sporet fra varsel til ændring
Når et varsel er relevant, skal det blive til en handling: en opdatering, en ændret indstilling eller en midlertidig afskærmning. Forordningens krav om sammenhæng med ændrings- og patchstyringen betyder i praksis, at varslet skal kunne følges ind i den sag eller ændring, der lukkede det.
Gennemgangen tager en stikprøve af varsler fra en afgrænset periode og følger hvert af dem. Hvornår kom det? Hvem læste det? Hvad blev vurderingen? Hvilken ændring fulgte, og hvornår var den gennemført? Sporet er praksis og står ikke som krav i nogen kilde, men det er den mest direkte måde at vise, at kæden virker.
Et tænkt spor kan se sådan ud: varsel modtaget mandag, vurderet relevant tirsdag, ændringssag oprettet samme dag, opdatering installeret torsdag, kontrol af version fredag. Et brudt spor kan se sådan ud: varsel modtaget, ingen notat, opdatering installeret tre måneder senere ved den almindelige månedlige runde.
Kanalerne skal efterses
Bilagets punkt 6.10.4 beder om, at kanalerne gennemgås med planlagte mellemrum. Kilden sætter ikke tal på, så I fastsætter selv intervallet. Ved gennemgangen kontrolleres, om hver kanal stadig sender, om modtageradressen stadig virker, og om nye systemer har fået en kanal. Notér datoen, så næste gennemgang kan se, hvornår det sidst skete.
Leverandørens varsler
Driver en leverandør dele af miljøet, skal det aftales, hvem der modtager producentens varsler, og hvordan I får besked om, hvad leverandøren har gjort. DORA’s krav om at efterprøve, at tredjepartsudbydere rapporterer kritiske sårbarheder rettidigt, viser, at kanalen fra leverandøren hører med på listen.
Hvad det kræver, og hvad det koster at lade være
Det kræver en liste over kanaler, en fælles modtageradresse eller kø og en vane med at notere vurderingen. Det meste af arbejdet er at få varslerne samlet ét sted.
Uden kontrollen afhænger reaktionen på et kritisk varsel af, om den rette person tilfældigvis læste sin mail den dag. Det holder, indtil den dag det ikke gør.
Det skal I lade være med
- At lade varsler lande i personlige indbakker · brug en fælles kø, der overlever ferie og fratrædelse.
- At springe notatet over, når et varsel ikke er relevant · ellers kan ingen se, at det blev vurderet.
- At glemme systemer, som ingen kanal dækker · afstem kanalerne mod systemlisten.
Det skal gennemgangen kunne vise
- ☐ En liste over kanaler med afsender, dækkede systemer og modtager.
- ☐ En afstemning mod systemlisten med de systemer, ingen kanal dækker.
- ☐ Notater om vurdering af en stikprøve af varsler.
- ☐ Spor fra varsel til gennemført ændring for de relevante varsler i stikprøven.
Kilder
- Gennemførelsesforordning (EU) 2024/2690, dansk tekst, bilagets punkt 4.3.3, 6.10.1, 6.10.2 og 6.10.4, læst 13. november 2026.
- Delegeret forordning (EU) 2024/1774, artikel 10, stk. 2, litra a og c, læst 13. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Skriv listen over de kanaler, I får varsler fra i dag, og find det system, som ingen af dem dækker.
Læs også: Ændringsloggen som bevis · Fund i det, leverandøren driver
→ Kontakt · Tlf. 70 13 63 23 · Teknisk sikkerhedsgennemgang hos Nielco IT
