NIS2-tilsyn sker ikke kun som reaktion på hændelser. 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.
For mange CISO'er er det et nyt scenarie: ikke at håndtere en hændelse, men at dokumentere at organisationen systematisk håndterer risici — herunder certifikater og TLS — som en løbende praksis og ikke blot en akutsituation.
Her er hvad du konkret skal have klar.
1. 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 kritisk: en liste genereret i forberedelse til tilsynet ser anderledes ud end en rapport fra et system der har kørt kontinuerlig scanning i 6 måneder. Tilsynsmyndighederne ved forskellen.
2. Risikovurdering for certifikatlivscyklussen
Artikel 21(2)(a) kræver risikoanalyse. For certifikater bør din 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.
3. Procedurer for certifikathændelser
Hvad sker der i din 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.
4. Hændelseslog og historik
Har organisationen haft certifikatnære hændelser? Udløbne certifikater, beredskabsfornyelse, konfigurationsfejl der er opdaget? Tilsynet kan spørge — og din evne til at dokumentere hvad der skete, hvornår, og hvad der blev gjort, er et tegn på modning.
En ren historik uden nogen hændelser kan skabe tvivl om monitoring reelt fungerer. En historik med dokumenterede hændelser og lukkede løkker er mere overbevisende.
5. Forsyningskæde-dokumentation
Artikel 21(2)(f) 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 din 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 du har brug for.