Registry kontaktů pro regulatorní oznámení podle NIS2 a DORA jako důkaz pro ISO 27001

Incident ve 02:17: když se seznam kontaktů stává opatřením

V úterý ve 02:17 vidí analytik SOC vzorec, který nikdo vidět nechce. Privilegovaný servisní účet se autentizoval z neobvyklé geografické oblasti, zákaznické záznamy byly postupně dotazovány a poskytovatel řízené detekce otevřel tiket s vysokou závažností. Během několika minut velitel incidentu potvrzuje obavu: indikátory ransomwaru se šíří laterálně, kritická produkční služba je degradovaná a mohou být dotčena zákaznická data.

Technická reakce začíná rychle. Koncové body jsou izolovány, logy identit staženy, cloudové snapshoty zachovány a poskytovatel řízených bezpečnostních služeb se připojuje do krizového hovoru. Poté přichází chladnější panika.

CISO se ptá: „Koho máme informovat?“

Právní oddělení říká, že může být nutné zapojit úřad pro ochranu osobních údajů. DPO se ptá, zda jde o porušení zabezpečení osobních údajů. COO říká, že cloudového poskytovatele je nutné eskalovat podle podmínek podnikové podpory. Manažer souladu se ptá, zda je organizace důležitým subjektem podle NIS2, nebo zda se uplatní DORA, protože služba podporuje regulovanou finanční instituci. Správní orgán chce vědět, co se musí stát během prvních 24 hodin.

Nikdo nezpochybňuje potřebu komunikovat. Problém je v tom, že kontaktní údaje, schvalovací cesta, právní spouštěče a požadavky na důkazy jsou rozptýlené ve staré tabulce kontinuity činností, dodavatelských smlouvách, e-mailových vláknech, zastaralé wiki k souladu a v telefonu jedné osoby.

To není jen provozní nepohodlí. V roce 2026 jde o mezeru v souladu.

NIS2 učinila z fázovaného oznamování incidentů povinnost v oblasti správy a řízení, včetně včasného varování do 24 hodin, oznámení do 72 hodin a závěrečné zprávy do jednoho měsíce u významných incidentů. DORA vytvořila samostatný režim digitální provozní odolnosti pro finanční subjekty, včetně řízení incidentů souvisejících s ICT, klasifikace, hlášení orgánům dohledu, rizik třetích stran v oblasti ICT a krizové komunikace. GDPR zůstává relevantní vždy, když jsou dotčeny osobní údaje. ISO/IEC 27001:2022 převádí tyto povinnosti do auditovatelných důkazů systému řízení.

Registr kontaktů pro regulatorní oznámení může znít administrativně. Není. Je to spojovací článek mezi reakcí na incidenty, právním oznamováním, kontinuitou činností, koordinací s dodavateli, odpovědností vedení a auditními důkazy.

Clarysec k tomu přistupuje jako k otázce důkazů, nikoli jako k papírovému cvičení. V Zenith Blueprint: 30kroková mapa auditora Zenith Blueprint krok 22 ve fázi Controls in Action vysvětluje, proč musí být kontakt s orgány předem definován:

Opatření 5.5 zajišťuje, že organizace je připravena v případě potřeby komunikovat s externími orgány nikoli reaktivně nebo v panice, ale prostřednictvím předem definovaných, strukturovaných a dobře pochopených kanálů.

To je skutečné ponaučení z incidentu ve 02:17. Čas hledat oznamovací portál regulátora, služební telefon CSIRT, záložní kontakt DPO, kanál pro hlášení finančnímu orgánu dohledu a eskalační trasu dodavatele je před incidentem, nikoli ve chvíli, kdy už běží lhůta pro hlášení.

Proč se registry kontaktů pro regulatorní oznámení staly prioritou souladu pro rok 2026

Mnoho organizací již má seznamy nouzových kontaktů. Problém je v tom, že NIS2 a DORA vyžadují něco disciplinovanějšího než seznam jmen a telefonních čísel. Vyžadují přesnou, na rolích založenou a důkazně připravenou správu kontaktů navázanou na právní spouštěče, eskalační pravomoc, lhůty pro hlášení a závislosti na dodavatelích.

NIS2 se vztahuje na široký okruh základních a důležitých subjektů v odvětvích, jako jsou energetika, doprava, bankovnictví, infrastruktura finančních trhů, zdravotnictví, pitná voda, odpadní vody, digitální infrastruktura, řízení služeb ICT, veřejná správa a vesmír. Zahrnuje také řadu digitálních poskytovatelů, včetně služeb cloud computingu, služeb datových center, sítí pro doručování obsahu, poskytovatelů řízených služeb, poskytovatelů řízených bezpečnostních služeb, online tržišť, online vyhledávačů a platforem sociálních sítí. Členské státy měly povinnost sestavit seznamy základních a důležitých subjektů do 17. dubna 2025 a aktualizovat je nejméně každé dva roky. U mnoha poskytovatelů cloudových služeb, SaaS, řízených služeb a digitálních platforem se regulatorní expozice přesunula z teorie do provozu.

DORA se od 17. ledna 2025 vztahuje na finanční subjekty, jako jsou úvěrové instituce, platební instituce, instituce elektronických peněz, investiční podniky, poskytovatelé služeb souvisejících s kryptoaktivy, obchodní platformy, centrální depozitáře cenných papírů, ústřední protistrany, pojišťovny a zajišťovny a další organizace finančního sektoru v působnosti nařízení. DORA je také zásadně relevantní pro ekosystém třetích stran v oblasti ICT, protože finanční subjekty musí řídit poskytovatele podporující kritické nebo důležité funkce. Článek 17 DORA vyžaduje proces řízení incidentů souvisejících s ICT, článek 18 stanoví požadavky na klasifikaci a článek 19 upravuje hlášení závažných incidentů souvisejících s ICT příslušnému orgánu.

GDPR přidává rozměr ochrany soukromí. Kyberbezpečnostní incident se může stát porušením zabezpečení osobních údajů, pokud zahrnuje náhodné nebo protiprávní zničení, ztrátu, změnu, neoprávněné zpřístupnění osobních údajů nebo neoprávněný přístup k nim. Správce musí být schopen prokázat odpovědnost, posoudit riziko pro fyzické osoby a tam, kde je to vyžadováno, oznámit věc dozorovému úřadu a případně dotčeným subjektům údajů.

Vyspělý registr kontaktů pro regulatorní oznámení proto musí pod tlakem odpovědět na pět otázek:

• Který CSIRT, příslušný orgán, finanční orgán dohledu, úřad pro ochranu osobních údajů a kontakt na orgány činné v trestním řízení se vztahuje na tento právní subjekt, jurisdikci a službu?
• Která interní role je oprávněna zahájit kontakt, schválit znění a podat oznámení?
• Kteří dodavatelé musí být kontaktováni kvůli zamezení šíření, logům, obnově, zachování důkazů nebo smluvnímu hlášení?
• Která trasa komunikace se zákazníkem, protistranou nebo veřejností se spouští na jednotlivých úrovních závažnosti?
• Jak prokážeme, že registr byl přezkoumán, otestován a správně použit?

Odpověď nemůže existovat pouze v inboxu právního oddělení nebo v paměti CISO. Musí jít o řízený záznam ISMS.

Co obsahuje registr kontaktů pro NIS2 a DORA použitelný jako důkaz

Registr kontaktů pro regulatorní oznámení má být navržen pro použití během skutečného incidentu. Pokud musí velitel incidentu učinit první eskalační rozhodnutí během několika minut, registr nemůže být vágním seznamem webových stránek. Musí být strukturovaný, ověřený a propojený s playbookem reakce.

Úplný registr má zahrnovat nejméně šest rodin kontaktů.

Zaprvé oficiální orgány kybernetické bezpečnosti: národní CSIRT, příslušné orgány, jednotná kontaktní místa tam, kde existují, a odvětvové agentury kybernetické bezpečnosti.

Zadruhé finanční orgány dohledu pro DORA: příslušné orgány a kanály pro hlášení používané pro počáteční, průběžné a závěrečné hlášení závažných incidentů souvisejících s ICT.

Zatřetí orgány ochrany soukromí: úřady pro ochranu osobních údajů, logika vedoucího dozorového úřadu pro přeshraniční zpracování a eskalační cesty DPO.

Začtvrté orgány činné v trestním řízení: jednotky kyberkriminality, útvary pro podvody a nouzové kontakty pro vydírání, ransomware, neoprávněný přístup a zachování důkazů.

Zapáté dodavatelé a třetí strany v oblasti ICT: poskytovatelé cloudových služeb, poskytovatelé řízených bezpečnostních služeb, poskytovatelé řízených služeb, platformy identit, zpracovatelé plateb, poskytovatelé digitální forenziky a právní poradci.

Zašesté interní eskalační role: velitel incidentu, CISO, DPO, vedoucí právního oddělení, vedoucí komunikace, odpovědná osoba za kontinuitu činností, schvalovatel z vrcholového vedení, spojka se správním orgánem a vlastník služby.

Registr má zahrnovat také zájmové skupiny tam, kde je to relevantní, například ISAC nebo odvětvové komunity pro sdílení informací. Nejde o regulační orgány, ale mohou se stát důležitými kanály pro informace o hrozbách a koordinovanou reakci.

Zenith Blueprint to v kroku 22 převádí do praxe:

Vytvořte nebo aktualizujte postupy pro zapojení orgánů během bezpečnostních událostí (5.5), včetně kontaktních údajů místních CERT, regulačních orgánů a orgánů činných v trestním řízení. Udržujte obdobný seznam kontaktů pro účast v bezpečnostních fórech nebo odvětvových skupinách (5.6). Uložte tyto informace na dostupné, ale přístupově řízené místo a zahrňte je do runbooku reakce na incidenty.

Na poslední větě záleží. Pokud registr není v runbooku reakce na incidenty, je nepravděpodobné, že bude použit, až bude tlak skutečný.

Příklad struktury registru kontaktů pro poskytovatele FinTech nebo SaaS

Představte si fintechového poskytovatele SaaS, který podporuje platební analytiku pro klienty v EU. Využívá cloudového poskytovatele, poskytovatele řízené detekce, platformu identit, platformu zákaznické podpory a externí právní poradce. Podle své role může být finančním subjektem, poskytovatelem služeb ICT třetí strany, digitálním poskytovatelem v působnosti NIS2 nebo zpracovatelem osobních údajů podle GDPR.

Praktický registr může začít takto:

Položky nemají obsahovat zbytečné osobní údaje. Kde je to možné, používejte kontakty založené na rolích, chraňte citlivé kontaktní údaje a zajistěte offline dostupnost při závažném výpadku. Registr, který je dostupný pouze ze stejných systémů zasažených ransomwarovým incidentem, není odolný.

Mapování registru na důkazy ISO/IEC 27001:2022

Auditoři zřídkakdy vyhodnotí organizaci negativně proto, že nemá tabulku. Vyhodnotí ji negativně proto, že organizace nedokáže prokázat, že tabulka je úplná, aktuální, schválená, chráněná, otestovaná a propojená se skutečnými procesy.

ISO/IEC 27001:2022 začíná kontextem organizace. Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla interním a externím otázkám, identifikovala zainteresované strany a jejich požadavky, definovala rozsah ISMS a porozuměla rozhraním a závislostem. Registr kontaktů pro regulatorní oznámení je silným důkazem, že právní, regulatorní, smluvní a stakeholder požadavky byly převedeny do provozních vztahů.

Následuje leadership. Kapitoly 5.1 až 5.3 vyžadují, aby vrcholové vedení prokázalo leadership, přidělilo odpovědnosti, zajistilo komunikaci a podporovalo ISMS. Pokud registr identifikuje, kdo je oprávněn oznámit incident CSIRT, orgánu dohledu nebo dozorovému úřadu, kdo schvaluje externí komunikaci a kdo hlásí stav incidentu vrcholovému vedení, podporuje důkazy leadershipu.

Plánování rizik následně převádí povinnosti do opatření. Kapitoly 6.1.1 až 6.1.3 vyžadují proces posouzení rizik a ošetření rizik, porovnání s přílohou A, Prohlášení o použitelnosti, Plán ošetření rizik a přijetí zbytkového rizika. Registr se má objevit v plánu ošetření u rizik, jako je selhání právního oznámení, opožděná eskalace incidentu, selhání reakce dodavatele, chyba přeshraničního oznámení a rozpad komunikace pro kontinuitu činností.

Opory v opatřeních přílohy A jsou zřejmé:

V Zenith Controls: průvodce napříč oblastmi souladu Zenith Controls je kontakt s orgány řešen jako opatření 5.5 s preventivními a nápravnými charakteristikami. Podporuje důvěrnost, integritu a dostupnost a propojuje se s kyberbezpečnostními koncepty Identify, Protect, Respond a Recover. Zenith Controls jej váže na plánování incidentů, hlášení událostí, informace o hrozbách, zájmové skupiny a reakci na incidenty. Zároveň vysvětluje, proč předem zavedené kontakty s regulačními orgány, orgány činnými v trestním řízení, národními CERT nebo úřady pro ochranu osobních údajů umožňují rychlejší eskalaci a získání pokynů během událostí, jako jsou významná porušení zabezpečení nebo ransomwarové útoky.

Toto opatření není izolované. Zenith Controls také mapuje opatření 6.8, Hlášení událostí informační bezpečnosti, jako detekční kontrolu navázanou na plánování incidentů, posouzení událostí, reakci, získané poznatky, povědomí, monitorování a disciplinární proces. Opatření 5.24, Plánování a příprava řízení incidentů informační bezpečnosti, se propojuje s posouzením událostí, získanými poznatky, protokolováním, monitorováním, bezpečností během narušení, kontinuitou a kontaktem s orgány. Auditní příběh je silnější, když jsou události hlášeny, posuzovány, eskalovány, komunikovány, dokládány a zlepšovány.

NIS2, DORA a GDPR: jeden registr, různé právní lhůty

Jeden incident může spustit několik právních pracovních postupů. Neoprávněný přístup u poskytovatele SaaS může být významným incidentem podle NIS2, porušením zabezpečení osobních údajů podle GDPR a smluvní oznamovací událostí vůči zákazníkům. Výpadek u finančního subjektu může být závažným incidentem souvisejícím s ICT podle DORA a zároveň vyžadovat analýzu podle GDPR a koordinaci s dodavateli.

NIS2 vyžaduje, aby základní a důležité subjekty bez zbytečného odkladu oznamovaly svému CSIRT nebo příslušnému orgánu významné incidenty ovlivňující poskytování služeb. Fázovaný model hlášení zahrnuje včasné varování bez zbytečného odkladu a do 24 hodin od zjištění, oznámení incidentu bez zbytečného odkladu a do 72 hodin, průběžné stavové zprávy na vyžádání a závěrečnou zprávu do jednoho měsíce po oznámení incidentu. Pokud incident stále probíhá, může být vyžadováno také průběžné hlášení postupu.

DORA vyžaduje, aby finanční subjekty udržovaly proces řízení incidentů souvisejících s ICT, který detekuje, řídí a oznamuje incidenty, zaznamenává incidenty a významné kybernetické hrozby, klasifikuje závažnost a kritičnost, přiřazuje role, definuje eskalaci a komunikaci, hlásí závažné incidenty vrcholovému vedení a podporuje včasnou obnovu. Hlášení závažných incidentů souvisejících s ICT se řídí logikou počátečního, průběžného a závěrečného hlášení, přičemž klasifikace vychází z faktorů, jako jsou dotčení klienti, doba trvání, geografické rozšíření, ztráta dat, kritičnost služeb a ekonomický dopad.

GDPR přidává posouzení porušení zabezpečení osobních údajů. Registr kontaktů sám o sobě nerozhoduje o právní oznamovací povinnosti. Zajišťuje, aby správní lidé mohli rozhodnout rychle, s použitím aktuálních kanálů a zdokumentovaných kritérií.

Knihovna politik Clarysec to převádí do provozu. V politice pro SME Politika reakce na incidenty Politika reakce na incidenty - SME kapitola 5.1.1 stanoví:

Generální ředitel (GM) odpovídá za autorizaci všech rozhodnutí o eskalaci incidentů, regulačních oznámení a externí komunikace.

Stejná politika pro SME v kapitole 7.4.1 doplňuje:

Pokud jsou dotčena zákaznická data, musí generální ředitel posoudit právní oznamovací povinnosti na základě použitelnosti GDPR, NIS2 nebo DORA.

Pro podniková prostředí stanoví Politika reakce na incidenty Politika reakce na incidenty v kapitole 5.5 komunikační rámec:

Veškerá komunikace související s incidentem musí postupovat podle Komunikační a eskalační matice, čímž se zajistí:

Kapitola 6.4.2 doplňuje požadavek na důkazy:

Všechna oznámení o porušení zabezpečení musí být před odesláním zdokumentována a schválena a jejich kopie musí být uchovávány v ISMS.

Zde se registr stává důkazem pro ISO. Nejde jen o to vědět, komu zavolat. Jde o to doložit, kdo byl oprávněn, co bylo posouzeno, co bylo schváleno, co bylo odesláno a kde je uchovávaná kopie.

Důkazní model Clarysec: čtyři artefakty, které fungují společně

Silná schopnost práce s kontakty pro regulatorní oznámení potřebuje čtyři artefakty fungující jako jeden důkazní řetězec.

Registr kontaktů pro regulatorní oznámení identifikuje kontakty, kanály, spouštěče a vlastníky. Komunikační a eskalační matice definuje, kdo co dělá. Log rozhodnutí zaznamenává klasifikaci, posouzení oznamovací povinnosti, právní přezkum a schválení. Balíček důkazů k oznámení uchovává podaná oznámení, potvrzení z portálů, e-maily, poznámky z hovorů, zpětnou vazbu regulačního orgánu, odpovědi dodavatelů a závěrečné zprávy.

Politika Clarysec Politika právního a regulačního souladu Politika právního a regulačního souladu - SME vyjadřuje koncept registru explicitně. Kapitola 5.5.2 stanoví:

Klíčové podmínky souladu (např. lhůty pro oznamování porušení zabezpečení a ustanovení o nakládání s daty) musí být extrahovány a sledovány v Registru souladu.

Registr souladu má napájet registr kontaktů pro regulatorní oznámení. Právní požadavek může znít „včasné varování podle NIS2 do 24 hodin“, zatímco registr kontaktů identifikuje národní portál CSIRT, záložní služební číslo, oprávněného odesílatele, právního přezkoumávajícího, požadované důkazy a cestu uchování.

Politiky kontinuity činností posilují stejné očekávání. Politika pro SME Politika kontinuity činností a obnova po havárii Politika kontinuity činností a obnova po havárii - SME v kapitole 5.2.1.1 odkazuje na:

seznamy kontaktů a plány alternativní komunikace

Podniková Politika kontinuity činností a obnova po havárii Politika kontinuity činností a obnova po havárii v kapitole 5.3.3 vyžaduje, aby opatření kontinuity byla:

Podporována aktuálními seznamy kontaktů a eskalačními toky

Do modelu patří také správa dodavatelů. V politice pro SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME kapitola 5.4.3 vyžaduje:

Přiřazenou kontaktní osobu

Pro NIS2 a DORA tento kontakt nemůže být obecný. Pokud kritický cloudový poskytovatel, poskytovatel řízených bezpečnostních služeb, poskytovatel identit nebo zpracovatel plateb podporuje regulovanou službu, registr má identifikovat provozní kontakt, kontakt pro bezpečnostní incidenty, smluvní oznamovací kanál a eskalační trasu pro žádosti o důkazy.

Vytvořte registr během jedné pracovní schůzky

Užitečný registr lze vytvořit rychle, pokud jsou v místnosti správní lidé. Naplánujte dvouhodinovou schůzku s CISO, DPO, právním poradcem, manažerem dodavatelů, odpovědnou osobou za kontinuitu činností, velitelem incidentu a vlastníkem souladu.

Začněte Registrem souladu. Extrahujte oznamovací povinnosti podle NIS2, DORA, GDPR, smluv a odvětvových požadavků. Zaznamenejte lhůty, kritéria oznamovací povinnosti a požadavky na důkazy.

Otevřete runbook reakce na incidenty. Pro každou kategorii incidentu, například ransomware, neoprávněný přístup, výpadek služby, exfiltraci dat, dodavatelský incident a selhání cloudového regionu, určete potřebné externí kontakty.

Naplňte registr kontaktů pro regulatorní oznámení orgánem, jurisdikcí, spouštěčem, primárním kanálem, záložním kanálem, vlastníkem, schvalovatelem, potřebnými důkazy, datem posledního ověření a místem uchování.

Propojte kontakty dodavatelů. U každé kritické nebo důležité funkce určete kontakt poskytovatele pro bezpečnostní incidenty, smluvní oznamovací kanál, auditní kontakt a nouzovou eskalační cestu.

Přezkoumejte soulad s politikami. Potvrďte, že eskalační pravomoc odpovídá Politice reakce na incidenty, důkazy o oznámení jsou uchovávány v ISMS, seznamy kontaktů pro kontinuitu činností jsou sladěné a kontakty dodavatelů mají přiřazené vlastníky.

Otestujte jeden scénář. Použijte cílené tabletop cvičení: „Expozice zákaznických dat zjištěná ve 02:17, dotýká se klientů v EU a mohla být způsobena kompromitovanými přihlašovacími údaji poskytovatele identit.“ Požádejte tým, aby určil, zda mohou být vyžadována oznámení CSIRT, dozorovému úřadu, finančnímu orgánu dohledu, dodavateli a zákazníkům. Cílem není vynutit si během cvičení konečný právní závěr. Cílem je prokázat, kde jsou kontakty k nalezení, kdo schvaluje kontakt, jaké důkazy jsou potřebné a kde se logují rozhodnutí.

Vytvořte balíček důkazů. Uložte verzi registru, účastníky schůzky, schválení, poznámky ke scénáři, log rozhodnutí, akční položky a aktualizovaný odkaz na runbook.

Zde se Zenith Blueprint krok 23 stává praktickým:

Zajistěte, abyste měli aktuální plán reakce na incidenty (5.24) pokrývající přípravu, eskalaci, reakci a komunikaci. Definujte, co představuje bezpečnostní událost podléhající hlášení (5.25), a jak je rozhodovací proces spuštěn a dokumentován. Vyberte nedávnou událost nebo proveďte tabletop cvičení za účelem validace plánu.

Cvičení nemusí být rozsáhlé. Musí prokázat připravenost.

Mapování napříč rámci souladu: jeden registr, mnoho rámců

Hodnota registru kontaktů pro regulatorní oznámení spočívá v tom, že snižuje duplicitní úsilí v oblasti souladu. Jeden artefakt připravený jako důkaz může podporovat očekávání správy a řízení podle ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

NIST CSF 2.0 je obzvlášť užitečný jako integrační vrstva. Jeho funkce GOVERN očekává, že organizace porozumí zainteresovaným stranám, právním a regulačním povinnostem, kritickým službám, závislostem, ochotě podstupovat riziko, rolím, politikám, dohledu a dodavatelskému riziku. Profily CSF pomáhají organizacím dokumentovat Current Profile, definovat Target Profile, analyzovat mezery a vytvořit prioritizovaný akční plán. Registr kontaktů pro regulatorní oznámení může být konkrétním důkazem, který uzavírá mezeru mezi současnou a cílovou správou incidentů.

Pro dodavatelský řetězec NIST CSF 2.0 očekává, že dodavatelé, zákazníci a partneři budou mít definované role a odpovědnosti v oblasti kybernetické bezpečnosti, bude známa kritičnost dodavatelů, požadavky na kybernetickou bezpečnost budou začleněny do smluv, dodavatelská rizika budou posuzována a relevantní dodavatelé budou zahrnuti do plánování incidentů, reakce a obnovy. To se přímo mapuje na rizika třetích stran v oblasti ICT podle DORA a očekávání NIS2 v oblasti dodavatelského řetězce.

Jak budou auditoři a orgány dohledu testovat stejný registr

Dobře udržovaný registr bude zkoumán různě podle pohledu hodnotitele.

Auditor ISO/IEC 27001:2022 začne rozsahem a zainteresovanými stranami. Bude se ptát, jak organizace identifikovala použitelné orgány, právní povinnosti, smluvní oznamovací povinnosti a outsourcované závislosti. Poté vysleduje registr k Prohlášení o použitelnosti, plánu reakce na incidenty, plánu kontinuity činností a uchovávání důkazů. Může vybrat jeden kontakt a požádat o důkaz posledního ověření.

Hodnotitel NIS2 se zaměří na to, zda subjekt identifikoval správný CSIRT nebo příslušný orgán a zda jsou prahové hodnoty významných incidentů operacionalizovány. Bude hledat proces schopný podporovat včasné varování do 24 hodin, oznámení do 72 hodin a závěrečné hlášení. Bude také posuzovat dohled řídicího orgánu, protože článek 20 NIS2 činí správu kybernetické bezpečnosti odpovědností vedení.

Orgán dohledu podle DORA nebo tým interního auditu ověří, zda registr podporuje řízení incidentů, klasifikaci, hlášení závažných incidentů souvisejících s ICT, krizovou komunikaci, hlášení vrcholovému vedení, koordinaci s dodavateli a provozní obnovu. Může se ptát, zda existují kontakty na poskytovatele služeb ICT třetích stran podporující kritické nebo důležité funkce a zda jsou komunikační povinnosti promítnuty do smluv.

Auditor GDPR nebo přezkum DPO se zaměří na posouzení porušení zabezpečení osobních údajů. Bude se ptát, zda jsou DPO a právní kontakty pro ochranu soukromí zapojeny včas, zda jsou jasné role správce a zpracovatele, zda je identifikován správný dozorový úřad a zda jsou zaznamenána rozhodnutí o komunikaci se subjekty údajů.

Hodnotitel NIST CSF bude registr chápat jako důkaz pro výsledky GOVERN: očekávání zainteresovaných stran, právní povinnosti, role, politiky, dohled a riziko dodavatelského řetězce. Auditor ve stylu COBIT 2019 nebo ISACA prověří, zda jsou potřeby zainteresovaných stran převedeny do postupů správy a řízení a řízení, zda jsou přiřazeny odpovědnosti a zda je monitorována výkonnost procesů.

Stejný artefakt musí obstát ve všech těchto otázkách. Proto má být registr řízený, vlastněný, přezkoumávaný, chráněný řízením přístupu a testovaný.

Běžné vzorce selhání ve správě kontaktů

Organizace zřídkakdy selhávají proto, že nemají žádné kontakty. Selhávají proto, že kontaktům nelze při skutečném incidentu důvěřovat.

Každý problém vytváří předvídatelné zjištění auditu. Náprava je stejně předvídatelná: sladit registr s politikou, integrovat jej do reakce na incidenty, ověřit kontakty, otestovat pracovní postup a uchovat důkazy.

Odpovědnost správního orgánu a vedení

NIS2 vyžaduje, aby řídicí orgány schvalovaly opatření řízení kyberbezpečnostních rizik, dohlížely na jejich implementaci a absolvovaly školení. Článek 5 DORA činí řídicí orgán odpovědným za definování, schvalování, dohled a odpovědnost za uspořádání řízení rizik ICT, včetně politik, rolí, kontinuity činností v ICT, plánů reakce a obnovy, politiky třetích stran ICT, povědomí a školení. ISO/IEC 27001:2022 vyžaduje, aby vedení sladilo ISMS se strategickým směřováním, poskytlo zdroje, přidělilo odpovědnosti a podporovalo neustálé zlepšování.

Správní orgán si nemusí pamatovat telefonní číslo CSIRT. Musí však mít ujištění, že připravenost k oznamování existuje, má vlastníka, je testována a přezkoumávána.

Čtvrtletní manažerský balíček má obsahovat:

• Stav přezkumu registru kontaktů pro regulatorní oznámení
• Změny v použitelných orgánech, orgánech dohledu nebo jurisdikcích
• Otevřené mezery v kontaktech dodavatelů pro incidenty
• Výsledky tabletop cvičení a získané poznatky
• Důkazy o testování schvalovacího workflow oznámení
• Metriky času od detekce po eskalační rozhodnutí
• Aktualizace oznamovacích povinností podle NIS2, DORA, GDPR a smluv
• Zbytková rizika vyžadující akceptaci vedením

Tím se registr přesouvá z provozní tabulky na řídicí opatření.

Jak vám Clarysec pomůže vybudovat správu kontaktů připravenou na audit

Clarysec propojuje texty politik, pořadí implementace a mapování kontrol napříč rámci do jedné důkazní cesty.

Knihovna politik definuje odpovědnost a vyžadované záznamy. Politika reakce na incidenty stanoví očekávání pro eskalaci, schválení oznámení a uchovávání. Politika právního a regulačního souladu vyžaduje sledování podmínek souladu, například lhůt pro oznamování porušení zabezpečení. Politika kontinuity činností a obnova po havárii vyžaduje aktuální seznamy kontaktů a plány alternativní komunikace. Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran vyžaduje přiřazené kontakty dodavatelů.

Zenith Blueprint poskytuje pořadí implementace. Krok 5 ve fázi ISMS Foundation & Leadership řeší komunikaci, povědomí a kompetence, včetně externích zainteresovaných stran, načasování, rolí komunikátorů a komunikačních plánů. Krok 22 začleňuje kontakty na orgány a zájmové skupiny do organizačních opatření. Krok 23 validuje řízení incidentů, rozhodnutí o událostech podléhajících hlášení, zachování forenzních důkazů a získané poznatky.

Průvodce Zenith Controls poskytuje kompas pro soulad napříč rámci. Ukazuje, jak se kontakt s orgány propojuje s plánováním incidentů, hlášením událostí, informacemi o hrozbách, zájmovými skupinami a reakcí na incidenty. Také ukazuje, proč jsou hlášení událostí informační bezpečnosti a příprava na incidenty nezbytnými doprovodnými prvky. Registr kontaktů je účinný pouze tehdy, pokud jsou události hlášeny a posouzeny dostatečně včas, aby jej spustily.

Pro SME to znamená štíhlý, ale obhajitelný registr, jasnou odpovědnost a důkazy odpovídající zásadě proporcionality. Pro podniky to znamená integraci napříč jurisdikcemi, právními subjekty, obchodními jednotkami, dodavateli, regulačními orgány, orgány dohledu, CSIRT a reportováním správnímu orgánu.

Další kroky: vytvořte registr dříve, než začne běžet lhůta

Pokud se vaše organizace připravuje na NIS2, DORA, připravenost na oznamování porušení zabezpečení podle GDPR nebo certifikaci ISO/IEC 27001:2022, nečekejte na živý incident, abyste zjistili, zda vaše správa kontaktů funguje.

Začněte tento týden čtyřmi kroky:

1. Vytvořte nebo aktualizujte registr kontaktů pro regulatorní oznámení pro CSIRT, příslušné orgány, finanční orgány dohledu, úřady pro ochranu osobních údajů, orgány činné v trestním řízení, kritické dodavatele a interní eskalační role.
2. Namapujte každý kontakt na spouštěč, vlastníka, schvalovací cestu, požadavek na důkazy a místo uchování.
3. Proveďte jedno tabletop cvičení zaměřené na rozhodnutí o oznámení, kontakt s orgánem, koordinaci s dodavateli a uchování důkazů.
4. Aktualizujte záznamy ISMS, včetně Registru souladu, runbooku reakce na incidenty, seznamů kontaktů pro kontinuitu činností a záznamů kontaktů dodavatelů.

Clarysec vám pomůže rychle to implementovat pomocí Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls a našich knihoven politik pro SME i podniková prostředí, včetně Politiky reakce na incidenty Politika reakce na incidenty, Politiky právního a regulačního souladu Politika právního a regulačního souladu - SME, Politiky kontinuity činností a obnovy po havárii Politika kontinuity činností a obnova po havárii a Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME.

Čtyřiadvacetihodinová lhůta se nezastaví, zatímco váš tým hledá správný kontakt. Vytvořte registr nyní, otestujte jej a zahrňte jej do svých důkazů pro ISO dříve, než vám další incident určí časovou osu.