Forordning 2024/2690 forlanger i bilagets punkt 6.4, at en digital enhed styrer ændringer i sine net- og informationssystemer. Ændringer dokumenteres, testes og vurderes for deres mulige virkninger, før de gennemføres. Kan procedurerne ikke følges på grund af en nødsituation, dokumenteres resultatet af ændringen og begrundelsen.
For en udbyder, der ændrer i sin platform hver uge, er det et af de punkter, hvor en audit hurtigt finder huller. Ændringsloggen er der næsten altid. Spørgsmålet er, om den viser det, forordningen kræver.
Hvad punkt 6.4 kræver
Efter punkt 6.4.1 anvender enheden ændringsstyringsprocedurer til at kontrollere ændringer af net- og informationssystemer.
Punkt 6.4.2 siger, hvad procedurerne gælder. De gælder udgivelser, ændringer og nødændringer af software og hardware i drift og ændringer af konfigurationen. Ændringerne dokumenteres og testes og vurderes i betragtning af de potentielle virkninger, inden de gennemføres. Det sker på grundlag af risikovurderingen.
Efter punkt 6.4.3 gælder der en særregel. Kunne de regelmæssige procedurer ikke følges på grund af en nødsituation, dokumenteres resultatet af ændringen og begrundelsen for, hvorfor procedurerne ikke kunne følges.
Punkt 6.4.4 kræver, at procedurerne selv tages op efter en plan og efter større hændelser og ændringer.
Nødændringer
Nødændringer er den del, hvor procedurer oftest bryder sammen. Om natten under en hændelse retter en tekniker en fejl direkte i produktionen. Det kan være den rigtige beslutning. Forordningen accepterer det. Bagefter skal resultatet af ændringen og begrundelsen for, at den normale vej ikke kunne følges, være skrevet ned.
For auditten er nødændringerne et særskilt felt. Auditor ser efter, hvor mange ændringer der er markeret som nødændringer. Er andelen høj, kan det tyde på, at mærket bruges til at springe test og godkendelse over. Det er en auditors iagttagelse og ikke en grænse i forordningen.
Konfigurationsstyring i punkt 6.3
Punkt 6.3 handler om konfigurationsstyring og hænger tæt sammen med 6.4. Kort sagt fastlægger enheden sikre konfigurationer og processer og værktøjer, der håndhæver dem i hele levetiden. Ændringer i konfigurationen er omfattet af ændringsstyringen i 6.4.2.
Om de sikre konfigurationer faktisk er sat i systemerne, kræver en kontrol direkte i systemerne. Den hører til en teknisk gennemgang af konfigurationerne. Her ser vi på styringen af ændringerne.
Sådan bruger auditor stikprøver i ændringsloggen
Stikprøverne er auditmetode og ikke forordningens ord. Fremgangsmåden er almindelig praksis.
Auditor beder om ændringsloggen for en periode, fx de seneste seks måneder. Dernæst vælges et antal ændringer på tværs af typer: almindelige ændringer, udgivelser, konfigurationsændringer og nødændringer. Hvordan stikprøver vælges, står i stikprøver i audit.
For hver almindelig ændring ser auditor efter:
- en beskrivelse af ændringen
- en vurdering af de mulige virkninger med kobling til risikovurderingen
- spor af test før produktion
- en godkendelse fra en anden end den, der udførte ændringen
- et tidspunkt for gennemførelse, der ligger efter test og godkendelse.
For hver nødændring ser auditor efter resultatet og begrundelsen efter 6.4.3.
Auditor går også den anden vej. Fra systemernes egne logs vælges nogle ændringer, og auditor ser efter, om de findes i ændringsloggen. En ændring i produktionen, der ikke står i loggen, er et tegn på, at styringen ikke dækker alt. Metoden er beskrevet i logs og ændringsspor som bevis.
Kravet om adskillelse
Punkt 1.2.5 kræver, at modstridende ansvarsområder adskilles, hvor det er relevant. Den, der udfører en ændring, og den, der godkender den, er et typisk eksempel i en auditors øjne. I en lille enhed kan adskillelsen fravælges med en begrundelse og en kompenserende foranstaltning, som beskrevet i roller og ansvar efter punkt 1.2.
Standardændringer
Bilaget skelner ikke mellem store og små ændringer. Mange udbydere har en kategori af standardændringer, der er godkendt på forhånd, fx en rutinemæssig udskiftning af en disk. Det kan forenes med 6.4.2, hvis virkningerne er vurderet én gang for hele kategorien, og vurderingen er skrevet ned. Det er en tolkning. Auditor vil se forhåndsgodkendelsen og kontrollere, at ændringerne i kategorien faktisk ligner hinanden.
Hvad det kræver, og hvad det koster at lade være
Det kræver en skrevet procedure for ændringer, en log, hvor test, vurdering og godkendelse kan ses, og en særskilt markering af nødændringer med begrundelse. Udviklere og drift skal bruge samme log.
Uden ændringsstyring er mange hændelser selvforskyldte og svære at forklare bagefter. Et tilsyn, der beder om sporet efter en ændring, der gik galt, kan se med det samme, om det findes.
Det skal I lade være med
- At teste i produktionen og kalde det test · punkt 6.4.2 kræver test før gennemførelsen.
- At bruge nødmærket som genvej · hver nødændring kræver resultat og begrundelse.
- At lade ændringer i konfigurationen gå uden om loggen · de er omfattet af 6.4.2.
Det skal auditten kunne vise
- ☐ En skrevet procedure for ændringsstyring, der dækker udgivelser, ændringer, nødændringer og konfiguration.
- ☐ En ændringslog med vurdering af virkninger, test og godkendelse.
- ☐ Resultat og begrundelse for hver nødændring.
- ☐ Ændringer i systemernes logs, der kan genfindes i ændringsloggen.
- ☐ Gennemgang af procedurerne med planlagte mellemrum.
Kilder
- Kommissionens gennemførelsesforordning (EU) 2024/2690 af 17. oktober 2024, bilaget punkt 1.2, 6.3 og 6.4, https://publications.europa.eu/resource/celex/32024R2690, læst 12. november 2026.
Senest gennemgået: november 2026.
Næste skridt
Find de fem seneste nødændringer i jeres log, og læs, om resultatet og begrundelsen står der.
Læs også: Netarkitektur og segmentering · Følg én sag fra start til slut
→ Kontakt · Tlf. 70 13 63 23 · NIS2-audit hos Nielco IT
