NIS2-pentest

Hændelse hos MSP’en: hvad mange kunder skal have at vide

Hændelse hos MSP'en: hvad mange kunder skal have at vide

Når en hændelse rammer en driftsleverandørs fælles platform, står leverandøren med et spørgsmål, som en almindelig virksomhed ikke har: hvilke kunder skal have besked, hvad skal de vide, og hvor hurtigt? Svaret hviler på to grundlag. Det ene er de aftaler, NIS2-kunderne har indgået med jer, hvor forordning (EU) 2024/2690 nævner en pligt for tjenesteudbydere til at underrette om hændelser. Det andet er NIS 2-lovens § 15, hvis I selv er en væsentlig eller vigtig enhed.

Testen kommer ind to steder: før hændelsen, hvor den viser, hvad en hændelse kan nå, og bagefter, hvor den kan bekræfte, at hullet er lukket. Teksten er ikke juridisk rådgivning.

To slags pligter

Kundens krav kommer fra aftalen. Bilagets punkt 5.1.4, litra d, i forordning 2024/2690 siger, at enhedernes kontrakter med leverandører og tjenesteudbydere, hvor det er relevant, skal angive en forpligtelse til uden unødig forsinkelse at underrette enheden om hændelser, der udgør en risiko for sikkerheden i enhedens net- og informationssystemer. Forordningen gælder en bestemt kreds af digitale udbydere, men andre NIS2-kunder kan bruge samme ordlyd i deres aftaler.

Er I selv omfattet af NIS 2-loven, fx som udbyder af administrerede tjenester, gælder lovens egne regler også. § 15, stk. 1, siger, at væsentlige og vigtige enheder uden unødigt ophold underretter modtagerne af deres tjenester om væsentlige hændelser, der sandsynligvis vil påvirke leveringen af tjenesterne negativt. Efter §§ 12 og 13 skal I samtidig underrette myndigheden og CSIRT’en, med en tidlig varsling senest inden for 24 timer efter at have fået kendskab til en væsentlig hændelse. → MSP og NIS2

Forordningens artikel 1 nævner desuden, at forordningen præciserer, hvornår en hændelse skal anses for væsentlig for de udbydere, den gælder. Den vurdering hører til jeres hændelseshåndtering og ikke til testen.

Hvem er berørt

Det første spørgsmål er ikke, hvad I skal skrive, men til hvem. På en fælles platform kan en hændelse i én komponent nå alle kunder, mens en hændelse i et enkelt kundemiljø kun rammer den kunde. Den skelnen afgør, hvor mange beskeder der skal ud.

Tre forhold afgør rækkevidden:

  • Den berørte komponent · om hændelsen ramte noget fælles som fjernadministration, identitetsløsning eller backup, eller noget kundespecifikt.
  • Rettighederne · hvilke kunder komponenten eller de berørte konti havde adgang til på tidspunktet.
  • Sporene · hvad logs og overvågning viser om, hvor der faktisk har været aktivitet.

Her viser en tidligere test sin værdi. Har I en test, der har kortlagt, hvor langt jeres fælles adgange rækker, ved I hurtigere, hvilke kunder der kan være berørt. → Delte platforme hos MSP’en

Hvad hver kunde skal have

Hver NIS2-kunde har sin egen pligt til at vurdere, om hændelsen er væsentlig for kunden, og sin egen frist, hvis den er. Kundens frist løber fra kundens eget kendskab. Jo tidligere kunden får en brugbar besked, desto bedre kan kunden nå sin egen vurdering. → Kundens 24 timer

En brugbar besked fra en MSP indeholder:

  1. Tidspunkt · hvornår hændelsen blev opdaget, og hvornår den formodes at være begyndt.
  2. Kundens del · hvilke af kundens systemer, konti eller data der kan være berørt.
  3. Status · hvad I har gjort for at begrænse hændelsen, og hvad kunden selv bør gøre.
  4. Næste besked · hvornår kunden hører fra jer igen, og hvem kunden kan ringe til.

Beskeden skal ikke nævne andre kunder, og den skal være den samme i indhold for alle kunder i samme situation. Hvis nogle kunder får mere at vide end andre uden en saglig grund, bliver det svært at forklare bagefter. → Besked om hændelser

Når hændelsen starter hos jeres egen leverandør

En MSP er selv kunde hos andre. Rammes jeres cloudplatform, jeres leverandør af fjernadministrationsværktøj eller jeres hostingpartner, kan hændelsen nå jeres kunder gennem jer. Kunderne har ikke en aftale med jeres leverandør og hører derfor kun om det, hvis I giver det videre.

Sørg for, at jeres egne aftaler med leverandørerne giver jer besked hurtigt nok til, at I kan nå at orientere kunderne. Når beskeden kommer, gælder de samme spørgsmål som ved en hændelse hos jer: hvilke kunder bruger den berørte tjeneste, hvad kan være ramt, og hvad gør I. Skriv tydeligt, at hændelsen stammer fra jeres leverandør, men lad være med at skubbe ansvaret for beskeden videre. Kunden har en aftale med jer, og det er jer, kunden forventer at høre fra. → MSP’en som mellemled

Hændelse eller test

En test af den fælles platform kan give alarmer, der ligner en hændelse. Har kunderne ikke fået besked om testen, kan de begynde deres egen hændelseshåndtering. Varsling af kunderne før en test er derfor også en måde at undgå falske hændelser på. Omvendt må en reel hændelse under et testvindue ikke afvises som en del af testen, før det er kontrolleret. → Testvindue hos MSP’en

Et tænkt eksempel

En driftsleverandør opdager en nat, at en teknikerkonto er brugt fra en ukendt placering til at logge ind i fjernadministrationsværktøjet. Kontoen havde rettigheder hos atten kunder. Logs viser aktivitet hos to af dem. Leverandøren lukker kontoen og giver alle atten kunder besked tidligt om morgenen: hvad der skete, at aktivitet er set hos to kunder, som får en særskilt opfølgning, og hvornår næste status kommer. Efter oprydningen bestiller leverandøren en test af fjernadministrationen, og kunderne får resultatet i et kort resumé.

Det skal I lade være med

  • At vente med beskeden, til alt er undersøgt · kunden har sin egen vurdering at nå.
  • At give kun de kunder besked, hvor der er set aktivitet · kunder med samme eksponering skal også vide det.
  • At bruge jeres egen underretning til myndigheden som kundens · kunden har sin egen pligt.
  • At sende forskellige forklaringer til kunder i samme situation · det skaber tvivl om, hvad der skete.
  • At afvise en alarm som en del af en test uden at tjekke · testen kan dække over en reel hændelse.

Hvad kan og ikke kan konkluderes

En tidligere test kan gøre det lettere at se, hvilke kunder en hændelse kan have nået, og en test bagefter kan vise, om den svaghed, der blev udnyttet, er lukket. Ingen test afgør, om en hændelse er væsentlig, eller om I og kunderne har opfyldt jeres pligter. Det afhænger af jeres aftaler, lovens regler og kundernes egne vurderinger.

Tjekliste før en hændelse rammer platformen

  • ☐ Ved I, hvilke kunder hver fælles komponent har adgang til?
  • ☐ Har I en liste over kontaktpersoner hos hver kunde, også uden for arbejdstid?
  • ☐ Ligger der en skabelon til beskeden med de fire oplysninger?
  • ☐ Giver jeres egne leverandører jer besked hurtigt nok?
  • ☐ Er det afklaret, om I selv har pligter efter NIS 2-loven?

Kilder

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om NIS2 og penetrationstest

Læs også: Fund, der rammer flere kunder · Privilegerede konti hos MSP’en

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Har en kunde stillet NIS2‑krav?

Fortæl kort, hvad kunden har bedt om, og hvornår kunden skal have svar. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.