NIS2- og DORA-kontaktregistre som ISO 27001-revisionsbevis

Hændelsen kl. 02:17: Når kontaktlisten bliver kontrollen

Kl. 02:17 en tirsdag ser SOC-analytikeren det mønster, ingen ønsker at se. En privilegeret servicekonto er blevet autentificeret fra en usædvanlig geografi, kunderegistre er blevet forespurgt sekventielt, og en managed detection-leverandør har oprettet en sag med høj alvorlighed. Inden for få minutter bekræfter hændelseslederen bekymringen: indikatorer på ransomware spreder sig lateralt, en kritisk produktionstjeneste er forringet, og kundedata kan være involveret.

Den tekniske respons starter hurtigt. Endpoints isoleres, identitetslogfiler udtrækkes, cloud-snapshots bevares, og den administrerede sikkerhedsleverandør tilslutter sig broen. Derefter begynder den kolde panik.

CISO spørger: “Hvem skal vi underrette?”

Jura siger, at databeskyttelsesmyndigheden muligvis skal involveres. DPO spørger, om der er tale om et brud på persondatasikkerheden. COO siger, at cloududbyderen skal eskaleres i henhold til virksomhedens supportklausul. Den compliance-ansvarlige spørger, om enheden er en vigtig enhed under NIS2, eller om DORA gælder, fordi tjenesten understøtter en reguleret finansiel enhed. Bestyrelsen vil vide, hvad der skal ske inden for de første 24 timer.

Ingen bestrider behovet for at kommunikere. Problemet er, at kontaktoplysninger, godkendelsesvej, juridiske udløsere og krav til bevismateriale er spredt i et gammelt regneark for forretningskontinuitet, leverandørkontrakter, e-mailtråde, en forældet compliance-wiki og én persons telefon.

Det er ikke blot en driftsmæssig ulempe. I 2026 er det et efterlevelseshul.

NIS2 har gjort trinvis hændelsesunderretning til en ledelsesforpligtelse, herunder tidlig varsling inden for 24 timer, en 72-timers underretning og en endelig rapport inden for en måned for væsentlige hændelser. DORA har etableret et særskilt regime for digital operationel robusthed for finansielle enheder, herunder IKT-hændelsesstyring, klassificering, tilsynsrapportering, IKT-tredjepartsrisiko og krisekommunikation. GDPR er fortsat relevant, når personoplysninger er involveret. ISO/IEC 27001:2022 omsætter disse forpligtelser til revisionsbart bevismateriale i ledelsessystemet.

Et register over regulatoriske kontakter lyder administrativt. Det er det ikke. Det er bindevævet mellem hændelseshåndtering, juridisk underretning, forretningskontinuitet, leverandørkoordinering, ledelsesmæssig ansvarlighed og revisionsbevis.

Clarysec behandler dette som et bevisproblem, ikke som en papirøvelse. I Zenith Blueprint: en revisors 30-trins køreplan Zenith Blueprint forklarer trin 22 i fasen Kontroller i praksis, hvorfor kontakt med myndigheder skal være fastlagt på forhånd:

Kontrol 5.5 sikrer, at en organisation er forberedt på at interagere med eksterne myndigheder, når det er nødvendigt, ikke reaktivt eller i panik, men via på forhånd definerede, strukturerede og velforståede kanaler.

Det er den reelle læring fra hændelsen kl. 02:17. Tidspunktet for at finde regulatorens underretningsportal, CSIRT-vagttelefonen, DPO-stedfortræderen, den finansielle tilsynsmyndigheds rapporteringskanal og leverandørens eskaleringsvej er før hændelsen, ikke mens rapporteringsfristen allerede løber.

Hvorfor regulatoriske kontaktregistre blev en efterlevelsesprioritet i 2026

Mange organisationer har allerede beredskabskontaktlister. Problemet er, at NIS2 og DORA kræver noget mere disciplineret end en liste med navne og telefonnumre. De kræver præcis, rollebaseret og revisionsklar kontaktstyring, som er knyttet til juridiske udløsere, eskaleringsbeføjelse, rapporteringsfrister og leverandørafhængigheder.

NIS2 gælder for en bred kreds af væsentlige og vigtige enheder på tværs af sektorer som energi, transport, bankvirksomhed, finansiel markedsinfrastruktur, sundhed, drikkevand, spildevand, digital infrastruktur, styring af IKT-tjenester, offentlig forvaltning og rumfart. Direktivet omfatter også mange digitale udbydere, herunder cloud computing-tjenester, datacentertjenester, content delivery-netværk, managed service providers, managed security service providers, online markedspladser, online søgemaskiner og sociale netværksplatforme. Medlemsstaterne skulle etablere lister over væsentlige og vigtige enheder senest den 17. april 2025 og opdatere dem mindst hvert andet år. For mange cloud-, SaaS-, managed service- og digitale platformudbydere er regulatorisk eksponering gået fra teoretisk til operationel.

DORA finder anvendelse fra den 17. januar 2025 på finansielle enheder som kreditinstitutter, betalingsinstitutter, e-pengeinstitutter, investeringsselskaber, udbydere af kryptoaktivtjenester, markedspladser, værdipapircentraler, centrale modparter, forsikrings- og genforsikringsselskaber og andre omfattede organisationer i den finansielle sektor. DORA er også meget relevant for IKT-tredjepartsøkosystemet, fordi finansielle enheder skal styre udbydere, der understøtter kritiske eller vigtige funktioner. DORA Article 17 kræver en proces for styring af IKT-relaterede hændelser, Article 18 fastsætter forventninger til klassificering, og Article 19 regulerer rapportering af større IKT-relaterede hændelser til den kompetente myndighed.

GDPR tilføjer privatlivsdimensionen. En cybersikkerhedshændelse kan blive et brud på persondatasikkerheden, hvis den indebærer hændelig eller ulovlig tilintetgørelse, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger. Den dataansvarlige skal kunne dokumentere ansvarlighed, vurdere risikoen for enkeltpersoner og, hvor det kræves, underrette tilsynsmyndigheden og eventuelt berørte registrerede.

Et modent register over regulatoriske kontakter skal derfor kunne besvare fem spørgsmål under pres:

• Hvilken CSIRT, kompetent myndighed, finansiel tilsynsmyndighed, databeskyttelsesmyndighed og retshåndhævende kontakt gælder for denne juridiske enhed, jurisdiktion og tjeneste?
• Hvilken intern rolle er godkendt til at indlede kontakt, godkende formuleringer og indsende underretninger?
• Hvilke leverandører skal kontaktes ved inddæmning, logfiler, gendannelse, bevarelse af bevismateriale eller kontraktlig rapportering?
• Hvilken kunde-, modparts- eller offentlig kommunikationsvej udløses på hvert alvorlighedsniveau?
• Hvordan dokumenterer vi, at registeret er gennemgået, testet og anvendt korrekt?

Svaret kan ikke kun ligge i jurafunktionens indbakke eller i CISO’s hukommelse. Det skal være en kontrolleret ISMS-registrering.

Hvad et revisionsklart NIS2- og DORA-kontaktregister indeholder

Et register over regulatoriske kontakter bør udformes til brug under en reel hændelse. Hvis hændelseslederen skal træffe den første eskaleringsbeslutning inden for få minutter, kan registeret ikke være en uklar liste over websites. Det skal være struktureret, verificeret og knyttet til respons-playbooken.

Et fuldstændigt register bør som minimum omfatte seks kontaktfamilier.

For det første officielle cybersikkerhedsmyndigheder: nationale CSIRTs, kompetente myndigheder, fælles kontaktpunkter, hvor det er relevant, og sektorspecifikke cybersikkerhedsmyndigheder.

For det andet finansielle tilsynsmyndigheder for DORA: kompetente myndigheder og rapporteringskanaler, der anvendes til indledende, mellemliggende og endelig rapportering af større IKT-relaterede hændelser.

For det tredje privatlivsmyndigheder: databeskyttelsesmyndigheder, logik for ledende tilsynsmyndighed ved grænseoverskridende behandling og DPO-eskaleringsveje.

For det fjerde retshåndhævelse: cyberkriminalitetsenheder, svigenheder og nødkontakter ved afpresning, ransomware, uautoriseret adgang og bevarelse af bevismateriale.

For det femte leverandører og IKT-tredjeparter: cloududbydere, administrerede sikkerhedsleverandører, managed service providers, identitetsplatforme, betalingsformidlere, udbydere af digital efterforskning og juridisk rådgiver.

For det sjette interne eskaleringsroller: hændelsesleder, CISO, DPO, chefjurist, kommunikationsansvarlig, kontinuitetsansvarlig, ledelsesgodkender, bestyrelseskontakt og serviceejer.

Registeret bør også omfatte særlige interessegrupper, hvor det er relevant, såsom ISAC’er eller sektorspecifikke informationsdelingsfællesskaber. De er ikke regulatorer, men de kan blive vigtige kanaler for trusselsintelligens og koordineret respons.

Zenith Blueprint gør dette praktisk i trin 22:

Opret eller opdater procedurer for kontakt med myndigheder under sikkerhedshændelser (5.5), herunder kontaktoplysninger for lokale CERT’er, regulatorer og retshåndhævende myndigheder. Vedligehold en tilsvarende kontaktliste for deltagelse i sikkerhedsfora eller sektorspecifikke grupper (5.6). Opbevar disse oplysninger et tilgængeligt, men adgangsstyret sted, og medtag dem i organisationens runbook for hændelseshåndtering.

Den sidste sætning er vigtig. Hvis registeret ikke er en del af runbooken for hændelseshåndtering, bliver det sandsynligvis ikke brugt, når presset er reelt.

Eksempel på kontaktregisterstruktur for en FinTech- eller SaaS-udbyder

Forestil dig en fintech-SaaS-udbyder, der understøtter betalingsanalyse for EU-kunder. Den bruger en cloududbyder, en managed detection-leverandør, en identitetsplatform, en kundesupportplatform og ekstern juridisk rådgiver. Afhængigt af dens rolle kan den være en finansiel enhed, en IKT-tredjepartsleverandør, en digital udbyder omfattet af NIS2 eller en databehandler af personoplysninger under GDPR.

Et praktisk register kunne begynde sådan:

Poster bør ikke indeholde unødvendige personoplysninger. Brug rollebaserede kontakter, hvor det er muligt, beskyt følsomme kontaktoplysninger, og sørg for offline tilgængelighed under et større nedbrud. Et register, der kun er tilgængeligt fra de samme systemer, som påvirkes af en ransomwarehændelse, er ikke robust.

Kortlægning af registeret til ISO/IEC 27001:2022-bevismateriale

Revisorer underkender sjældent en organisation, fordi den mangler et regneark. De underkender den, fordi organisationen ikke kan dokumentere, at regnearket er fuldstændigt, aktuelt, godkendt, beskyttet, testet og forbundet med faktiske processer.

ISO/IEC 27001:2022 begynder med organisationens kontekst. Clauses 4.1 til 4.4 kræver, at organisationen forstår interne og eksterne forhold, identificerer interessenter og deres krav, definerer ISMS-omfanget og forstår grænseflader og afhængigheder. Et register over regulatoriske kontakter er stærkt bevismateriale for, at juridiske, regulatoriske, kontraktlige og interessentbaserede krav er omsat til operationelle relationer.

Dernæst kommer ledelse. Clauses 5.1 til 5.3 kræver, at øverste ledelse dokumenterer lederskab, tildeler ansvar, sikrer kommunikation og understøtter ISMS. Hvis registeret identificerer, hvem der er godkendt til at underrette en CSIRT, tilsynsmyndighed eller DPA, hvem der godkender ekstern kommunikation, og hvem der rapporterer hændelsesstatus til øverste ledelse, understøtter det ledelsesbevismateriale.

Risikoplanlægning omsætter derefter forpligtelser til handling. Clauses 6.1.1 til 6.1.3 kræver en risikovurderings- og risikobehandlingsproces, sammenligning med Annex A, en anvendelighedserklæring, en risikobehandlingsplan og accept af restrisiko. Registeret bør fremgå af behandlingsplanen for risici som svigt i juridisk underretning, forsinket hændelseseskalering, leverandørresponsfejl, fejl i grænseoverskridende underretning og sammenbrud i kommunikation ved forretningskontinuitet.

Forankringerne i Annex A-kontrollerne er klare:

I Zenith Controls: vejledningen til tværgående efterlevelse Zenith Controls behandles kontakt med myndigheder som kontrol 5.5 med forebyggende og korrigerende egenskaber. Den understøtter fortrolighed, integritet og tilgængelighed og knytter an til cybersikkerhedsbegreberne Identify, Protect, Respond og Recover. Zenith Controls knytter den til hændelsesplanlægning, hændelsesrapportering, trusselsintelligens, særlige interessegrupper og hændelseshåndtering. Den forklarer også, hvorfor forhåndsetablerede kontakter til regulatorer, retshåndhævende myndigheder, nationale CERT’er eller databeskyttelsesmyndigheder muliggør hurtigere eskalering og vejledning under hændelser som væsentlige brud eller ransomwareangreb.

Kontrollen står ikke alene. Zenith Controls kortlægger også kontrol 6.8, Information security event reporting, som en opdagende kontrol knyttet til hændelsesplanlægning, hændelsesvurdering, respons, erfaringer, bevidstgørelse, overvågning og disciplinær proces. Kontrol 5.24, Information security incident management planning and preparation, knytter an til hændelsesvurdering, erfaringer, logning, overvågning, sikkerhed under driftsafbrydelse, kontinuitet og kontakt med myndigheder. Revisionsfortællingen bliver stærkere, når hændelser rapporteres, vurderes, eskaleres, kommunikeres, dokumenteres og forbedres.

NIS2, DORA og GDPR: Ét register, forskellige juridiske frister

En enkelt hændelse kan udløse flere juridiske arbejdsgange. Uautoriseret adgang hos en SaaS-udbyder kan være en væsentlig NIS2-hændelse, et GDPR-brud på persondatasikkerheden og en kontraktlig kundemeddelelseshændelse. Et nedbrud hos en finansiel enhed kan være en større IKT-relateret hændelse under DORA og samtidig kræve GDPR-analyse og leverandørkoordinering.

NIS2 kræver, at væsentlige og vigtige enheder uden unødig forsinkelse underretter deres CSIRT eller kompetente myndighed om væsentlige hændelser, der påvirker tjenesteleveringen. Den trinvise rapporteringsmodel omfatter en tidlig varsling uden unødig forsinkelse og inden for 24 timer efter, at enheden er blevet opmærksom på hændelsen, en hændelsesunderretning uden unødig forsinkelse og inden for 72 timer, mellemliggende statusrapporter efter anmodning og en endelig rapport inden for en måned efter hændelsesunderretningen. Hvis hændelsen stadig er i gang, kan fremdriftsrapportering også være påkrævet.

DORA kræver, at finansielle enheder opretholder en proces for IKT-relateret hændelsesstyring, som detekterer, håndterer og underretter om hændelser, registrerer hændelser og væsentlige cybertrusler, klassificerer alvorlighed og kritikalitet, tildeler roller, definerer eskalering og kommunikation, rapporterer større hændelser til øverste ledelse og understøtter rettidig gendannelse. Rapportering af større IKT-relaterede hændelser følger en indledende, mellemliggende og endelig rapporteringslogik med klassificering baseret på faktorer som berørte kunder, varighed, geografisk udbredelse, datatab, tjenesternes kritikalitet og økonomisk påvirkning.

GDPR tilføjer vurderingen af brud på persondatasikkerheden. Et kontaktregister afgør ikke i sig selv juridisk rapporteringspligt. Det sikrer, at de rette personer kan træffe beslutningen hurtigt ved hjælp af aktuelle kanaler og dokumenterede kriterier.

Clarysecs politikbibliotek gør dette operationelt. I SMV-Politik for hændelseshåndtering Politik for hændelseshåndtering - SMV står der i klausul 5.1.1:

Direktøren (GM) er ansvarlig for at godkende alle beslutninger om hændelseseskalering, regulatoriske underretninger og ekstern kommunikation.

Samme SMV-politik tilføjer i klausul 7.4.1:

Hvor kundedata er involveret, skal direktøren vurdere juridiske underretningsforpligtelser baseret på anvendeligheden af GDPR, NIS2 eller DORA.

For enterprise-miljøer fastlægger Politik for hændelseshåndtering Politik for hændelseshåndtering klausul 5.5 kommunikationsrammen:

Al hændelsesrelateret kommunikation skal følge kommunikations- og eskaleringsmatricen og sikre:

Klausul 6.4.2 tilføjer kravet til bevismateriale:

Alle underretninger om brud skal dokumenteres og godkendes før indsendelse, og kopier skal opbevares i SIMS.

Det er her, registeret bliver ISO-bevismateriale. Det handler ikke kun om at vide, hvem man skal ringe til. Det handler om at vise, hvem der var godkendt, hvad der blev vurderet, hvad der blev godkendt, hvad der blev indsendt, og hvor den opbevarede kopi findes.

Clarysecs bevismodel: Fire artefakter, der fungerer sammen

En stærk regulatorisk kontaktkapacitet kræver fire artefakter, der fungerer som én beviskæde.

Registeret over regulatoriske kontakter identificerer kontakter, kanaler, udløsere og ejere. Kommunikations- og eskaleringsmatricen definerer, hvem der gør hvad. Beslutningsloggen registrerer klassificering, vurdering af rapporteringspligt, juridisk gennemgang og godkendelse. Bevispakken for underretninger opbevarer indsendte meddelelser, portalkvitteringer, e-mails, opkaldsnoter, regulatorfeedback, leverandørsvar og endelige rapporter.

Clarysecs Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse - SMV gør registerkonceptet eksplicit. Klausul 5.5.2 fastslår:

Centrale efterlevelsesvilkår (f.eks. tidsfrister for underretning om brud og databehandleraftaleklausuler) skal udtrækkes og spores i efterlevelsesregisteret.

Efterlevelsesregisteret bør føde registeret over regulatoriske kontakter. Det juridiske krav kan sige “NIS2-tidlig varsling inden for 24 timer”, mens kontaktregisteret identificerer den nationale CSIRT-portal, reservevagtnummer, godkendt indsender, juridisk reviewer, påkrævet bevismateriale og opbevaringsvej.

Politikker for forretningskontinuitet understøtter samme forventning. SMV-Politik for forretningskontinuitet og politik for katastrofeberedskab Politik for forretningskontinuitet og politik for katastrofeberedskab - SMV klausul 5.2.1.1 henviser til:

kontaktlister og alternative kommunikationsplaner

Enterprise-Politik for forretningskontinuitet og politik for katastrofeberedskab Politik for forretningskontinuitet og politik for katastrofeberedskab klausul 5.3.3 kræver, at kontinuitetsordninger er:

Understøttet af ajourførte kontaktlister og eskaleringsflows

Leverandørstyring hører også hjemme i modellen. I SMV-Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed - SMV kræver klausul 5.4.3 en:

Tildelt kontaktperson

For NIS2 og DORA kan den kontakt ikke være generisk. Hvis en kritisk cloududbyder, managed security service provider, identitetsudbyder eller betalingsformidler understøtter en reguleret tjeneste, bør registeret identificere den driftsmæssige kontakt, sikkerhedshændelseskontakten, den kontraktlige meddelelseskanal og eskaleringsvejen for anmodninger om bevismateriale.

Opbyg registeret i én arbejdssession

Et brugbart register kan opbygges hurtigt, hvis de rette personer er i rummet. Planlæg en session på to timer med CISO, DPO, juridisk rådgiver, leverandøransvarlig, kontinuitetsansvarlig, hændelsesleder og compliance-ejer.

Start med efterlevelsesregisteret. Udtræk NIS2-, DORA-, GDPR-, kontraktlige og sektorspecifikke rapporteringsforpligtelser. Registrér tidsfrister, kriterier for rapporteringspligt og krav til bevismateriale.

Åbn runbooken for hændelseshåndtering. For hver hændelseskategori, såsom ransomware, uautoriseret adgang, serviceafbrydelse, dataeksfiltrering, leverandørhændelse og fejl i cloudregion, identificeres de nødvendige eksterne kontakter.

Udfyld registeret over regulatoriske kontakter med myndighed, jurisdiktion, udløser, primær kanal, reservekanal, ejer, godkender, nødvendigt bevismateriale, seneste valideringsdato og opbevaringslokation.

Knyt leverandørkontakter til. For hver kritisk eller vigtig funktion identificeres udbyderens sikkerhedshændelseskontakt, kontraktlige meddelelseskanal, revisionskontakt og nødeskaleringsvej.

Gennemgå mod politikker. Bekræft, at eskaleringsbeføjelsen matcher Politik for hændelseshåndtering, at bevismateriale for underretninger opbevares i SIMS, at kontaktlister for forretningskontinuitet er afstemt, og at leverandørkontakter har tildelte ejere.

Test ét scenarie. Brug en fokuseret tabletop: “Kundedataeksponering detekteret kl. 02:17, som påvirker EU-kunder og muligvis skyldes kompromitterede legitimationsoplysninger hos identitetsudbyderen.” Bed teamet identificere, om CSIRT-, DPA-, finansiel tilsynsmyndigheds-, leverandør- og kundeunderretninger kan være påkrævet. Målet er ikke at gennemtvinge en endelig juridisk konklusion under øvelsen. Målet er at dokumentere, hvor kontakter findes, hvem der godkender kontakt, hvilket bevismateriale der kræves, og hvor beslutninger logges.

Opret bevispakken. Gem registerversionen, mødedeltagere, godkendelser, scenarienoter, beslutningslog, handlingspunkter og opdateret runbook-reference.

Det er her, Zenith Blueprint trin 23 bliver praktisk:

Sørg for, at organisationen har en ajourført hændelseshåndteringsplan (5.24), der dækker forberedelse, eskalering, respons og kommunikation. Definér, hvad der udgør en rapporteringspligtig sikkerhedshændelse (5.25), og hvordan beslutningsprocessen udløses og dokumenteres. Vælg en nylig hændelse, eller gennemfør en tabletop-øvelse for at validere planen.

Øvelsen behøver ikke være omfattende. Den skal dokumentere beredskab.

Kortlægning på tværs af rammeværker: Ét register, mange rammeværker

Værdien af et register over regulatoriske kontakter er, at det reducerer dobbeltarbejde med efterlevelse. Ét revisionsklart artefakt kan understøtte forventninger til styring i ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 2019.

NIST CSF 2.0 er særligt nyttigt som integrationslag. GOVERN-funktionen forventer, at organisationer forstår interessenter, juridiske og regulatoriske forpligtelser, kritiske tjenester, afhængigheder, risikovillighed, roller, politikker, tilsyn og leverandørrisiko. Dens CSF-profiler hjælper organisationer med at dokumentere en Current Profile, definere en Target Profile, analysere gaps og oprette en prioriteret handlingsplan. Et register over regulatoriske kontakter kan være konkret bevismateriale, der lukker hullet mellem aktuel og målrettet hændelsesstyring.

For forsyningskæden forventer NIST CSF 2.0, at leverandører, kunder og partnere har definerede cybersikkerhedsroller og -ansvar, at leverandørers kritikalitet er kendt, at cybersikkerhedskrav er indarbejdet i aftaler, at leverandørrisici vurderes, og at relevante leverandører indgår i hændelsesplanlægning, respons og genopretning. Det kortlægger direkte til DORA IKT-tredjepartsrisiko og NIS2-forventninger til forsyningskæden.

Hvordan revisorer og tilsynsmyndigheder tester det samme register

Et velvedligeholdt register vil blive undersøgt forskelligt afhængigt af reviewerens perspektiv.

En ISO/IEC 27001:2022-revisor vil begynde med omfang og interessenter. Revisoren vil spørge, hvordan organisationen har identificeret relevante myndigheder, juridiske forpligtelser, kontraktlige underretningsforpligtelser og outsourcede afhængigheder. Derefter vil revisoren spore registeret til anvendelighedserklæringen, hændelseshåndteringsplanen, forretningskontinuitetsplanen og opbevaring af bevismateriale. Revisoren kan udtage én kontakt som stikprøve og bede om dokumentation for seneste validering.

En NIS2-vurderingspart vil fokusere på, om enheden har identificeret korrekt CSIRT eller kompetent myndighed, og om tærskler for væsentlige hændelser er operationaliseret. Vurderingsparten vil se efter en proces, der kan understøtte 24-timers tidlig varsling, 72-timers underretning og endelig rapportering. Vurderingsparten vil også se på ledelsesorganets tilsyn, fordi NIS2 Article 20 gør cybersikkerhedsstyring til et ledelsesansvar.

En DORA-tilsynsmyndighed eller et internt revisionsteam vil teste, om registeret understøtter hændelsesstyring, klassificering, rapportering af større IKT-relaterede hændelser, krisekommunikation, rapportering til øverste ledelse, leverandørkoordinering og operationel genopretning. De kan spørge, om der findes kontakter for IKT-tredjepartsleverandører, der understøtter kritiske eller vigtige funktioner, og om kommunikationsforpligtelser er afspejlet i kontrakter.

En GDPR-revisor eller DPO-gennemgang vil fokusere på vurdering af brud på persondatasikkerheden. De vil spørge, om DPO og juridiske privatlivskontakter involveres tidligt, om roller som dataansvarlig og databehandler er klare, om den korrekte tilsynsmyndighed er identificeret, og om beslutninger om kommunikation til registrerede er registreret.

En NIST CSF-vurderingspart vil behandle registeret som bevismateriale for GOVERN-resultater: interessentforventninger, juridiske forpligtelser, roller, politikker, tilsyn og forsyningskæderisiko. En COBIT 2019- eller ISACA-orienteret revisor vil undersøge, om interessentbehov er omsat til styrings- og ledelsespraksisser, om ansvar er tildelt, og om procesperformance overvåges.

Det samme artefakt skal kunne bestå alle disse spørgsmål. Derfor bør registeret være kontrolleret, ejet, gennemgået, adgangsstyret og testet.

Almindelige fejlmønstre i kontaktstyring

Organisationer fejler sjældent, fordi de slet ikke har kontakter. De fejler, fordi kontakterne ikke kan stoles på under en reel hændelse.

Hvert forhold skaber en forudsigelig revisionskonstatering. Afhjælpningen er lige så forudsigelig: afstem registeret med politikken, integrér det i hændelseshåndtering, validér kontakter, test arbejdsgangen og opbevar bevismateriale.

Bestyrelses- og ledelsesansvarlighed

NIS2 kræver, at ledelsesorganer godkender foranstaltninger til styring af cybersikkerhedsrisici, fører tilsyn med implementeringen og gennemfører træning. DORA Article 5 gør ledelsesorganet ansvarligt for at definere, godkende, føre tilsyn med og stå til ansvar for IKT-risikoordninger, herunder politikker, roller, IKT-forretningskontinuitet, respons- og genopretningsplaner, IKT-tredjepartspolitik, bevidstgørelse og træning. ISO/IEC 27001:2022 kræver, at ledelsen afstemmer ISMS med den strategiske retning, stiller ressourcer til rådighed, tildeler ansvar og understøtter løbende forbedring.

Bestyrelsen behøver ikke at huske CSIRT-telefonnummeret. Den har brug for sikkerhed for, at underretningsberedskabet findes, er ejet, er testet og gennemgås.

En kvartalsvis ledelsespakke bør omfatte:

• Gennemgangsstatus for registeret over regulatoriske kontakter
• Ændringer i relevante myndigheder, tilsynsmyndigheder eller jurisdiktioner
• Åbne mangler i leverandørers hændelseskontakter
• Resultater fra tabletop-øvelser og erfaringer
• Bevismateriale for test af godkendelsesarbejdsgang for underretninger
• Målinger for tid fra detektion til eskaleringsbeslutning
• Opdateringer til NIS2-, DORA-, GDPR- og kontraktlige rapporteringsforpligtelser
• Restrisici, der kræver ledelsens accept

Det flytter registeret fra et driftsmæssigt regneark til en styringskontrol.

Hvordan Clarysec hjælper dig med at opbygge revisionsklar kontaktstyring

Clarysec forbinder politiktekst, implementeringsrækkefølge og tværgående kontrolkortlægning i én bevisvej.

Politikbiblioteket definerer ansvarlighed og påkrævede registreringer. Politik for hændelseshåndtering fastlægger forventninger til eskalering, godkendelse af underretninger og opbevaring. Politik for juridisk og regulatorisk efterlevelse kræver, at efterlevelsesvilkår såsom tidsfrister for underretning om brud spores. Politik for forretningskontinuitet og politik for katastrofeberedskab kræver ajourførte kontaktlister og alternative kommunikationsplaner. Politik for tredjeparts- og leverandørsikkerhed kræver tildelte leverandørkontakter.

Zenith Blueprint giver implementeringsrækkefølgen. Trin 5 i fasen ISMS Foundation & Leadership behandler kommunikation, bevidstgørelse og kompetence, herunder eksterne interessenter, timing, kommunikatørroller og kommunikationsplaner. Trin 22 indbygger myndigheds- og særlige interessekontakter i organisatoriske kontroller. Trin 23 validerer hændelsesstyring, beslutninger om rapporteringspligtige hændelser, bevarelse af digitale beviser og erfaringer.

Vejledningen Zenith Controls giver kompasset for tværgående efterlevelse. Den viser, hvordan kontakt med myndigheder hænger sammen med hændelsesplanlægning, hændelsesrapportering, trusselsintelligens, særlige interessegrupper og hændelseshåndtering. Den viser også, hvorfor rapportering af informationssikkerhedshændelser og hændelsesforberedelse er nødvendige følgesvende. Et kontaktregister er kun effektivt, hvis hændelser rapporteres og vurderes tidligt nok til at udløse det.

For SMV’er betyder det et enkelt, men forsvarligt register, klar ansvarlighed og bevismateriale, der passer til proportionalitetsprincippet. For enterprise-organisationer betyder det integration på tværs af jurisdiktioner, juridiske enheder, forretningsenheder, leverandører, regulatorer, tilsynsmyndigheder, CSIRTs og bestyrelsesrapportering.

Næste skridt: Opbyg registeret, før uret starter

Hvis din organisation forbereder sig på NIS2, DORA, GDPR-beredskab for underretning om brud eller ISO/IEC 27001:2022-certificering, så vent ikke på en livehændelse for at opdage, om jeres kontaktstyring virker.

Start med fire handlinger i denne uge:

1. Opret eller opdater jeres register over regulatoriske kontakter for CSIRTs, kompetente myndigheder, finansielle tilsynsmyndigheder, databeskyttelsesmyndigheder, retshåndhævelse, kritiske leverandører og interne eskaleringsroller.
2. Kortlæg hver kontakt til en udløser, ejer, godkendelsesvej, krav til bevismateriale og opbevaringslokation.
3. Gennemfør én tabletop-øvelse med fokus på underretningsbeslutninger, myndighedskontakt, leverandørkoordinering og opbevaring af bevismateriale.
4. Opdater ISMS-registreringer, herunder efterlevelsesregisteret, runbooken for hændelseshåndtering, kontaktlister for forretningskontinuitet og leverandørkontaktregistreringer.

Clarysec kan hjælpe jer med at implementere dette hurtigt ved hjælp af Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls og vores politikbiblioteker for SMV’er og enterprise-organisationer, herunder Politik for hændelseshåndtering Politik for hændelseshåndtering, Politik for juridisk og regulatorisk efterlevelse Politik for juridisk og regulatorisk efterlevelse - SMV, Politik for forretningskontinuitet og politik for katastrofeberedskab Politik for forretningskontinuitet og politik for katastrofeberedskab og Politik for tredjeparts- og leverandørsikkerhed Politik for tredjeparts- og leverandørsikkerhed - SMV.

24-timersfristen holder ikke pause, mens dit team leder efter den rette kontakt. Opbyg registeret nu, test det, og gør det til en del af jeres ISO-bevismateriale, før den næste hændelse fastlægger tidslinjen for jer.