Hvis din kommune stadig ser cybersikkerhed som noget, IT-afdelingen “ordner”, mens leverandører og it-partnere passer sig selv, er der en ubehagelig overraskelse på vej: de nye cyberkrav flytter ansvaret helt ind i ledelsesrummet.
I denne artikel får du et praktisk overblik over, hvorfor kommuner bør styrke kontrol og governance over leverandører, hvordan man gør det uden at kvæle drift og innovation, og hvilke konkrete greb der giver mest effekt. Du får også typiske faldgruber, prisniveauer og eksempler fra hverdagen i kommunal it, hvor eksterne parter ofte har mere adgang, end man tror.
Du kan bruge teksten som tjekliste til dialogen med direktion, it-chef, DPO, indkøb og leverandører—og som afsæt for en plan, der kan tåle både revision, tilsyn og virkelige angreb.
Nye cyberkrav gør leverandører til et ledelsesansvar, ikke et bilag
Definition: Leverandørstyring og it-governance i kommunen er de processer, aftaler og kontroller, der sikrer, at eksterne leverandører leverer sikkert, lovligt og i tråd med kommunens risikotolerance—både før kontrakt, under drift og ved ophør. Det betyder noget, fordi en leverandør i praksis kan være “en del af kommunen”, når de har adgang til data, systemer eller netværk.
De seneste års udvikling i krav og forventninger—fra skærpede tilsynspraksisser til NIS2-krav og øget fokus på kritiske leverandørkæder—har ændret spillereglerne. Det er ikke nok at have en databehandleraftale liggende i en mappe. Kommunen skal kunne dokumentere, at man løbende styrer leverandørrisici, og at man kan reagere hurtigt, hvis en leverandør bliver ramt.
Mini-konklusion: Kravene bevæger sig fra “har vi papir?” til “har vi kontrol i praksis?”.
Hvorfor leverandører er den blinde vinkel i kommunal cybersikkerhed
Kommuner har typisk en kompleks leverandørportefølje: fagsystemer, driftsleverandører, integratorer, SaaS-platforme, konsulenthuse, supportpartnere og nicheleverandører. Mange af dem har fjernadgang, admin-rettigheder eller håndterer persondata i stor skala.
Den klassiske udfordring er, at risikoen ikke følger kontraktens størrelse. En lille leverandør med adgang til en integrationsplatform kan være en større risiko end en stor leverandør, der kun leverer licenser.
Angrebsfladen vokser med integrationer og fjernadgang
I praksis ser jeg ofte, at kommuner har 30–100+ integrationer på tværs af systemer. Hver integration betyder nøgler, tokens, servicekonti og dataflows. Hvis en leverandør kompromitteres, kan det give en “motorvej” ind i kommunens miljø—særligt hvis adgangen er permanent og ikke overvåges.
“Skyen” flytter ikke ansvaret væk
SaaS og cloud kan være mere sikkert end on-prem, men kun hvis governance følger med. Misforståelsen er, at leverandørens certificeringer automatisk dækker kommunens konkrete opsætning, brugeradgange og integrationsdesign. Shared responsibility betyder netop delt ansvar—ikke fralagt ansvar.
Mini-konklusion: Leverandørens adgang og dataflows er ofte den reelle angrebsvej, også når kommunen har stærk intern sikkerhed.
Hvad betyder “styrket kontrol og governance” i praksis?
Styrket governance handler ikke om flere møder for mødernes skyld. Det handler om at etablere en styringsmodel, hvor kommunen konsekvent kan svare på: Hvem har adgang? Hvad må de? Hvordan kontrollerer vi det? Hvad gør vi, når noget går galt?
- Risikoklassificering af leverandører (kritikalitet, data, adgang, afhængigheder)
- Standardkrav til sikkerhed (MFA, logging, patching, kryptering, sårbarhedshåndtering)
- Kontrakt- og bilagsstyring (SLA, sikkerhedsbilag, databehandleraftaler, underdatabehandlere)
- Driftskontroller (adgangsreviews, log-review, ændringsstyring, beredskabsøvelser)
- Leverandør- og revisionsdialog (ISAE 3000/3402, SOC-rapporter, pentest-resuméer)
- Exit- og kontinuitetsplaner (dataudtræk, overgang, nøddrift, “break glass”)
Et konkret tegn på modenhed er, at kommunen kan trække en liste over kritiske leverandører på 10 minutter—inklusive systemejere, kontraktstatus, datatyper, integrationspunkter og seneste kontrolaktiviteter.
Mini-konklusion: Governance er bedst, når den er målbar: få, faste kontroller der gentages og dokumenteres.
Kontrakter, krav og dokumentation: sådan løfter I niveauet uden at drukne i papir
Typiske spørgsmål i kommuner er: “Hvilke krav skal vi stille?” og “Hvordan dokumenterer vi det uden at skabe udbudsmæssig friktion?”. Svaret er at arbejde med en skalerbar kravpakke, hvor de tungeste krav er reserveret til de mest kritiske leverandører.
Minimumskrav (baseline) vs. skærpede krav (kritiske leverandører)
Baseline kan fx omfatte MFA, sikkerhedslogging, håndtering af sårbarheder, rettighedsstyring, incident-notifikation og underdatabehandlerstyring. Skærpede krav kan inkludere krav om uafhængig revision, hyppigere rapportering, krav til RTO/RPO, kryptering af data i hvile og transport, samt dokumenteret sikkerhedstræning hos leverandøren.
Dokumentation der virker i virkeligheden
Det er fristende at kræve “ISO 27001” af alle, men det kan både være urealistisk og give falsk tryghed. Bedre er at kræve konkret evidens: seneste revisionsrapport, sårbarhedsproces, oversigt over sikkerhedshændelser, samt en erklæring om hvem der har adgang til kommunens data og hvordan den adgang kontrolleres.
Midt i den praktiske implementering bliver mange kommuner hjulpet af at strukturere arbejdet omkring leverandørstyring i kommuner som et samlet spor, hvor indkøb, jura, it-drift og informationssikkerhed bruger samme risikomodel og samme kontrolpakke.
Mini-konklusion: God dokumentation er konkret og risikobaseret—ikke en samling generelle certificeringsønsker.
Kontroller der fanger problemerne tidligt: adgang, logs og ændringer
“Hvordan gør vi?” er ofte den vigtigste del. Mange kommuner har aftalerne på plads, men mangler driftsnære kontroller. Tre områder giver typisk hurtigst effekt: adgang, overvågning og ændringsstyring.
Adgangsstyring: fra “fast admin” til styret, tidsbegrænset adgang
Jeg ser stadig leverandørkonti med brede rettigheder og ingen udløb. Det er en invitation til misbrug og en gave ved kompromittering. Praktiske greb:
- Indfør MFA på alle leverandøradgange (også “service accounts”, hvor det er muligt)
- Brug tidsbegrænset adgang til admin (just-in-time), især til drift og fejlsøgning
- Krav om navngivne brugere—undgå delte konti
- Kvartalsvis access review for kritiske systemer med systemejer som ansvarlig
Logging og opfølgning: hvis ingen kigger, findes hændelsen ikke
Logs hjælper kun, hvis nogen følger op. I praksis bør I definere, hvilke hændelser leverandøren skal logge, hvor længe, og hvordan kommunen får adgang til logudtræk ved mistanke. En pragmatisk løsning kan være månedlige rapporter for kritiske systemer og en tydelig eskalationsvej ved afvigelser.
Mini-konklusion: Adgang + logging + ændringskontrol er den praktiske triade, der stopper mange leverandørrelaterede hændelser, før de eskalerer.
Incident response og beredskab: når leverandøren bliver ramt, rammes kommunen
“Hvad gør vi, når det sker?” bør være afklaret, før det sker. Når en leverandør får et ransomware-angreb, er kommunen ofte afhængig af deres tempo, transparens og prioritering. Derfor skal incident-krav være konkrete og testede.
- Krav om tidsfrister for notifikation (fx inden for få timer ved bekræftet brud)
- Tydelig rollefordeling: hvem kommunikerer hvad til hvem (it, ledelse, DPO, kommunikation)
- Adgang til beviser: logudtræk, tidslinje, scope, påvirkede data
- Krav om læring: root cause og forebyggende tiltag med deadlines
- Mulighed for kommunal deltagelse i øvelser (table-top) mindst én gang årligt for kritiske leverandører
En konkret øvelse kan være: “Leverandørens supportportal er nede, og der er mistanke om datalæk—hvilke systemer kan kommunen stadig drive, hvad er nødproceduren, og hvem godkender midlertidige løsninger?”
Mini-konklusion: Beredskab er ikke en plan i PDF; det er en samarbejdsform, der skal kunne afvikles på en mandag kl. 07:30.
Hvad koster det at styrke governance? (og hvad koster det ikke at gøre det)
Spørgsmålet om økonomi kommer altid: “Hvad koster det?” Svaret afhænger af modenhed og leverandørlandskab, men man kan tænke i tre lag: etablering, drift og leverandørkrav.
Etablering kan ofte gøres med 4–12 ugers fokuseret indsats for at få risikomodel, skabeloner og top-10 kritiske leverandører på plads. Drift kræver typisk faste timer pr. måned til opfølgning, reviews og leverandørmøder. Mange kommuner ender med en model, hvor systemejere tager en del, mens informationssikkerhed/it-sikkerhed driver metode og kvalitet.
Det dyre er sjældent governance-arbejdet. Det dyre er nedetid, genopretning, juridisk håndtering og tab af tillid. En enkelt større driftsforstyrrelse i et fagsystem kan hurtigt koste mange hundrede arbejdstimer på tværs af forvaltninger. Og ved et brud med persondata kan udgifterne til analyse, notifikationer, ekstern bistand og ekstra drift løbe voldsomt op—selv uden bøder.
Mini-konklusion: Governance er en relativt lille, løbende udgift, der reducerer sandsynligheden for store, uforudsigelige omkostninger.
Typiske fejl kommuner begår—og hvordan I undgår dem
De samme faldgruber går igen, uanset kommune og størrelse. Her er de mest almindelige, og hvad der virker i praksis.
- Fejl: Man stiller krav, men følger ikke op. Løsning: Planlæg faste kontrolpunkter (kvartal/halvår) og gør det til en del af systemejerens årshjul.
- Fejl: Man fokuserer kun på persondata og glemmer drift/tilgængelighed. Løsning: Risikovurder på CIA (fortrolighed, integritet, tilgængelighed) og tag RTO/RPO alvorligt.
- Fejl: Man har ikke styr på underleverandører. Løsning: Kræv opdateret liste over underdatabehandlere og ret til indsigelse ved kritiske ændringer.
- Fejl: Man accepterer delte leverandørkonti “for nemhedens skyld”. Løsning: Navngivne identiteter, MFA og sporbarhed som minimum.
- Fejl: Man mangler exit-plan og bliver låst fast. Løsning: Indbyg krav til dataudtræk, overgangsstøtte og dokumentation ved ophør.
Mini-konklusion: De fleste problemer skyldes ikke manglende politikker, men manglende rytme og ansvar for opfølgning.
Sådan kommer I i gang: en realistisk 60-dages plan
Hvis I vil løfte governance uden at starte et flerårigt program, kan I komme langt på 60 dage med en fokuseret, risikobaseret indsats. Her er en praksisnær rækkefølge, der typisk fungerer i en kommune med mange systemer og begrænsede ressourcer:
- Lav en top-20 liste over leverandører med adgang til data/systemer og klassificér dem (kritisk/høj/middel/lav).
- Udpeg systemejer og kontraktejer pr. kritisk leverandør—ingen “fælles ansvar”.
- Indfør en baseline-kravpakke og et sikkerhedsbilag, der kan genbruges i nye og eksisterende aftaler.
- Gennemfør adgangsreview for top-10: fjern delte konti, indfør MFA, og dokumentér admin-adgang.
- Aftal incident-proces og kontaktliste med top-10, inkl. krav til notifikation og evidens.
- Planlæg første kontrolcyklus: kvartalsvis for kritiske, halvårlig for høj, årlig for resten.
Hvis I har brug for en tommelfingerregel: Start med de leverandører, der både har høj adgang og høj forretningskritikalitet. Det er her, governance flytter risiko mest pr. investeret time.
Mini-konklusion: Hurtige forbedringer kommer af at fokusere på de få leverandører, der kan vælte mest, og gøre opfølgning til en fast proces.
