Mandag morgen kører jeres egne systemer, som de skal, overvågningen er grøn, og der er ingen sager i servicedesken. Alligevel kan tre af jeres kunder ikke få det, I har lovet dem, fordi en leverandør midt i leverancen har lukket ned for sine systemer. It-chefen opdaterer leverandørens statusside hvert kvarter, mens salg spørger, hvad de må skrive til kunderne. Imens står der ét spørgsmål tilbage, som ingen har fået tildelt: er det her vores hændelse?

Beredskabsplanen svarer ikke, for den begynder i jeres egne systemer, mens den hændelse, der stopper jeres leverance, sker i en andens. Scenariet er konstrueret og handler ikke om en bestemt leverandør.

En hændelse hos leverandøren bliver ikke jeres hændelse af sig selv. Nogen skal beslutte det, og spørgsmålet er, om I har udpeget den person på forhånd. Hullet handler hverken om detektion eller om værktøjer, men om en beslutningsret.

Et aktuelt forløb hos it-leverandøren Dustin Group

Dustin Group er en it-leverandør, og virksomhedens aktuelle forløb er et konkret eksempel på spørgsmålet ovenfor og værd at læse nøgternt, fordi det viser præcis det tidsrum, hvor beslutningen skal træffes. Torsdag den 3. september 2026 oplyste Dustin Group, at virksomheden havde konstateret uautoriseret adgang til nogle interne it-systemer, og at man betragtede hændelsen som alvorlig. Dustin lukkede selv ned for udvalgte systemer for at begrænse konsekvenserne. Ordreflowet kørte igen den 8. september, i første omgang via telefon og mail, hjemmesiderne åbnede den 9. september, og den 10. september oplyste Dustin i sine egne opdateringer, at alle hjemmesider og kundeportaler til at afgive ordrer fungerede normalt igen.

Ifølge Dustins opdatering af 10. september er den tekniske undersøgelse af de berørte interne og administrative systemer stadig i gang, og Dustin har ikke offentliggjort nyt siden. Den 4. september oplyste Dustin, at årsag og omfang blev undersøgt sammen med eksterne eksperter, og ingen af de senere opdateringer angiver en årsag. Dustin har som dataansvarlig indgivet en indledende anmeldelse af et muligt brud på persondatasikkerheden til det svenske datatilsyn, Integritetsskyddsmyndigheten. Om kundeportalen Skyportal oplyser Dustin, at de persondata, der kan være berørt, er et begrænset antal kategorier af ikke-følsomme, forretningsrelaterede oplysninger om kontaktpersoner og brugere hos erhvervskunder, og at man ikke har indikationer på, at de indebærer en høj risiko for de berørte personer. Alt ovenstående er, hvad Dustin selv har offentliggjort, opgjort den 14. september 2026.

Jeg bedømmer ikke Dustins håndtering, og mere end det kan I heller ikke se udefra, når det er leverandøren og ikke jer selv, der er ramt. Det er i det tidsrum, nogen hos jer skal beslutte, om det også er jeres sag.

Spørgsmålet, ingen havde fået tildelt

Jeg har selv været i en lignende situation, dengang jeg ledte genopretningen efter et ransomwareangreb hos en producent med flere fabrikker. Der var det virksomhedens egne systemer, der var ramt, mens det tekniske arbejde var under kontrol. Genopretningen var i gang, og der var folk på opgaven, mens produktionen vidste, hvad den ventede på, og it vidste, hvad næste skridt var.

Det, der ikke havde en ejer, var noget andet, for salg havde kundeaftaler med klausuler om, hvornår kunden skulle orienteres. Spørgsmålet kom op næsten som en bemærkning: er det her sådan en sag, hvem beslutter det, og hvem skal så have besked? Der blev stille, da ingen af os havde fået den beslutning tildelt. Imens løb de frister, der stod i kundernes kontrakter, videre.

Det burde have været let, for sagen var vores egen, systemerne var vores egne, og der var ingen tvivl om, at det var en hændelse, men alligevel var beslutningsretten ikke placeret. Ligger hændelsen uden for jeres egne systemer, men inde i jeres leverance, bliver det samme spørgsmål endnu sværere. Der er ingen alarm og ingen logfil, der kan afgøre det for jer, og de beredskabsplaner, jeg har set, dækker det ikke, når leverandøren er nede.

Det ur, der tæller, står i jeres kundekontrakter

Reflekset er at lede efter fristen i lovgivningen, men de fleste virksomheder, der bliver ramt indirekte gennem en leverandør, har ikke selv en anmeldelsespligt over for en myndighed efter NIS2-loven i den situation. Er persondata hos leverandøren berørt, gælder databeskyttelsesreglerne særskilt. NIS2-loven, LOV nr 434 af 06/05/2025, lægger pligterne på de virksomheder, der selv er omfattet, og § 6 kræver blandt andet, at en omfattet virksomhed håndterer sikkerhed i sin leverandørkæde.

Det er kundens pligt, ikke jeres, medmindre I selv er omfattet. Er I selv omfattet, har I desuden en selvstændig pligt efter § 15 til uden unødigt ophold at underrette modtagerne af jeres tjenester om væsentlige hændelser, der sandsynligvis vil påvirke leveringen negativt, uanset hvad kontrakten siger. Også dér er det den samme beslutning, der skal træffes først: er det jeres hændelse eller ej. Er I leverandør til en omfattet kunde og ikke selv en af de leverandørtyper, loven omfatter direkte, for eksempel cloud- og datacentertjenester, møder I kravet gennem kontrakten frem for gennem loven. Hvordan den forpligtelse ser ud i praksis hos en omfattet virksomhed, har jeg beskrevet her (på engelsk).

Det ur, der reelt binder jer, står i jeres egne kundeaftaler. Tag jeres fem største kundekontrakter frem, find underretningsklausulen, og læs, hvad der udløser den, og hvilken frist den sætter. Jeg har set formuleringen være bredere, end sikkerhedsafdelingen tror, og i de tilfælde nævnte den ikke, at hændelsen skulle være opstået hos jer. Efter min erfaring tager den læsning en eftermiddag.

Fremstiller I selv produkter med digitale elementer, findes der en særskilt myndighedsfrist for producenter, og den har jeg gennemgået i en øvelse om CRA-rapportering. Den frist er ikke den, der binder jer her.

En regel, der venter på leverandørens bekræftelse, udløses aldrig

Det første spørgsmål, når leverandøren er ramt, er, hvad der er sket, og det er et forkert grundlag for en regel. En regel, der siger, at I erklærer hændelsen, når I ved, hvad der er sket, udløses aldrig i tide. Den forudsætter en oplysning, som kun leverandøren kan give, og som leverandøren ofte selv venter på. At erklære en hændelse er ikke det samme som at konkludere, for det sætter kun jeres egen proces i gang, og den første besked til kunden kan sagtens være, at I endnu ikke kender omfanget.

Tærsklerne skal derfor være forhold, I kan konstatere fra jeres egen side, uafhængigt af leverandørens vurdering af alvorlighed. Er der noget, I har lovet en kunde, som ikke længere kan leveres? Kan leverandøren bekræfte, at jeres data og adgange er uberørte? Fravær af en bekræftelse er i sig selv en udløser, og det samme gælder tavshed, der varer længere end den grænse, I har sat på forhånd.

Forløbet hos Dustin viser det, for ordrer kunne afgives igen fem dage efter, at hændelsen blev oplyst, og undersøgelsen var ikke meldt afsluttet, da jeg gjorde status. De to tidslinjer følges ikke ad, og driften kommer tilbage længe før forklaringen. Den, der venter på forklaringen, træffer ingen beslutning i det tidsrum, hvor beslutningen betyder noget.

Jeg har set mønsteret indefra i en større kapitalfondsejet koncern, hvor jeg tidligere var indlejet it-direktør. Signalet lå hos sikkerhed, kundeløftet lå hos driftsdirektøren, og der var ingen skrevet linje mellem de to, hvorfor reglen skal navngive den, der beslutter.

Erklæringsreglen på én side: hvem må kalde det jeres hændelse?

Det, der mangler, er en erklæringsregel, altså den nedskrevne regel for, hvem der må erklære en hændelse uden for jeres egne systemer, men inde i jeres leverance, som jeres egen hændelse, ved hvilken tærskel, og hvem der så skal have besked. Den fylder én side, og efter min erfaring kan den skrives på en halv time.

Hos jer må én navngiven person erklære en hændelse hos leverandøren for jeres egen hændelse, med én navngiven stedfortræder. Det er den, der ejer kundeløftet, typisk direktøren eller driftsdirektøren, og vedkommende skal kunne træffe beslutningen alene, uden at samle en gruppe og uden leverandørens bekræftelse. Beslutningen er kommerciel, før den er teknisk, fordi det næste skridt er en besked til jeres egne kunder under deres kontrakt. Fire ting skal stå på siden.

  1. Hvem må kalde det. Både navnet og stedfortræderens navn skal stå på skrift, ikke en funktion. Retten følger kundeløftet, og ligger navnet hos it, bliver beslutningen teknisk, og så venter den på en forklaring, leverandøren endnu ikke kan give.
  2. Tre tærskler, I kan se fra jeres egen side. Leverance: en hændelse hos leverandøren stopper eller forringer noget, I har lovet en kunde, ud over en tolerance, I har fastsat på forhånd, målt i arbejdstimer, ikke i et skøn over væsentlighed. Har I ikke sat den endnu, så start med fire arbejdstimer og ret den, når I har prøvet den. Data og adgang: leverandøren har jeres data eller stående adgang og kan ikke bekræfte, at det er uberørt. Varighed og tavshed: leverandøren undersøger stadig efter det tidspunkt, I selv har sat, uden at oplyse noget om omfanget. Har I ikke sat det, så start med to arbejdsdage. Alle tre kan afgøres uden leverandørens medvirken.
  3. Hvilke kunder får besked, og under hvilken klausul. Lav listen på forhånd ud fra kontraktregistret. Find de kunder, der har en klausul, som forpligter jer til at orientere dem, og som er bred nok til også at fange en hændelse hos en leverandør eller underdatabehandler. Skriv ned, hvad der udløser klausulen, hvilken frist den sætter, og hvem der sender beskeden. Den liste er svær at lave, mens sagen står på, og kun den, der ejer kundeforholdet, kan beslutte at underrette tidligt.
  4. Den dokumentation, nogen beder om senere. Seks uger efter ringer en kundes sikkerhedsansvarlige eller revisor og beder om forløbet: hvornår vidste I det, hvem traf beslutningen, på hvilket grundlag, hvem underrettede I, og hvornår. Svaret er ét fælles notat med tidsstempler, ejet af den, der erklærede hændelsen. Det skriver I undervejs.

Siden er hele opgaven, og den indeholder ingen leverandørvurdering, ingen risikoscore og ingen prioriteret liste over jeres leverandører. Det kan være fornuftigt arbejde, men det hjælper jer ikke den mandag, hvor leverandøren er nede og kunden ringer. Selve leverandørgennemgangen er en anden opgave, og hvad en kunde forventer at se af leverandørdokumentation, har jeg skrevet om her (på engelsk).

Én person, én tærskel, inden næste gang

Dustin havde ordreflowet oppe igen efter fem dage, og undersøgelsen var ikke meldt afsluttet, da jeg gjorde status. Det siger ingenting om, hvor længe I kan holde jeres egne kundeløfter, mens I venter. Er navnet og tærsklen skrevet ned på forhånd, kan I svare kunden samme dag og bagefter vise, hvem der besluttede hvad, mens I ellers bruger det første døgn på at finde ud af, hvem der overhovedet må beslutte det.

Derfor er den næste beslutning to linjer på et stykke papir: navnet på den ene person, der må erklære en hændelse hos leverandøren for jeres egen, og den ene tærskel, hvor vedkommende skal gøre det, også når leverandøren ikke siger noget. Træffer I ikke den beslutning, har I accepteret, at den første leverandørhændelse afgør det for jer. Én person, én tærskel, i denne uge.