NIS2-tilsyn venter ikke på at noget går galt. Tilsynsmyndigheder har under direktivet ret til proaktivt at anmode om oplysninger, gennemføre dokumentbaserede inspektioner og i visse tilfælde foretage on-site inspektioner af vigtige og væsentlige enheder — og spørgsmålet er ikke om I har styr på jeres certifikater, men om I kan bevise det.
Fokus er ikke på at håndtere en hændelse, men på at dokumentere at organisationen løbende og systematisk styrer risici — herunder TLS-certifikaternes livscyklus — og ikke kun handler under pres.
Her er hvad I konkret skal have klar.
Aktivfortegnelse — certifikater og systemer
Tilsynet vil med stor sandsynlighed bede om dokumentation for at organisationen kender sine informationsaktiver. For certifikater betyder det:
- En liste over alle certifikater i brug, med tilhørende domæner, udstedte dato, udløbsdato og ansvarlig ejer
- Hvilke systemer certifikaterne beskytter — og systemernes klassifikation (kritisk, vigtig, normal)
- Leverandørers certifikater på organisationens domæner (forsyningskæde)
- Dokumentation for at listen er opdateret — ikke lavet til lejligheden
Det sidste punkt er afgørende: en liste over certifikater genereret dagen før tilsynet ser fundamentalt anderledes ud — og vurderes anderledes — end audit log-udtræk fra et system der har kørt kontinuerlig scanning i seks måneder. Tilsynsmyndighederne ved forskellen.
Risikovurdering for certifikatlivscyklussen
Artikel 21(2)(a) kræver risikoanalyse. For certifikater bør jeres dokumentation inkludere:
- Identifikation af risici: certifikatudløb, svag TLS-konfiguration, kompromitterede nøgler, shadow IT-certifikater
- Vurdering af sandsynlighed og konsekvens for hvert risikoområde
- De kontroller der er implementeret for at mitigere risiciene — og hvad residualrisikoen er
- Dato for seneste vurdering og hvem der er ansvarlig
En risikovurdering der er to år gammel og ikke opdateret er svær at forsvare. Risikovurderingen bør være et levende dokument med daterede revideringer.
Procedurer for certifikathændelser
Hvad sker der i jeres organisation, konkret, hvis et certifikat udløber uventet? Tilsynet vil forvente et svar der peger på dokumenterede procedurer:
- Hvem opdager det — og hvordan? (Monitoring, alarmering, borgerhenvendelse?)
- Hvem notificeres, i hvilken rækkefølge?
- Hvem har myndighed til at igangsætte nødfornyelse?
- Hvad er eskaleringsstien hvis den primært ansvarlige ikke er tilgængelig?
- Hvornår vurderes hændelsen som NIS2-rapporteringspligtig?
Disse procedurer behøver ikke være lange — men de skal eksistere, være daterede og ideelt set have spor af at være testet eller øvet.
Hændelseslog og historik
Har organisationen haft certifikatnære hændelser? Udløbne certifikater, beredskabsfornyelse, konfigurationsfejl der er opdaget? Tilsynet kan spørge — og jeres evne til at dokumentere hvad der skete, hvornår, og hvad der blev gjort, er et tegn på modning.
En historik der er fuldstændig uden hændelser kan faktisk vække mistanke: har monitoringen kørt kontinuerligt, eller er data blot ikke indsamlet? En historik med dokumenterede hændelser der er opdaget, håndteret og lukket er langt mere overbevisende end en der viser ingenting.
Forsyningskæde-dokumentation
Artikel 21(2)(d) og Artikel 22 om forsyningskædesikkerhed er et af de krav mange organisationer er dårligst forberedt på. For certifikater betyder det:
- Liste over kritiske leverandører der leverer tjenester over TLS
- Dokumentation for at leverandørernes certifikater overvåges — eller kontraktuelle krav til leverandøren om at gøre det
- Hvad der sker hvis en kritisk leverandørs certifikat udløber og forstyrrer jeres tjeneste
Hvad der er svært at lave baglæns
Al dokumentation der kræver historik er svær at rekonstruere til tilsynet. En audit-log over certifikathændelser og ændringer, en tidsserie over udløbsstatus, rapporter med dato for hvornår de blev genereret — disse er troværdige fordi de ikke kan laves baglæns.
Det er den konkrete begrundelse for at investere i automatiseret certifikatstyring nu, ikke to uger før et tilsyn: systemet bygger kontinuerligt den dokumentation I har brug for. Se NIS2-tjeklisten for en fuld oversigt over hvad tilsynsmyndigheder forventer.
Hvad CertControl producerer til NIS2-dokumentationen
De fem dokumenttyper der er beskrevet ovenfor er hvad CertControl leverer som en del af løbende drift — ikke som en forberedelsesopgave inden tilsyn:
- Certifikatregister med udløbsdatoer, ejere og tilknyttede systemer. CertControl opdager automatisk via CT-logs og aktiv scanning. Registret er altid opdateret — hvert certifikat har en navngivet ejer i systemet, og tilknyttede systemer er synlige via scanning.
- Monitoringstatus med kontinuerlig tidsserie. CertControl logger hvornår hvert endepunkt sidst blev scannet, hvilke findings der eksisterer, og om de er ændret. Tilsynet der spørger "hvornår kørte I senest scanning?" får et præcist svar med tidsstempel.
- Alarmkonfiguration og -log. Advarselsintervaller, modtagere og alarmhistorik er tilgængelige i platformen. Tilsynet der beder om bevis for at alarmer virker får loggen — ikke en forsikring om at det er tilfældet.
- Hændelsesprocedure understøttet af systemdata. CertControl giver den baggrundsinformation der muliggør hurtig vurdering: hvilke systemer er påvirket, hvad er certifikatets historik, hvornår udløber det. Det er fundamentet for en procedure der holder under NIS2's 24-timers rapporteringskrav.
- Forsyningskæde-dokumentation via leverandørovervågning. CertControl kan overvåge TLS-certifikater på kritiske leverandørers endpoints direkte. Listen over overvågede leverandørcertifikater og alarmhistorikken er dokumentationen for Artikel 21(2)(f)-opfyldelse.