Register regulačných kontaktov pre NIS2 a DORA ako dôkaz pre ISO 27001

Incident o 02:17: keď sa zo zoznamu kontaktov stáva kontrola

V utorok o 02:17 analytik SOC vidí vzorec, ktorý nechce vidieť nikto. Privilegovaný servisný účet sa autentifikoval z nezvyčajnej geografickej lokality, záznamy zákazníkov boli postupne dotazované a poskytovateľ služby riadenej detekcie a reakcie (MDR) otvoril tiket s vysokou závažnosťou. V priebehu niekoľkých minút vedúci riešenia incidentu potvrdzuje obavu: indikátory ransomvéru sa šíria laterálne, kritická produkčná služba je degradovaná a môžu byť dotknuté údaje zákazníkov.

Technická reakcia sa spustí rýchlo. Koncové zariadenia sa izolujú, exportujú sa logy identít, uchovávajú sa cloudové snapshoty a poskytovateľ riadených bezpečnostných služieb sa pripája ku koordinačnému hovoru. Potom sa začína chladnejšia panika.

CISO sa pýta: „Koho máme informovať?“

Právne oddelenie hovorí, že možno bude potrebné zapojiť dozorný orgán na ochranu údajov. DPO sa pýta, či ide o porušenie ochrany osobných údajov. COO upozorňuje, že cloudového poskytovateľa treba eskalovať podľa podmienok podnikovej podpory. Manažér súladu sa pýta, či je subjekt dôležitým subjektom podľa NIS2 alebo či sa uplatňuje DORA, pretože služba podporuje regulovaný finančný subjekt. Predstavenstvo chce vedieť, čo sa musí stať počas prvých 24 hodín.

Nikto nespochybňuje potrebu komunikovať. Problémom je, že kontaktné údaje, schvaľovací postup, právne spúšťače a požiadavky na dôkazy sú roztrúsené v starej tabuľke kontinuity činností, dodávateľských zmluvách, e-mailových vláknach, zastaranej wiki k súladu a v telefóne jednej osoby.

Nie je to iba prevádzková nepríjemnosť. V roku 2026 je to medzera v súlade.

NIS2 zmenila odstupňované oznamovanie incidentov na povinnosť v oblasti správy a riadenia vrátane včasného varovania do 24 hodín, oznámenia do 72 hodín a záverečnej správy do jedného mesiaca pri významných incidentoch. DORA vytvorila osobitný režim digitálnej prevádzkovej odolnosti pre finančné subjekty vrátane riadenia incidentov IKT, klasifikácie, oznamovania dohľadovým orgánom, riadenia rizík tretích strán v oblasti IKT a krízovej komunikácie. GDPR zostáva relevantné vždy, keď sú dotknuté osobné údaje. ISO/IEC 27001:2022 tieto povinnosti premieňa na overiteľné dôkazy systému manažérstva.

Register regulačných kontaktov môže znieť administratívne. Nie je. Je to spojovací prvok medzi reakciou na incidenty, právnym oznámením, kontinuitou činností, koordináciou s dodávateľmi, zodpovednosťou vrcholového manažmentu a auditnými dôkazmi.

Clarysec k tomu pristupuje ako k problému dôkazov, nie ako k papierovému cvičeniu. V Zenith Blueprint: 30-kroková cestovná mapa audítora Zenith Blueprint, krok 22 vo fáze Kontroly v praxi vysvetľuje, prečo musí byť kontakt s orgánmi definovaný vopred:

Kontrola 5.5 zabezpečuje, že organizácia je pripravená komunikovať s externými orgánmi v prípade potreby nie reaktívne alebo v panike, ale prostredníctvom vopred definovaných, štruktúrovaných a dobre pochopených kanálov.

Toto je skutočná lekcia z incidentu o 02:17. Čas na vyhľadanie oznamovacieho portálu regulátora, služobného telefónu CSIRT, záložného kontaktu DPO, oznamovacieho kanála finančného dohľadu a dodávateľskej eskalačnej trasy je pred incidentom, nie vtedy, keď už plynie lehota na oznámenie.

Prečo sa registre regulačných kontaktov stali prioritou súladu v roku 2026

Mnohé organizácie už majú zoznamy núdzových kontaktov. Problém je, že NIS2 a DORA vyžadujú disciplinovanejší prístup než zoznam mien a telefónnych čísel. Vyžadujú presnú, rolovo orientovanú a dôkazmi podloženú správu kontaktov prepojenú na právne spúšťače, eskalačnú právomoc, lehoty na oznámenie a závislosti od dodávateľov.

NIS2 sa vzťahuje na široký okruh základných a dôležitých subjektov v sektoroch, ako sú energetika, doprava, bankovníctvo, infraštruktúra finančných trhov, zdravotníctvo, pitná voda, odpadová voda, digitálna infraštruktúra, riadenie služieb IKT, verejná správa a vesmír. Zahŕňa aj mnohých digitálnych poskytovateľov vrátane služieb cloud computingu, služieb dátových centier, sietí na doručovanie obsahu, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb, online trhovísk, online vyhľadávačov a platforiem sociálnych sietí. Členské štáty mali povinnosť vytvoriť zoznamy základných a dôležitých subjektov do 17. apríla 2025 a aktualizovať ich najmenej každé dva roky. Pre mnohých poskytovateľov cloudových služieb, SaaS, riadených služieb a digitálnych platforiem sa regulačná expozícia presunula z teórie do prevádzky.

DORA sa od 17. januára 2025 vzťahuje na finančné subjekty, ako sú úverové inštitúcie, platobné inštitúcie, inštitúcie elektronických peňazí, investičné spoločnosti, poskytovatelia služieb kryptoaktív, obchodné miesta, centrálne depozitáre cenných papierov, centrálne protistrany, poisťovne a zaisťovne a ďalšie zahrnuté organizácie finančného sektora. DORA je zásadne relevantná aj pre ekosystém tretích strán v oblasti IKT, pretože finančné subjekty musia riadiť poskytovateľov podporujúcich kritické alebo dôležité funkcie. DORA Article 17 vyžaduje proces riadenia incidentov súvisiacich s IKT, Article 18 stanovuje očakávania klasifikácie a Article 19 upravuje oznamovanie závažných incidentov súvisiacich s IKT príslušnému orgánu.

GDPR pridáva rozmer ochrany súkromia. Kybernetický incident sa môže stať porušením ochrany osobných údajov, ak zahŕňa náhodné alebo nezákonné zničenie, stratu, zmenu, neoprávnené zverejnenie osobných údajov alebo neoprávnený prístup k nim. Prevádzkovateľ musí byť schopný preukázať zodpovednosť, posúdiť riziko pre fyzické osoby a v prípade potreby oznámiť incident dozornému orgánu a prípadne dotknutým osobám.

Zrelý register regulačných kontaktov preto musí pod tlakom odpovedať na päť otázok:

• Ktorý CSIRT, príslušný orgán, finančný dohľadový orgán, dozorný orgán na ochranu údajov a kontakt orgánov činných v trestnom konaní sa vzťahuje na daný právny subjekt, jurisdikciu a službu?
• Ktorá interná rola je oprávnená iniciovať kontakt, schváliť znenie a podať oznámenie?
• Ktorí dodávatelia musia byť kontaktovaní z dôvodu zamedzenia šírenia, získania logov, obnovy, uchovania dôkazov alebo zmluvného oznámenia?
• Ktorá komunikačná trasa voči zákazníkom, protistranám alebo verejnosti sa spúšťa pri jednotlivých úrovniach závažnosti?
• Ako preukážeme, že register bol preskúmaný, otestovaný a použitý správne?

Odpoveď nemôže byť iba v schránke právneho oddelenia alebo v pamäti CISO. Musí ísť o riadený záznam ISMS.

Čo obsahuje register kontaktov pre NIS2 a DORA pripravený na dôkazné použitie

Register regulačných kontaktov má byť navrhnutý na použitie počas skutočného incidentu. Ak musí vedúci riešenia incidentu prijať prvé eskalačné rozhodnutie v priebehu niekoľkých minút, register nemôže byť neurčitým zoznamom webových stránok. Musí byť štruktúrovaný, overený a prepojený s playbookom reakcie.

Úplný register má obsahovať najmenej šesť skupín kontaktov.

Po prvé, oficiálne orgány kybernetickej bezpečnosti: národné CSIRT, príslušné orgány, jednotné kontaktné miesta tam, kde sa uplatňujú, a sektorové agentúry kybernetickej bezpečnosti.

Po druhé, finančné dohľadové orgány pre DORA: príslušné orgány a oznamovacie kanály používané na počiatočné, priebežné a záverečné hlásenie závažných incidentov súvisiacich s IKT.

Po tretie, orgány ochrany súkromia: dozorné orgány na ochranu údajov, logika vedúceho dozorného orgánu pri cezhraničnom spracúvaní a eskalačné postupy DPO.

Po štvrté, orgány činné v trestnom konaní: útvary pre kybernetickú kriminalitu, útvary pre podvody a núdzové kontakty pre vydieranie, ransomvér, neoprávnený prístup a uchovanie dôkazov.

Po piate, dodávatelia a tretie strany v oblasti IKT: cloudoví poskytovatelia, poskytovatelia riadených bezpečnostných služieb, poskytovatelia riadených služieb, platformy identít, spracovatelia platieb, poskytovatelia digitálnej forenznej analýzy a právni zástupcovia.

Po šieste, interné eskalačné roly: vedúci riešenia incidentu, CISO, DPO, generálny právny zástupca, vedúci komunikácie, vedúci kontinuity činností, výkonný schvaľovateľ, kontaktná osoba pre predstavenstvo a vlastník služby.

Register má zahŕňať aj špeciálne záujmové skupiny, ak sú relevantné, napríklad ISAC alebo sektorové komunity na zdieľanie informácií. Nie sú to regulátori, ale môžu sa stať dôležitými kanálmi pre spravodajstvo o hrozbách a koordinovanú reakciu.

Zenith Blueprint to v kroku 22 prevádza do praxe:

Vytvorte alebo aktualizujte postupy zapájania orgánov počas bezpečnostných udalostí (5.5) vrátane kontaktných údajov na miestne CERT, regulátorov a orgány činné v trestnom konaní. Udržiavajte podobný zoznam kontaktov na účasť v bezpečnostných fórach alebo sektorovo špecifických skupinách (5.6). Uchovávajte tieto informácie na dostupnom, no prístupovo riadenom mieste a zahrňte ich do runbooku reakcie na incidenty.

Na poslednej vete záleží. Ak register nie je v runbooku reakcie na incidenty, pravdepodobne sa nepoužije, keď bude tlak skutočný.

Príklad štruktúry registra kontaktov pre FinTech alebo poskytovateľa SaaS

Predstavte si fintech poskytovateľa SaaS, ktorý podporuje platobnú analytiku pre klientov v EÚ. Používa cloudového poskytovateľa, poskytovateľa služby riadenej detekcie a reakcie, platformu identít, platformu zákazníckej podpory a externého právneho zástupcu. Podľa svojej roly môže byť finančným subjektom, externým poskytovateľom IKT služieb, digitálnym poskytovateľom v rozsahu NIS2 alebo sprostredkovateľom spracúvania osobných údajov podľa GDPR.

Praktický register môže začínať takto:

Záznamy nemajú obsahovať zbytočné osobné údaje. Používajte rolové kontakty všade, kde je to možné, chráňte citlivé kontaktné údaje a zabezpečte offline dostupnosť počas významného výpadku. Register, ktorý je dostupný iba zo systémov dotknutých ransomvérovým incidentom, nie je odolný.

Mapovanie registra na dôkazy podľa ISO/IEC 27001:2022

Audítori zriedka označia organizáciu za nevyhovujúcu preto, že jej chýba tabuľka. Označia ju za nevyhovujúcu preto, že organizácia nevie preukázať, že tabuľka je úplná, aktuálna, schválená, chránená, otestovaná a prepojená na skutočné procesy.

ISO/IEC 27001:2022 začína kontextom organizácie. Kapitoly 4.1 až 4.4 vyžadujú, aby organizácia rozumela interným a externým otázkam, identifikovala zainteresované strany a ich požiadavky, definovala rozsah ISMS a rozumela rozhraniam a závislostiam. Register regulačných kontaktov je silným dôkazom, že právne, regulačné, zmluvné požiadavky a požiadavky zainteresovaných strán boli prevedené do prevádzkových vzťahov.

Nasleduje vedenie. Kapitoly 5.1 až 5.3 vyžadujú, aby vrcholový manažment preukázal vedenie, pridelil zodpovednosti, zabezpečil komunikáciu a podporoval ISMS. Ak register identifikuje, kto je oprávnený informovať CSIRT, dohľadový orgán alebo dozorný orgán na ochranu údajov, kto schvaľuje externú komunikáciu a kto hlási stav incidentu vrcholovému manažmentu, podporuje dôkazy o vedení.

Plánovanie rizík následne premieňa povinnosti na opatrenia. Kapitoly 6.1.1 až 6.1.3 vyžadujú proces posúdenia rizík a ošetrenia rizík, porovnanie s prílohou A, vyhlásenie o uplatniteľnosti, plán ošetrenia rizík a akceptáciu zvyškového rizika. Register má byť zahrnutý v pláne ošetrenia rizík pre riziká, ako sú zlyhanie právneho oznámenia, oneskorená eskalácia incidentu, zlyhanie reakcie dodávateľa, chyba cezhraničného oznámenia a zlyhanie komunikácie v rámci kontinuity činností.

Oporné body kontrol prílohy A sú jasné:

V Zenith Controls: sprievodca krížovým súladom Zenith Controls sa kontakt s orgánmi spracúva ako kontrola 5.5 s preventívnymi a nápravnými charakteristikami. Podporuje dôvernosť, integritu a dostupnosť a prepája sa s konceptmi kybernetickej bezpečnosti Identify, Protect, Respond a Recover. Zenith Controls ho prepája s plánovaním incidentov, nahlasovaním udalostí, spravodajstvom o hrozbách, špeciálnymi záujmovými skupinami a reakciou na incidenty. Zároveň vysvetľuje, prečo vopred vytvorené kontakty s regulátormi, orgánmi činnými v trestnom konaní, národnými CERT alebo orgánmi na ochranu údajov umožňujú rýchlejšiu eskaláciu a usmernenie počas udalostí, ako sú významné porušenia ochrany údajov alebo ransomvérové útoky.

Kontrola nie je izolovaná. Zenith Controls mapuje aj kontrolu 6.8, nahlasovanie udalostí informačnej bezpečnosti, ako detekčnú kontrolu prepojenú s plánovaním incidentov, posúdením udalostí, reakciou, poučením, povedomím, monitorovaním a disciplinárnym procesom. Kontrola 5.24, plánovanie a príprava riadenia incidentov informačnej bezpečnosti, sa prepája s posúdením udalostí, poučením, logovaním, monitorovaním, bezpečnosťou počas narušenia, kontinuitou a kontaktom s orgánmi. Auditný príbeh je silnejší, keď sú udalosti nahlasované, posudzované, eskalované, komunikované, podložené dôkazmi a zlepšované.

NIS2, DORA a GDPR: jeden register, rôzne právne lehoty

Jeden incident môže spustiť viacero právnych pracovných tokov. Neoprávnený prístup u poskytovateľa SaaS môže byť významným incidentom podľa NIS2, porušením ochrany osobných údajov podľa GDPR a udalosťou vyžadujúcou zmluvné oznámenie zákazníkovi. Výpadok vo finančnom subjekte môže byť závažným incidentom súvisiacim s IKT podľa DORA a zároveň môže vyžadovať analýzu podľa GDPR a koordináciu s dodávateľmi.

NIS2 vyžaduje, aby základné a dôležité subjekty bez zbytočného odkladu oznamovali svojmu CSIRT alebo príslušnému orgánu významné incidenty ovplyvňujúce poskytovanie služieb. Odstupňovaný model hlásenia zahŕňa včasné varovanie bez zbytočného odkladu a do 24 hodín od zistenia, oznámenie incidentu bez zbytočného odkladu a do 72 hodín, priebežné správy o stave na požiadanie a záverečnú správu do jedného mesiaca po oznámení incidentu. Ak incident stále prebieha, môže sa vyžadovať aj hlásenie pokroku.

DORA vyžaduje, aby finančné subjekty udržiavali proces riadenia incidentov súvisiacich s IKT, ktorý incidenty deteguje, riadi a oznamuje, zaznamenáva incidenty a významné kybernetické hrozby, klasifikuje závažnosť a kritickosť, priraďuje roly, definuje eskaláciu a komunikáciu, hlási závažné incidenty vrcholovému manažmentu a podporuje včasnú obnovu. Oznamovanie závažných incidentov súvisiacich s IKT sa riadi logikou počiatočného, priebežného a záverečného hlásenia, pričom klasifikácia vychádza z faktorov, ako sú dotknutí klienti, trvanie, geografický rozsah, strata údajov, kritickosť služieb a ekonomický dopad.

GDPR pridáva posúdenie porušenia ochrany osobných údajov. Register kontaktov sám osebe nerozhoduje o právnej oznamovacej povinnosti. Zabezpečuje, aby správne osoby mohli rozhodnúť rýchlo, s použitím aktuálnych kanálov a zdokumentovaných kritérií.

Knižnica politík Clarysec to operacionalizuje. V SME Politika reakcie na incidenty Politika reakcie na incidenty - SME, bod 5.1.1 stanovuje:

Generálny manažér (GM) zodpovedá za autorizáciu všetkých rozhodnutí o eskalácii incidentov, regulačných oznámení a externej komunikácie.

Tá istá SME politika v bode 7.4.1 dopĺňa:

Ak sú dotknuté údaje zákazníkov, generálny manažér musí posúdiť právne oznamovacie povinnosti na základe uplatniteľnosti GDPR, NIS2 alebo DORA.

Pre podnikové prostredia stanovuje Politika reakcie na incidenty Politika reakcie na incidenty v bode 5.5 komunikačný rámec:

Všetka komunikácia súvisiaca s incidentom musí postupovať podľa komunikačnej a eskalačnej matice, čím sa zabezpečí:

Bod 6.4.2 pridáva požiadavku na dôkazy:

Všetky oznámenia o porušení ochrany údajov musia byť pred podaním zdokumentované a schválené a ich kópie musia byť uchovávané v ISMS.

Tu sa register stáva dôkazom pre ISO. Nejde iba o to vedieť, komu zavolať. Ide o preukázanie toho, kto bol oprávnený, čo bolo posúdené, čo bolo schválené, čo bolo podané a kde sa uchovávaná kópia nachádza.

Dôkazový model Clarysec: štyri artefakty, ktoré fungujú spolu

Silná schopnosť riadiť regulačné kontakty potrebuje štyri artefakty fungujúce ako jeden dôkazový reťazec.

Register regulačných kontaktov identifikuje kontakty, kanály, spúšťače a vlastníkov. Komunikačná a eskalačná matica definuje, kto čo robí. Rozhodovací log zaznamenáva klasifikáciu, posúdenie oznamovacej povinnosti, právne preskúmanie a schválenie. Balík dôkazov k oznámeniu uchováva podané oznámenia, potvrdenia z portálov, e-maily, poznámky z hovorov, spätnú väzbu regulátora, odpovede dodávateľov a záverečné správy.

Politika právneho a regulačného súladu Clarysec Politika právneho a regulačného súladu - SME robí koncept registra explicitným. Bod 5.5.2 stanovuje:

Kľúčové podmienky súladu, napríklad lehoty oznámenia porušenia ochrany údajov a ustanovenia o nakladaní s údajmi, musia byť extrahované a sledované v registri súladu.

Register súladu má napájať register regulačných kontaktov. Právna požiadavka môže hovoriť „včasné varovanie NIS2 do 24 hodín“, zatiaľ čo register kontaktov identifikuje portál národného CSIRT, záložné služobné číslo, oprávnenú osobu na podanie, právneho preskúmavateľa, požadované dôkazy a cestu uchovávania.

Politiky kontinuity činností posilňujú rovnaké očakávanie. SME Politika kontinuity činností a obnovy po havárii Politika kontinuity činností a obnovy po havárii - SME v bode 5.2.1.1 odkazuje na:

zoznamy kontaktov a alternatívne komunikačné plány

Podniková Politika kontinuity činností a obnovy po havárii Politika kontinuity činností a obnovy po havárii v bode 5.3.3 vyžaduje, aby opatrenia kontinuity boli:

podporené aktuálnymi zoznamami kontaktov a eskalačnými tokmi

Do modelu patrí aj správa a riadenie dodávateľov. V SME Politika bezpečnosti tretích strán a dodávateľov Politika bezpečnosti tretích strán a dodávateľov - SME, bod 5.4.3 vyžaduje:

priradenú kontaktnú osobu

Pre NIS2 a DORA tento kontakt nemôže byť generický. Ak kritický cloudový poskytovateľ, poskytovateľ riadených bezpečnostných služieb, poskytovateľ identít alebo spracovateľ platieb podporuje regulovanú službu, register má identifikovať prevádzkový kontakt, kontakt pre bezpečnostný incident, zmluvný oznamovací kanál a eskalačnú trasu pre požiadavky na dôkazy.

Vytvorte register počas jedného pracovného stretnutia

Užitočný register možno vytvoriť rýchlo, ak sú v miestnosti správni ľudia. Naplánujte dvojhodinové stretnutie s CISO, DPO, právnym zástupcom, manažérom dodávateľov, vedúcim kontinuity činností, vedúcim riešenia incidentu a vlastníkom súladu.

Začnite registrom súladu. Extrahujte oznamovacie povinnosti podľa NIS2, DORA, GDPR, zmlúv a sektorových požiadaviek. Zaznamenajte lehoty, kritériá oznamovacej povinnosti a požiadavky na dôkazy.

Otvorte runbook reakcie na incidenty. Pre každú kategóriu incidentu, napríklad ransomvér, neoprávnený prístup, výpadok služby, exfiltrácia údajov, dodávateľský incident a zlyhanie cloudového regiónu, identifikujte potrebné externé kontakty.

Vyplňte register regulačných kontaktov o orgán, jurisdikciu, spúšťač, primárny kanál, záložný kanál, vlastníka, schvaľovateľa, potrebné dôkazy, dátum posledného overenia a miesto uchovávania.

Prepojte kontakty dodávateľov. Pre každú kritickú alebo dôležitú funkciu identifikujte kontakt poskytovateľa pre bezpečnostné incidenty, zmluvný oznamovací kanál, auditný kontakt a núdzový eskalačný postup.

Preskúmajte súlad s politikami. Potvrďte, že eskalačná právomoc zodpovedá Politike reakcie na incidenty, dôkazy o oznámeniach sa uchovávajú v ISMS, zoznamy kontaktov kontinuity činností sú zosúladené a kontakty dodávateľov majú priradených vlastníkov.

Otestujte jeden scenár. Použite zamerané stolové cvičenie: „Sprístupnenie údajov zákazníkov zistené o 02:17, ktoré ovplyvňuje klientov v EÚ a mohlo byť spôsobené kompromitovanými povereniami poskytovateľa identít.“ Požiadajte tím, aby určil, či môžu byť potrebné oznámenia pre CSIRT, dozorný orgán na ochranu údajov, finančný dohľadový orgán, dodávateľa a zákazníkov. Cieľom cvičenia nie je vynútiť konečný právny záver. Cieľom je preukázať, kde sa kontakty nachádzajú, kto schvaľuje kontakt, aké dôkazy sú potrebné a kde sa rozhodnutia logujú.

Vytvorte balík dôkazov. Uložte verziu registra, účastníkov stretnutia, schválenia, poznámky zo scenára, rozhodovací log, akčné položky a aktualizovaný odkaz na runbook.

Tu sa Zenith Blueprint krok 23 stáva praktickým:

Zabezpečte aktuálny plán reakcie na incidenty (5.24), ktorý pokrýva prípravu, eskaláciu, reakciu a komunikáciu. Definujte, čo predstavuje bezpečnostnú udalosť podliehajúcu hláseniu (5.25), a ako sa spúšťa a dokumentuje rozhodovací proces. Vyberte nedávnu udalosť alebo uskutočnite stolové cvičenie na validáciu plánu.

Cvičenie nemusí byť rozsiahle. Musí preukázať pripravenosť.

Mapovanie krížového súladu: jeden register, mnoho rámcov

Hodnota registra regulačných kontaktov spočíva v tom, že znižuje duplicitu úsilia o súlad. Jeden artefakt pripravený na dôkazné použitie môže podporiť očakávania správy a riadenia podľa ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

NIST CSF 2.0 je mimoriadne užitočný ako integračná vrstva. Jeho funkcia GOVERN očakáva, že organizácie rozumejú zainteresovaným stranám, právnym a regulačným povinnostiam, kritickým službám, závislostiam, apetítu na riziko, rolám, politikám, dohľadu a dodávateľskému riziku. Jeho profily CSF pomáhajú organizáciám zdokumentovať aktuálny profil, definovať cieľový profil, analyzovať medzery a vytvoriť prioritizovaný akčný plán. Register regulačných kontaktov môže byť konkrétnym dôkazom, ktorý uzatvára medzeru medzi aktuálnym a cieľovým stavom riadenia incidentov.

Pre dodávateľský reťazec NIST CSF 2.0 očakáva, že dodávatelia, zákazníci a partneri majú definované roly a zodpovednosti v kybernetickej bezpečnosti, kritickosť dodávateľov je známa, požiadavky kybernetickej bezpečnosti sú zahrnuté v zmluvách, dodávateľské riziká sú posudzované a relevantní dodávatelia sú zahrnutí do plánovania incidentov, reakcie a obnovy. To sa priamo mapuje na riziká tretích strán v oblasti IKT podľa DORA a očakávania NIS2 pre dodávateľský reťazec.

Ako audítori a dohľadové orgány otestujú ten istý register

Dobre udržiavaný register bude posudzovaný odlišne podľa perspektívy posudzovateľa.

Audítor ISO/IEC 27001:2022 začne rozsahom a zainteresovanými stranami. Bude sa pýtať, ako organizácia identifikovala príslušné orgány, právne povinnosti, zmluvné oznamovacie povinnosti a outsourcované závislosti. Následne prepojí register na vyhlásenie o uplatniteľnosti, plán reakcie na incidenty, plán kontinuity činností a uchovávanie dôkazov. Môže vybrať vzorku jedného kontaktu a požiadať o dôkaz posledného overenia.

Posudzovateľ NIS2 sa zameria na to, či subjekt identifikoval správny CSIRT alebo príslušný orgán a či sú prahové hodnoty významného incidentu prevedené do prevádzky. Bude hľadať proces schopný podporiť 24-hodinové včasné varovanie, 72-hodinové oznámenie a záverečné hlásenie. Bude sa tiež pozerať na dohľad riadiaceho orgánu, pretože NIS2 Article 20 robí správu kybernetickej bezpečnosti zodpovednosťou vedenia.

Dohľadový orgán DORA alebo tím vnútorného auditu otestuje, či register podporuje riadenie incidentov, klasifikáciu, oznamovanie závažných incidentov súvisiacich s IKT, krízovú komunikáciu, hlásenie vrcholovému manažmentu, koordináciu s dodávateľmi a prevádzkovú obnovu. Môže sa pýtať, či existujú kontakty na externých poskytovateľov IKT služieb podporujúcich kritické alebo dôležité funkcie a či sú komunikačné povinnosti premietnuté do zmlúv.

Audítor GDPR alebo preskúmanie zo strany DPO sa zameria na posúdenie porušenia ochrany osobných údajov. Budú sa pýtať, či sú DPO a právne kontakty pre ochranu súkromia zapojené včas, či sú roly prevádzkovateľa a sprostredkovateľa jasné, či je identifikovaný správny dozorný orgán a či sú rozhodnutia o komunikácii s dotknutými osobami zaznamenané.

Posudzovateľ NIST CSF bude register považovať za dôkaz výstupov GOVERN: očakávania zainteresovaných strán, právne povinnosti, roly, politiky, dohľad a riziko dodávateľského reťazca. Audítor podľa COBIT 2019 alebo štýlu ISACA preskúma, či sú potreby zainteresovaných strán prevedené do postupov správy a riadenia a manažmentu, či sú priradené zodpovednosti a či sa monitoruje výkonnosť procesov.

Ten istý artefakt musí obstáť pri všetkých týchto otázkach. Preto má byť register riadený, vlastnený, preskúmavaný, chránený riadením prístupu a testovaný.

Bežné vzorce zlyhaní pri správe kontaktov

Organizácie zriedka zlyhávajú preto, že nemajú žiadne kontakty. Zlyhávajú preto, že kontaktom nemožno dôverovať počas skutočného incidentu.

Každý problém vytvára predvídateľné auditné zistenie. Náprava je rovnako predvídateľná: zosúladiť register s politikou, integrovať ho do reakcie na incidenty, overovať kontakty, testovať pracovný tok a uchovávať dôkazy.

Zodpovednosť predstavenstva a manažmentu

NIS2 vyžaduje, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie. DORA Article 5 robí riadiaci orgán zodpovedným za definovanie, schvaľovanie, dohľad a zodpovednosť za opatrenia rizík IKT vrátane politík, rolí, kontinuity činností IKT, plánov reakcie a obnovy, politiky tretích strán v oblasti IKT, povedomia a školení. ISO/IEC 27001:2022 vyžaduje, aby vedenie zosúladilo ISMS so strategickým smerovaním, poskytlo zdroje, pridelilo zodpovednosti a podporovalo neustále zlepšovanie.

Predstavenstvo si nemusí pamätať telefónne číslo CSIRT. Potrebuje však uistenie, že pripravenosť na oznámenie existuje, má vlastníka, je testovaná a preskúmavaná.

Štvrťročný manažérsky balík má obsahovať:

• Stav preskúmania registra regulačných kontaktov
• Zmeny v príslušných orgánoch, dohľadových orgánoch alebo jurisdikciách
• Otvorené medzery v dodávateľských kontaktoch pre incidenty
• Výsledky stolových cvičení a poučenia
• Dôkazy o testovaní schvaľovacieho pracovného toku oznámení
• Metriky času od detekcie po eskalačné rozhodnutie
• Aktualizácie oznamovacích povinností podľa NIS2, DORA, GDPR a zmlúv
• Zvyškové riziká vyžadujúce akceptáciu manažmentom

Tým sa register posúva z prevádzkovej tabuľky na kontrolu správy a riadenia.

Ako vám Clarysec pomáha vybudovať správu kontaktov pripravenú na audit

Clarysec prepája text politík, postupnosť implementácie a mapovanie kontrol naprieč rámcami do jednej dôkazovej cesty.

Knižnica politík definuje zodpovednosť a požadované záznamy. Politika reakcie na incidenty stanovuje očakávania pre eskaláciu, schvaľovanie oznámení a uchovávanie. Politika právneho a regulačného súladu vyžaduje sledovanie podmienok súladu, ako sú lehoty oznamovania porušení ochrany údajov. Politika kontinuity činností a obnovy po havárii vyžaduje aktuálne zoznamy kontaktov a alternatívne komunikačné plány. Politika bezpečnosti tretích strán a dodávateľov vyžaduje priradené kontakty dodávateľov.

Zenith Blueprint poskytuje postupnosť implementácie. Krok 5 vo fáze Základy ISMS a vedenie rieši komunikáciu, povedomie a kompetentnosť vrátane externých zainteresovaných strán, načasovania, rolí komunikátorov a komunikačných plánov. Krok 22 začleňuje kontakty na orgány a špeciálne záujmové skupiny do organizačných opatrení. Krok 23 validuje riadenie incidentov, rozhodnutia o udalostiach podliehajúcich hláseniu, uchovanie forenzných dôkazov a poučenia.

Sprievodca Zenith Controls poskytuje kompas krížového súladu. Ukazuje, ako kontakt s orgánmi súvisí s plánovaním incidentov, nahlasovaním udalostí, spravodajstvom o hrozbách, špeciálnymi záujmovými skupinami a reakciou na incidenty. Ukazuje tiež, prečo sú nahlasovanie udalostí informačnej bezpečnosti a príprava na incidenty nevyhnutnými sprievodnými prvkami. Register kontaktov je účinný iba vtedy, ak sa udalosti nahlasujú a posudzujú dostatočne skoro na jeho spustenie.

Pre MSP to znamená štíhly, ale obhájiteľný register, jasnú zodpovednosť a dôkazy primerané proporcionalite. Pre podniky to znamená integráciu naprieč jurisdikciami, právnymi subjektmi, organizačnými jednotkami, dodávateľmi, regulátormi, dohľadovými orgánmi, CSIRT a reportovaním predstavenstvu.

Ďalšie kroky: vytvorte register skôr, než začne plynúť lehota

Ak sa vaša organizácia pripravuje na NIS2, DORA, pripravenosť oznamovať porušenia ochrany údajov podľa GDPR alebo certifikáciu ISO/IEC 27001:2022, nečakajte na živý incident, aby ste zistili, či správa kontaktov funguje.

Začnite tento týždeň štyrmi krokmi:

1. Vytvorte alebo aktualizujte register regulačných kontaktov pre CSIRT, príslušné orgány, finančné dohľadové orgány, dozorné orgány na ochranu údajov, orgány činné v trestnom konaní, kritických dodávateľov a interné eskalačné roly.
2. Namapujte každý kontakt na spúšťač, vlastníka, schvaľovací postup, požiadavku na dôkazy a miesto uchovávania.
3. Uskutočnite jedno stolové cvičenie zamerané na rozhodnutia o oznámení, kontakt s orgánom, koordináciu s dodávateľmi a uchovanie dôkazov.
4. Aktualizujte záznamy ISMS vrátane registra súladu, runbooku reakcie na incidenty, zoznamov kontaktov kontinuity činností a záznamov kontaktov dodávateľov.

Clarysec vám môže pomôcť rýchlo to implementovať pomocou Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls a našich knižníc politík pre MSP a podniky vrátane Politiky reakcie na incidenty Politika reakcie na incidenty, Politiky právneho a regulačného súladu Politika právneho a regulačného súladu - SME, Politiky kontinuity činností a obnovy po havárii Politika kontinuity činností a obnovy po havárii a Politiky bezpečnosti tretích strán a dodávateľov Politika bezpečnosti tretích strán a dodávateľov - SME.

24-hodinová lehota sa nezastaví, kým váš tím hľadá správny kontakt. Vytvorte register teraz, otestujte ho a urobte z neho súčasť vašich dôkazov pre ISO skôr, než o časovej osi rozhodne ďalší incident.