Připravenost na Akt EU o kybernetické solidaritě s využitím ISO 27001

Incident ve 03:17, který mění spolupráci v EU ve váš auditní problém

V úterý ve 03:17 ráno sleduje Maria, CISO společnosti InnovateCloud, obrazovku plnou upozornění. Její společnost je středně velký evropský poskytovatel SaaS služeb pro logistické zákazníky v Německu, Francii a Polsku. První upozornění vypadá jako podezřelý privilegovaný přístup v produkčním tenantovi. O deset minut později poskytovatel řízených bezpečnostních služeb hlásí podobnou aktivitu u dalších dvou zákazníků. Ve 04:00 SOC zaznamenává volání API z infrastruktury, která byla dříve spojována s přípravou ransomwarového útoku.

InnovateCloud nebyl původním cílem. Zdá se, že klíčový poskytovatel infrastruktury je někde v zasaženém prostředí. Dopad je však nyní Mariin problém.

Jedním z dotčených zákazníků je německá banka, která požaduje odpovědi podle DORA. Dalším je kritický dodavatel v energetickém sektoru, již klasifikovaný podle vnitrostátních pravidel NIS2. Prostředí může obsahovat osobní údaje, ale exfiltrace zatím nebyla potvrzena. Bezpečnostní tým chce hrozbu okamžitě zadržet. Právní oddělení potřebuje vědět, zda již začala běžet 24hodinová lhůta pro včasné varování podle NIS2. Odpovědná osoba pro ochranu soukromí se ptá, zda může vzniknout povinnost oznámit porušení zabezpečení osobních údajů podle GDPR. Řídicí orgán chce vědět, zda se výpadek může rozšířit napříč členskými státy.

V roce 2026 už nejde jen o interní krizi.

Akt EU o kybernetické solidaritě mění provozní realitu rozsáhlých a přeshraničních kybernetických incidentů. Zavádí mechanismy detekce, připravenosti a reakce na úrovni EU, včetně Evropského systému kybernetických výstrah, Mechanismu pro mimořádné situace v oblasti kybernetické bezpečnosti a Rezervy EU pro kybernetickou bezpečnost. I když organizace nikdy přímo nepožádá o pomoc z rezervy, její důkazy, kontakty na orgány, dodavatelské smlouvy, časové osy incidentů a komunikace se zákazníky se mohou stát součástí širšího evropského řetězce reakce.

Mezera se projeví rychle. Mnoho organizací má nástroje, tikety a politiky, ale nemá důkazy, které obstojí při regulatorním přezkumu. Mohou říci: „kontaktovali jsme příslušný orgán“, ale nedokážou doložit, kdo byl oprávněn kontakt provést, jaká prahová hodnota kontakt spustila, co bylo sděleno, zda byly uchovány logy, zda měl dodavatel smluvní povinnost poskytnout součinnost nebo zda lze závěrečnou zprávu rekonstruovat z rozhodnutí učiněných v daném čase.

Řešením není další izolovaný „šanón k Aktu EU o kybernetické solidaritě“. Řešením je systém řízení bezpečnosti informací podle ISO/IEC 27001:2022, který vytváří důkazy jednou a opakovaně je využívá pro očekávání vyplývající z NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

Tyto důkazy vznikají ještě před incidentem.

Proč Akt EU o kybernetické solidaritě zvyšuje laťku pro důkazy

Akt EU o kybernetické solidaritě je navržen pro kybernetickou detekci, připravenost a krizovou reakci na úrovni EU. Jeho praktický dopad pro CISO, auditory a manažery compliance je jasný: koordinace rozsáhlých incidentů vyžaduje důkazy, které jsou rychleji dostupné, čistší, konzistentnější a snáze sdílené s důvěryhodnými zainteresovanými stranami.

Pokud je možný přeshraniční dopad, organizace může potřebovat koordinaci s národními CSIRT, příslušnými orgány, sektorovými regulátory, úřady pro ochranu osobních údajů, orgány finančního dohledu, orgány činnými v trestním řízení, zákazníky, zpracovateli, dodavateli a externími týmy reakce na incidenty. Rezerva EU pro kybernetickou bezpečnost přidává další rozměr, protože předem prověření soukromí poskytovatelé mohou podporovat připravenost, reakci a obnovu. Tím roste význam řízení dodavatelů, právního oprávnění, nakládání s daty a uchování důkazů.

Soukromé subjekty stojí v centru této reality. Poskytovatelé cloudových služeb, datová centra, poskytovatelé řízených služeb, poskytovatelé řízených bezpečnostních služeb, provozovatelé digitální infrastruktury, fintech společnosti a SaaS platformy často drží telemetrii, logy, údaje o dopadu na zákazníky a technická fakta, která orgány potřebují k pochopení závažného incidentu.

NIS2 již tímto směrem ukazuje. Vztahuje se na mnoho středních a velkých subjektů v odvětvích uvedených v příloze I a příloze II, které poskytují služby nebo vykonávají činnosti v EU. Zahrnuje také určité subjekty bez ohledu na velikost, včetně poskytovatelů služeb vytvářejících důvěru, poskytovatelů služeb DNS, registrů domén nejvyšší úrovně a poskytovatelů služeb registrace doménových jmen. Příloha I zahrnuje digitální infrastrukturu, například služby cloud computingu, služby datových center, sítě pro doručování obsahu, poskytovatele DNS, poskytovatele služeb vytvářejících důvěru a registry TLD. Zahrnuje také řízení ICT služeb v režimu B2B, včetně poskytovatelů řízených služeb a poskytovatelů řízených bezpečnostních služeb. Příloha II zahrnuje digitální poskytovatele, například online tržiště, internetové vyhledávače a platformy služeb sociálních sítí.

DORA přidává druhou vrstvu pro finanční sektor. Od 17. ledna 2025 se vztahuje na široký okruh finančních subjektů, včetně úvěrových institucí, platebních institucí, institucí elektronických peněz, investičních podniků, poskytovatelů služeb souvisejících s kryptoaktivy, obchodních systémů, pojišťoven a zajišťoven, ratingových agentur, poskytovatelů služeb skupinového financování a dalších. Zároveň vytváří významná očekávání vůči poskytovatelům ICT služeb z řad třetích stran, protože finanční subjekty zůstávají odpovědné za outsourcované ICT služby.

Fintech incident v roce 2026 proto může být koordinován prostřednictvím dohledových kanálů DORA, zatímco SaaS poskytovatel nebo MSSP podporující tento fintech může spadat pod NIS2. Stejná technická událost může pro různé aktéry vytvořit odlišné oznamovací povinnosti, očekávání ohledně důkazů a smluvní povinnosti.

ISO/IEC 27001:2022 dává organizacím provozní systém pro řízení této složitosti. Kapitoly 4.1 až 4.4 vyžadují, aby organizace definovala ISMS ve svém podnikatelském kontextu, identifikovala zainteresované strany a jejich právní, regulatorní a smluvní požadavky, určila hranice a závislosti a zavedla systém řízení. Kapitoly 5.1 až 5.3 činí vedení odpovědným za politiku, zdroje, integraci a přiřazení rolí. Kapitoly 6.1.1 až 6.1.3 vyžadují opakovatelné posouzení rizik, ošetření rizik a Prohlášení o použitelnosti. Kapitola 8.1 vyžaduje operativní řízení, včetně řízení externě poskytovaných procesů, produktů a služeb.

Toto je jádro připravenosti na Akt EU o kybernetické solidaritě: doložit, že krizová reakce je řízená, testovaná a auditovatelná, nikoli improvizovaná.

Důkazní model Clarysec: jeden incident, mnoho povinností

Přeshraniční incident nečeká, až jej právní týmy klasifikují. Důkazy musí být zachyceny od prvního upozornění a poté směrovány do správných oznamovacích a koordinačních postupů.

Přístup Clarysec propojuje tři aktiva:

1. Zenith Blueprint: 30krokový plán auditora Zenith Blueprint, který převádí implementaci ISO/IEC 27001:2022 do posloupnosti kroků připravených na audit.
2. Zenith Controls: průvodce napříč rámci souladu Zenith Controls, který mapuje opatření ISO/IEC 27002:2022 na související opatření, atributy, provozní schopnosti, bezpečnostní domény a očekávání ohledně důkazů napříč rámci.
3. Šablony politik Clarysec pro reakci na incidenty, sběr důkazů, bezpečnost dodavatelů, protokolování, monitorování a kontinuitu činností, přizpůsobené podnikovým prostředím i prostředím SME.

V dokumentu Zenith Blueprint, ve fázi Controls in Action, se krok 22 věnuje opatření ISO/IEC 27002:2022 5.5, kontaktu s orgány. Uvádí:

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

Stejná část klade otázku, na kterou by měl každý CISO odpovědět před krizí:

pokud by se vaše organizace stala cílem kybernetického útoku, byla zapojena do porušení zabezpečení dat nebo byla předmětem vyšetřování, kdo by rozhodl o kontaktu s orgány? Jak by věděl, co má říci? Za jakých podmínek by byl takový kontakt zahájen?

To není administrativní formalita. V prostředí Aktu EU o kybernetické solidaritě jde o rozdíl mezi klidným včasným varováním a rozpornými sděleními napříč jurisdikcemi.

Zenith Controls považuje opatření ISO/IEC 27002:2022 5.5, kontakt s orgány, za preventivní a nápravné opatření propojené s důvěrností, integritou a dostupností a sladěné s koncepty Identify, Protect, Respond a Recover. Propojuje 5.5 s plánováním a přípravou řízení incidentů, hlášením událostí, informacemi o hrozbách, zvláštními zájmovými skupinami a reakcí na incidenty.

Stejný průvodce zachází s opatřením ISO/IEC 27002:2022 5.24, plánování a příprava řízení incidentů bezpečnosti informací, jako s nápravným opatřením propojeným s Respond a Recover. Vazby na hodnocení událostí, reakci na incidenty, získané poznatky, protokolování, monitorování, bezpečnost během narušení a kontinuitu ukazují, co auditoři často testují: zda váš plán propojuje detekci, klasifikaci, eskalaci, důkazy, obnovu a učení.

Pro nakládání s důkazy je zvlášť důležité opatření ISO/IEC 27002:2022 5.28, sběr důkazů. Zenith Controls jej propojuje s reakcí na incidenty, protokolováním, monitorováním a hlášením událostí. U závažného přeshraničního incidentu se zde technické šetření stává obhajitelným.

Mapování připravenosti na Akt EU o kybernetické solidaritě na důkazy ISO 27001

Akt EU o kybernetické solidaritě vytváří prostředí připravenosti a koordinace. ISO/IEC 27001:2022 poskytuje důkazní mechanismus. NIS2, DORA a GDPR definují mnoho konkrétních očekávání v oblasti oznamování, správy a ochrany.

Všimněte si, co chybí: samostatné silo souladu. Stejné důkazy, které podporují certifikaci ISO/IEC 27001:2022, mohou podporovat odpovědnost vedení podle NIS2, řízení rizik v oblasti ICT podle DORA, odpovědnost za bezpečnost podle GDPR, komunikační výsledky podle NIST CSF a očekávání zajištění podle COBIT 2019.

NIS2: oznamovací lhůta začíná okamžikem zjištění

NIS2 je pro připravenost v roce 2026 klíčová, protože definuje fázovaný pracovní postup hlášení incidentů.

Article 23 vyžaduje, aby základní a důležité subjekty bez zbytečného odkladu oznámily svému CSIRT nebo příslušnému orgánu významné incidenty ovlivňující poskytování služeb. Včasné varování musí být podáno bez zbytečného odkladu a nejpozději do 24 hodin od okamžiku, kdy se subjekt o významném incidentu dozvěděl. Má uvést, je-li to relevantní, zda existuje podezření na zlovolné nebo protiprávní jednání a zda je možný přeshraniční dopad.

Oznámení incidentu následuje bez zbytečného odkladu a nejpozději do 72 hodin od zjištění, aktualizuje včasné varování a poskytuje prvotní posouzení závažnosti, dopadu a dostupných indikátorů kompromitace. Závěrečná zpráva je splatná do jednoho měsíce po oznámení incidentu a obsahuje závažnost, dopad, pravděpodobný typ hrozby nebo kořenovou příčinu, zmírňující opatření a přeshraniční dopad.

Proto reakce na incidenty nemůže začínat prázdným dokumentem.

Podniková Politika reakce na incidenty Politika reakce na incidenty uvádí:

NIS2 Article 23 (oznámení do 24 hodin od okamžiku zjištění incidentu)

SME Politika reakce na incidenty - SME Politika reakce na incidenty - SME převádí stejnou logiku lhůt do praktického modelu řízení:

„Lhůty reakce, včetně obnovy dat a oznamovacích povinností, musí být dokumentovány a sladěny s právními požadavky, například s požadavkem GDPR oznámit porušení zabezpečení osobních údajů do 72 hodin.“

Z dokumentu Politika reakce na incidenty - SME, část „Požadavky na správu a řízení“, kapitola 5.3.2.

Zároveň vkládá posouzení více režimů přímo do incidentního procesu:

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

Z dokumentu Politika reakce na incidenty - SME, část „Ošetření rizik a výjimky“, kapitola 7.4.1.

Ve scénáři Aktu EU o kybernetické solidaritě se tvrzení „přeshraniční dopad je možný“ stává provozně důležitým. Včasné varování nemusí obsahovat úplná fakta, ale organizace musí být schopna doložit, proč přeshraniční dopad na základě dostupných důkazů předpokládala nebo nepředpokládala.

Záznam o incidentu by měl zachytit:

• Kdy se organizace o události dozvěděla.
• Kdo událost označil za potenciální incident.
• Které služby, země, zákazníci nebo sektory mohly být dotčeny.
• Zda existovalo podezření na zlovolnou nebo protiprávní aktivitu.
• Které indikátory kompromitace byly dostupné.
• Jaká kontaktní cesta na orgány byla použita.
• Zda byla vyžadována komunikace se zákazníky.
• Které důkazy byly uchovány před zásadní nápravou.

Nejlepší čas navrhnout tato pole je před 03:17.

DORA: když je zákazník regulovaný, ale logy drží dodavatel

DORA mění rozhovor s dodavateli. Finanční subjekty musí řídit riziko ICT třetích stran jako součást svého rámce řízení rizik v oblasti ICT. Outsourcing ICT služeb nepřevádí regulatorní odpovědnost z finančního subjektu.

DORA vyžaduje strategie pro rizika ICT třetích stran, registry smluv o ICT službách, náležitou péči, plánování auditů a inspekcí, práva na ukončení a otestované strategie ukončení pro kritické nebo důležité ICT služby. Article 30 vyžaduje smluvní jasnost, včetně popisu služeb, umístění, nakládání s daty, důvěrnosti, integrity, dostupnosti, úrovní služeb, pomoci během ICT incidentů, spolupráce s orgány a práv na ukončení. Pro kritické nebo důležité funkce platí přísnější podmínky.

Vraťme se k Mariinu incidentu. Německá banka je regulována podle DORA. InnovateCloud poskytuje SaaS služby. MSSP detekuje podezřelou aktivitu. Poskytovatel cloudové infrastruktury má část klíčových auditních logů. Subdodavatel provozuje část telemetrického toku. Banka zůstává odpovědná, ale bez důkazů od dodavatelů nedokáže incident správně klasifikovat a oznámit.

Clarysec to řeší prostřednictvím klasifikace dodavatelů a smluvních důkazů. Podniková Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran vyžaduje:

Smlouvy s dodavateli musí obsahovat:

SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME používá stejnou logiku souladu v odlehčeném provozním modelu:

Smlouvy musí obsahovat povinné doložky pokrývající:

Hodnota je v harmonogramu za těmito slovy: povinnosti oznamování incidentů, přístup k logům, práva na audit, důvěrnost, umístění dat, kontroly subdodavatelů, spolupráce s orgány, podpora obnovy a povinnosti při ukončení.

Dokument Zenith Blueprint, fáze Controls in Action, krok 23, poskytuje implementační postup:

Sestavte úplný seznam současných dodavatelů a poskytovatelů služeb (5.19) a klasifikujte je podle přístupu k systémům, datům nebo provoznímu řízení. U každého klasifikovaného dodavatele ověřte, že bezpečnostní očekávání jsou jasně zakotvena ve smlouvách (5.20), včetně důvěrnosti, přístupu, hlášení incidentů a povinností v oblasti souladu.

Pokračuje návazným rizikem:

U každého kritického dodavatele určete, zda využívá subdodavatele (dílčí zpracovatele), kteří mohou přistupovat k vašim datům nebo systémům. Zdokumentujte, jak jsou vaše požadavky na bezpečnost informací přenášeny na tyto strany, buď prostřednictvím smluvních podmínek dodavatele, nebo vašich vlastních přímých doložek.

Toto je také připravenost na Rezervu EU pro kybernetickou bezpečnost. Pokud externí poskytovatel reakce vstoupí během mimořádné situace do vašeho prostředí, musíte znát právní základ, rozsah přístupu, pravidla pro důkazy, povinnosti při nakládání s daty, způsob koordinace s orgány a podmínky ukončení. DORA to výslovně stanoví pro finanční subjekty. NIS2 to činí relevantním pro základní a důležité subjekty. ISO/IEC 27001:2022 z toho činí auditovatelný stav.

GDPR: otázka porušení zabezpečení uvnitř kybernetické krize

Ne každý kybernetický incident je porušením zabezpečení osobních údajů, ale každý závažný incident by měl být z tohoto pohledu posouzen.

GDPR se vztahuje na zpracování v souvislosti s činnostmi provozovny v EU a také na správce nebo zpracovatele mimo EU, kteří nabízejí zboží nebo služby osobám v EU nebo sledují jejich chování v EU. Definuje osobní údaje, zpracování, správce, zpracovatele a porušení zabezpečení osobních údajů. Mezi jeho zásady patří integrita, důvěrnost a odpovědnost, což znamená, že správci musí být schopni doložit soulad.

Během incidentu ve 03:17 se musí Mariin tým ptát:

• Došlo k přístupu k osobním údajům, jejich zpřístupnění, změně, ztrátě nebo zničení?
• Je InnovateCloud správcem, zpracovatelem, nebo obojím pro dotčená data?
• Jsou dotčeny zvláštní kategorie osobních údajů?
• Kteří zákazníci nebo jednotlivci jsou dotčeni?
• Jsou logy dostatečné k posouzení rozsahu?
• Běží oznamovací povinnosti podle GDPR souběžně s povinnostmi podle NIS2 nebo DORA?

Proto koordinace ochrany soukromí patří do eskalace incidentu, nikoli do pozdního právního přezkumu poté, co byly systémy znovu vybudovány a logy zrotovaly.

SME Politika protokolování a monitorování - SME Politika protokolování a monitorování - SME uvádí:

Upozornění s vysokou prioritou musí být do 24 hodin eskalována na generálního ředitele a koordinátora ochrany soukromí

Tato doložka je jednoduchá, ale řeší skutečný vzorec selhání. Odpovědné osoby pro ochranu soukromí potřebují důkazy, dokud jsou stále dostatečně čerstvé k určení, zda došlo k porušení zabezpečení osobních údajů a zda jsou jednotlivci vystaveni riziku.

Vytvořte 24hodinový důkazní balíček pro přeshraniční incident

Praktické cvičení připravenosti by mělo simulovat prvních 24 hodin přeshraničního incidentu. Cílem není nadměrné hlášení. Cílem je prokázat, že organizace dokáže sestavit fakta, přijímat obhajitelná rozhodnutí a udržet konzistentní komunikaci.

Scénář

Váš MSSP detekuje podezřelý privilegovaný přístup z neobvyklého regionu proti vašemu produkčnímu tenantovi. Stejná zdrojová infrastruktura se objevuje v upozorněních týkajících se dvou zákazníků ve dvou členských státech. Jeden zákazník je finanční subjekt. Dotčené prostředí obsahuje osobní údaje, ale exfiltrace není potvrzena.

Krok 1: Otevřete záznam o incidentu

Vytvořte incidentní tiket s využitím schválených klasifikačních polí. Uveďte čas zjištění, zdroj detekce, dotčená aktiva, dotčené služby, potenciálně dotčené země, podezření na zlovolnou aktivitu, počáteční závažnost a velitele incidentu.

Propojte to s opatřeními ISO/IEC 27002:2022 5.24, 5.25 a 5.26 a s opatřeními přílohy A ISO/IEC 27001:2022 A.5.24, A.5.25 a A.5.26.

Krok 2: Spusťte rozhodovací pracovní postup pro kontakt s orgány

Použijte matici kontaktů na orgány vyžadovanou krokem 22 v Zenith Blueprint. Určete, které orgány mohou být relevantní: národní CSIRT, úřad pro ochranu osobních údajů, finanční regulátor, orgány činné v trestním řízení a sektorový regulátor.

Zaznamenejte rozhodnutí a jeho odůvodnění. Pokud není podáno včasné varování podle NIS2, zachyťte proč. Pokud je možný přeshraniční dopad, zaznamenejte důkazy podporující tento závěr.

Krok 3: Uchovejte důkazy před zásadní nápravou

Podniková Politika sběru důkazů a forenzního šetření Politika sběru důkazů a forenzního šetření uvádí:

Všechny shromážděné důkazy musí být jedinečně identifikovány, označeny a uloženy v zabezpečeném repozitáři s:

SME Politika sběru důkazů a forenzního šetření - SME Politika sběru důkazů a forenzního šetření - SME poskytuje stejnou disciplínu v jednodušší podobě:

„Každá položka digitálního důkazu musí být zaznamenána s:“

Z dokumentu Politika sběru důkazů a forenzního šetření - SME, část „Požadavky na správu a řízení“, kapitola 5.2.1.

Pro simulační cvičení shromážděte vzorové záznamy důkazů: export upozornění ze SIEM, logy poskytovatele identit, záznamy privilegovaných relací, snapshot koncového bodu, logy firewallu, cloudové auditní logy, poznámky k dopadu na zákazníky a schválení komunikace.

Krok 4: Aktivujte součinnost dodavatelů

Zkontrolujte registr dodavatelů. Identifikujte MSSP, poskytovatele cloudových služeb a kritické subdodavatele. Potvrďte doložky o podpoře při incidentu, eskalační kontakty, doby uchování logů, formát důkazů a povinnosti spolupráce s orgány.

To přímo podporuje požadavky DORA na rizika ICT třetích stran a očekávání NIS2 v oblasti zabezpečení dodavatelského řetězce.

Krok 5: Připravte tři komunikace

Připravte tři komunikace ze stejné faktické základny:

Krok 6: Uzavřete cvičení získanými poznatky

Aktualizujte Registr rizik, Prohlášení o použitelnosti, Registr dodavatelů a Plán reakce na incidenty. Pokud cvičení odhalí chybějící logy, nejasné kontakty na orgány nebo slabé dodavatelské doložky, založte nápravná opatření.

Dokument Zenith Blueprint, fáze Controls in Action, krok 23, instruuje organizace k validaci incidentních schopností takto:

Vyberte nedávnou událost nebo proveďte tabletop cvičení k validaci svého plánu. Zachyťte a zaznamenejte všechna rozhodnutí, role a komunikaci (5.26) a aktualizujte plán o získané poznatky (5.27). Potvrďte, že jsou zavedeny postupy pro uchování forenzních důkazů (5.28), včetně snapshotů logů, záloh a bezpečné izolace dotčených systémů.

Tento odstavec je agenda cvičení připravená na audit.

Protokolování: rozdíl mezi koordinací a spekulací

Koordinace přeshraničních incidentů selhává, když mají všichni názory a nikdo nemá časová razítka.

Dokument Zenith Blueprint, fáze Controls in Action, krok 19, to vyjadřuje jasně:

Protokolování je životodárnou součástí každého bezpečného IT prostředí. Bez něj zůstávají incidenty neviditelné, odpovědnost se vytrácí a vztahy příčiny a následku mizí beze stopy.

Pokračuje:

Ve své podstatě je protokolování o dohledatelnosti. Když se něco pokazí, ať už jde o neúspěšný pokus o přihlášení, smazání kritických souborů nebo spuštění neautorizovaného skriptu na serveru, logy poskytují forenzní vlákno, které pomáhá rozplést, co se skutečně stalo.

Pro NIS2 logy podporují 72hodinové oznámení incidentu s počáteční závažností, dopadem a indikátory kompromitace. Pro DORA logy podporují klasifikaci závažného incidentu souvisejícího s ICT, analýzu kořenové příčiny, provozní dopad a odpovědnost třetích stran. Pro GDPR logy podporují posouzení, zda došlo k přístupu k osobním údajům nebo jejich zpřístupnění. V kontextu Aktu EU o kybernetické solidaritě logy podporují sdílené situační povědomí, aniž by týmy reakce musely spoléhat na spekulace.

Pokud je odpověď na kteroukoli otázku „nejsem si jistý“, problém patří do plánu ošetření rizik.

Kontinuita činností a bezpečný krizový provoz

Diskuse o Aktu EU o kybernetické solidaritě se přirozeně soustředí na reakci na incidenty, ale odolnost znamená také udržet kritické služby bezpečné během narušení.

NIS2 Article 21 vyžaduje přístup založený na všech rizicích, který pokrývá zvládání incidentů, kontinuitu činností, správu záloh, obnovu po havárii, krizové řízení, zabezpečení dodavatelského řetězce, zvládání zranitelností, posouzení účinnosti, kybernetickou hygienu, kryptografii, bezpečnost HR, řízení přístupu, správu aktiv, vícefaktorovou autentizaci, bezpečnou komunikaci a zabezpečenou nouzovou komunikaci, je-li to vhodné.

DORA obdobně vyžaduje správu a řízení, řízení rizik v oblasti ICT, řízení incidentů, testování odolnosti, řízení rizik třetích stran, kontinuitu a obnovu. Menší subjekty mohou mít zjednodušené požadavky, ale stále potřebují dokumentované řízení rizik v oblasti ICT, monitorování, odolné systémy, zvládání incidentů, identifikaci závislostí na třetích stranách, zálohy, obnovu, testování, učení po incidentu a školení.

Podniková Politika kontinuity činností a obnovy po havárii Politika kontinuity činností a obnovy po havárii vychází z jednoduchého požadavku:

Plány musí pokrývat:

Za touto větou stojí důkazy kontinuity, které auditoři očekávají: priority obnovy, cílové doby obnovy, cílové body obnovy, harmonogramy záloh, testy obnovy, krizové role, alternativní komunikace, závislosti na dodavatelích a opatření ke zlepšení po cvičení.

ISO/IEC 27002:2022 opatření 5.29 a 5.30 jsou zde zásadní. Opatření 5.29 se zabývá bezpečností informací během narušení. Opatření 5.30 se zabývá připraveností ICT pro kontinuitu činností. V Zenith Controls je plánování incidentů podle 5.24 propojeno s bezpečností během narušení a širším plánováním kontinuity. To je zvlášť relevantní, když běžné kanály nejsou dostupné, systémy pro správu identit jsou degradované nebo krizové týmy musí koordinovat s orgány prostřednictvím zabezpečené nouzové komunikace.

Mapa napříč rámci souladu: NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019

CISO nepotřebuje pět samostatných incidentních programů. Potřebuje jeden důkazní model, na který lze nahlížet pěti optikami.

Metoda aktuálního a cílového profilu NIST CSF 2.0 je zvlášť užitečná pro organizace, které ještě nejsou dostatečně vyspělé pro plně integrovanou platformu GRC. Vede organizace k vymezení profilu, shromáždění vstupů, jako jsou politiky, priority podnikových rizik, analýzy dopadů na obchodní činnost, požadavky, normy, postupy, ochranná opatření a role, a poté k analýze mezer a vytvoření prioritizovaného akčního plánu. To je blízké praktickému sprintu připravenosti na Akt EU o kybernetické solidaritě: současné důkazy, cílové povinnosti, plán mezer, vlastníci, termíny a auditní stopa.

Auditoři zaměření na COBIT 2019 a postupy ISACA se obvykle ptají, zda jsou cíle správy a řízení vlastněny, měřeny a monitorovány. Neuspokojí je odpověď „řeší to SOC“. Budou se ptát, jak řídicí orgány schvalují riziková opatření, jak se reportuje výkonnost, jak je řízeno riziko třetích stran, jak se přijímají výjimky a jak se sledují nápravná opatření.

Jak budou auditoři testovat stejný incident

Stejný incident ve 03:17 vytvoří různé auditní otázky podle mandátu hodnotitele.

Auditor ISO/IEC 27001:2022 začne u ISMS. Bude se ptát, zda je incidentní proces v rozsahu, zda požadavky zainteresovaných stran zahrnují NIS2, DORA, GDPR a smlouvy, zda posouzení rizik zohlednilo přeshraniční a dodavatelské scénáře, zda byla opatření přílohy A vybrána v Prohlášení o použitelnosti a zda provozní záznamy dokazují dodržení procesu.

Orgán nebo hodnotitel zaměřený na NIS2 se soustředí na odpovědnost vedení, opatření řízení rizik podle Article 21 a oznamování podle Article 23. Může se ptát, kdy se organizace o incidentu dozvěděla, proč incident byl nebo nebyl významný, jak byl posouzen přeshraniční dopad, zda byli informováni zákazníci a zda byla bez zbytečného odkladu přijata nápravná opatření.

Dohledový orgán podle DORA nebo tým interního auditu se bude ptát, zda incident ovlivnil kritické nebo důležité funkce, zda poskytovatelé ICT služeb třetích stran podpořili reakci, zda si finanční subjekt zachoval odpovědnost, zda byl registr informací přesný, zda byl incident správně klasifikován a zda byly získané poznatky promítnuty zpět do testování odolnosti a dohledu nad dodavateli.

Auditor GDPR nebo úřad pro ochranu osobních údajů se bude ptát, zda měla organizace dostatek důkazů k určení, zda došlo k porušení zabezpečení osobních údajů, zda byly jasné role správce a zpracovatele, zda byly subjekty údajů vystaveny riziku, zda byla opatření důvěrnosti a integrity přiměřená a zda byly vedeny záznamy o odpovědnosti.

Hodnotitel NIST CSF 2.0 převede událost do výsledků Govern, Identify, Protect, Detect, Respond a Recover. Bude hledat očekávání zainteresovaných stran, právní povinnosti, ochotu podstupovat riziko, správu dodavatelů, protokolování, monitorování, provedení reakce, komunikaci a validaci obnovy.

Auditor COBIT 2019 nebo ISACA se zaměří na účinnost správy a systému řízení: vlastnictví, rozhodovací pravomoci, metriky, přijetí rizika, výkonnost procesů, zajištění a neustálé zlepšování.

Právě zde je Zenith Controls užitečný jako kompas napříč rámci souladu. Nepřejmenovává oficiální opatření ani nevytváří paralelní rámec kontrol. Ukazuje, jak opatření ISO/IEC 27002:2022, například 5.5, 5.24 a 5.28, souvisejí s provozními schopnostmi, souvisejícími opatřeními a auditně relevantními důkazy.

Co by měli CISO udělat nyní pro připravenost v roce 2026

Pokud se připravujete na provozní realitu Aktu EU o kybernetické solidaritě, začněte důkazy, nikoli hesly.

Zaprvé aktualizujte kontext ISMS a analýzu zainteresovaných stran. Určete, zda vaše organizace, zákazníci nebo dodavatelé spadají pod NIS2, DORA nebo GDPR. Zahrňte působnost v členských státech, sektorovou klasifikaci, kritické zákazníky, závislosti na ICT službách a kontakty na orgány.

Zadruhé proveďte simulační cvičení přeshraničního incidentu. Použijte scénář, který zahrnuje dodavatele, více než jeden členský stát, možnou expozici osobních údajů a regulovaného finančního zákazníka. Časově omezte prvních 24 hodin.

Zatřetí přezkoumejte dodavatelské smlouvy. Potvrďte oznamovací povinnosti, přístup k logům, forenzní podporu, spolupráci s orgány, přenesené povinnosti na subdodavatele, umístění dat, práva na audit, podporu kontinuity a práva na ukončení.

Začtvrté otestujte sběr důkazů. Exportujte logy, uchovejte snapshoty, označte důkazy, zaznamenejte řetězec nakládání s důkazy a ověřte přístup do repozitáře. Pokud vaše politika říká, že důkazy jsou jedinečně identifikovány a bezpečně uloženy, dokažte to.

Zapáté slaďte incidentní komunikaci. Vaše včasné varování podle NIS2, eskalace podle DORA, posouzení porušení zabezpečení podle GDPR a oznámení zákazníkům si nesmí odporovat. Mohou mít různé právní účely, ale musí vycházet ze stejné faktické základny.

Zašesté zapojte do cvičení řídicí orgán. NIS2 i DORA zvyšují odpovědnost vedení. Kapitoly ISO/IEC 27001:2022 o vedení z toho činí auditovatelný požadavek. Řídicí orgán, který nikdy neviděl 24hodinovou oznamovací lhůtu pro kybernetický incident, není připraven na přeshraniční krizi.

Další kroky s Clarysec

Budoucnost kybernetické bezpečnosti EU stojí na spolupráci a prokázané důvěře. Organizace, které s NIS2 a DORA zacházejí jako s izolovanými kontrolními seznamy, budou mít při přeshraničních incidentech potíže. Organizace, které vybudují provozní systémy ISO/IEC 27001:2022 podložené důkazy, budou schopny s jistotou odpovídat regulačním orgánům, zákazníkům, auditorům i krizovým týmům reakce.

Clarysec pomáhá CISO, manažerům compliance, auditorům a vlastníkům společností převádět kybernetickou regulaci EU do provozních důkazů připravených na audit prostřednictvím:

• Zenith Blueprint: 30krokový plán auditora pro strukturovanou implementaci ISO/IEC 27001:2022 a posloupnost auditních kroků.
• Zenith Controls: průvodce napříč rámci souladu pro mapování incidentních, autoritativních, dodavatelských, důkazních, protokolovacích a kontinuitních opatření napříč rámci.
• Šablon politik Clarysec, včetně Politiky reakce na incidenty, Politiky sběru důkazů a forenzního šetření, Bezpečnostní politiky dodavatelů a poskytovatelů služeb třetích stran, Politiky kontinuity činností a obnovy po havárii, a také verzí pro SME tam, kde je důležitá přiměřenost.

Nejlepší čas připravit se na koordinaci přeshraničních incidentů je před upozorněním ve 03:17. Druhý nejlepší čas je dnes.

Začněte přezkumem připravenosti od Clarysec, stáhněte si relevantní sadu politik nebo si vyžádejte průchod řešením, jak mohou Zenith Blueprint a Zenith Controls pomoci vašemu ISMS vytvářet důkazy, které bude kybernetická odolnost v roce 2026 vyžadovat.