Kontaktregister för NIS2 och DORA som ISO 27001-underlag

02:17-incidenten: när kontaktlistan blir kontrollen

Klockan 02:17 en tisdag ser SOC-analytikern det mönster som ingen vill se. Ett privilegierat tjänstekonto har autentiserats från en ovanlig geografi, kundregister har slagits upp sekventiellt och en leverantör av hanterad detektering har öppnat ett ärende med hög allvarlighetsgrad. Inom några minuter bekräftar incidentledaren farhågan: indikatorer på ransomware sprids lateralt, en kritisk produktionstjänst är degraderad och kunddata kan vara berörda.

Den tekniska responsen startar snabbt. Slutpunkter isoleras, identitetsloggar hämtas, ögonblicksbilder i molnmiljö bevaras och den hanterade säkerhetsleverantören ansluter till bryggan. Därefter börjar en kallare form av panik.

CISO frågar: ”Vem ska vi underrätta?”

Juridikfunktionen säger att dataskyddsmyndigheten kan behöva involveras. Dataskyddsombudet frågar om detta är en personuppgiftsincident. COO säger att molnleverantören måste eskaleras enligt organisationens supportklausul. Ansvarig för regelefterlevnad frågar om entiteten är en viktig entitet enligt NIS2, eller om DORA gäller eftersom tjänsten stödjer en reglerad finansiell entitet. Styrelsen vill veta vad som måste ske under de första 24 timmarna.

Ingen ifrågasätter behovet av kommunikation. Problemet är att kontaktuppgifter, godkännandeväg, rättsliga utlösande faktorer och krav på underlag är utspridda i ett gammalt kalkylblad för verksamhetskontinuitet, leverantörsavtal, e-posttrådar, en inaktuell wiki för regelefterlevnad och en persons telefon.

Det är inte bara en operativ olägenhet. År 2026 är det en efterlevnadslucka.

NIS2 har gjort stegvis incidentanmälan till en styrningsskyldighet, inklusive tidig varning inom 24 timmar, underrättelse inom 72 timmar och en slutrapport inom en månad för betydande incidenter. DORA har skapat ett särskilt regelverk för digital operativ resiliens för finansiella entiteter, inklusive IKT-incidenthantering, klassificering, rapportering till tillsynsmyndighet, IKT-tredjepartsrisk och kriskommunikation. GDPR är fortsatt relevant när personuppgifter berörs. ISO/IEC 27001:2022 gör dessa skyldigheter till granskningsbart underlag i ledningssystemet.

Ett register över regulatoriska kontakter låter administrativt. Det är det inte. Det är bindväven mellan incidentrespons, rättslig underrättelse, verksamhetskontinuitet, leverantörssamordning, ledningens ansvarsskyldighet och revisionsunderlag.

Clarysec behandlar detta som en underlagsfråga, inte som en pappersövning. I Zenith Blueprint: en revisors 30-stegs färdplan Zenith Blueprint förklarar steg 22 i fasen Controls in Action varför kontakt med myndigheter måste vara fördefinierad:

Kontroll 5.5 säkerställer att en organisation är förberedd att interagera med externa myndigheter när det behövs, inte reaktivt eller under panik, utan genom fördefinierade, strukturerade och väl förstådda kanaler.

Det är den verkliga lärdomen från 02:17-incidenten. Tidpunkten för att hitta tillsynsmyndighetens anmälningsportal, CSIRT:ens jourtelefon, dataskyddsombudets ersättare, den finansiella tillsynsmyndighetens rapporteringskanal och leverantörens eskaleringsväg är före incidenten, inte när rapporteringsklockan redan tickar.

Varför register över regulatoriska kontakter blev en efterlevnadsprioritet 2026

Många organisationer har redan kontaktlistor för nödlägen. Problemet är att NIS2 och DORA kräver något mer disciplinerat än en lista med namn och telefonnummer. De kräver korrekt, rollbaserad och revisionsklar kontaktstyrning kopplad till rättsliga utlösande faktorer, eskaleringsbefogenhet, rapporteringsfrister och leverantörsberoenden.

NIS2 gäller för ett brett urval av väsentliga och viktiga entiteter inom sektorer som energi, transport, bank, infrastruktur för finansmarknader, hälso- och sjukvård, dricksvatten, avloppsvatten, digital infrastruktur, IKT-tjänstehantering, offentlig förvaltning och rymd. Direktivet omfattar också många digitala leverantörer, inklusive molntjänster, datacentertjänster, innehållsleveransnätverk, leverantörer av hanterade tjänster (MSP:er), leverantörer av hanterade säkerhetstjänster, marknadsplatser online, sökmotorer online och plattformar för sociala nätverk. Medlemsstaterna skulle upprätta listor över väsentliga och viktiga entiteter senast den 17 april 2025 och uppdatera dem minst vartannat år. För många moln-, SaaS-, hanterade tjänste- och digitala plattformsleverantörer har regulatorisk exponering gått från teoretisk till operativ.

DORA gäller från den 17 januari 2025 för finansiella entiteter som kreditinstitut, betalningsinstitut, institut för elektroniska pengar, värdepappersföretag, leverantörer av kryptotillgångstjänster, handelsplatser, värdepapperscentraler, centrala motparter, försäkrings- och återförsäkringsföretag samt andra omfattade organisationer inom finanssektorn. DORA är också mycket relevant för IKT-tredjepartsekosystemet eftersom finansiella entiteter måste hantera leverantörer som stödjer kritiska eller viktiga funktioner. DORA Article 17 kräver en process för IKT-relaterad incidenthantering, Article 18 anger förväntningar på klassificering och Article 19 reglerar rapportering av större IKT-relaterade incidenter till behörig myndighet.

GDPR tillför dataskyddsdimensionen. En cybersäkerhetsincident kan bli en personuppgiftsincident om den innebär oavsiktlig eller olaglig förstöring, förlust, ändring, obehörigt röjande av eller obehörig åtkomst till personuppgifter. Den personuppgiftsansvariga måste kunna visa ansvarsskyldighet, bedöma risk för enskilda och, där så krävs, underrätta tillsynsmyndigheten och eventuellt berörda registrerade.

Ett moget register över regulatoriska kontakter måste därför kunna besvara fem frågor under press:

• Vilken CSIRT, behörig myndighet, finansiell tillsynsmyndighet, dataskyddsmyndighet och kontakt hos brottsbekämpande myndigheter gäller för denna juridiska person, jurisdiktion och tjänst?
• Vilken intern roll är behörig att initiera kontakt, godkänna formuleringar och lämna in underrättelser?
• Vilka leverantörer måste kontaktas för begränsning, loggar, återställning, bevarande av bevismaterial eller avtalsenlig rapportering?
• Vilken kund-, motparts- eller publik kommunikationsväg utlöses vid respektive allvarlighetsgrad?
• Hur visar vi att registret har granskats, testats och använts korrekt?

Svaret kan inte bara finnas i juridikfunktionens inkorg eller i CISO:s minne. Det måste vara en styrd ISMS-post.

Vad ett revisionsklart kontaktregister för NIS2 och DORA innehåller

Ett register över regulatoriska kontakter ska utformas för användning under en verklig incident. Om incidentledaren behöver fatta det första eskaleringsbeslutet inom några minuter kan registret inte vara en vag lista med webbplatser. Det måste vara strukturerat, verifierat och kopplat till åtgärdsplanen.

Ett komplett register bör omfatta minst sex kontaktfamiljer.

För det första, officiella cybersäkerhetsmyndigheter: nationella CSIRT:er, behöriga myndigheter, gemensamma kontaktpunkter där sådana finns och sektorspecifika cybersäkerhetsmyndigheter.

För det andra, finansiella tillsynsmyndigheter för DORA: behöriga myndigheter och rapporteringskanaler som används för initial, mellanliggande och slutlig rapportering av större IKT-relaterade incidenter.

För det tredje, dataskyddsmyndigheter: dataskyddsmyndigheter, logik för ledande tillsynsmyndighet vid gränsöverskridande behandling och dataskyddsombudets eskaleringsvägar.

För det fjärde, brottsbekämpande myndigheter: cyberbrottsenheter, bedrägerienheter och nödkontakter för utpressning, ransomware, obehörig åtkomst och bevarande av bevismaterial.

För det femte, leverantörer och IKT-tredjeparter: molnleverantörer, leverantörer av hanterade säkerhetstjänster, leverantörer av hanterade tjänster, identitetsplattformar, betalningsförmedlare, leverantörer av digital forensik och juridiska rådgivare.

För det sjätte, interna eskaleringsroller: incidentledare, CISO, dataskyddsombud, chefsjurist, kommunikationsansvarig, kontinuitetsansvarig, verkställande godkännare, styrelsekontakt och tjänsteägare.

Registret bör också inkludera särskilda intressegrupper där det är relevant, såsom ISAC:er eller sektorspecifika informationsdelningsgemenskaper. Dessa är inte tillsynsmyndigheter, men de kan bli viktiga kanaler för hotinformation och samordnad respons.

Zenith Blueprint gör detta praktiskt i steg 22:

Skapa eller uppdatera rutiner för kontakt med myndigheter under säkerhetshändelser (5.5), inklusive kontaktuppgifter till lokala CERT:er, tillsynsmyndigheter och brottsbekämpande myndigheter. Upprätthåll en motsvarande kontaktlista för deltagande i säkerhetsforum eller sektorspecifika grupper (5.6). Lagra denna information på en tillgänglig men åtkomstkontrollerad plats och inkludera den i er runbook för incidenthantering.

Den sista meningen är viktig. Om registret inte finns i runbooken för incidenthantering är det osannolikt att det används när trycket är verkligt.

Exempel på kontaktregisterstruktur för en FinTech- eller SaaS-leverantör

Föreställ dig en fintech-SaaS-leverantör som stödjer betalningsanalys för EU-kunder. Den använder en molnleverantör, en leverantör av hanterad detektering, en identitetsplattform, en kundsupportplattform och extern juridisk rådgivare. Beroende på roll kan den vara en finansiell entitet, en IKT-tredjepartstjänsteleverantör, en digital leverantör inom NIS2:s tillämpningsområde eller ett personuppgiftsbiträde enligt GDPR.

Ett praktiskt register kan börja så här:

Posterna ska inte innehålla onödiga personuppgifter. Använd rollbaserade kontakter där det är möjligt, skydda känsliga kontaktuppgifter och säkerställ offline-tillgänglighet vid ett större avbrott. Ett register som bara är åtkomligt från samma system som påverkas av en ransomware-incident är inte resilient.

Mappning av registret mot ISO/IEC 27001:2022-underlag

Revisorer underkänner sällan en organisation för att den saknar ett kalkylblad. De underkänner den för att organisationen inte kan visa att kalkylbladet är komplett, aktuellt, godkänt, skyddat, testat och kopplat till faktiska processer.

ISO/IEC 27001:2022 börjar med organisationens kontext. Klausulerna 4.1 till 4.4 kräver att organisationen förstår interna och externa frågor, identifierar intressenter och deras krav, definierar ISMS-omfattningen och förstår gränssnitt och beroenden. Ett register över regulatoriska kontakter är starkt underlag för att rättsliga, regulatoriska, avtalsmässiga och intressentrelaterade krav har översatts till operativa relationer.

Därefter följer ledarskap. Klausulerna 5.1 till 5.3 kräver att högsta ledningen visar ledarskap, tilldelar ansvar, säkerställer kommunikation och stödjer ISMS. Om registret identifierar vem som är behörig att underrätta en CSIRT, tillsynsmyndighet eller dataskyddsmyndighet, vem som godkänner extern kommunikation och vem som rapporterar incidentstatus till högsta ledningen, stödjer det ledarskapsunderlag.

Riskplanering omsätter sedan skyldigheter i åtgärder. Klausulerna 6.1.1 till 6.1.3 kräver en process för riskbedömning och riskbehandling, jämförelse mot Annex A, en Statement of Applicability, en riskbehandlingsplan och acceptans av kvarstående risk. Registret bör ingå i behandlingsplanen för risker som utebliven rättslig underrättelse, fördröjd incidenteskalering, bristande leverantörsrespons, gränsöverskridande underrättelsefel och avbrott i kommunikation för verksamhetskontinuitet.

Kopplingarna till Annex A-kontroller är tydliga:

I Zenith Controls: vägledningen för tvärgående efterlevnad Zenith Controls behandlas kontakt med myndigheter som kontroll 5.5 med förebyggande och korrigerande egenskaper. Den stödjer konfidentialitet, riktighet och tillgänglighet och kopplar till cybersäkerhetsbegreppen Identify, Protect, Respond och Recover. Zenith Controls kopplar den till incidentplanering, händelserapportering, hotinformation, särskilda intressegrupper och incidentrespons. Den förklarar också varför förhandsupprättade kontakter med tillsynsmyndigheter, brottsbekämpande myndigheter, nationella CERT:er eller dataskyddsmyndigheter möjliggör snabbare eskalering och vägledning vid händelser som betydande incidenter eller ransomware-angrepp.

Kontrollen är inte isolerad. Zenith Controls mappar även kontroll 6.8, rapportering av informationssäkerhetshändelser, som en upptäckande kontroll kopplad till incidentplanering, händelsebedömning, respons, erfarenhetsåterföring, medvetenhet, övervakning och disciplinär process. Kontroll 5.24, planering och förberedelse för hantering av informationssäkerhetsincidenter, kopplar till händelsebedömning, erfarenhetsåterföring, loggning, övervakning, säkerhet under störning, kontinuitet och kontakt med myndigheter. Revisionsberättelsen blir starkare när händelser rapporteras, bedöms, eskaleras, kommuniceras, styrks med underlag och förbättras.

NIS2, DORA och GDPR: ett register, olika rättsliga tidsfrister

En enda incident kan utlösa flera rättsliga arbetsflöden. Obehörig åtkomst hos en SaaS-leverantör kan vara en betydande incident enligt NIS2, en personuppgiftsincident enligt GDPR och en avtalsenlig kundunderrättelsehändelse. Ett avbrott hos en finansiell entitet kan vara en större IKT-relaterad incident enligt DORA och samtidigt kräva GDPR-analys och leverantörssamordning.

NIS2 kräver att väsentliga och viktiga entiteter utan onödigt dröjsmål underrättar sin CSIRT eller behöriga myndighet om betydande incidenter som påverkar tillhandahållandet av tjänster. Den stegvisa rapporteringsmodellen omfattar en tidig varning utan onödigt dröjsmål och inom 24 timmar från att organisationen fått kännedom, en incidentanmälan utan onödigt dröjsmål och inom 72 timmar, mellanliggande statusrapporter på begäran och en slutrapport inom en månad efter incidentanmälan. Om incidenten fortfarande pågår kan även lägesrapportering krävas.

DORA kräver att finansiella entiteter upprätthåller en process för IKT-relaterad incidenthantering som detekterar, hanterar och underrättar om incidenter, registrerar incidenter och betydande cyberhot, klassificerar allvarlighetsgrad och kritikalitet, tilldelar roller, definierar eskalering och kommunikation, rapporterar större incidenter till högsta ledningen och stödjer snabb återställning. Rapportering av större IKT-relaterade incidenter följer en logik för initial, mellanliggande och slutlig rapportering, med klassificering baserad på faktorer som berörda kunder, varaktighet, geografisk spridning, dataförlust, tjänsternas kritikalitet och ekonomisk påverkan.

GDPR tillför bedömningen av personuppgiftsincident. Ett kontaktregister avgör inte i sig rättslig rapporteringsplikt. Det säkerställer att rätt personer snabbt kan fatta beslut, med aktuella kanaler och dokumenterade kriterier.

Clarysecs policybibliotek gör detta operativt. I SME-versionen av Policy för incidenthantering Policy för incidenthantering - SME anger klausul 5.1.1:

Verkställande chef (GM) ansvarar för att godkänna alla beslut om incidenteskalering, regulatoriska underrättelser och extern kommunikation.

Samma SME-policy, klausul 7.4.1, tillägger:

När kunddata berörs måste Verkställande chef bedöma rättsliga underrättelseskyldigheter baserat på tillämpligheten av GDPR, NIS2 eller DORA.

För större organisationer etablerar Policy för incidenthantering Policy för incidenthantering klausul 5.5 kommunikationsramverket:

All incidentrelaterad kommunikation måste följa kommunikations- och eskaleringsmatrisen och säkerställa att:

Klausul 6.4.2 lägger till kravet på underlag:

Alla incidentanmälningar måste dokumenteras och godkännas före inlämning, och kopior måste bevaras i SIMS.

Det är här registret blir ISO-underlag. Det handlar inte bara om att veta vem som ska kontaktas. Det handlar om att visa vem som var behörig, vad som bedömdes, vad som godkändes, vad som lämnades in och var den bevarade kopian finns.

Clarysecs underlagsmodell: fyra artefakter som fungerar tillsammans

En stark förmåga för regulatoriska kontakter behöver fyra artefakter som fungerar som en sammanhängande beviskedja.

Registret över regulatoriska kontakter identifierar kontakter, kanaler, utlösare och ägare. Kommunikations- och eskaleringsmatrisen definierar vem som gör vad. Beslutsloggen dokumenterar klassificering, bedömning av rapporteringsplikt, juridisk granskning och godkännande. Underlagspaketet för underrättelser bevarar inlämnade meddelanden, portalkvittenser, e-post, samtalsanteckningar, återkoppling från tillsynsmyndigheter, leverantörssvar och slutrapporter.

Clarysecs Policy för rättslig och regulatorisk efterlevnad Policy för rättslig och regulatorisk efterlevnad - SME gör registerkonceptet uttryckligt. Klausul 5.5.2 anger:

Viktiga villkor för regelefterlevnad (t.ex. tidsfrister för incidentanmälan och datahanteringsklausuler) måste extraheras och följas upp i register över regelefterlevnadskrav.

Register över regelefterlevnadskrav bör mata registret över regulatoriska kontakter. Det rättsliga kravet kan säga ”NIS2 tidig varning inom 24 timmar”, medan kontaktregistret identifierar den nationella CSIRT-portalen, reservnummer till jourfunktion, behörig inlämnare, juridisk granskare, krav på underlag och bevarandeväg.

Policyer för verksamhetskontinuitet förstärker samma förväntan. SME-versionen av Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning - SME klausul 5.2.1.1 hänvisar till:

kontaktlistor och alternativa kommunikationsplaner

Enterprise-versionen av Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning klausul 5.3.3 kräver att kontinuitetsarrangemang ska vara:

Stödda av aktuella kontaktlistor och eskaleringsflöden

Leverantörsstyrning hör också hemma i modellen. I SME-versionen av Policy för leverantörssäkerhet och tredjepartssäkerhet Policy för leverantörssäkerhet och tredjepartssäkerhet - SME kräver klausul 5.4.3 en:

Tilldelad kontaktperson

För NIS2 och DORA kan den kontakten inte vara generisk. Om en kritisk molnleverantör, leverantör av hanterade säkerhetstjänster, identitetsleverantör eller betalningsförmedlare stödjer en reglerad tjänst bör registret identifiera operativ kontakt, säkerhetsincidentkontakt, avtalsenlig underrättelsekanal och eskaleringsväg för begäranden om underlag.

Bygg registret under ett arbetspass

Ett användbart register kan byggas snabbt om rätt personer finns i rummet. Boka ett tvåtimmarsmöte med CISO, dataskyddsombud, juridisk rådgivare, leverantörsansvarig, kontinuitetsansvarig, incidentledare och ansvarig för regelefterlevnad.

Börja med register över regelefterlevnadskrav. Extrahera NIS2-, DORA-, GDPR-, avtals- och sektorspecifika rapporteringsskyldigheter. Dokumentera tidsfrister, kriterier för rapporteringsplikt och krav på underlag.

Öppna runbooken för incidenthantering. För varje incidentkategori, såsom ransomware, obehörig åtkomst, tjänsteavbrott, dataexfiltration, leverantörsincident och fel i molnregion, identifiera de externa kontakter som behövs.

Fyll registret över regulatoriska kontakter med myndighet, jurisdiktion, utlösare, primär kanal, reservkanal, ägare, godkännare, underlag som behövs, senaste valideringsdatum och bevarandeplats.

Koppla leverantörskontakter. För varje kritisk eller viktig funktion, identifiera leverantörens säkerhetsincidentkontakt, avtalsenliga underrättelsekanal, revisionskontakt och akuta eskaleringsväg.

Granska mot policyer. Bekräfta att eskaleringsbefogenhet matchar Policy för incidenthantering, att underrättelseunderlag bevaras i SIMS, att kontaktlistor för verksamhetskontinuitet är samordnade och att leverantörskontakter har tilldelade ägare.

Testa ett scenario. Använd en fokuserad skrivbordsövning: ”Exponering av kunddata upptäcks 02:17, påverkar EU-kunder och kan ha orsakats av komprometterade autentiseringsuppgifter hos identitetsleverantör.” Be teamet identifiera om CSIRT, dataskyddsmyndighet, finansiell tillsynsmyndighet, leverantör och kunder kan behöva underrättas. Målet är inte att tvinga fram en slutlig juridisk slutsats under övningen. Målet är att visa var kontakter finns, vem som godkänner kontakt, vilket underlag som behövs och var beslut loggas.

Skapa underlagspaketet. Spara registerversion, mötesdeltagare, godkännanden, scenarionoteringar, beslutslogg, åtgärdspunkter och uppdaterad runbook-referens.

Det är här Zenith Blueprint steg 23 blir praktiskt:

Säkerställ att ni har en aktuell incidenthanteringsplan (5.24) som omfattar förberedelse, eskalering, respons och kommunikation. Definiera vad som utgör en rapporteringspliktig säkerhetshändelse (5.25) och hur beslutsprocessen utlöses och dokumenteras. Välj en aktuell händelse eller genomför en skrivbordsövning för att validera planen.

Övningen behöver inte vara omfattande. Den behöver visa beredskap.

Tvärgående efterlevnadsmappning: ett register, många ramverk

Värdet med ett register över regulatoriska kontakter är att det minskar duplicerat efterlevnadsarbete. En revisionsklar artefakt kan stödja ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 och COBIT 2019-styrningsförväntningar.

NIST CSF 2.0 är särskilt användbart som integrationslager. Funktionen GOVERN förväntar sig att organisationer förstår intressenter, rättsliga och regulatoriska skyldigheter, kritiska tjänster, beroenden, riskaptit, roller, policyer, tillsyn och leverantörsrisk. CSF Profiles hjälper organisationer att dokumentera en Current Profile, definiera en Target Profile, analysera gap och skapa en prioriterad åtgärdsplan. Ett register över regulatoriska kontakter kan vara konkret underlag som stänger gapet mellan nuvarande och önskad incidentstyrning.

För leveranskedjan förväntar sig NIST CSF 2.0 att leverantörer, kunder och partner har definierade cybersäkerhetsroller och ansvar, att leverantörskritikalitet är känd, att cybersäkerhetskrav byggs in i avtal, att leverantörsrisker bedöms och att relevanta leverantörer inkluderas i incidentplanering, respons och återställning. Det mappar direkt mot DORA:s IKT-tredjepartsrisk och NIS2:s förväntningar på leveranskedjan.

Hur revisorer och tillsynsmyndigheter kommer att testa samma register

Ett väl underhållet register kommer att granskas på olika sätt beroende på granskarens perspektiv.

En ISO/IEC 27001:2022-revisor börjar med omfattning och intressenter. Revisorn frågar hur organisationen har identifierat tillämpliga myndigheter, rättsliga skyldigheter, avtalsenliga underrättelseskyldigheter och outsourcade beroenden. Därefter spåras registret till Statement of Applicability, incidenthanteringsplan, plan för verksamhetskontinuitet och bevarande av underlag. Revisorn kan ta ett stickprov på en kontakt och begära bevis på senaste validering.

En NIS2-granskare fokuserar på om entiteten har identifierat korrekt CSIRT eller behörig myndighet och om trösklar för betydande incidenter har operationaliserats. Granskaren letar efter en process som kan stödja 24-timmars tidig varning, 72-timmars underrättelse och slutrapportering. Granskaren tittar också på ledningsorganets tillsyn eftersom NIS2 Article 20 gör cybersäkerhetsstyrning till ett ledningsansvar.

En DORA-tillsynsmyndighet eller ett internrevisionsteam testar om registret stödjer incidenthantering, klassificering, rapportering av större IKT-relaterade incidenter, kriskommunikation, rapportering till högsta ledningen, leverantörssamordning och operativ återställning. De kan fråga om det finns kontakter för IKT-tredjepartstjänsteleverantörer som stödjer kritiska eller viktiga funktioner och om kommunikationsskyldigheter återspeglas i avtalen.

En GDPR-revisor eller granskning av dataskyddsombudet fokuserar på bedömning av personuppgiftsincident. De frågar om dataskyddsombudet och juridiska dataskyddskontakter involveras tidigt, om roller som personuppgiftsansvarig och personuppgiftsbiträde är tydliga, om rätt tillsynsmyndighet har identifierats och om beslut om kommunikation med registrerade dokumenteras.

En NIST CSF-granskare behandlar registret som underlag för GOVERN-resultat: intressentförväntningar, rättsliga skyldigheter, roller, policyer, tillsyn och risk i leveranskedjan. En COBIT 2019- eller ISACA-inriktad revisor granskar om intressentbehov översätts till styrnings- och ledningspraxis, om ansvar har tilldelats och om processprestanda övervakas.

Samma artefakt måste klara alla dessa frågor. Därför ska registret vara styrt, ägt, granskat, åtkomstkontrollerat och testat.

Vanliga felmönster i kontaktstyrning

Organisationer fallerar sällan för att de helt saknar kontakter. De fallerar för att kontakterna inte kan betros under en verklig incident.

Varje problem skapar en förutsägbar revisionsiakttagelse. Åtgärden är lika förutsägbar: anpassa registret till policy, integrera det i incidenthanteringen, validera kontakter, testa arbetsflödet och bevara underlag.

Styrelsens och ledningens ansvarsskyldighet

NIS2 kräver att ledningsorgan godkänner åtgärder för cybersäkerhetsriskhantering, övervakar genomförandet och genomgår utbildning. DORA Article 5 gör ledningsorganet ansvarigt för att definiera, godkänna, övervaka och ansvara för IKT-riskarrangemang, inklusive policyer, roller, IKT-verksamhetskontinuitet, respons- och återställningsplaner, IKT-tredjepartspolicy samt medvetenhet och utbildning. ISO/IEC 27001:2022 kräver att ledningen anpassar ISMS till strategisk inriktning, tillhandahåller resurser, tilldelar ansvar och stödjer ständig förbättring.

Styrelsen behöver inte memorera CSIRT:ens telefonnummer. Den behöver däremot försäkran om att underrättelseberedskap finns, är ägd, testad och granskad.

Ett kvartalsvis ledningspaket bör innehålla:

• Granskningsstatus för registret över regulatoriska kontakter
• Förändringar i tillämpliga myndigheter, tillsynsmyndigheter eller jurisdiktioner
• Öppna gap i leverantörskontakter för incidenter
• Resultat från skrivbordsövningar och erfarenhetsåterföring
• Underlag för test av godkännandearbetsflöde för underrättelser
• Mätetal för tid från detektering till eskaleringsbeslut
• Uppdateringar av NIS2-, DORA-, GDPR- och avtalsenliga rapporteringsskyldigheter
• Kvarstående risker som kräver ledningens acceptans

Detta flyttar registret från ett operativt kalkylblad till en styrningskontroll.

Hur Clarysec hjälper er att bygga revisionsklar kontaktstyrning

Clarysec kopplar policytext, genomförandesekvensering och kontrollmappning över ramverk till en sammanhängande underlagsväg.

Policybiblioteket definierar ansvarsskyldighet och nödvändiga poster. Policy för incidenthantering fastställer förväntningar på eskalering, godkännande av underrättelser och bevarande. Policy för rättslig och regulatorisk efterlevnad kräver att villkor för regelefterlevnad, såsom tidsfrister för incidentanmälan, följs upp. Policy för verksamhetskontinuitet och katastrofåterställning kräver aktuella kontaktlistor och alternativa kommunikationsplaner. Policy för leverantörssäkerhet och tredjepartssäkerhet kräver tilldelade leverantörskontakter.

Zenith Blueprint ger genomförandesekvensering. Steg 5 i fasen ISMS Foundation & Leadership behandlar kommunikation, medvetenhet och kompetens, inklusive externa intressenter, tidpunkt, kommunikatörsroller och kommunikationsplaner. Steg 22 bygger in myndighetskontakter och kontakter med särskilda intressegrupper i organisatoriska kontroller. Steg 23 validerar incidenthantering, beslut om rapporteringspliktiga händelser, bevarande av forensisk bevisning och erfarenhetsåterföring.

Vägledningen Zenith Controls ger kompassen för tvärgående efterlevnad. Den visar hur kontakt med myndigheter kopplar till incidentplanering, händelserapportering, hotinformation, särskilda intressegrupper och incidentrespons. Den visar också varför rapportering av informationssäkerhetshändelser och incidentförberedelse är nödvändiga följeslagare. Ett kontaktregister är bara effektivt om händelser rapporteras och bedöms tillräckligt tidigt för att utlösa det.

För små och medelstora företag innebär detta ett slimmat men försvarbart register, tydlig ansvarsskyldighet och underlag som passar proportionalitetsprincipen. För större organisationer innebär det integration över jurisdiktioner, juridiska personer, affärsenheter, leverantörer, tillsynsmyndigheter, CSIRT:er och styrelserapportering.

Nästa steg: bygg registret innan klockan startar

Om organisationen förbereder sig för NIS2, DORA, beredskap för incidentanmälan enligt GDPR eller ISO/IEC 27001:2022-certifiering, vänta inte på en skarp incident för att upptäcka om kontaktstyrningen fungerar.

Börja med fyra åtgärder denna vecka:

1. Skapa eller uppdatera ert register över regulatoriska kontakter för CSIRT:er, behöriga myndigheter, finansiella tillsynsmyndigheter, dataskyddsmyndigheter, brottsbekämpande myndigheter, kritiska leverantörer och interna eskaleringsroller.
2. Mappa varje kontakt till en utlösare, ägare, godkännandeväg, krav på underlag och bevarandeplats.
3. Genomför en skrivbordsövning med fokus på underrättelsebeslut, myndighetskontakt, leverantörssamordning och bevarande av underlag.
4. Uppdatera ISMS-poster, inklusive register över regelefterlevnadskrav, runbook för incidenthantering, kontaktlistor för verksamhetskontinuitet och leverantörskontaktposter.

Clarysec kan hjälpa er att genomföra detta snabbt med Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls och våra policybibliotek för små och medelstora företag samt större organisationer, inklusive Policy för incidenthantering Policy för incidenthantering, Policy för rättslig och regulatorisk efterlevnad Policy för rättslig och regulatorisk efterlevnad - SME, Policy för verksamhetskontinuitet och katastrofåterställning Policy för verksamhetskontinuitet och katastrofåterställning och Policy för leverantörssäkerhet och tredjepartssäkerhet Policy för leverantörssäkerhet och tredjepartssäkerhet - SME.

24-timmarsklockan pausar inte medan teamet söker efter rätt kontakt. Bygg registret nu, testa det och gör det till en del av ert ISO-underlag innan nästa incident bestämmer tidslinjen åt er.