TLS-certifikater er dukket op som et standardpunkt på revisionsagendaen — og ikke kun i ISO 27001-audits. NIS2-tilsyn, ISAE 3000-rapportering, interne revisioner og leverandørevalueringer begynder alle at stille specifikke spørgsmål om, hvordan organisationen styrer sine certifikater.

Mange IT-chefer og CISO'er opdager det sent: at det spørgsmål revisorerne stiller ikke er "har I TLS?" men "kan I dokumentere at I styrer jeres TLS systematisk?"

Hvad ISO 27001 kræver

ISO 27001:2022 Annex A kontrol 8.24 omhandler eksplicit brug af kryptografi og nøglestyring. Kontrol 8.20 dækker netværkssikkerhed inkl. TLS-konfiguration. Kontrol 5.9 og 5.10 handler om aktivfortegnelse og acceptable brug.

Revisor vil typisk spørge:

  • Har I en politik for brug af kryptografi og certifikater?
  • Er alle certifikater registreret — hvem ejer dem, hvornår udløber de?
  • Er der en defineret proces for fornyelse og hvem der er ansvarlig?
  • Kan I dokumentere at fornyelser gennemføres rettidigt?
  • Hvad sker der med certifikater der ikke længere er i brug?

Hvad NIS2-tilsyn kigger efter

NIS2-tilsyn er mere procesorienteret end ISO 27001. Tilsynet vil undersøge om organisationen har et velfungerende risikostyringssystem — og certifikater er en målbar, konkret del af det.

Spørgsmål der typisk stilles:

  • Har I et komplet aktivregister over jeres informationssystemer og de certifikater de bruger?
  • Har I dokumenteret risiciene forbundet med certifikatudløb og TLS-konfiguration?
  • Hvad er jeres kontroller for at sikre at certifikater fornys inden udløb?
  • Kan I vise historik over hændelser og hvad der blev gjort?
  • Hvad er jeres procedure for at rapportere en certifikatrelateret hændelse?

Hvad der er sværest at svare på

Baseret på revisionssamtaler er der typisk tre spørgsmål organisationer har sværest ved at besvare tilfredsstillende:

"Er I sikre på at jeres certifikatregister er komplet?" — Svaret "vi tror det er komplet" er ikke et godt svar. Revisor vil forstå processen: hvordan ved I at der ikke er certifikater I ikke kender til? Automatiseret scanning og CT-log overvågning er det eneste svar der holder.

"Hvad skete der senest en fornyelse fejlede eller trak ud?" — Hvis I ikke har et system der logger dette, kan I ikke svare. Et tomt svar signalerer at I ikke ved det — ikke at der ikke er sket noget.

"Hvem er ansvarlig for certifikat X?" — For certifikater på systemer hostet af leverandører eller oprettet af afdelinger uden for IT er svaret ofte uklart. Det er et rødt flag for revisor.

Hvad der faktisk imponerer revisorerne

Erfaringen fra organisationer der klarer revisioner godt på dette område er konsistent:

  • De kan trække en aktuel rapport over alle certifikater med status og udløbsdatoer med få klik
  • De kan vise en tidsserie der dokumenterer at monitoring har kørt kontinuerligt
  • De har en dokumenteret, navngiven ansvarlig for hvert certifikat
  • De kan vise at advarslerne fungerer — fx ved at vise de seneste alarmnotifikationer
  • De har en skriftlig procedure for certifikathændelser — kort og operationel

Ingen af disse krav er svære at opfylde med det rigtige værktøj. Det er svært at opfylde med regneark og kalendernotater.

Forberedelse til revision: Tjekliste

  • Komplet certifikatregister med udløbsdatoer, ejere og tilknyttede systemer
  • Dokumenteret monitoringstatus — hvornår kørte sidste scanning?
  • Alarmkonfiguration — hvem modtager advarsler og ved hvilke tærskler?
  • Hændelsesprocedure for certifikatudløb og kompromittering
  • Liste over leverandørers certifikater på jeres domæner
  • Rapport over udløbte certifikater de seneste 12 måneder og hvad der skete
  • Kryptografipolitik med reference til TLS-standarder og certifikatkrav

Hvad CertControl leverer til revisionen

Tjeklisten og de tre svære spørgsmål ovenfor er præcis hvad CertControl adresserer — ikke som en forberedelse til revision, men som en bivirkning af løbende drift:

  • "Er I sikre på at jeres certifikatregister er komplet?" — CertControl forespørger Certificate Transparency-logs og kører aktiv netværksscanning kontinuerligt. Registret opdateres automatisk ved nye udstedelser. Svaret på revisorens spørgsmål er en rapport, ikke en undskyldning.
  • "Hvad skete der senest en fornyelse fejlede eller trak ud?" — CertControl logger alle hændelser med tidsstempel: hvornår advarsler udløste, hvem de gik til, hvornår certifikater blev fornyet eller udløb. Denne log kan ikke laves baglæns og er svær at bestride.
  • "Hvem er ansvarlig for certifikat X?" — Hvert certifikat i CertControl har en navngivet ejer tildelt i systemet. Svaret er i platformen, ikke i nogens hoved.
  • Komplet certifikatoversigt med udløbsdatoer og status med få klik. Executive-rapporten i CertControl viser certifikatstatus, udløbsprognoser og compliance-score. Den kan genereres on-demand og eksporteres — ikke samlet fra spredte systemer dagen inden revisionen.
  • TLS-konfigurationsscanning på tværs af alle endepunkter. Cipher suites, protokolversioner og sikkerhedsheadere kontrolleres automatisk. Svage konfigurationer på staging-miljøer og interne systemer — det typiske røde flag ved revisioner — dukker op som findings i CertControl uden manuel scanning.
Se platformen Book en gennemgang