Cybersikkerhed i kommuner: governance før teknologi

Hvis din kommune køber endnu et sikkerhedsværktøj i håb om ro i maven, men stadig ikke kan svare klart på “hvem ejer risikoen?” og “hvad gør vi, når det brænder på?” – så er problemet ikke teknikken.

Den her artikel viser, hvorfor governance, ansvarsfordeling og processer bør ligge forrest i kommunal cybersikkerhed, og hvordan I konkret bygger fundamentet, før I investerer i flere systemer. Du får en praktisk model, typiske faldgruber, eksempler fra kommunal hverdag (leverandører, driftsmiljøer, fagsystemer og beredskab) samt en enkel tjekliste til at komme i gang.

Vi går også ind i de spørgsmål, der ofte stopper arbejdet: Hvad betyder governance i praksis? Hvorfor er det dyrere at starte med værktøjer? Hvordan fordeler man ansvar i en organisation med mange fagområder? Og hvad koster det realistisk at få styr på processerne?

Hvad betyder “governance” i cybersikkerhed – og hvorfor betyder det så meget?

Cybersikkerhedsgovernance er de principper, beslutningsfora, roller og styringsmekanismer, der sikrer, at sikkerhed bliver prioriteret, ejet og fulgt op på på tværs af kommunen. Kort sagt: hvem beslutter hvad, på hvilket grundlag, og hvordan sikrer vi, at det faktisk sker.

Det betyder noget, fordi kommuner typisk har en kompleks virkelighed: mange fagsystemer, mange leverandører, 24/7-drift, blandede miljøer (on-prem, cloud, SaaS), og store konsekvenser ved nedbrud i fx hjemmepleje, skole, borgerservice eller socialområdet. Uden governance bliver sikkerhed et IT-projekt. Med governance bliver det en ledelsesdisciplin.

Mini-konklusion: Værktøjer kan reducere risiko, men kun governance kan styre den.

Hvorfor værktøjer og teknik ofte fejler, når fundamentet mangler

Jeg ser ofte, at kommuner investerer i EDR, SIEM, sårbarhedsscannere, awareness-platforme eller nye IAM-løsninger – men ender med et “værktøjslandskab” uden effekt. Årsagen er sjældent, at værktøjet er dårligt, men at organisationen ikke er klar.

Symptomer på “tool-first” sikkerhed

• Alarmer bliver ikke triageret konsekvent, fordi der ikke er en aftalt vagtordning eller eskalationsvej.
• Rapporter produceres, men ingen ejer beslutningen om risikotolerance eller prioritering.
• Sårbarheder scannes, men patching halter, fordi driften mangler proces, vinduer og godkendelser.
• Adgange gennemgås, men ingen kan afgøre, hvem der må godkende afvigelser i fagområderne.
• Incident response-planer findes, men ingen har øvet dem, og kontaktlister er forældede.

Den skjulte omkostning: drift og koordinering

Tekniske løsninger kræver driftskapacitet: opdateringer, tuning, logkilder, integrationer, datakvalitet og opfølgning. Når governance og processer mangler, bliver værktøjet enten underudnyttet eller en ny kilde til “støj”. Over tid betaler I både licens og frustration.

Mini-konklusion: Uden klare roller og arbejdsgange bliver selv de bedste sikkerhedsværktøjer til dyre dashboards.

Kommunal virkelighed: derfor er governance ekstra vigtigt i en kommune

Kommuner har særlige vilkår, der gør “bare implementér et tool” til en farlig strategi. Der er mange interessenter, spredt ansvar, og høj afhængighed af eksterne leverandører – ofte med lange kontrakter og systemer, der ikke kan ændres hurtigt.

Fagområder og kritiske services

Cybersikkerhed er ikke kun et IT-anliggende, når konsekvensen rammer borgernære ydelser: hvis journaladgang i hjemmeplejen går ned, eller et centralt fagsystem låses, er det en drifts- og ledelseskrise. Det kræver, at forvaltningerne forstår deres rolle: klassificering, prioritering af genopretning og accept af restriktioner (fx MFA, segmentering eller strengere adgangsstyring).

Leverandørstyring som sikkerhedsfunktion

En stor del af kommunal it er outsourcet eller baseret på SaaS. Derfor er leverandørstyring reelt en del af sikkerhedsarbejdet: krav til logning, hændelsesrapportering, patching, databehandleraftaler, exit-planer og test af beredskab. Uden governance ender kravene i skuffen eller bliver “nice to have”.

Mini-konklusion: I kommuner skal sikkerhed styres på tværs af fag, drift og leverandører – ellers opstår huller mellem stolene.

Ansvarsfordeling: hvem ejer risikoen, og hvem gør arbejdet?

Et af de mest oversete spørgsmål i kommunal cybersikkerhed er: hvem er egentlig ansvarlig for hvad? IT kan drive tekniske kontroller, men IT kan ikke alene eje forretningsrisikoen ved nedbrud, datalæk eller manglende tilgængelighed.

Brug en simpel RACI-tankegang

I praksis fungerer en enkel RACI-model godt: hvem er Responsible (udfører), Accountable (ejer beslutningen), Consulted (høres), Informed (orienteres). Det behøver ikke være tungt, men det skal være konkret for de vigtigste processer: adgangsstyring, patching, backup, incident response, leverandørændringer og risikovurdering.

Minimumsroller der typisk skal være tydelige

1. Risikoejer i forretningen (typisk fagchef eller direktørområde) for kritiske services og data.
2. CISO/sikkerhedsansvarlig (kan være en funktion, ikke nødvendigvis en fuldtidsrolle) som rammesætter kontroller og rapportering.
3. IT-drift som udfører kontroller og ændringer, med klare SLA’er og ændringsprocesser.
4. DPO/jura ift. persondata, brudshåndtering og krav til leverandører.
5. Indkøb/kontraktstyring som sikrer, at sikkerhedskrav faktisk kommer med i kontrakter og opfølgning.
6. Beredskabsansvarlig (ofte sammen med IT) der koordinerer øvelser og krisestyring.

Mini-konklusion: Når “accountability” er uklar, bliver sikkerhed et fælles ansvar – og dermed reelt ingens ansvar.

Processer før platforme: de 6 sikkerhedsprocesser, der giver mest effekt

Hvis jeg skulle vælge seks processer, der næsten altid skaber hurtigere og mere målbar effekt end endnu et værktøj, er det disse. De kan skaleres op eller ned, men de skal være definerede, ejede og øvede.

• Risikostyring: fast cadence (fx kvartalsvis) for risikovurdering, prioritering og accept/afvisning.
• Adgangsstyring: onboarding/offboarding, privilegerede konti, periodiske reviews og afvigelsesgodkendelse.
• Sårbarheds- og patchproces: prioritering baseret på kritikalitet, patchvinduer, undtagelser og rapportering.
• Backup og gendannelse: testet restore, RPO/RTO pr. system, og klar ejer af gendannelsesbeslutninger.
• Hændelseshåndtering: triage, eskalation, kommunikation, beslutningslog og efterfølgende læring.
• Leverandør- og ændringsstyring: sikkerhedskrav, ændringsgodkendelse og opfølgning på leverandørens kontroller.

Bemærk, at flere af disse processer kan understøttes af værktøjer – men værktøjet er sekundært. Først skal I kunne beskrive, hvordan arbejdet udføres, og hvem der beslutter hvad.

Mini-konklusion: Processer skaber forudsigelighed; værktøjer skaber kapacitet. Uden forudsigelighed udnyttes kapaciteten ikke.

Sådan bygger I governance i praksis: fra mødekalender til beslutninger

Governance bliver ofte misforstået som “flere møder”. I virkeligheden handler det om få, faste beslutningspunkter, der flytter risiko fra mavefornemmelse til styret prioritering. En pragmatisk model kan se sådan ud:

• Et sikkerhedsforum (månedligt) med IT, CISO-funktion, DPO og repræsentanter fra udvalgte fagområder.
• En risikolog med tydelige ejere, status, deadlines og beslutninger om accept/mitigation.
• Et ledelsesbrief (fx kvartalsvis) med få KPI’er: patchcompliance, MFA-dækning, backup-restore test, incident response-tider og leverandørstatus.
• En fast proces for undtagelser: hvem kan godkende, hvor længe, og med hvilke kompenserende kontroller.

Hvis du arbejder specifikt med kommunal cybersikkerhed, er pointen netop at gøre styringen enkel nok til at fungere i en travl organisation, men tydelig nok til at skabe ansvar.

Mini-konklusion: Governance virker først, når den ender i beslutninger, der kan spores: “vi accepterer”, “vi prioriterer”, “vi ændrer”, “vi øver”.

Typiske faldgruber (og hvordan I undgår dem)

Her er fejl, jeg ser igen og igen, når kommuner forsøger at løfte cybersikkerhed – og hvordan de kan forebygges uden at opfinde et nyt bureaukrati.

Faldgrube 1: “IT må løse det”

Når cybersikkerhed placeres som et rent IT-ansvar, mangler mandatet til at ændre adfærd i fagområderne (fx adgangsdisciplin, klassificering, procesforankring). Løsningen er at udpege risikoejere i forretningen og koble sikkerhed til driftskritiske mål.

Faldgrube 2: KPI’er der måler aktivitet, ikke effekt

At måle “antal gennemførte awareness-kurser” siger mindre end at måle fx phishing-rapporteringstid eller andel af systemer med testet restore. Vælg 5–7 målepunkter, hvor I kan handle på afvigelser.

Faldgrube 3: Undtagelser uden udløbsdato

“Midlertidige” undtagelser bliver ofte permanente. Kræv altid udløbsdato, risikovurdering og kompenserende kontrol (fx strengere logning eller netsegmentering), og lad undtagelser være synlige i risikologgen.

Mini-konklusion: De fleste sikkerhedsbrister er ikke tekniske mysterier – de er styringshuller, der får lov at leve for længe.

Hvad koster det at starte med governance og processer?

Omkostninger afhænger af modenhed, størrelse og leverandørlandskab, men governance og processer er ofte billigere end nye platforme, fordi de primært kræver tid, koordinering og ledelsesfokus. Den reelle investering ligger i at få de rette personer til bordet og skabe en fast rytme.

Som tommelfingerregel ser jeg ofte, at kommuner kan komme langt med:

• 2–6 ugers arbejde for at kortlægge kritiske services, risikoejere og de vigtigste processer (workshops + dokumentation).
• 1–2 timer ugentligt pr. nøgleperson i en opstartsperiode til at få cadence, risikolog og undtagelsesflow i drift.
• 1–2 øvelser årligt af incident response og gendannelse, hvor resultaterne munder ud i konkrete forbedringer.

Det er sjældent “gratis”, men det er ofte den billigste måde at få effekt af de værktøjer, I allerede betaler for. Og når fundamentet er på plads, bliver det markant nemmere at lave business case for nye investeringer, fordi behov og gevinst er tydeligere.

Mini-konklusion: Governance koster primært tid og disciplin – og sparer typisk penge ved at reducere spild, dobbeltarbejde og panikindkøb.

Bedste praksis: en 30-dages plan til at komme i gang

Hvis du skal omsætte det her til handling uden at drukne organisationen, så start small og målrettet. Her er en realistisk 30-dages plan, jeg ville bruge som editor og rådgiver på et kommunalt setup.

1. Identificér 5–10 mest kritiske services (fx hjemmepleje, løn, ESDH, borgerkontakt, netværk/AD) og udpeg en risikoejer pr. service.
2. Lav en enkel risikolog: top 10 risici, nuværende kontroller, gap, ejer, deadline og beslutning (mitigér/acceptér).
3. Definér én fælles incident response-proces (triage, eskalation, kommunikation) og gennemfør en mini-tabletop på 60 minutter.
4. Vælg to “hårde” procesmål for næste kvartal: fx restore-test på de 3 vigtigste systemer og patchcompliance over en fast tærskel.
5. Indfør undtagelsesproces med udløbsdato og ledelsesgodkendelse.
6. Fastsæt møderytme: månedligt sikkerhedsforum og kvartalsvis ledelsesbrief med 5 KPI’er.

Efter 30 dage har I ikke “løst cybersikkerhed”, men I har skabt styring, ejerskab og fremdrift. Derefter giver det mening at evaluere, hvilke værktøjer der mangler for at understøtte processerne – ikke omvendt.

Mini-konklusion: Når governance og processer sidder, bliver tekniske valg et spørgsmål om optimering i stedet for brandslukning.