Registri regulatornih kontaktov za NIS2 in DORA kot dokazila za ISO 27001

Incident ob 02:17: ko seznam kontaktov postane kontrola

Ob 02:17 v torek analitik v SOC zazna vzorec, ki ga nihče ne želi videti. Privilegirani storitveni račun se je avtenticiral z neobičajne geografske lokacije, zapisi o strankah so bili zaporedno poizvedovani, ponudnik upravljanega zaznavanja in odzivanja pa je odprl zahtevek visoke resnosti. V nekaj minutah vodja incidenta potrdi skrb: kazalniki izsiljevalske programske opreme se širijo lateralno, kritična produkcijska storitev deluje degradirano, lahko pa so vključeni tudi podatki strank.

Tehnični odziv se začne hitro. Končne točke se izolirajo, dnevniki identitet se pridobijo, posnetki v oblaku se zavarujejo, ponudnik upravljanih varnostnih storitev pa se pridruži konferenčnemu klicu. Nato se začne hladnejša panika.

Vodja informacijske varnosti vpraša: »Koga moramo obvestiti?«

Pravna služba pove, da bo morda treba vključiti organ za varstvo podatkov. DPO vpraša, ali gre za kršitev varnosti osebnih podatkov. COO pove, da je treba ponudnika storitev v oblaku eskalirati na podlagi klavzule o podpori za poslovne uporabnike. Vodja skladnosti vpraša, ali je subjekt po NIS2 pomemben subjekt oziroma ali se uporablja DORA, ker storitev podpira regulirani finančni subjekt. Upravni odbor želi vedeti, kaj se mora zgoditi v prvih 24 urah.

Nihče ne dvomi, da je treba komunicirati. Težava je, da so kontaktni podatki, odobritvena pot, pravni sprožilci in zahteve glede dokazil razpršeni po stari preglednici za neprekinjeno poslovanje, pogodbah z dobavitelji, e-poštnih nitih, zastarelem wikiju za skladnost in telefonu ene osebe.

To ni le operativna nevšečnost. V letu 2026 je to vrzel skladnosti.

NIS2 je postopno obveščanje o incidentih spremenila v obveznost upravljanja, vključno z zgodnjim opozorilom v 24 urah, obvestilom v 72 urah in končnim poročilom v enem mesecu za pomembne incidente. DORA je vzpostavila namenski režim digitalne operativne odpornosti za finančne subjekte, vključno z upravljanjem incidentov IKT, razvrščanjem, poročanjem nadzornikom, tveganji IKT tretjih oseb in kriznim komuniciranjem. GDPR ostaja relevanten vedno, kadar so vključeni osebni podatki. ISO/IEC 27001:2022 te obveznosti pretvori v preverljiva dokazila sistema upravljanja.

Register regulatornih kontaktov zveni administrativno. Ni. Je povezovalno tkivo med odzivom na incidente, pravnim obveščanjem, neprekinjenim poslovanjem, koordinacijo z dobavitelji, odgovornostjo najvišjega vodstva in revizijskimi dokazili.

Clarysec to obravnava kot vprašanje dokazil, ne kot administrativno vajo. V Zenith Blueprint: 30-koračni načrt presojevalca Zenith Blueprint korak 22 v fazi Kontrole v praksi pojasnjuje, zakaj mora biti stik z organi določen vnaprej:

Kontrola 5.5 zagotavlja, da je organizacija pripravljena sodelovati z zunanjimi organi, kadar je to potrebno, ne odzivno ali v paniki, temveč prek vnaprej določenih, strukturiranih in dobro razumljenih kanalov.

To je dejanska lekcija incidenta ob 02:17. Čas za iskanje portala regulatorja za obvestila, dežurne telefonske številke CSIRT, nadomestnega kontakta DPO, kanala finančnega nadzornika za poročanje in eskalacijske poti dobavitelja je pred incidentom, ne takrat, ko rok za poročanje že teče.

Zakaj so registri regulatornih kontaktov postali prednostna naloga skladnosti v letu 2026

Mnoge organizacije že imajo sezname kontaktov za nujne primere. Težava je, da NIS2 in DORA zahtevata več discipline kot le seznam imen in telefonskih številk. Zahtevata točno, na vlogah temelječe in z dokazili podprto upravljanje kontaktov, povezano s pravnimi sprožilci, pooblastili za eskalacijo, roki poročanja in odvisnostmi od dobaviteljev.

NIS2 velja za širok nabor bistvenih in pomembnih subjektov v sektorjih, kot so energetika, promet, bančništvo, infrastruktura finančnih trgov, zdravstvo, pitna voda, odpadne vode, digitalna infrastruktura, upravljanje storitev IKT, javna uprava in vesolje. Zajema tudi številne digitalne ponudnike, vključno s storitvami računalništva v oblaku, storitvami podatkovnih centrov, omrežji za dostavo vsebin, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev, spletnimi tržnicami, spletnimi iskalniki in platformami družbenih omrežij. Države članice so morale do 17. aprila 2025 vzpostaviti sezname bistvenih in pomembnih subjektov ter jih posodobiti najmanj vsaki dve leti. Za številne ponudnike storitev v oblaku, SaaS, upravljanih storitev in digitalnih platform se je regulatorna izpostavljenost iz teoretične premaknila v operativno.

DORA se od 17. januarja 2025 uporablja za finančne subjekte, kot so kreditne institucije, plačilne institucije, institucije za izdajo elektronskega denarja, investicijska podjetja, ponudniki storitev v zvezi s kriptosredstvi, mesta trgovanja, centralne depotne družbe, centralne nasprotne stranke, zavarovalnice in pozavarovalnice ter druge zajete organizacije finančnega sektorja. DORA je zelo pomembna tudi za ekosistem IKT tretjih oseb, ker morajo finančni subjekti upravljati ponudnike, ki podpirajo kritične ali pomembne funkcije. DORA Article 17 zahteva proces upravljanja incidentov, povezanih z IKT, Article 18 določa pričakovanja glede razvrščanja, Article 19 pa ureja poročanje o večjih incidentih, povezanih z IKT, pristojnemu organu.

GDPR dodaja razsežnost zasebnosti. Kibernetski incident lahko postane kršitev varnosti osebnih podatkov, če vključuje nenamerno ali nezakonito uničenje, izgubo, spremembo, nepooblaščeno razkritje osebnih podatkov ali dostop do njih. Upravljavec mora biti sposoben dokazati odgovornost, oceniti tveganje za posameznike in, kadar je to potrebno, obvestiti nadzorni organ ter po možnosti prizadete posameznike, na katere se nanašajo podatki.

Zrel register regulatornih kontaktov mora zato pod pritiskom odgovoriti na pet vprašanj:

• Kateri CSIRT, pristojni organ, finančni nadzornik, organ za varstvo podatkov in kontakt organov pregona velja za to pravno osebo, jurisdikcijo in storitev?
• Katera notranja vloga je pooblaščena za začetek stika, odobritev besedila in oddajo obvestil?
• Katere dobavitelje je treba kontaktirati zaradi zajezitve, dnevnikov, obnovitve, ohranitve dokazil ali pogodbenega poročanja?
• Katera pot obveščanja strank, nasprotnih strank ali javnosti se sproži pri posamezni ravni resnosti?
• Kako dokažemo, da je bil register pregledan, testiran in pravilno uporabljen?

Odgovor ne sme obstajati samo v nabiralniku pravne službe ali v spominu vodje informacijske varnosti. Biti mora nadzorovan zapis SUVI.

Kaj vsebuje z dokazili podprt register kontaktov za NIS2 in DORA

Register regulatornih kontaktov mora biti zasnovan za uporabo med dejanskim incidentom. Če mora vodja incidenta v nekaj minutah sprejeti prvo odločitev o eskalaciji, register ne sme biti nejasen seznam spletnih mest. Biti mora strukturiran, preverjen in povezan z odzivnim priročnikom.

Popoln register mora vključevati najmanj šest družin kontaktov.

Prvič, uradne organe za kibernetsko varnost: nacionalne CSIRT, pristojne organe, enotne kontaktne točke, kjer je to relevantno, in sektorske agencije za kibernetsko varnost.

Drugič, finančne nadzornike za DORA: pristojne organe in kanale za poročanje, ki se uporabljajo za začetno, vmesno in končno poročanje o večjih incidentih, povezanih z IKT.

Tretjič, organe za zasebnost: organe za varstvo podatkov, logiko vodilnega nadzornega organa za čezmejno obdelavo in eskalacijske poti DPO.

Četrtič, organe pregona: enote za kibernetsko kriminaliteto, enote za goljufije in kontakte za nujne primere pri izsiljevanju, izsiljevalski programski opremi, nepooblaščenem dostopu in ohranitvi dokazil.

Petič, dobavitelje in IKT tretje osebe: ponudnike storitev v oblaku, ponudnike upravljanih varnostnih storitev, ponudnike upravljanih storitev, platforme identitet, plačilne procesorje, ponudnike digitalne forenzike in pravne svetovalce.

Šestič, notranje eskalacijske vloge: vodjo incidenta, vodjo informacijske varnosti, DPO, glavnega pravnega svetovalca, vodjo komuniciranja, odgovorno osebo za neprekinjeno poslovanje, izvršnega odobritelja, povezavo z upravnim odborom in lastnika storitve.

Register mora po potrebi vključevati tudi posebne interesne skupine, kot so ISAC ali sektorske skupnosti za izmenjavo informacij. To niso regulatorji, lahko pa postanejo pomembni kanali za obveščevalne podatke o grožnjah in usklajen odziv.

Zenith Blueprint to v koraku 22 pretvori v prakso:

Ustvarite ali posodobite postopke za sodelovanje z organi med varnostnimi dogodki (5.5), vključno s kontaktnimi podatki lokalnih CERT, regulatorjev in organov pregona. Vzdržujte podoben seznam kontaktov za sodelovanje v varnostnih forumih ali sektorskih skupinah (5.6). Te informacije hranite na dostopni, vendar z nadzorom dostopa zaščiteni lokaciji, ter jih vključite v operativni priročnik za odziv na incidente.

Zadnji stavek je pomemben. Če register ni v operativnem priročniku za odziv na incidente, se ob dejanskem pritisku verjetno ne bo uporabljal.

Primer strukture registra kontaktov za ponudnika FinTech ali SaaS

Predstavljajte si ponudnika FinTech SaaS, ki podpira analitiko plačil za stranke v EU. Uporablja ponudnika storitev v oblaku, ponudnika upravljanega zaznavanja in odzivanja, platformo identitet, platformo podpore strankam in zunanjega pravnega svetovalca. Glede na svojo vlogo je lahko finančni subjekt, ponudnik storitev IKT tretje osebe, digitalni ponudnik v obsegu NIS2 ali obdelovalec osebnih podatkov po GDPR.

Praktičen register bi se lahko začel tako:

Vnosi ne smejo vsebovati nepotrebnih osebnih podatkov. Kjer je mogoče, uporabljajte kontakte na podlagi vlog, zaščitite občutljive kontaktne podatke in zagotovite razpoložljivost izven omrežja med večjim izpadom. Register, ki je dostopen samo iz istih sistemov, prizadetih zaradi incidenta z izsiljevalsko programsko opremo, ni odporen.

Preslikava registra v dokazila ISO/IEC 27001:2022

Presojevalci organizacije redko ocenijo negativno zato, ker nima preglednice. Ocenijo jo negativno, ker organizacija ne more dokazati, da je preglednica popolna, aktualna, odobrena, zaščitena, testirana in povezana z dejanskimi procesi.

ISO/IEC 27001:2022 se začne z organizacijskim kontekstom. Klavzule 4.1 do 4.4 zahtevajo, da organizacija razume notranja in zunanja vprašanja, opredeli zainteresirane strani in njihove zahteve, določi obseg SUVI ter razume vmesnike in odvisnosti. Register regulatornih kontaktov je močno dokazilo, da so bile zakonske, regulatorne, pogodbene in deležniške zahteve prevedene v operativna razmerja.

Sledi voditeljstvo. Klavzule 5.1 do 5.3 zahtevajo, da najvišje vodstvo izkazuje voditeljstvo, dodeli odgovornosti, zagotovi komuniciranje in podpira SUVI. Če register opredeljuje, kdo je pooblaščen za obveščanje CSIRT, nadzornika ali organa za varstvo podatkov, kdo odobri zunanje komuniciranje in kdo poroča o statusu incidenta najvišjemu vodstvu, podpira dokazila o voditeljstvu.

Načrtovanje tveganj nato obveznosti pretvori v ukrepe. Klavzule 6.1.1 do 6.1.3 zahtevajo proces ocenjevanja in obravnave tveganj, primerjavo s Prilogo A, izjavo o uporabljivosti (SoA), načrt obravnave tveganja in sprejem preostalega tveganja. Register mora biti vključen v načrt obravnave tveganja za tveganja, kot so neuspešno pravno obveščanje, zamujena eskalacija incidenta, neuspešen odziv dobavitelja, napaka pri čezmejnem obveščanju in prekinitev komunikacije za neprekinjeno poslovanje.

Izhodiščne kontrole iz Priloge A so jasne:

V Zenith Controls: vodnik za navzkrižno skladnost Zenith Controls je stik z organi obravnavan kot kontrola 5.5 s preventivnimi in korektivnimi značilnostmi. Podpira zaupnost, celovitost in razpoložljivost ter se povezuje s koncepti kibernetske varnosti Identify, Protect, Respond in Recover. Zenith Controls jo povezuje z načrtovanjem incidentov, poročanjem o dogodkih, obveščevalnimi podatki o grožnjah, posebnimi interesnimi skupinami in odzivom na incidente. Pojasnjuje tudi, zakaj vnaprej vzpostavljeni kontakti z regulatorji, organi pregona, nacionalnimi CERT ali organi za varstvo podatkov omogočajo hitrejšo eskalacijo in usmerjanje med dogodki, kot so pomembne kršitve ali napadi z izsiljevalsko programsko opremo.

Kontrola ni izolirana. Zenith Controls preslika tudi kontrolo 6.8, poročanje o dogodkih informacijske varnosti, kot odkrivalno kontrolo, povezano z načrtovanjem incidentov, presojo dogodkov, odzivom, pridobljenimi izkušnjami, ozaveščanjem, spremljanjem in disciplinskimi postopki. Kontrola 5.24, načrtovanje in priprava upravljanja incidentov informacijske varnosti, se povezuje s presojo dogodkov, pridobljenimi izkušnjami, beleženjem, spremljanjem, varnostjo med motnjami, neprekinjenostjo in stikom z organi. Revizijska zgodba postane močnejša, ko so dogodki prijavljeni, ocenjeni, eskalirani, komunicirani, podprti z dokazili in izboljšani.

NIS2, DORA in GDPR: en register, različni pravni roki

En sam incident lahko sproži več pravnih delovnih tokov. Nepooblaščen dostop pri ponudniku SaaS je lahko pomemben incident po NIS2, kršitev varnosti osebnih podatkov po GDPR in pogodbeni dogodek obveščanja strank. Izpad pri finančnem subjektu je lahko večji incident, povezan z IKT, po DORA, hkrati pa zahteva tudi analizo po GDPR in koordinacijo z dobavitelji.

NIS2 od bistvenih in pomembnih subjektov zahteva, da brez nepotrebnega odlašanja obvestijo svoj CSIRT ali pristojni organ o pomembnih incidentih, ki vplivajo na zagotavljanje storitev. Model postopnega poročanja vključuje zgodnje opozorilo brez nepotrebnega odlašanja in v 24 urah od seznanitve, obvestilo o incidentu brez nepotrebnega odlašanja in v 72 urah, vmesna poročila o stanju na zahtevo ter končno poročilo v enem mesecu po obvestilu o incidentu. Če incident še traja, je lahko potrebno tudi poročanje o napredku.

DORA od finančnih subjektov zahteva, da vzdržujejo proces upravljanja incidentov, povezanih z IKT, ki zaznava, upravlja in sporoča incidente, evidentira incidente in pomembne kibernetske grožnje, razvršča resnost in kritičnost, dodeljuje vloge, določa eskalacijo in komunikacijo, poroča o večjih incidentih višjemu vodstvu ter podpira pravočasno obnovitev. Poročanje o večjih incidentih, povezanih z IKT, sledi logiki začetnega, vmesnega in končnega poročanja, pri čemer razvrščanje temelji na dejavnikih, kot so prizadete stranke, trajanje, geografska razširjenost, izguba podatkov, kritičnost storitev in gospodarski vpliv.

GDPR dodaja oceno kršitve varnosti osebnih podatkov. Register kontaktov sam po sebi ne odloča o pravni prijavljivosti. Zagotavlja, da lahko pravi ljudje hitro odločijo z uporabo aktualnih kanalov in dokumentiranih meril.

Clarysecova knjižnica politik to operacionalizira. V SME Politika odzivanja na incidente Politika odzivanja na incidente - SME klavzula 5.1.1 določa:

Generalni direktor (GM) je odgovoren za odobritev vseh odločitev o eskalaciji incidentov, regulatornih obvestil in zunanjega komuniciranja.

Ista SME politika v klavzuli 7.4.1 dodaja:

Kadar so vključeni podatki strank, mora generalni direktor oceniti zakonske obveznosti obveščanja glede na uporabljivost GDPR, NIS2 ali DORA.

Za podjetniška okolja Politika odzivanja na incidente Politika odzivanja na incidente v klavzuli 5.5 vzpostavlja komunikacijski okvir:

Vsa komunikacija, povezana z incidenti, mora slediti komunikacijski in eskalacijski matriki ter zagotavljati:

Klavzula 6.4.2 dodaja zahtevo glede dokazil:

Vsa obvestila o kršitvah morajo biti dokumentirana in odobrena pred oddajo, kopije pa morajo biti hranjene v SUVI.

Tu register postane dokazilo za ISO. Ne gre samo za to, da vemo, koga poklicati. Gre za dokazovanje, kdo je bil pooblaščen, kaj je bilo ocenjeno, kaj je bilo odobreno, kaj je bilo oddano in kje je hranjena kopija.

Clarysecov model dokazil: štirje artefakti, ki delujejo skupaj

Močna zmožnost upravljanja regulatornih kontaktov potrebuje štiri artefakte, ki delujejo kot ena veriga dokazil.

Register regulatornih kontaktov opredeljuje kontakte, kanale, sprožilce in lastnike. Komunikacijska in eskalacijska matrika določa, kdo kaj opravi. Dnevnik odločitev beleži razvrstitev, oceno prijavljivosti, pravni pregled in odobritev. Paket dokazil o obvestilih hrani oddana obvestila, potrdila portalov, e-pošto, zapiske klicev, povratne informacije regulatorjev, odzive dobaviteljev in končna poročila.

Clarysecova Politika pravne in regulativne skladnosti Politika pravne in regulativne skladnosti - SME izrecno uvaja koncept registra. Klavzula 5.5.2 določa:

Ključne zahteve skladnosti (npr. časovni roki za obvestila o kršitvah in klavzule o ravnanju s podatki) morajo biti izluščene in spremljane v evidenci skladnosti.

Evidenca skladnosti mora napajati register regulatornih kontaktov. Pravna zahteva lahko določa »zgodnje opozorilo po NIS2 v 24 urah«, register kontaktov pa opredeli nacionalni portal CSIRT, nadomestno dežurno številko, pooblaščenega oddajatelja, pravnega pregledovalca, zahtevana dokazila in pot hrambe.

Politike neprekinjenega poslovanja krepijo enako pričakovanje. SME Politika neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči - SME se v klavzuli 5.2.1.1 sklicuje na:

sezname kontaktov in alternativne komunikacijske načrte

Podjetniška Politika neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči v klavzuli 5.3.3 zahteva, da so ureditve neprekinjenosti:

podprte z ažurnimi seznami kontaktov in eskalacijskimi tokovi

V model sodi tudi upravljanje dobaviteljev. V SME Politika varnosti tretjih oseb in dobaviteljev Politika varnosti tretjih oseb in dobaviteljev - SME klavzula 5.4.3 zahteva:

dodeljeno kontaktno osebo

Za NIS2 in DORA ta kontakt ne sme biti generičen. Če kritični ponudnik storitev v oblaku, ponudnik upravljanih varnostnih storitev, ponudnik identitet ali plačilni procesor podpira regulirano storitev, mora register opredeliti operativni kontakt, kontakt za varnostne incidente, pogodbeni kanal za obvestila in eskalacijsko pot za zahteve po dokazilih.

Zgradite register v enem delovnem srečanju

Uporaben register je mogoče vzpostaviti hitro, če so v prostoru pravi ljudje. Načrtujte dvourno srečanje z vodjo informacijske varnosti, DPO, pravnim svetovalcem, upravljavcem dobaviteljev, odgovorno osebo za neprekinjeno poslovanje, vodjo incidenta in lastnikom skladnosti.

Začnite z evidenco skladnosti. Izluščite obveznosti poročanja po NIS2, DORA, GDPR, pogodbah in sektorskih zahtevah. Zabeležite roke, merila prijavljivosti in zahteve glede dokazil.

Odprite operativni priročnik za odziv na incidente. Za vsako kategorijo incidentov, kot so izsiljevalska programska oprema, nepooblaščen dostop, izpad storitve, iznos podatkov, incident dobavitelja in odpoved regije v oblaku, opredelite potrebne zunanje kontakte.

Register regulatornih kontaktov izpolnite z organom, jurisdikcijo, sprožilcem, primarnim kanalom, nadomestnim kanalom, lastnikom, odobriteljem, potrebnimi dokazili, datumom zadnjega preverjanja in lokacijo hrambe.

Povežite kontakte dobaviteljev. Za vsako kritično ali pomembno funkcijo opredelite kontakt ponudnika za varnostne incidente, pogodbeni kanal za obvestila, revizijski kontakt in eskalacijsko pot za nujne primere.

Preglejte skladnost s politikami. Potrdite, da pooblastila za eskalacijo ustrezajo Politiki odzivanja na incidente, da se dokazila o obvestilih hranijo v SUVI, da so seznami kontaktov za neprekinjeno poslovanje usklajeni in da imajo kontakti dobaviteljev dodeljene lastnike.

Preizkusite en scenarij. Uporabite osredotočeno namizno vajo: »Izpostavljenost podatkov strank je bila zaznana ob 02:17, vpliva na stranke v EU in je morda posledica kompromitiranih poverilnic ponudnika identitet.« Ekipa naj ugotovi, ali so morda potrebna obvestila CSIRT, organu za varstvo podatkov, finančnemu nadzorniku, dobavitelju in strankam. Cilj vaje ni izsiliti končnega pravnega sklepa. Cilj je dokazati, kje so kontakti, kdo odobri stik, katera dokazila so potrebna in kje se odločitve beležijo.

Ustvarite paket dokazil. Shranite različico registra, udeležence srečanja, odobritve, zapiske scenarija, dnevnik odločitev, akcijske naloge in posodobljen sklic na operativni priročnik.

Tu postane korak 23 v Zenith Blueprint praktičen:

Zagotovite, da imate ažuren načrt odzivanja na incidente (5.24), ki zajema pripravo, eskalacijo, odziv in komunikacijo. Določite, kaj predstavlja prijavljiv varnostni dogodek (5.25), ter kako se proces odločanja sproži in dokumentira. Izberite nedavni dogodek ali izvedite namizno vajo za potrditev načrta.

Vaja ne rabi biti obsežna. Dokazati mora pripravljenost.

Preslikava navzkrižne skladnosti: en register, več okvirov

Vrednost registra regulatornih kontaktov je v tem, da zmanjšuje podvojeno delo za skladnost. En artefakt, pripravljen kot dokazilo, lahko podpira pričakovanja upravljanja po ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019.

NIST CSF 2.0 je posebej uporaben kot integracijska plast. Njegova funkcija GOVERN pričakuje, da organizacije razumejo deležnike, zakonske in regulatorne obveznosti, kritične storitve, odvisnosti, apetit po tveganju, vloge, politike, nadzor in tveganje dobaviteljev. Profili CSF organizacijam pomagajo dokumentirati trenutni profil, opredeliti ciljni profil, analizirati vrzeli in pripraviti prednostni akcijski načrt. Register regulatornih kontaktov je lahko konkretno dokazilo, ki zapira vrzel med trenutnim in ciljnim upravljanjem incidentov.

Za dobavno verigo NIST CSF 2.0 pričakuje, da imajo dobavitelji, stranke in partnerji opredeljene vloge in odgovornosti za kibernetsko varnost, da je znana kritičnost dobaviteljev, da so zahteve kibernetske varnosti vključene v pogodbe, da se tveganja dobaviteljev ocenjujejo in da so relevantni dobavitelji vključeni v načrtovanje incidentov, odziv in obnovitev. To se neposredno preslika v tveganja IKT tretjih oseb po DORA in pričakovanja dobavne verige po NIS2.

Kako bodo presojevalci in nadzorniki testirali isti register

Dobro vzdrževan register bo pregledan različno, odvisno od pogleda pregledovalca.

Presojevalec ISO/IEC 27001:2022 bo začel z obsegom in zainteresiranimi stranmi. Vprašal bo, kako je organizacija opredelila relevantne organe, zakonske obveznosti, pogodbene obveznosti obveščanja in zunanje izvajane odvisnosti. Nato bo sledil registru do izjave o uporabljivosti, načrta odzivanja na incidente, načrta neprekinjenega poslovanja in hrambe dokazil. Lahko vzorči en kontakt in zahteva dokazilo o zadnjem preverjanju.

Ocenjevalec NIS2 se bo osredotočil na to, ali je subjekt opredelil pravilen CSIRT ali pristojni organ in ali so pragovi pomembnih incidentov operacionalizirani. Iskal bo proces, ki podpira 24-urno zgodnje opozorilo, 72-urno obvestilo in končno poročanje. Prav tako bo preveril nadzor organa upravljanja, ker NIS2 Article 20 določa upravljanje kibernetske varnosti kot odgovornost vodstva.

Nadzornik DORA ali skupina za notranjo revizijo bo preverila, ali register podpira upravljanje incidentov, razvrščanje, poročanje o večjih incidentih, povezanih z IKT, krizno komuniciranje, poročanje višjemu vodstvu, koordinacijo z dobavitelji in operativno obnovitev. Lahko vpraša, ali obstajajo kontakti za ponudnike storitev IKT tretjih oseb, ki podpirajo kritične ali pomembne funkcije, ter ali se komunikacijske obveznosti odražajo v pogodbah.

Presoja po GDPR ali pregled DPO se bo osredotočil na oceno kršitve varnosti osebnih podatkov. Pregledovalci bodo vprašali, ali so DPO in pravni kontakti za zasebnost vključeni zgodaj, ali so vloge upravljavca in obdelovalca jasne, ali je opredeljen pravilen nadzorni organ in ali so odločitve o obveščanju posameznikov, na katere se nanašajo podatki, zabeležene.

Ocenjevalec NIST CSF bo register obravnaval kot dokazilo za rezultate GOVERN: pričakovanja deležnikov, zakonske obveznosti, vloge, politike, nadzor in tveganje dobavne verige. Presojevalec COBIT 2019 ali presojevalec v slogu ISACA bo preveril, ali so potrebe deležnikov prevedene v prakse upravljanja in vodenja, ali so odgovornosti dodeljene in ali se uspešnost procesov spremlja.

Isti artefakt mora prestati vsa ta vprašanja. Zato mora biti register nadzorovan, imeti lastnika, biti pregledan, zaščiten z nadzorom dostopa in testiran.

Pogosti vzorci neuspehov pri upravljanju kontaktov

Organizacije redko padejo zato, ker sploh nimajo kontaktov. Padejo zato, ker kontaktom med dejanskim incidentom ni mogoče zaupati.

Vsaka težava ustvarja predvidljivo revizijsko ugotovitev. Odprava je enako predvidljiva: uskladite register s politiko, vključite ga v odziv na incidente, preverite kontakte, testirajte delovni tok in hranite dokazila.

Odgovornost upravnega odbora in vodstva

NIS2 zahteva, da organi upravljanja odobrijo ukrepe upravljanja kibernetskih tveganj, nadzirajo implementacijo in se udeležijo usposabljanja. DORA Article 5 določa, da je organ upravljanja odgovoren za opredelitev, odobritev, nadzor in odgovornost za ureditve IKT-tveganj, vključno s politikami, vlogami, neprekinjenim poslovanjem IKT, načrti odziva in obnovitve, politiko IKT tretjih oseb ter ozaveščanjem in usposabljanjem. ISO/IEC 27001:2022 od vodstva zahteva, da SUVI uskladi s strateško usmeritvijo, zagotovi vire, dodeli odgovornosti in podpira nenehno izboljševanje.

Upravnemu odboru ni treba znati telefonske številke CSIRT na pamet. Potrebuje pa zagotovilo, da pripravljenost na obveščanje obstaja, ima lastnika, je testirana in pregledana.

Četrtletni paket za vodstvo mora vključevati:

• status pregleda registra regulatornih kontaktov
• spremembe relevantnih organov, nadzornikov ali jurisdikcij
• odprte vrzeli pri kontaktih dobaviteljev za incidente
• rezultate namiznih vaj in pridobljene izkušnje
• dokazila o testiranju odobritvenega delovnega toka za obvestila
• metrike časa od zaznave do odločitve o eskalaciji
• posodobitve obveznosti poročanja po NIS2, DORA, GDPR in pogodbah
• preostala tveganja, ki zahtevajo sprejem vodstva

S tem se register iz operativne preglednice spremeni v kontrolno točko upravljanja.

Kako vam Clarysec pomaga vzpostaviti upravljanje kontaktov, pripravljeno za presojo

Clarysec povezuje besedilo politik, zaporedje implementacije in preslikavo kontrol med okviri v eno dokazno pot.

Knjižnica politik določa odgovornost in zahtevane zapise. Politika odzivanja na incidente določa pričakovanja glede eskalacije, odobritve obvestil in hrambe. Politika pravne in regulativne skladnosti zahteva spremljanje zahtev skladnosti, kot so časovni roki za obvestila o kršitvah. Politika neprekinjenega poslovanja in obnovitve po nesreči zahteva ažurne sezname kontaktov in alternativne komunikacijske načrte. Politika varnosti tretjih oseb in dobaviteljev zahteva dodeljene kontakte dobaviteljev.

Zenith Blueprint zagotavlja zaporedje implementacije. Korak 5 v fazi temeljev SUVI in voditeljstva obravnava komunikacijo, ozaveščanje in kompetence, vključno z zunanjimi deležniki, časovnim okvirom, vlogami komunikatorjev in komunikacijskimi načrti. Korak 22 vgrajuje kontakte organov in posebnih interesnih skupin v organizacijske ukrepe. Korak 23 potrjuje upravljanje incidentov, odločitve o prijavljivih dogodkih, ohranitev forenzičnih dokazov in pridobljene izkušnje.

Vodnik Zenith Controls zagotavlja kompas navzkrižne skladnosti. Prikazuje, kako se stik z organi povezuje z načrtovanjem incidentov, poročanjem o dogodkih, obveščevalnimi podatki o grožnjah, posebnimi interesnimi skupinami in odzivom na incidente. Prikazuje tudi, zakaj sta poročanje o dogodkih informacijske varnosti in priprava na incidente nujna spremljevalca. Register kontaktov je učinkovit samo, če so dogodki prijavljeni in ocenjeni dovolj zgodaj, da ga sprožijo.

Za mala in srednja podjetja to pomeni vitek, vendar zagovorljiv register, jasno odgovornost in dokazila, skladna z načelom sorazmernosti. Za podjetja pomeni integracijo med jurisdikcijami, pravnimi osebami, poslovnimi enotami, dobavitelji, regulatorji, nadzorniki, CSIRT in poročanjem upravnemu odboru.

Naslednji koraki: zgradite register, preden ura začne teči

Če se vaša organizacija pripravlja na NIS2, DORA, pripravljenost na obveščanje o kršitvah po GDPR ali certifikacijo ISO/IEC 27001:2022, ne čakajte na dejanski incident, da ugotovite, ali vaše upravljanje kontaktov deluje.

Ta teden začnite s štirimi ukrepi:

1. Ustvarite ali osvežite register regulatornih kontaktov za CSIRT, pristojne organe, finančne nadzornike, organe za varstvo podatkov, organe pregona, kritične dobavitelje in notranje eskalacijske vloge.
2. Vsak kontakt preslikajte na sprožilec, lastnika, odobritveno pot, zahtevo glede dokazil in lokacijo hrambe.
3. Izvedite eno namizno vajo, osredotočeno na odločitve o obveščanju, stik z organi, koordinacijo z dobavitelji in hrambo dokazil.
4. Posodobite zapise SUVI, vključno z evidenco skladnosti, operativnim priročnikom za odziv na incidente, seznami kontaktov za neprekinjeno poslovanje in evidencami kontaktov dobaviteljev.

Clarysec vam lahko pomaga to hitro implementirati z uporabo Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls ter naših SME in podjetniških knjižnic politik, vključno s Politiko odzivanja na incidente Politika odzivanja na incidente, Politiko pravne in regulativne skladnosti Politika pravne in regulativne skladnosti - SME, Politiko neprekinjenega poslovanja in obnovitve po nesreči Politika neprekinjenega poslovanja in obnovitve po nesreči in Politiko varnosti tretjih oseb in dobaviteljev Politika varnosti tretjih oseb in dobaviteljev - SME.

24-urna ura se ne ustavi, medtem ko vaša ekipa išče pravi kontakt. Zgradite register zdaj, testirajte ga in ga vključite med dokazila ISO, preden naslednji incident namesto vas določi časovnico.