Test efter en hændelse hos jer: hvad kunden kan forvente

Når der har været en hændelse hos jer, som berørte en NIS2-kundes leverance, kan kunden bede om en ny penetrationstest. Kunden kan forvente en test, der afprøver, om de ændringer, I har lavet efter hændelsen, holder, og om andre veje ind i leverancen står åbne. Kunden kan ikke forvente, at testen forklarer, hvad der skete. Det er en undersøgelse af hændelsen, og det er en anden opgave.

Kundens interesse hviler på reglerne for kundens opfølgning på leverandører. Teksten er ikke juridisk rådgivning.

Hvorfor kunden spørger efter en hændelse

Gennemførelsesforordning 2024/2690 gælder direkte for bestemte digitale udbydere, fx cloud, datacentre og administrerede tjenester. Bilagets punkt 5.1.6 beskriver, at de overvåger, evaluerer og om nødvendigt reagerer på ændringer i leverandørernes cybersikkerhedspraksis, både med planlagte mellemrum og når der opstår væsentlige hændelser i forbindelse med leveringen af ikt-tjenester. Punkt 5.1.7 nævner bl.a., at de gennemgår hændelser i forbindelse med leverandørernes produkter og tjenester (litra b) og vurderer behovet for spontane gennemgange (litra c).

SAMSIK’s vejledning om foranstaltninger beskriver for de øvrige enheder under loven, at enheden bør monitorere og evaluere ændringer i de direkte leverandørers cybersikkerhedspraksis. En hændelse hos jer er netop sådan en ændring. En ny test er en af de måder, kunden kan få noget at evaluere på. Andre måder er en gennemgang af jeres redegørelse, et møde eller en revision efter aftalens bestemmelser. Hvad kunden vælger, afhænger af kundens egen risikovurdering og af, hvor tæt hændelsen kom på kundens drift. → Kundens løbende opfølgning på leverandører

Kunden står selv over for tilsynet

En NIS2-kunde kan blive spurgt af sin kompetente myndighed, hvad kunden gjorde efter en hændelse hos en vigtig leverandør. Med væsentlige enheder fører myndigheden tilsyn efter lovens § 21; med vigtige enheder er tilsynet efter § 24 reaktivt og sker efter indikationer på, at loven ikke overholdes. Kundens svar bliver stærkere, hvis kunden kan vise, at leverandøren har rettet årsagen, og at det er efterprøvet. Det er det, testen kan bidrage med. → Tilsynets audits og sikkerhedsscanninger hos kunden

Undersøgelse og test er to opgaver

En undersøgelse af hændelsen ser bagud: hvordan kom angriberen ind, hvad blev berørt, og er angriberen ude igen. En penetrationstest ser fremad: hvordan står systemerne nu, og kan andre komme ind ad samme eller andre veje.

For kunden betyder rækkefølgen noget. En test, der gennemføres, mens det stadig er uklart, om angriberen er ude, kan give et misvisende billede og kan forstyrre undersøgelsen. Fortæl derfor kunden, hvornår undersøgelsen er afsluttet, og planlæg testen efter det. Lad gerne undersøgelsens konklusioner indgå i testerens forberedelse, så testen rettes mod de svagheder, hændelsen pegede på. Testeren behøver ikke alle detaljer om hændelsen, men skal vide nok til at kunne afprøve, om indgangen og de veje, der ligner den, er lukket. → Årsagen bag fundet

Hvad testen bør dække

Kunden har brug for at kunne se en linje fra hændelsen til testen. Et omfang, der giver den linje, kan bestå af:

Indgangen · den vej, hændelsen udnyttede, efter at den er lukket.
Lignende veje · andre adgange af samme slags, fx andre fjernadgange eller andre konti med samme rettigheder.
Ændringerne · nye kontroller, der er indført efter hændelsen, og om de virker efter hensigten.
Kundens del · den del af leverancen, kunden er afhængig af, så kunden kan se, at den er med.

Omfanget skal stå i dokumentationen, så kunden kan se, hvad der er testet, og hvad der ikke er. Vis gerne kunden et udkast til omfanget, før testen begynder. Kunden kan have oplysninger fra sin egen side af hændelsen, som peger på dele, I ikke selv har tænkt på, og et omfang, kunden har set på forhånd, er sværere at afvise bagefter. → Type, omfang, tidspunkt og resultat

Hvad kunden skal have bagefter

Kunden har brug for et sammenhængende svar, ikke bare en rapport. Det kan være en kort redegørelse, der binder tre ting sammen:

Hændelsen · i den grad, I kan og må beskrive den over for kunden.
Tiltagene · hvad der er ændret, og hvornår.
Testen · hvad den afprøvede, hvad den fandt, og hvordan fundene håndteres.

Redegørelsen bør skrives, så den kan læses af en person hos kunden, der ikke har fulgt sagen, og så den kan lægges i kundens leverandørmappe uden yderligere forklaring. Vær præcis med datoer: hvornår hændelsen blev opdaget, hvornår tiltagene var på plads, og hvornår testen blev udført. Uden datoerne kan kunden ikke se, om testen afprøvede den nye tilstand. Er der fund, går de ind i den almindelige opfølgning med status og efterprøvning. → Retest som dokumentation over for kunden

Et tænkt eksempel

En leverandør drifter et journalsystem for en privat klinik, som er omfattet af NIS2. En medarbejders fjernadgang blev misbrugt, og klinikkens data var utilgængelige i en periode.

Efter undersøgelsen indfører leverandøren multifaktorlogin på alle fjernadgange og fjerner gamle konti. Klinikken beder om en test. Leverandøren lader teste fjernadgangene, kontoopsætningen og den del af systemet, klinikken bruger, og sender en redegørelse, der forbinder hændelsen, tiltagene og testens resultat. Klinikken bruger redegørelsen i sin opfølgning på leverandøren og har dermed et skriftligt svar, hvis tilsynet spørger, hvad klinikken gjorde efter hændelsen. To mindre fund fra testen kommer på statuslisten med datoer, og klinikken får besked, når de er rettet og efterprøvet.

Det skal I lade være med

At teste, før undersøgelsen er afsluttet · resultatet kan blive misvisende.
At sende testrapporten som svar på, hvad der skete · den svarer på et andet spørgsmål.
At afgrænse testen til kun det, der blev ramt · kunden vil vide, om lignende veje står åbne.
At love kunden, at det ikke kan ske igen · testen viser tilstanden på testtidspunktet.
At vente med at tale med kunden, til testen er færdig · kunden skal vide, hvad der er planlagt.

Hvad kan og ikke kan konkluderes

En test efter en hændelse kan vise kunden, at den kendte indgang er lukket, og at testerne ikke fandt andre veje ind inden for det aftalte omfang. Den kan ikke vise, hvordan hændelsen skete, eller at angriberen ikke har efterladt noget, testen ikke så. Hvad kunden skal gøre ud fra resultatet, afgør kunden. Hvordan et softwarehus mere generelt svarer kunder efter en hændelse, er beskrevet på pentestrapport.dk.

Tjekliste før testen

☐ Er undersøgelsen af hændelsen afsluttet?
☐ Dækker omfanget indgangen, lignende veje og de nye tiltag?
☐ Er kundens del af leverancen med?
☐ Har kunden fået besked om plan og tidspunkt?
☐ Er der aftalt en redegørelse, der binder hændelse, tiltag og test sammen?
☐ Er det aftalt, hvordan fund følges op?

Kilder

Gennemførelsesforordning (EU) 2024/2690: bilagets punkt 5.1.6 og 5.1.7, litra b og c. Gælder for de digitale udbydere, der er nævnt i artikel 1.
SAMSIK, vejledning om foranstaltninger (juni 2025): afsnit 4 om opfølgning på leverandørers cybersikkerhedspraksis.
NIS 2-loven, lov nr. 434 af 6. maj 2025: § 21 om tilsyn med væsentlige enheder og § 24 om tilsyn med vigtige enheder.

Senest gennemgået: oktober 2026.