--- title: "NIS2-loven gælder for offentlige webplatforme" description: "NIS2 klassificerer offentlige myndigheder som vigtige enheder med krav til hændelseslog og adgangsstyring - men de fleste leverandørkontrakter er ikke opdateret til det." date: "2026-07-10" created: "2026-07-10" --- # NIS2-loven gælder for offentlige webplatforme NIS2 klassificerer offentlige myndigheder som vigtige enheder med krav til hændelseslog og adgangsstyring - men de fleste leverandørkontrakter er ikke opdateret til det. [Hjem](https://moliri.dk/) [Viden](https://moliri.dk/viden) [NIS2-loven gælder for offentlige webplatforme](https://moliri.dk/viden/nis2-loven-gaelder-for-offentlige-webplatforme) ## NIS2-loven er trådt i kraft i Danmark Offentlige organisationer som kommuner, styrelser og ministerier er klassificeret som væsentlige enheder og er dermed underlagt kravene til risikostyring, hændelsesberedskab og logning. Det har udløst interne risikovurderinger, opdateringer til politikker og leverandørdialoger på tværs af den offentlige IT-portefølje. Ét system dukker dog sjældent op i den sammenhæng: CMS'et og kommunikationsplatformen. Det er desværre en forkert udeladelse. For tager man f.eks. en kommunal webplatform, behandler denne typisk login oplysninger for potentielt hundredvis af redaktører, fagspecialister og administratorer. Den registrerer også, hvem der har publiceret hvad og hvornår, og styrer formentlig også adgangsrettigheder til myndighedens indhold. Og det er præcis den type system, NIS2's log- og adgangsstyringskrav gælder for. ## Det vigtigste om loven ### Tre NIS2-krav der er direkte relevante for et CMS NIS2-direktivet (EU 2022/2555) og den danske implementering er principbaserede. Loven specificerer ikke, hvilke systemer der skal logge hvilke felter. Den fastslår, at organisationer skal kunne demonstrere kontrol over adgang til og brug af deres systemer. Tre kravkategorier er direkte relevante for en webkommunikationsplatform. 1. **Adgangsstyring og brugerrettighedslog.** Organisationen skal kunne dokumentere, hvem der har adgang til systemer med kommunikationsdata, og at ændringer i adgangsrettigheder registreres. For en webplatform gælder det oprettelse og sletning af brugerkonti, rolleændringer og tildeling eller fratagelse af rettigheder til bestemte sektioner eller kanaler. Revisionsevne begynder med, at disse begivenheder kan rekonstrueres. 2. **Hændelsesregistrering.** NIS2 kræver, at organisationen kan identificere sikkerhedshændelser og rekonstruere et hændelsesforløb. I en webplatform er relevante hændelser mislykkede login-forsøg (potentielle bruteforce-angreb), usædvanlig publiceringsaktivitet — mange handlinger fra én konto på kort tid — og ændringer i systemkonfiguration. Disse hændelser skal registreres, og registreringen skal være tilgængelig. 3. **Incident-rapporteringsberedskab.** Organisationer, der opdager en sikkerhedshændelse der opfylder lovens tærskel, har pligt til at rapportere til Center for Cybersikkerhed inden for snævre tidsfrister. Det kræver, at organisationen kan rekonstruere, hvad der skete i systemerne og hvornår. En log der kun kan tilgås via en supportanmodning til CMS-leverandøren er ikke et tilstrækkeligt beredskab i den situation. ### Forskellen på at logge og at levere en revisorvenlig log De fleste offentlige webplatforme logger noget. Indholdsrevisioner — hvem redigerede en side hvornår — er standardfunktionalitet. Det er nyttigt for redaktørerne. Men det er ikke den type log, der er relevant i en NIS2-revisionssituation. Et indholdsrevisionshistorik dokumenterer, hvad der stod i en tekst tidligere. Det dokumenterer ikke, hvem der loggede ind, hvornår, fra hvilken IP-adresse, og hvad de foretog sig på systemniveau. Sondringen er vigtig: internt logges der muligvis meget mere, end der er tilgængeligt via CMS'et. Leverandøren har infrastruktur-logs. De eksponeres bare ikke. Organisationen har typisk ikke direkte adgang til dem, kan ikke eksportere dem til et SIEM-system, og kender ikke retentionsperioden. Det er forskellen på at logge og at levere en revisorvenlig log, organisationen selv kontrollerer. ### Hvad der mangler i de fleste leverandørkontrakter Problemet er ikke, at CMS-leverandørerne nødvendigvis logger dårligt. Problemet er, at kontrakterne typisk ikke specificerer, hvad der logges, hvem der har adgang til loggen, i hvilke formater den kan eksporteres, og hvor lange den gemmes. Det er ikke et teknologiproblem, men nærmere et spørgsmål om at stille de rigtige krav til leverandøren. NIS2 introducerer ikke en simpel tjekliste. Det introducerer en forventning om, at organisationen som ansvarlig enhed kan demonstrere kontrol over sine systemer. Kontrol forudsætter indsigt. Indsigt kræver adgang. En kommunal IT-chef, der ikke kan besvare grundlæggende spørgsmål om sin webplatforms log-arkitektur, har et konkret hul. ## To spørgsmål at stille CMS-leverandøren For offentlige organisationer, der endnu ikke har haft denne dialog, vil følgende spørgsmål være det naturlige udgangspunkt: 1. Kan I levere en struktureret, eksportbar hændelseslog, der dækker brugerlogins, mislykkede autentificeringsforsøg og administrative handlinger — og i hvilket format? Et svar der beskriver intern logning uden eksportmulighed er ikke tilstrækkeligt, hvis organisationen skal kunne indsende dokumentation til en ekstern revision eller til Center for Cybersikkerhed. 2. Hvad er log-retentionsperioden for sikkerhedshændelser, og kan den tilpasses organisationens interne politikker? En standard 30-dages log kan være utilstrækkelig, hvis en hændelse identificeres sent. Mange organisationer opererer med minimum 12 måneders retention for sikkerhedsrelevante logs. Disse spørgsmål er ikke teknisk avancerede. De er præcis de spørgsmål en NIS2-tilsynsmyndighed vil stille — og de er væsentligt lettere at besvare, hvis de stilles til leverandøren først.