Hvis du vil blive hacket i 2026, kan du gøre det på den besværlige måde ved at angribe et mål direkte. Eller du kan gøre det på den smarte måde: gå gennem en leverandør, en SaaS, en underleverandør, et plugin, en driftspartner eller en konsulent med for brede rettigheder og for lidt kontrol. Gæt hvad der sker oftest.
NIS2 gør leverandørstyring til et seriøst krav, ikke en “vi har en leverandørliste i Excel et sted”-aktivitet. Det giver mening, fordi moderne virksomheder ikke bare har et IT-miljø. De har et helt økosystem af tredjepartsservices, der håndterer data, adgang, drift og kritiske processer.
I denne artikel får du en praktisk tilgang til leverandørstyring under NIS2, så du kan reducere risikoen for at blive ramt via tredjeparter, og samtidig gøre det på en måde, der ikke ender som bureaukrati uden effekt.
Hvorfor leverandører er din største (og mest undervurderede) risiko
Tredjepartsrisiko handler sjældent om, at leverandøren er “dårlig”. Det handler om kombinationen af:
- Adgang: Leverandører får ofte for brede rettigheder (admin, API-nøgler, delte konti).
- Afhængighed: Hvis leverandøren går ned, stopper du.
- Data: Hvis leverandøren bliver kompromitteret, kan dine data blive kompromitteret.
- Manglende synlighed: Du opdager ofte først noget, når skaden er sket.
Den økonomiske logik er brutal: Et leverandørrelateret brud bliver dyrt, fordi du betaler for:
- driftstop og tabt omsætning
- ekstern hjælp (incident response, juridisk, kommunikation)
- genopretning og oprydning
- eventuelle bøder/krav
- tab af tillid (som ofte er den dyreste del)
Så ja: leverandørstyring er cybersikkerhed, men det er også ren risikostyring og økonomisk sund fornuft.
NIS2 og leverandørstyring, helt lavpraktisk
NIS2 lægger op til, at organisationer skal arbejde risikobaseret med sikkerhedsforanstaltninger, og her indgår forsyningskæden. Oversat til hverdagsdansk betyder det:
- Du skal vide, hvem dine leverandører er (og hvad de laver).
- Du skal kunne vurdere, hvilke der er kritiske.
- Du skal stille krav og følge op, især på dem der kan “vælte dig”.
- Du skal have en plan for, hvad du gør, hvis de fejler eller bliver ramt.
Hvis du vil have en samlet indgang til emnet, så er denne side en relevant reference: NIS2 leverandørstyring
Trin 1: Få styr på leverandørlandskabet (uden at gøre det til et projekt i 3 måneder)
Start med at lave et leverandørregister. Ikke noget fancy. Bare en oversigt, der kan opdateres. For hver leverandør skal du mindst have:
- Leverandørnavn + kontakt (inkl. incident kontakt)
- Hvilken service leverer de?
- Hvilke systemer integrerer den med?
- Hvilke data håndterer den? (persondata, finans, drift, “alt”)
- Hvilke adgangsniveauer har de? (admin, bruger, API, VPN)
- Afhængighed: hvad sker der, hvis den er nede?
- Underleverandører (hvis kendt): fx cloud-hosting, datacenters
Tip: Du finder ofte de “hemmelige” leverandører ved at kigge på:
- SSO/IdP app-liste (Microsoft Entra/Google Workspace)
- fakturaer/abonnementer
- browser extensions, plugins, integratorer
- marketing- og trackingværktøjer (ja, de tæller også)
Trin 2: Klassificér leverandører efter risiko (så du ikke spilder tid på de forkerte)
Du kan ikke behandle alle leverandører ens. Det er her, mange går galt: de laver én lang kravliste til alle, og så bliver det enten ignorering eller pseudo-compliance.
Brug i stedet en simpel risikomodel med 3 niveauer:
Niveau 1: Kritiske leverandører
Kendetegn:
- driftstop = du stopper
- de har adgang til kritiske systemer/data
- de er en del af din sikkerhedskæde (hosting, drift, IAM, backup, betalingsinfrastruktur)
Niveau 2: Vigtige leverandører
Kendetegn:
- påvirker væsentlige processer, men du kan arbejde uden i en periode
- håndterer data, men ikke alt
- lavere adgangsniveauer
Niveau 3: Standard leverandører
Kendetegn:
- begrænset data/afhængighed
- ingen kritisk adgang
- nem at udskifte
Målet: 80% af din indsats skal ligge på niveau 1 og 2.
Trin 3: Due diligence der faktisk kan udføres
Du behøver ikke lave en full audit på alle. Du skal lave en risikobaseret kontrol, der matcher niveauet.
For kritiske leverandører (niveau 1)
Spørg efter og dokumentér:
- Sikkerhedscertificeringer/attestationer (fx ISO 27001, SOC 2, ISAE 3000/3402 hvor relevant)
- Incident process: hvordan varsler de dig, hvor hurtigt, og via hvilke kanaler?
- Backup/restore og RTO/RPO (hvor hurtigt kan de gendanne, hvor meget data kan gå tabt)
- Adgangsstyring: MFA, least privilege, logging
- Sårbarhedshåndtering: patch cycles, disclosure, SLA på kritiske sårbarheder
- Underleverandører: hvem hoster de hos, og hvilke afhængigheder findes?
For vigtige leverandører (niveau 2)
Fokusér på:
- adgangsstyring + logging
- incident varsling
- databehandleraftale (hvis persondata)
- ændringsstyring for større opdateringer, der kan påvirke drift
For standard leverandører (niveau 3)
Hold det let:
- basis sikkerhedskrav (MFA, adgang, dataminimering)
- klar kontrakttekst om databrud/varsling hvis relevant
Pro-tip: Hvis leverandøren ikke kan svare på helt grundlæggende sikkerhedsspørgsmål, er det et signal. Ikke nødvendigvis “drop dem nu”, men “begræns adgang og planlæg exit”.
Trin 4: Kontraktkrav som gør en forskel (og ikke bare fylder)
Kontrakter er ikke kun juristeri. De er din mulighed for at få sikkerhedsadfærd ned på papir.
Her er de vigtigste kontraktpunkter for niveau 1–2:
1) Incident notification (varsling)
- Varslingsfrist (fx “uden unødig forsinkelse” og gerne konkret tidsramme)
- Hvilke informationer skal med (omfang, påvirkning, tiltag)
- Kontaktveje (24/7 hvis kritisk)
2) Adgang og identitet
- MFA som minimum
- least privilege (kun de rettigheder, der er nødvendige)
- forbud mod delte konti
- logging af administrative handlinger
3) Underleverandører
- krav om transparens: hvem bruges, og til hvad
- krav om at sikkerhedskrav “flyder ned” i kæden
4) Ret til dokumentation og “evidence”
- ret til at modtage relevante rapporter/attestationer
- ret til at få svar på sikkerhedsspørgsmål årligt (eller ved større ændringer)
5) Exit og datahåndtering
- hvordan får du data ud?
- sletning/retention når samarbejdet stopper
- format og tidsramme
6) SLA på drift (hvis kritisk)
- oppetid
- support-responstid
- gendannelsesforpligtelser
Hvis du vil undgå papir uden effekt: hold kontraktkravene korte, målbare og knyttet til din risikoklassificering.
Trin 5: Begræns leverandørers adgang (det er her, du vinder mest)
Den hurtigste måde at reducere tredjepartsrisiko på er ikke flere dokumenter. Det er mindre adgang.
Tjekliste der typisk giver stor effekt hurtigt:
- Brug SSO, hvor muligt (så du kan lukke adgang centralt)
- MFA overalt, især på admin og support-adgange
- Fjern “evige” API-nøgler eller roter dem
- Adskil miljøer (dev/test/prod)
- Giv tidsbegrænset adgang til support (“just-in-time access”)
- Log alt admin-arbejde og få alerts på unormale handlinger
Hvis en leverandør kan logge ind som “superadmin” uden sporbarhed, har du i praksis outsourcet din sikkerhed til held.
Trin 6: Løbende opfølgning der ikke dræber din kalender
Leverandørstyring dør ofte efter første runde, fordi opfølgning bliver tung.
Gør det enkelt:
Kvartalsvist (niveau 1)
- tjek ændringer: nye integrationer, nye datatyper, nye privilegier
- gennemgå hændelser (hvis nogen) og læring
- bekræft incident kontaktinfo
Årligt (niveau 1–2)
- opdater sikkerhedsvurdering
- indhent relevant dokumentation (attestationer, politikker, rapporter)
- test “exit” på papir: kan vi reelt skifte, og hvor lang tid tager det?
Løbende
- hvis der kommer større ændringer (platform migration, ny hosting, opkøb), så re-vurder risikoniveau
Målet er at holde et “living register”, ikke at lave én stor leverandør-øvelse og så glemme den.
“Hvad gør vi hvis…”: leverandøren bliver ramt
Det her er den del, man altid håber, man aldrig får brug for. Og derfor er det smart at have en mini-plan.
Når du får besked om et leverandørbrud, skal du hurtigt kunne svare på:
- Hvad er påvirket hos os? (systemer, data, drift)
- Hvilke konti/tokens skal lukkes nu?
- Hvem informerer vi internt, og hvem ejer beslutningerne?
- Skal kunder/partnere informeres?
- Har vi et alternativ eller en fallback?
Praktisk checklist (første time):
- Deaktivér/rotér adgang (API keys, service accounts, admin)
- Forøg overvågning/logging på berørte systemer
- Bekræft scope skriftligt fra leverandøren
- Dokumentér alt (tidslinje, beslutninger, handlinger)
Hvis du har gjort arbejdet i trin 1–5, kan du reagere hurtigt. Hvis du ikke har, bliver det “kaotisk møde-maraton”.
Typiske fejl i leverandørstyring (som du kan undgå uden at være genial)
- Ingen ejer
Hvis ingen er ansvarlig for leverandørstyring, bliver det ingen. - Alt behandles ens
Du drukner i administration og får ingen effekt. - Krav uden verifikation
“De sagde de har MFA” er ikke kontrol. - Leverandører har mere adgang end nødvendigt
Det er den mest almindelige og farligste. - Ingen exit-plan
Hvis du ikke kan skifte, har du en binding, ikke en leverandør.
Konklusion: Leverandørstyring er ikke et dokument. Det er en disciplin.
NIS2 presser virksomheder til at tage tredjepartsrisiko seriøst, og ærligt: det er på tide. Den moderne organisation er en samling af eksterne services, integrationer og partnere. Hvis du ikke styrer dem, styrer de dig.
Hvis du vil gøre det praktisk og effektivt:
- kortlæg leverandører og adgang
- klassificér risiko (niveau 1–3)
- stil målrettede krav og få evidens
- begræns adgang og log kritiske handlinger
- følg op i et simpelt cadence
- hav en mini-plan for leverandørhændelser
Det er ikke glamourøst. Det er til gengæld den slags arbejde, der forebygger de bøder, driftstop og kriser, som ellers ender med at koste rigtige penge og rigtige weekender.
Leave a Reply