Når NIS2 rammer kommunerne, opstår et klassisk spørgsmål i indkøb og IT: “Er vi ansvarlige for, at leverandørerne overholder NIS2?” Mange kommunale FAQ’er svarer korrekt, at kommunen ikke er direkte ansvarlig for leverandørens egen efterlevelse. Men det ændrer ikke på, at kommunen skal håndtere forsyningskæderisici som en del af sin egen compliance, risikostyring og driftssikkerhed.
I denne artikel får du en praktisk metode til at klassificere leverandører, stille en standard kravpakke, lave kontrakt- og review-cadence, forstå cloudens “shared responsibility” i en kommunal virkelighed og gemme evidens, der kan tåle revision. Til sidst får du et 1-side leverandørscorecard, du kan kopiere ind i jeres proces.
Hvad betyder NIS2 for kommunens leverandørstyring?
NIS2 er EU-regler for cybersikkerhed, der kræver, at organisationer arbejder risikobaseret med sikkerhed, hændelseshåndtering og leverandørstyring. I kommunal kontekst betyder det, at I skal kunne dokumentere, at I har vurderet og reduceret risikoen ved de leverandører, der leverer kritiske systemer, datahåndtering eller drift.
Det centrale skel er dette: Leverandøren kan være underlagt egne krav, men kommunen skal stadig kunne vise, at leverandørforholdet ikke efterlader jer med uacceptabel risiko. Mini-konklusion: Ansvar for leverandørens compliance er ikke det samme som ansvar for jeres forsyningskæde.
Klassificér leverandører: kritisk vs. ikke-kritisk
En robust leverandørproces starter med klassificering. “Kritisk” handler ikke om, hvor kendt leverandøren er, men om konsekvensen, hvis noget går galt: nedbrud, datalæk, leverandørsvigt eller kompromittering via underleverandører.
Kriterier baseret på ydelser
Start med ydelsen: Hvilken rolle spiller leverandøren i kommunens kerneopgaver? Leverer de drift af infrastruktur, fagsystemer, identitet, netværk, betaling, velfærdsteknologi, telefoniplatform, fjernsupport eller overvågning? Jo tættere på driften og jo større afhængighed, desto mere kritisk.
Kriterier baseret på data og adgang
Dernæst data: Behandler leverandøren personoplysninger, helbredsdata, børn/unge-data, socialdata, løn, sagsakter eller fortrolige beslutningsgrundlag? Og hvilken adgang får de: admin-rettigheder, fjernadgang, API-nøgler, log-adgang eller fysisk adgang? Mini-konklusion: Kritikalitet afgøres af konsekvens og adgang, ikke af kontraktens størrelse.
- Kritisk: Drift af centrale platforme, identitet, netværk eller fagsystemer med høj tilgængelighedskrav
- Kritisk: Behandling af følsomme persondata eller store datamængder med høj samfundsmæssig konsekvens
- Ikke-kritisk: Standardværktøjer uden følsomme data og uden privilegeret adgang
- Ikke-kritisk: Rådgivning uden systemadgang og uden dataudtræk
- Gråzone: SaaS med almindelige persondata, hvor kommunen stadig ejer konfiguration og brugeradgang
Standard kravpakke: minimumskrav der kan genbruges
Når klassificeringen er på plads, skal I have en kravpakke, der ikke opfindes på ny hver gang. Det reducerer både omkostninger og variation i kvalitet. Spørgsmålet “hvad koster det?” handler ofte om tid: bedre krav tidligt koster mindre end brandslukning senere.
Tekniske og organisatoriske minimumskrav
Følgende krav fungerer som et solidt udgangspunkt, der kan skærpes for kritiske leverandører. Hold dem konkrete, testbare og bundet til evidens.
- MFA på alle administrative konti og fjernadgang, gerne phishing-resistent hvor muligt
- Logging af adgang, ændringer, admin-aktiviteter og relevante sikkerhedshændelser med passende retention
- Incident notification med tidsfrister, kontaktveje og minimumsindhold i en hændelsesrapport
- Underleverandører: krav om forhåndsinformation, flow-down af sikkerhedskrav og mulighed for at afvise højrisikoled
- Backup og gendannelsestest, herunder RPO/RTO mål og dokumenterede øvelser
- Exit-plan: dataudlevering, format, sletning, overgangsperiode og støtte ved leverandørskifte
Mini-konklusion: En standard kravpakke virker bedst, når den kan genbruges, måles og bindes til kontrakt og drift.
Kontrakt og review-cadence: før køb, ved fornyelse og årligt
Leverandørstyring fejler sjældent på vilje, men ofte på timing. Hvis krav først stilles efter underskrift, bliver de til “nice to have”. En fast cadence gør det muligt at spørge det rigtige på det rigtige tidspunkt og følge op uden at drukne i ad hoc.
Før køb: due diligence der matcher risiko
Før indkøb bør kommunen lave en risikovurdering, der matcher klassificeringen. For kritiske leverandører: kræv sikkerhedsbeskrivelser, relevante certificeringer eller rapporter og klare svar på adgangsmodeller, datalagring og underleverandører. For ikke-kritiske leverandører kan en light-proces være tilstrækkelig, så længe den er dokumenteret.
Ved fornyelse og årligt: driftens virkelighed
Ved kontraktfornyelse bør I opdatere risikobilledet: nye integrationer, nye data, nye trusler og ændret leverandørsetup. Årligt review kan være en kort kontrol med fokus på ændringer, hændelser, resultater fra tests og status på aftalte forbedringer. Midt i arbejdet med forsyningskædesikkerhed er det ofte dette årshjul, der skaber den varige effekt.
Mini-konklusion: Cadence slår enkeltstående audits, fordi den fanger ændringerne, der ellers sniger sig ind.
Cloud og “shared responsibility” i kommunal praksis
Cloud kan være sikker, men kun hvis man forstår ansvarsdelingen. “Shared responsibility” betyder, at leverandøren typisk sikrer platformen, mens kommunen sikrer sin brug af platformen. For kommuner er det især vigtigt, fordi mange hændelser skyldes fejlkonfiguration, for brede rettigheder eller manglende overblik over dataflow.
Hvad leverandøren typisk har ansvaret for
Leverandøren har ofte ansvaret for fysisk sikkerhed i datacentre, hypervisor/underliggende infrastruktur, basispatching af platformskomponenter og robusthed i selve tjenesten. De leverer også standardlogs, driftsstatus og sikkerhedsfeatures som kan aktiveres.
Hvad kommunen stadig skal kunne og dokumentere
Kommunen skal typisk kunne styre identiteter og adgang, konfigurere sikkerhedsindstillinger, definere dataklassifikation, sikre korrekt logopsamling til eget overblik og håndtere livscyklus for brugere og privilegier. Derudover skal kommunen kunne gennemføre beredskab: hvem gør hvad ved hændelser, hvordan sikres kommunikation, og hvordan gendannes kritiske funktioner.
Mini-konklusion: I cloud er manglende konfiguration ofte den største risiko, ikke leverandørens datacenter.
Evidens: hvad skal gemmes, så det ikke kun er “vi spurgte dem pænt”?
NIS2-lignende krav falder ofte på dokumentation i praksis. En mailtråd med “ja, vi gør det” er sjældent nok, hvis noget går galt, eller hvis revisionen spørger. Evidens skal være sporbar, opdateret og knyttet til krav og risici.
- Seneste sikkerhedsbeskrivelse eller kontrolrapport (fx SOC 2-rapport eller tilsvarende)
- Databehandleraftale og oversigt over underleverandører med ændringslog
- Incident-proces: kontaktliste, eskalationsvej og skabelon til hændelsesrapport
- Tilgængeligheds- og backupdokumentation, herunder testresultater og datoer
- Log- og adgangsmodel: hvilke logs findes, hvordan tilgår kommunen dem, og retention
- Risikovurdering og beslutningsnotat: hvorfor leverandøren er accepteret, og på hvilke vilkår
Gem også bevis for, at kommunen har fulgt op: mødenotater, action-lister, frister og lukning. Mini-konklusion: Evidens er både leverandørens bilag og kommunens egne beslutningsspor.
Typiske fejl og bedste praksis i kommunal leverandørstyring
Mange spørger: “Hvilke fejl ser man oftest, og hvordan undgår vi dem?” Her er de mest almindelige faldgruber, især når indkøb, jura og IT arbejder parallelt uden fælles model.
Faldgruber der går igen
- Man klassificerer alle som “kritiske” og ender med en udrulig proces
- Man klassificerer ingen og kan ikke forklare prioriteringer eller tilsyn
- Man accepterer uklare formuleringer som “industry standard” uden målepunkter
- Man glemmer underleverandører, integrationer og supportadgange
- Man får fine bilag ved køb, men ingen årlig opfølgning
Bedste praksis der giver effekt
Hold en enkel model med få niveauer, bind krav til niveau, og lav en fast review-cadence. Sørg for, at de samme minimumskrav går igen i alle kontrakter, og at undtagelser kræver risikoejerens godkendelse. Mini-konklusion: En lille, konsekvent proces slår en stor, uensartet proces.
1-side leverandørscorecard (kan bruges i indkøb og årlig review)
Scorecardet er tænkt som et enkelt ark, der kan udfyldes på 15–30 minutter for ikke-kritiske leverandører og udvides for kritiske. Brug det både før køb, ved fornyelse og i det årlige review, så I kan sammenligne leverandører over tid.
- Leverandør: Navn, ydelse, kontraktperiode, kontaktpunkter (forretning/IT/sikkerhed)
- Klassificering: Kritisk/ikke-kritisk + kort begrundelse (ydelse, data, adgang)
- Data: Datatyper, datalokation, retention, sletning ved ophør
- Adgang: Supportadgang, admin-rettigheder, MFA-krav, privilegeret adgangsstyring
- Logging: Hvilke logs findes, adgang til logs, retention, alarmering/overvågning
- Hændelser: Notifikationskrav, responstider, seneste hændelser og læring
- Backup og robusthed: RPO/RTO, testfrekvens, dokumenteret gendannelse
- Underleverandører: Liste, ændringer siden sidst, flow-down af krav, godkendelsesret
- Compliance-bilag: Rapporter/certificeringer, dato, dækningsgrad, afvigelser
- Exit: Dataudlevering, format, overgang, omkostninger, bekræftet sletning
- Score: Grøn/gul/rød pr. område + samlet risikoniveau
- Actions: 3–5 konkrete forbedringer, ansvarlig, deadline, status
Mini-konklusion: Når scorecardet bliver udfyldt konsekvent, får kommunen både overblik, prioritering og dokumentation uden at gøre processen tungere end nødvendigt.
