Registar regulatornih kontakata za NIS2 i DORA kao dokaz za ISO 27001

Incident u 02:17: kada popis kontakata postaje kontrola

U utorak u 02:17 analitičar u sigurnosno-operativnom centru uočava obrazac koji nitko ne želi vidjeti. Povlašteni servisni račun autentificirao se s neuobičajene geografske lokacije, zapisi o klijentima sekvencijalno su pretraživani, a pružatelj MDR usluga otvorio je prijavu incidenta visoke ozbiljnosti. U roku od nekoliko minuta voditelj incidenta potvrđuje zabrinutost: pokazatelji ransomwarea šire se lateralno, kritična produkcijska usluga radi degradirano, a podaci klijenata mogu biti zahvaćeni.

Tehnički odgovor počinje brzo. Krajnji uređaji se izoliraju, dnevnici identiteta se izdvajaju, snapshoti u oblaku se čuvaju, a pružatelj upravljanih sigurnosnih usluga pridružuje se konferencijskom pozivu. Zatim počinje hladnija panika.

CISO pita: „Koga obavještavamo?”

Pravni odjel kaže da bi možda trebalo uključiti tijelo za zaštitu podataka. DPO pita je li riječ o povredi osobnih podataka. COO navodi da se problem mora eskalirati pružatelju usluga u oblaku prema klauzuli o podršci za poslovne korisnike. Rukovoditelj usklađenosti pita je li subjekt važan subjekt prema NIS2 ili se primjenjuje DORA jer usluga podupire regulirani financijski subjekt. Upravni odbor želi znati što se mora dogoditi u prvih 24 sata.

Nitko ne dovodi u pitanje potrebu za komunikacijom. Problem je u tome što su kontaktni podaci, put odobrenja, pravni okidači i zahtjevi za dokazima raspršeni po staroj proračunskoj tablici za neprekidnost poslovanja, ugovorima s dobavljačima, nitima e-pošte, zastarjelom wikiju za usklađenost i telefonu jedne osobe.

To nije samo operativna neugodnost. U 2026. to je nedostatak usklađenosti.

NIS2 je postupno obavješćivanje o incidentima pretvorio u obvezu upravljanja, uključujući rano upozorenje u roku od 24 sata, obavijest u roku od 72 sata i završno izvješće u roku od jednog mjeseca za značajne incidente. DORA je uspostavila poseban režim digitalne operativne otpornosti za financijske subjekte, uključujući upravljanje incidentima povezanima s IKT-om, klasifikaciju, izvješćivanje nadzornih tijela, IKT rizike trećih strana i kriznu komunikaciju. GDPR ostaje relevantan kad god su uključeni osobni podaci. ISO/IEC 27001:2022 pretvara te obveze u revizijski provjerljive dokaze sustava upravljanja.

Registar regulatornih kontakata zvuči administrativno. Nije. On je povezujuće tkivo između odgovora na incidente, pravnih obavijesti, neprekidnosti poslovanja, koordinacije s dobavljačima, odgovornosti rukovodstva i revizijskih dokaza.

Clarysec to tretira kao pitanje dokaza, a ne kao vježbu papirologije. U Zenith Blueprint: revizorov plan u 30 koraka Zenith Blueprint, korak 22 u fazi Kontrole u praksi objašnjava zašto kontakt s nadležnim tijelima mora biti unaprijed definiran:

Kontrola 5.5 osigurava da je organizacija spremna komunicirati s vanjskim nadležnim tijelima kada je to potrebno, ne reaktivno ili u panici, nego putem unaprijed definiranih, strukturiranih i dobro razumljivih kanala.

To je stvarna pouka incidenta u 02:17. Vrijeme za pronalazak regulatornog portala za obavješćivanje, dežurnog telefona CSIRT-a, zamjenskog kontakta DPO-a, kanala financijskog nadzornog tijela i puta eskalacije prema dobavljaču jest prije incidenta, a ne dok rok za prijavu već teče.

Zašto su registri regulatornih kontakata postali prioritet usklađenosti u 2026.

Mnoge organizacije već imaju popise kontakata za hitne slučajeve. Problem je u tome što NIS2 i DORA zahtijevaju discipliniraniji pristup od popisa imena i telefonskih brojeva. Zahtijevaju točno, na ulogama utemeljeno i dokazima potkrijepljeno upravljanje kontaktima povezano s pravnim okidačima, ovlastima za eskalaciju, rokovima za prijavu i ovisnostima o dobavljačima.

NIS2 se primjenjuje na širok skup ključnih i važnih subjekata u sektorima kao što su energetika, promet, bankarstvo, infrastruktura financijskih tržišta, zdravstvo, pitka voda, otpadne vode, digitalna infrastruktura, upravljanje IKT uslugama, javna uprava i svemir. Obuhvaća i mnoge digitalne pružatelje, uključujući usluge računalstva u oblaku, usluge podatkovnih centara, mreže za isporuku sadržaja, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, internetska tržišta, internetske tražilice i platforme društvenih mreža. Države članice morale su uspostaviti popise ključnih i važnih subjekata do 17. travnja 2025. i ažurirati ih najmanje svake dvije godine. Za mnoge pružatelje usluga u oblaku, SaaS-a, upravljanih usluga i digitalnih platformi regulatorna izloženost prešla je iz teorijske u operativnu.

DORA se od 17. siječnja 2025. primjenjuje na financijske subjekte kao što su kreditne institucije, institucije za platni promet, institucije za elektronički novac, investicijska društva, pružatelji usluga povezanih s kriptoimovinom, mjesta trgovanja, središnji depozitoriji vrijednosnih papira, središnje druge ugovorne strane, društva za osiguranje i reosiguranje te druge obuhvaćene organizacije financijskog sektora. DORA je vrlo relevantna i za ekosustav IKT trećih strana jer financijski subjekti moraju upravljati pružateljima koji podupiru kritične ili važne funkcije. DORA Article 17 zahtijeva proces upravljanja incidentima povezanima s IKT-om, Article 18 postavlja očekivanja klasifikacije, a Article 19 uređuje prijavljivanje većih incidenata povezanih s IKT-om nadležnom tijelu.

GDPR dodaje dimenziju privatnosti. Kibernetički incident može postati povreda osobnih podataka ako uključuje slučajno ili nezakonito uništenje, gubitak, izmjenu, neovlašteno otkrivanje ili pristup osobnim podacima. Voditelj obrade mora moći dokazati odgovornost, procijeniti rizik za pojedince i, kada je potrebno, obavijestiti nadzorno tijelo, a možda i pogođene ispitanike.

Zreo registar regulatornih kontakata stoga mora pod pritiskom odgovoriti na pet pitanja:

• Koji se CSIRT, nadležno tijelo, financijsko nadzorno tijelo, tijelo za zaštitu podataka i kontakt tijela kaznenog progona primjenjuju na ovaj pravni subjekt, jurisdikciju i uslugu?
• Koja je interna uloga ovlaštena pokrenuti kontakt, odobriti formulaciju i podnijeti obavijesti?
• Koje dobavljače treba kontaktirati radi ograničavanja štete, dnevnika, vraćanja podataka, očuvanja dokaza ili ugovornog izvješćivanja?
• Koji se komunikacijski put prema klijentima, ugovornim stranama ili javnosti aktivira na svakoj razini ozbiljnosti?
• Kako dokazujemo da je registar pregledan, testiran i ispravno korišten?

Odgovor ne smije postojati samo u sandučiću pravnog odjela ili u sjećanju CISO-a. Mora biti kontrolirani ISMS zapis.

Što sadrži registar kontakata za NIS2 i DORA spreman za dokaze

Registar regulatornih kontakata treba biti projektiran za uporabu tijekom stvarnog incidenta. Ako voditelj incidenta mora donijeti prvu odluku o eskalaciji u roku od nekoliko minuta, registar ne može biti nejasan popis internetskih stranica. Mora biti strukturiran, provjeren i povezan s operativnim uputama za odgovor.

Potpuni registar treba uključivati najmanje šest skupina kontakata.

Prvo, službena tijela za kibernetičku sigurnost: nacionalne CSIRT-ove, nadležna tijela, jedinstvene kontaktne točke gdje je primjenjivo i sektorske agencije za kibernetičku sigurnost.

Drugo, financijska nadzorna tijela za DORA: nadležna tijela i kanale za prijavu koji se koriste za početno, međufazno i završno prijavljivanje većih incidenata povezanih s IKT-om.

Treće, tijela za privatnost: tijela za zaštitu podataka, logiku vodećeg nadzornog tijela za prekograničnu obradu i putove eskalacije DPO-u.

Četvrto, tijela kaznenog progona: jedinice za kibernetički kriminal, jedinice za prijevare i hitne kontakte za iznudu, ransomware, neovlašteni pristup i očuvanje dokaza.

Peto, dobavljače i IKT treće strane: pružatelje usluga u oblaku, pružatelje upravljanih sigurnosnih usluga, pružatelje upravljanih usluga, platforme identiteta, procesore plaćanja, pružatelje digitalne forenzike i pravne savjetnike.

Šesto, interne uloge za eskalaciju: voditelja incidenta, CISO-a, DPO-a, glavnog pravnog savjetnika, voditelja komunikacija, odgovornu osobu za neprekidnost poslovanja, izvršnog odobravatelja, osobu za vezu s upravnim odborom i vlasnika usluge.

Registar također treba uključiti posebne interesne skupine kada je to relevantno, kao što su ISAC-i ili sektorske zajednice za razmjenu informacija. To nisu regulatori, ali mogu postati važni kanali za obavještajne podatke o prijetnjama i koordinirani odgovor.

Zenith Blueprint to praktično razrađuje u koraku 22:

Izradite ili ažurirajte postupke za uključivanje nadležnih tijela tijekom sigurnosnih događaja (5.5), uključujući podatke za kontakt lokalnih CERT-ova, regulatora i tijela kaznenog progona. Održavajte sličan popis kontakata za sudjelovanje u sigurnosnim forumima ili sektorskim skupinama (5.6). Pohranite te informacije na dostupnoj lokaciji s kontrolom pristupa i uključite ih u operativne upute za odgovor na incidente.

Ta je zadnja rečenica važna. Ako registar nije u operativnim uputama za odgovor na incidente, vjerojatno se neće koristiti kada pritisak postane stvaran.

Primjer strukture registra kontakata za FinTech ili SaaS pružatelja

Zamislite fintech SaaS pružatelja koji podupire analitiku plaćanja za klijente iz EU. Koristi pružatelja usluga u oblaku, pružatelja MDR usluga, platformu identiteta, platformu korisničke podrške i vanjskog pravnog savjetnika. Ovisno o svojoj ulozi, može biti financijski subjekt, pružatelj IKT usluga treće strane, digitalni pružatelj u opsegu NIS2 ili izvršitelj obrade osobnih podataka prema GDPR-u.

Praktični registar mogao bi započeti ovako:

Unosi ne smiju sadržavati nepotrebne osobne podatke. Gdje god je moguće koristite kontakte temeljene na ulogama, zaštitite osjetljive kontaktne podatke i osigurajte dostupnost izvan mreže tijekom većeg prekida. Registar koji je dostupan samo iz istih sustava pogođenih ransomware incidentom nije otporan.

Mapiranje registra na dokaze za ISO/IEC 27001:2022

Revizori rijetko negativno ocijene organizaciju zato što nema proračunsku tablicu. Negativno je ocijene zato što organizacija ne može dokazati da je tablica potpuna, ažurna, odobrena, zaštićena, testirana i povezana sa stvarnim procesima.

ISO/IEC 27001:2022 počinje kontekstom organizacije. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije interna i vanjska pitanja, identificira zainteresirane strane i njihove zahtjeve, definira opseg ISMS-a te razumije sučelja i ovisnosti. Registar regulatornih kontakata snažan je dokaz da su pravni, regulatorni, ugovorni i zahtjevi dionika prevedeni u operativne odnose.

Slijedi vodstvo. Točke 5.1 do 5.3 zahtijevaju od najvišeg rukovodstva da pokaže vodstvo, dodijeli odgovornosti, osigura komunikaciju i podupre ISMS. Ako registar identificira tko je ovlašten obavijestiti CSIRT, nadzorno tijelo ili tijelo za zaštitu podataka, tko odobrava vanjske komunikacije i tko izvješćuje najviše rukovodstvo o statusu incidenta, on podupire dokaze o vodstvu.

Planiranje rizika zatim pretvara obveze u djelovanje. Točke 6.1.1 do 6.1.3 zahtijevaju proces procjene rizika i obrade rizika, usporedbu s Prilogom A, Izjavu o primjenjivosti, plan obrade rizika i prihvaćanje preostalog rizika. Registar se treba pojaviti u planu obrade za rizike kao što su neuspjeh pravne obavijesti, zakašnjela eskalacija incidenta, neuspjeh odgovora dobavljača, pogreška prekogranične obavijesti i prekid komunikacije za neprekidnost poslovanja.

Uporišta kontrola iz Priloga A jasna su:

U Zenith Controls: vodič za međusobnu usklađenost Zenith Controls, kontakt s nadležnim tijelima obrađen je kao kontrola 5.5 s preventivnim i korektivnim obilježjima. Podupire povjerljivost, cjelovitost i dostupnost te se povezuje s konceptima kibernetičke sigurnosti Identify, Protect, Respond i Recover. Zenith Controls povezuje je s planiranjem incidenata, prijavljivanjem događaja, obavještajnim podacima o prijetnjama, posebnim interesnim skupinama i odgovorom na incidente. Također objašnjava zašto unaprijed uspostavljeni kontakti s regulatorima, tijelima kaznenog progona, nacionalnim CERT-ovima ili agencijama za zaštitu podataka omogućuju bržu eskalaciju i usmjeravanje tijekom događaja kao što su značajne povrede ili ransomware napadi.

Kontrola nije izolirana. Zenith Controls također mapira kontrolu 6.8, Prijavljivanje događaja informacijske sigurnosti, kao detektivnu kontrolu povezanu s planiranjem incidenata, procjenom događaja, odgovorom, naučenim lekcijama, podizanjem svijesti, praćenjem i stegovnim postupkom. Kontrola 5.24, Planiranje i priprema upravljanja incidentima informacijske sigurnosti, povezuje se s procjenom događaja, naučenim lekcijama, zapisivanjem događaja, praćenjem, sigurnošću tijekom poremećaja, neprekidnošću i kontaktom s nadležnim tijelima. Revizijska priča postaje snažnija kada se događaji prijavljuju, procjenjuju, eskaliraju, komuniciraju, potkrepljuju dokazima i poboljšavaju.

NIS2, DORA i GDPR: jedan registar, različiti pravni rokovi

Jedan incident može pokrenuti nekoliko pravnih radnih tokova. Neovlašteni pristup kod SaaS pružatelja može biti značajan incident prema NIS2, povreda osobnih podataka prema GDPR-u i ugovorni događaj za obavješćivanje klijenata. Prekid rada kod financijskog subjekta može biti veći incident povezan s IKT-om prema DORA, uz istodobnu potrebu za analizom prema GDPR-u i koordinacijom s dobavljačima.

NIS2 zahtijeva da ključni i važni subjekti bez nepotrebnog odgađanja obavijeste svoj CSIRT ili nadležno tijelo o značajnim incidentima koji utječu na pružanje usluga. Postupni model izvješćivanja uključuje rano upozorenje bez nepotrebnog odgađanja i u roku od 24 sata od saznanja, obavijest o incidentu bez nepotrebnog odgađanja i u roku od 72 sata, međufazna izvješća o statusu na zahtjev te završno izvješće u roku od jednog mjeseca nakon obavijesti o incidentu. Ako incident još traje, može biti potrebno i izvješćivanje o napretku.

DORA zahtijeva da financijski subjekti održavaju proces upravljanja incidentima povezanima s IKT-om koji otkriva, upravlja i prijavljuje incidente, evidentira incidente i značajne kibernetičke prijetnje, klasificira ozbiljnost i kritičnost, dodjeljuje uloge, definira eskalaciju i komunikaciju, prijavljuje veće incidente višem rukovodstvu i podupire pravodoban oporavak. Prijavljivanje većih incidenata povezanih s IKT-om slijedi početnu, međufaznu i završnu logiku izvješćivanja, uz klasifikaciju na temelju čimbenika kao što su pogođeni klijenti, trajanje, geografska rasprostranjenost, gubitak podataka, kritičnost usluga i ekonomski učinak.

GDPR dodaje procjenu povrede osobnih podataka. Registar kontakata sam po sebi ne odlučuje o pravnoj prijavljivosti. On osigurava da prave osobe mogu brzo odlučiti, koristeći ažurne kanale i dokumentirane kriterije.

Clarysecova biblioteka politika to operacionalizira. U Politici odgovora na incidente za MSP-ove Politika odgovora na incidente - MSP, točka 5.1.1 navodi:

Glavni direktor (GM) odgovoran je za odobravanje svih odluka o eskalaciji incidenata, regulatornih obavijesti i vanjskih komunikacija.

Ista politika za MSP-ove, točka 7.4.1, dodaje:

Kada su uključeni podaci klijenata, glavni direktor mora procijeniti pravne obveze obavješćivanja na temelju primjenjivosti GDPR-a, NIS2 ili DORA.

Za poslovna okruženja, Politika odgovora na incidente Politika odgovora na incidente, točka 5.5, uspostavlja komunikacijski okvir:

Sve komunikacije povezane s incidentima moraju slijediti Matricu komunikacije i eskalacije, čime se osigurava:

Točka 6.4.2 dodaje zahtjev za dokazima:

Sve prijave povrede podataka moraju biti dokumentirane i odobrene prije podnošenja, a kopije se moraju zadržati u ISMS-u.

Tu registar postaje ISO dokaz. Nije riječ samo o tome da znate koga nazvati. Riječ je o dokazivanju tko je bio ovlašten, što je procijenjeno, što je odobreno, što je podneseno i gdje se nalazi zadržana kopija.

Clarysecov model dokaza: četiri artefakta koji rade zajedno

Snažna sposobnost upravljanja regulatornim kontaktima zahtijeva četiri artefakta koji djeluju kao jedan lanac dokaza.

Registar regulatornih kontakata identificira kontakte, kanale, okidače i vlasnike. Matrica komunikacije i eskalacije definira tko što radi. Dnevnik odluka bilježi klasifikaciju, procjenu prijavljivosti, pravni pregled i odobrenje. Paket dokaza o obavijestima zadržava podnesene obavijesti, potvrde portala, e-poštu, bilješke poziva, povratne informacije regulatora, odgovore dobavljača i završna izvješća.

Clarysecova Politika pravne i regulatorne usklađenosti Politika pravne i regulatorne usklađenosti - MSP izričito uvodi koncept registra. Točka 5.5.2 navodi:

Ključni uvjeti usklađenosti (npr. rokovi za prijavu povrede podataka i odredbe o postupanju s podacima) moraju se izdvojiti i pratiti u Registru usklađenosti.

Registar usklađenosti treba hraniti registar regulatornih kontakata. Pravni zahtjev može glasiti „rano upozorenje prema NIS2 u roku od 24 sata”, dok registar kontakata identificira nacionalni CSIRT portal, zamjenski dežurni broj, ovlaštenog podnositelja, pravnog pregledavatelja, potrebne dokaze i lokaciju zadržavanja.

Politike neprekidnosti poslovanja pojačavaju isto očekivanje. Politika neprekidnosti poslovanja i oporavka od katastrofe za MSP-ove Politika neprekidnosti poslovanja i oporavka od katastrofe - MSP, točka 5.2.1.1, upućuje na:

popise kontakata i alternativne komunikacijske planove

Poslovna Politika neprekidnosti poslovanja i oporavka od katastrofe Politika neprekidnosti poslovanja i oporavka od katastrofe, točka 5.3.3, zahtijeva da aranžmani neprekidnosti budu:

Podržani ažurnim popisima kontakata i tokovima eskalacije

U model pripada i upravljanje dobavljačima. U Politici sigurnosti trećih strana i dobavljača za MSP-ove Politika sigurnosti trećih strana i dobavljača - MSP, točka 5.4.3 zahtijeva:

Dodijeljenu kontakt osobu

Za NIS2 i DORA taj kontakt ne može biti generički. Ako kritični pružatelj usluga u oblaku, pružatelj upravljanih sigurnosnih usluga, pružatelj identiteta ili procesor plaćanja podupire reguliranu uslugu, registar treba identificirati operativni kontakt, kontakt za sigurnosni incident, ugovorni kanal za obavijesti i put eskalacije za zahtjeve za dokazima.

Izradite registar u jednoj radnoj sesiji

Koristan registar može se brzo izraditi ako su prave osobe u prostoriji. Zakažite dvosatnu sesiju s CISO-om, DPO-om, pravnim savjetnikom, voditeljem dobavljača, odgovornom osobom za neprekidnost poslovanja, voditeljem incidenta i vlasnikom usklađenosti.

Počnite s Registrom usklađenosti. Izdvojite obveze izvješćivanja prema NIS2, DORA, GDPR-u, ugovorima i sektorskim pravilima. Zabilježite rokove, kriterije prijavljivosti i zahtjeve za dokazima.

Otvorite operativne upute za odgovor na incidente. Za svaku kategoriju incidenta, kao što su ransomware, neovlašteni pristup, prekid usluge, iznošenje podataka, incident dobavljača i kvar regije oblaka, identificirajte potrebne vanjske kontakte.

Popunite registar regulatornih kontakata nadležnim tijelom, jurisdikcijom, okidačem, primarnim kanalom, zamjenskim kanalom, vlasnikom, odobravateljem, potrebnim dokazima, datumom zadnje provjere i lokacijom zadržavanja.

Povežite kontakte dobavljača. Za svaku kritičnu ili važnu funkciju identificirajte kontakt pružatelja za sigurnosne incidente, ugovorni kanal za obavijesti, revizijski kontakt i hitni put eskalacije.

Pregledajte u odnosu na politike. Potvrdite da se ovlasti za eskalaciju podudaraju s Politikom odgovora na incidente, da se dokazi o obavijestima zadržavaju u ISMS-u, da su popisi kontakata za neprekidnost poslovanja usklađeni i da kontakti dobavljača imaju dodijeljene vlasnike.

Testirajte jedan scenarij. Upotrijebite fokusiranu stolnu vježbu: „Izloženost podataka klijenata otkrivena u 02:17, utječe na klijente iz EU i možda je uzrokovana kompromitiranim vjerodajnicama pružatelja identiteta.” Zatražite od tima da utvrdi mogu li biti potrebne obavijesti prema CSIRT-u, tijelu za zaštitu podataka, financijskom nadzornom tijelu, dobavljaču i klijentima. Cilj nije prisiliti konačan pravni zaključak tijekom vježbe. Cilj je dokazati gdje se kontakti nalaze, tko odobrava kontakt, koji su dokazi potrebni i gdje se odluke zapisuju.

Izradite paket dokaza. Spremite verziju registra, sudionike sastanka, odobrenja, bilješke scenarija, dnevnik odluka, stavke za postupanje i ažuriranu referencu na operativne upute.

Tu Zenith Blueprint korak 23 postaje praktičan:

Osigurajte ažuran plan odgovora na incidente (5.24), koji obuhvaća pripremu, eskalaciju, odgovor i komunikaciju. Definirajte što predstavlja prijavljivi sigurnosni događaj (5.25) te kako se proces odlučivanja pokreće i dokumentira. Odaberite nedavni događaj ili provedite stolnu vježbu kako biste provjerili svoj plan.

Vježba ne mora biti složena. Mora dokazati spremnost.

Mapiranje međusobne usklađenosti: jedan registar, mnogi okviri

Vrijednost registra regulatornih kontakata jest u tome što smanjuje duplicirani napor usklađenosti. Jedan artefakt spreman za dokaze može poduprijeti očekivanja upravljanja u ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

NIST CSF 2.0 posebno je koristan kao integracijski sloj. Njegova funkcija GOVERN očekuje da organizacije razumiju dionike, pravne i regulatorne obveze, kritične usluge, ovisnosti, apetit za rizik, uloge, politike, nadzor i rizik dobavljača. Njegovi CSF profili pomažu organizacijama dokumentirati Current Profile, definirati Target Profile, analizirati praznine i izraditi prioritizirani akcijski plan. Registar regulatornih kontakata može biti konkretan dokaz koji zatvara jaz između trenutačnog i ciljnog upravljanja incidentima.

Za opskrbni lanac, NIST CSF 2.0 očekuje da dobavljači, klijenti i partneri imaju definirane uloge i odgovornosti u kibernetičkoj sigurnosti, da je poznata kritičnost dobavljača, da su zahtjevi kibernetičke sigurnosti ugrađeni u ugovore, da se rizici dobavljača procjenjuju i da su relevantni dobavljači uključeni u planiranje, odgovor i oporavak od incidenata. To se izravno mapira na IKT rizik trećih strana prema DORA i očekivanja opskrbnog lanca prema NIS2.

Kako će revizori i nadzorna tijela testirati isti registar

Dobro održavan registar pregledavat će se različito ovisno o perspektivi pregledavatelja.

Revizor ISO/IEC 27001:2022 počet će od opsega i zainteresiranih strana. Pitat će kako je organizacija identificirala primjenjiva nadležna tijela, pravne obveze, ugovorne obveze obavješćivanja i ovisnosti o vanjsko ugovorenim uslugama. Zatim će pratiti registar do Izjave o primjenjivosti, plana odgovora na incidente, plana neprekidnosti poslovanja i zadržavanja dokaza. Može uzorkovati jedan kontakt i zatražiti dokaz zadnje provjere.

Procjenitelj za NIS2 usredotočit će se na to je li subjekt identificirao ispravan CSIRT ili nadležno tijelo i jesu li pragovi značajnog incidenta operativno uređeni. Tražit će proces sposoban poduprijeti rano upozorenje u roku od 24 sata, obavijest u roku od 72 sata i završno izvješćivanje. Također će gledati nadzor upravljačkog tijela jer NIS2 Article 20 čini upravljanje kibernetičkom sigurnošću odgovornošću vodstva.

Nadzorno tijelo za DORA ili tim unutarnje revizije testirat će podupire li registar upravljanje incidentima, klasifikaciju, izvješćivanje o većem incidentu povezanom s IKT-om, kriznu komunikaciju, izvješćivanje višem rukovodstvu, koordinaciju s dobavljačima i operativni oporavak. Mogu pitati postoje li kontakti za pružatelje IKT usluga trećih strana koji podupiru kritične ili važne funkcije i jesu li komunikacijske obveze odražene u ugovorima.

Revizor za GDPR ili pregled DPO-a usredotočit će se na procjenu povrede osobnih podataka. Pitat će jesu li DPO i pravni kontakti za privatnost rano uključeni, jesu li uloge voditelja i izvršitelja obrade jasne, je li identificirano ispravno nadzorno tijelo i jesu li odluke o komunikaciji s ispitanicima zabilježene.

Procjenitelj NIST CSF-a tretirat će registar kao dokaz za ishode GOVERN: očekivanja dionika, pravne obveze, uloge, politike, nadzor i rizik opskrbnog lanca. Revizor u stilu COBIT 2019 ili ISACA ispitat će jesu li potrebe dionika prevedene u prakse upravljanja i menadžmenta, jesu li odgovornosti dodijeljene i prati li se učinkovitost procesa.

Isti artefakt mora izdržati sva ta pitanja. Zato registar mora biti kontroliran, imati vlasnika, biti pregledavan, zaštićen kontrolom pristupa i testiran.

Uobičajeni obrasci neuspjeha u upravljanju kontaktima

Organizacije rijetko ne uspiju zato što nemaju nikakve kontakte. Ne uspijevaju zato što se kontaktima ne može vjerovati tijekom stvarnog incidenta.

Svaki problem stvara predvidljiv revizijski nalaz. Korektivna mjera jednako je predvidljiva: uskladiti registar s politikom, integrirati ga u odgovor na incidente, provjeriti kontakte, testirati radni tok i zadržati dokaze.

Odgovornost upravnog odbora i rukovodstva

NIS2 zahtijeva da upravljačka tijela odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i pohađaju obuku. DORA Article 5 čini upravljačko tijelo odgovornim za definiranje, odobravanje, nadzor i odgovornost za aranžmane IKT rizika, uključujući politike, uloge, IKT neprekidnost poslovanja, planove odgovora i oporavka, politiku IKT trećih strana, podizanje svijesti i obuku. ISO/IEC 27001:2022 zahtijeva da vodstvo uskladi ISMS sa strateškim smjerom, osigura resurse, dodijeli odgovornosti i podupre kontinuirano poboljšanje.

Upravni odbor ne mora zapamtiti telefonski broj CSIRT-a. Mora imati razumno uvjerenje da spremnost za obavješćivanje postoji, da ima vlasnika, da je testirana i da se pregledava.

Tromjesečni paket za rukovodstvo treba uključivati:

• Status pregleda registra regulatornih kontakata
• Promjene primjenjivih nadležnih tijela, nadzornih tijela ili jurisdikcija
• Otvorene praznine u kontaktima dobavljača za incidente
• Ishode stolnih vježbi i naučene lekcije
• Dokaze testiranja radnog toka odobrenja obavijesti
• Metrike vremena od otkrivanja do odluke o eskalaciji
• Ažuriranja obveza izvješćivanja prema NIS2, DORA, GDPR-u i ugovorima
• Preostale rizike koji zahtijevaju prihvaćanje od strane rukovodstva

Time se registar pomiče iz operativne proračunske tablice u upravljačku kontrolu.

Kako vam Clarysec pomaže izgraditi upravljanje kontaktima spremno za reviziju

Clarysec povezuje tekst politika, redoslijed implementacije i mapiranje kontrola među okvirima u jedan dokazni put.

Biblioteka politika definira odgovornost i potrebne zapise. Politika odgovora na incidente postavlja očekivanja za eskalaciju, odobrenje obavijesti i zadržavanje. Politika pravne i regulatorne usklađenosti zahtijeva praćenje uvjeta usklađenosti kao što su rokovi za prijavu povrede podataka. Politika neprekidnosti poslovanja i oporavka od katastrofe zahtijeva ažurne popise kontakata i alternativne komunikacijske planove. Politika sigurnosti trećih strana i dobavljača zahtijeva dodijeljene kontakte dobavljača.

Zenith Blueprint daje redoslijed implementacije. Korak 5 u fazi ISMS Foundation & Leadership obrađuje komunikaciju, podizanje svijesti i kompetencije, uključujući vanjske dionike, vrijeme, uloge komunikatora i komunikacijske planove. Korak 22 ugrađuje kontakte nadležnih tijela i posebnih interesnih skupina u organizacijske kontrole. Korak 23 provjerava upravljanje incidentima, odluke o prijavljivim događajima, očuvanje forenzičkih dokaza i naučene lekcije.

Vodič Zenith Controls daje kompas za međusobnu usklađenost. Pokazuje kako se kontakt s nadležnim tijelima povezuje s planiranjem incidenata, prijavljivanjem događaja, obavještajnim podacima o prijetnjama, posebnim interesnim skupinama i odgovorom na incidente. Također pokazuje zašto su prijavljivanje događaja informacijske sigurnosti i priprema za incidente nužni prateći elementi. Registar kontakata djelotvoran je samo ako se događaji prijave i procijene dovoljno rano da ga aktiviraju.

Za MSP-ove to znači sažet, ali dokaziv registar, jasnu odgovornost i dokaze primjerene načelu proporcionalnosti. Za velike organizacije to znači integraciju kroz jurisdikcije, pravne subjekte, poslovne jedinice, dobavljače, regulatore, nadzorna tijela, CSIRT-ove i izvješćivanje upravnom odboru.

Sljedeći koraci: izradite registar prije početka odbrojavanja

Ako se vaša organizacija priprema za NIS2, DORA, spremnost za prijavu povrede prema GDPR-u ili certifikaciju ISO/IEC 27001:2022, nemojte čekati stvarni incident da biste otkrili funkcionira li vaše upravljanje kontaktima.

Počnite s četiri aktivnosti ovaj tjedan:

1. Izradite ili osvježite registar regulatornih kontakata za CSIRT-ove, nadležna tijela, financijska nadzorna tijela, tijela za zaštitu podataka, tijela kaznenog progona, kritične dobavljače i interne uloge za eskalaciju.
2. Mapirajte svaki kontakt na okidač, vlasnika, put odobrenja, zahtjev za dokazima i lokaciju zadržavanja.
3. Provedite jednu stolnu vježbu usmjerenu na odluke o obavješćivanju, kontakt s nadležnim tijelom, koordinaciju s dobavljačima i zadržavanje dokaza.
4. Ažurirajte ISMS zapise, uključujući Registar usklađenosti, operativne upute za odgovor na incidente, popise kontakata za neprekidnost poslovanja i zapise kontakata dobavljača.

Clarysec vam može pomoći da to brzo implementirate koristeći Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls i naše biblioteke politika za MSP-ove i poslovna okruženja, uključujući Politiku odgovora na incidente Politika odgovora na incidente, Politiku pravne i regulatorne usklađenosti Politika pravne i regulatorne usklađenosti - MSP, Politiku neprekidnosti poslovanja i oporavka od katastrofe Politika neprekidnosti poslovanja i oporavka od katastrofe i Politiku sigurnosti trećih strana i dobavljača Politika sigurnosti trećih strana i dobavljača - MSP.

Rok od 24 sata ne zastaje dok vaš tim traži pravi kontakt. Izradite registar sada, testirajte ga i učinite ga dijelom svojih ISO dokaza prije nego što sljedeći incident umjesto vas odredi vremenski okvir.