Bezpečné řízení změn pro NIS2 a DORA

Bylo 16:30 v pátek, když Maria, CISO společnosti Finacore, uviděla, že řídicí panel zčervenal. Selhání API přibývala, transakční timeouty se šířily a spojení s významným bankovním klientem zcela vypadlo. Tým předpokládal nejhorší: DDoS, kompromitaci přihlašovacích údajů nebo aktivně zneužívaný exploit.

Kořenová příčina byla běžnější, a přitom škodlivější.

Vývojář s dobrým úmyslem nasadil před víkendem malý výkonnostní hotfix přímo do produkce. Neexistoval formální požadavek na změnu, žádné dokumentované posouzení rizik, žádná auditní stopa schválení, žádné důkazy o bezpečnostním testování a žádný plán rollbacku kromě „vrátit to zpět, když se něco rozbije“. Oprava zavedla nenápadný problém kompatibility API, který přerušil spojení se zákazníkem a spustil hektický rollback.

V pondělí už Maria věděla, že výpadek nebyl pouze selháním inženýringu. Finacore byl poskytovatelem SaaS pro finanční sektor, zpracovával zákaznická data z EU, závisel na cloudových službách a poskytovatelích identit a připravoval se na certifikaci ISO/IEC 27001:2022. DORA se uplatňuje od 17. ledna 2025. Vnitrostátní implementace NIS2 vstupovaly v celé EU v platnost od konce roku 2024. Stejná neúspěšná změna tak mohla být nově posuzována jako riziková událost v oblasti IKT, slabina kybernetické hygieny, problém závislosti na dodavateli, selhání odpovědnosti podle GDPR i auditní zjištění.

Otázka už nezněla: „Kdo schválil tiket?“

Skutečná otázka zněla: „Dokážeme prokázat, že tato změna byla posouzena z hlediska rizik, schválena, otestována, nasazena, monitorována, vratná a přezkoumaná?“

Tato otázka definuje bezpečné řízení změn v roce 2026.

Proč se bezpečné řízení změn stalo opatřením na úrovni řídicích orgánů

Bezpečné řízení změn bývalo chápáno jako ITIL pracovní postup skrytý v Jira, ServiceNow, tabulkách nebo e-mailových schváleních. V regulovaných digitálních organizacích to již nestačí. Řízení změn je nyní součástí provozní odolnosti, kybernetické hygieny, správy rizik IKT, odpovědnosti za ochranu soukromí a ujištění zákazníků.

NIS2 se široce vztahuje na mnoho veřejných i soukromých subjektů v uvedených odvětvích, včetně poskytovatelů digitální infrastruktury, jako jsou cloudové služby, služby datových center, sítě pro doručování obsahu, poskytovatelé služeb vytvářejících důvěru, poskytovatelé elektronických komunikací a B2B poskytovatelé řízení služeb IKT, včetně poskytovatelů řízených služeb a poskytovatelů řízených bezpečnostních služeb. U SaaS, cloudových služeb, poskytovatelů řízených služeb, poskytovatelů řízených bezpečnostních služeb, fintechů a malých a středních podniků poskytujících digitální služby je vymezení působnosti NIS2 často jednou z prvních otázek v oblasti souladu, kterou zákazníci kladou.

NIS2 Article 20 vyžaduje, aby řídicí orgány schvalovaly opatření pro řízení rizik v oblasti kybernetické bezpečnosti, dohlížely na jejich implementaci a absolvovaly školení v oblasti kybernetické bezpečnosti. Article 21 vyžaduje přiměřená a úměrná technická, provozní a organizační opatření v oblastech analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování, bezpečného vývoje a údržby, posuzování účinnosti opatření, kybernetické hygieny, školení, kryptografie, bezpečnosti lidských zdrojů, řízení přístupu, správy aktiv, autentizace a bezpečné komunikace.

Produkční změna se může dotknout téměř všech těchto oblastí.

DORA zvyšuje tlak na finanční subjekty a poskytovatele služeb IKT podporující finanční služby. DORA Article 5 se zabývá správou a řízením a organizací. Article 6 stanoví rámec řízení rizik v oblasti IKT. Article 8 pokrývá identifikaci aktiv IKT, funkcí, závislostí a rizik. Article 9 se věnuje ochraně a prevenci. Article 10 pokrývá detekci. Article 11 řeší reakci a obnovu. Article 12 pokrývá zálohování a obnovu. Article 13 řeší učení a vývoj. Article 14 pokrývá komunikaci. Articles 17 to 19 se týkají řízení, klasifikace a hlášení incidentů souvisejících s IKT. Articles 24 to 26 pokrývají testování digitální provozní odolnosti, včetně pokročilého testování tam, kde je použitelné. Articles 28 to 30 se týkají rizik třetích stran v oblasti IKT, smluv, náležité péče, monitorování, strategií ukončení a kontroly nad kritickými nebo důležitými závislostmi.

Pokud změna upravuje platební API, cloudový firewall, integraci poskytovatele identit, databázový parametr, pravidlo protokolování, zálohovací úlohu, nastavení šifrování, prahovou hodnotu monitorování nebo platformu spravovanou dodavatelem, jde o rizikovou událost v oblasti IKT. Zda se z ní stane úspěch v oblasti odolnosti, nebo regulatorní problém, závisí na tom, jak je změna řízena.

ISO/IEC 27001:2022 poskytuje páteř systému řízení. Kapitoly 4.1 až 4.4 definují kontext ISMS, zainteresované strany, povinnosti, rozsah a neustálé zlepšování. Kapitoly 5.1 až 5.3 vyžadují vedení, odpovědnost, politiku, zdroje a přiřazené odpovědnosti. Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, porovnání s přílohou A, Prohlášení o použitelnosti, plány ošetření rizik a schválení vlastníkem rizika. Kapitoly 8.1 až 8.3, 9.1 až 9.3 a 10.1 až 10.2 vyžadují řízený provoz, opětovné posouzení rizik, monitorování, interní audit, přezkoumání vedením, nápravná opatření a neustálé zlepšování.

Proto nelze řízení změn dodatečně připojit k inženýringu až po události. Musí fungovat uvnitř ISMS.

Klíčové opatření ISO: 8.32 Řízení změn

V ISO/IEC 27002:2022 vyžaduje opatření 8.32 Řízení změn, aby změny zařízení pro zpracování informací a informačních systémů podléhaly postupům řízení změn. Clarysec k tomu přistupuje jako k systému opatření, nikoli jako ke stavu tiketu.

Zenith Controls: průvodce napříč požadavky na soulad mapuje opatření ISO/IEC 27002:2022 8.32 Řízení změn jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Je sladěno s konceptem kybernetické bezpečnosti Protect a propojuje řízení změn se zabezpečením aplikací, zabezpečením systémů, zabezpečením sítí, provozní odolností a auditními důkazy.

Toto mapování je důležité, protože řízení změn nemá zpomalovat podnikání. Má předcházet zbytečným výpadkům, neoprávněné expozici, selhání integrity, odchylkám konfigurace, chybějícím logům, neúspěšné obnově a neotestovanému dopadu dodavatele.

Kniha Zenith Controls mapuje 8.32 na několik podpůrných opatření ISO/IEC 27002:2022:

Poznatek pro soulad napříč požadavky je jednoduchý: jeden disciplinovaný postup řízení změn může generovat důkazy pro ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a ujištění zákazníků, pokud je správně navržen.

Co Clarysec rozumí bezpečnou změnou

Bezpečná změna není pouze „schválená“. Je navržena, posouzena z hlediska rizik, autorizována, otestována, implementována řízeným způsobem, monitorována po nasazení, dokumentována a přezkoumána. Má vlastníka obchodního požadavku, technického vlastníka, vlastníka rizika, dotčená aktiva, dotčené služby, dopad na data, dopad na dodavatele, záznam o testování, záznam o schválení, rozhodnutí o rollbacku a důkazy po implementaci.

Podnikovým základem je P05 Politika řízení změn, která stanoví:

Zajistit, aby všechny změny byly před provedením přezkoumány, schváleny, otestovány a zdokumentovány.

Ze sekce „Cíle“, ustanovení politiky 3.1.

Stejná politika ukotvuje základ opatření ISO:

Příloha A, opatření 8.32 – Řízení změn: Tato politika plně implementuje požadavek řídit změny zařízení a systémů pro zpracování informací plánovaným a kontrolovaným způsobem.

Ze sekce „Referenční normy a rámce“, ustanovení politiky 11.1.3.

Auditorům zároveň poskytuje jasné očekávání ohledně důkazů:

Všechny požadavky na změnu, přezkumy, schválení a podpůrné důkazy musí být zaznamenány v centralizovaném systému řízení změn.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

Pro menší organizace zachovává Politika řízení změn pro malé a střední podniky proces přiměřený, aniž by byl neformální. Vyžaduje:

Před schválením musí být přiřazena úroveň rizika (nízká, střední, vysoká).

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.3.

U významných změn také výslovně stanoví zapojení vrcholového vedení:

Všechny zásadní změny, změny s vysokým dopadem nebo změny napříč odděleními musí být schváleny generálním ředitelem.

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2.

A zachovává základní důkazní stopu:

Udržuje základní evidenci změn zaznamenávající data, typy změn, výsledky a schvalovatele.

Ze sekce „Role a odpovědnosti“, ustanovení politiky 4.2.2.

To je zásada proporcionality v praxi. Podniky mohou používat centralizované nástroje pro řízení pracovních postupů, schválení výborem pro změny (CAB), vazby na CMDB, důkazy z CI/CD, bezpečnostní brány a řídicí panely pro správu a řízení. Malé a střední podniky mohou používat odlehčenou evidenci změn, klasifikaci rizik na nízké, střední a vysoké, definované prahové hodnoty schvalování, plánování rollbacku a následný přezkum nouzových změn. Obojí může vytvářet důkazy. Obojí může snižovat riziko.

Páteční změna provedená správně

Vraťme se k Mariinu pátečnímu incidentu. Slabý proces změn se ptá: „Vyhovovalo někomu toto vydání?“

Bezpečný proces změn se ptá:

1. Jaké aktivum, služba, tok dat, zákaznická funkce a závislost na dodavateli jsou dotčeny?
2. Jde o standardní, běžnou, nouzovou nebo vysoce rizikovou změnu?
3. Ovlivňuje kritickou nebo důležitou funkci podle DORA?
4. Ovlivňuje základní nebo důležitou službu podle NIS2?
5. Zpracovává osobní údaje podle GDPR?
6. Byla změna otestována mimo produkční prostředí?
7. Zahrnuje test bezpečnost, kompatibilitu, výkon, monitorování a ověření rollbacku?
8. Kdo vlastní riziko nasazení a kdo vlastní riziko nenasazení?
9. Jaké důkazy zůstanou po implementaci?
10. Jaké monitorování potvrdí, že změna nezhoršila odolnost?
11. Pokud selže, aktivuje se postup zvládání incidentů?

Zenith Blueprint: 30krokový plán pro auditora převádí tento přístup do praxe ve fázi Controls in Action, kroku 21, který pokrývá opatření 8.27 až 8.34:

Změna je nevyhnutelná, ale v kybernetické bezpečnosti je nekontrolovaná změna nebezpečná. Ať už jde o nasazení záplaty, aktualizaci softwaru, úpravu konfigurací nebo migraci systémů, i ta nejmenší změna může přinést neočekávané důsledky. Opatření 8.32 zajišťuje, aby všechny změny informačního prostředí, zejména ty s dopadem na bezpečnost, byly vyhodnoceny, autorizovány, implementovány a přezkoumány prostřednictvím strukturovaného a dohledatelného procesu.

Tentýž krok 21 popisuje rytmus implementace:

Jádrem účinného řízení změn je opakovatelný pracovní postup. Začíná jasným návrhem, který popisuje, co se mění, proč, kdy a jaká jsou potenciální rizika. Všechny navrhované změny musí projít autorizací a kolegiálním přezkoumáním, zejména u produkčních systémů nebo systémů zpracovávajících citlivá data. Změny musí být před nasazením otestovány v izolovaném prostředí. Nezbytná je také dokumentace a komunikace. Po implementaci musí být změny přezkoumány z hlediska účinnosti.

To je rozdíl mezi řízením změn jako administrativou a řízením změn jako provozní odolností.

Mapování napříč požadavky na soulad: jeden postup, mnoho povinností

Regulační orgány a auditoři často kladou stejnou otázku různými slovy: dokáže organizace řídit změny tak, aby chránila systémy, služby, data a odolnost?

NIST CSF 2.0 je užitečný, protože jej mohou organizace všech velikostí a odvětví používat společně s právními, regulatorními a smluvními požadavky. Jeho profily pomáhají týmům definovat aktuální a cílové profily, analyzovat mezery, stanovovat priority opatření, implementovat zlepšení a průběžně aktualizovat program. V praxi se řízení změn stává nejen opatřením, ale také plánem pro snižování provozního rizika.

Změny dodavatelů: riziko, které většina týmů podceňuje

Mnoho produkčních selhání nezpůsobuje interní kód. Přicházejí od dodavatelů.

Poskytovatel cloudových služeb změní verzi spravované databáze. Zpracovatel plateb upraví API. Poskytovatel řízených bezpečnostních služeb změní směrování upozornění. Dodavatel SaaS přesune dílčího zpracovatele. Poskytovatel spravované identity změní výchozí chování autentizace. Prostředí kontrolních mechanismů zákazníka se změní, i když žádný interní vývojář do produkce nezasáhl.

Zenith Blueprint se tím zabývá ve fázi Controls in Action, kroku 23, který pokrývá organizační opatření 5.19 až 5.37:

Vztah s dodavatelem není statický. V průběhu času se rozsah vyvíjí. Opatření 5.21 má zajistit, aby se to nedělo potmě. Vyžaduje, aby organizace řídily bezpečnostní rizika zaváděná změnami služeb dodavatelů, ať už tyto změny iniciuje dodavatel, nebo jsou řízeny interně.

Stejně důležitý je praktický spouštěč:

Jakákoli změna služeb dodavatele, která ovlivňuje vaše data, systémy, infrastrukturu nebo řetězec závislostí, musí spustit opětovné posouzení toho, k čemu má dodavatel nyní přístup; jak je tento přístup řízen, monitorován nebo zabezpečen; zda dříve zavedená opatření stále platí; a zda je nutné aktualizovat původní ošetření rizik nebo smlouvy.

Podle DORA Articles 28 to 30 musí finanční subjekty vést registry smluv o službách IKT, posuzovat riziko koncentrace, provádět náležitou péči, monitorovat poskytovatele, zachovat práva na audit a inspekci, udržovat strategie ukončení a řídit kritické nebo důležité závislosti IKT. Podle NIS2 Article 21 je zabezpečení dodavatelského řetězce součástí minimálních opatření pro řízení rizik v oblasti kybernetické bezpečnosti.

Provozní model Clarysec propojuje oznámení změn dodavatelů s interním postupem řízení změn. Pokud změna dodavatele ovlivňuje data, dostupnost, bezpečnost, smluvní závazky, kritické funkce nebo povinnosti vůči zákazníkům, stává se řízeným záznamem změny s opětovným posouzením rizik, schválením vlastníkem, testováním tam, kde je možné, komunikací se zákazníky tam, kde je vyžadována, a aktualizovanými důkazy.

Oddělení prostředí: bezpečnostní síť pro řízenou změnu

Politika, která říká „testovat před produkcí“, nemá význam, pokud organizace nemá spolehlivé neprodukční prostředí.

Kniha Zenith Controls mapuje opatření ISO/IEC 27002:2022 8.31 Oddělení vývojových, testovacích a produkčních prostředí jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Přímo podporuje 8.32, protože umožňuje přesouvat změny přes vývoj, testování, akceptaci a produkci s důkazy v každé bráně.

Oddělení prostředí se také propojuje s bezpečným kódováním, bezpečnostním testováním, ochranou testovacích informací a řízením zranitelností. Testování záplat v neprodukčním prostředí podporuje rychlejší a bezpečnější nápravu. Bezpečnostní testování musí probíhat před nasazením do produkčního prostředí. Testovací data musí být chráněna, maskována a řízena.

Tato tabulka často odděluje tvrzení „věříme, že to bylo řízené“ od „umíme prokázat, že to bylo řízené“.

Nouzová záplata zranitelnosti: praktický postup Clarysec

Představte si poskytovatele SaaS podporujícího finanční zákazníky. V knihovně používané jeho autentizační službou je objevena kritická zranitelnost. Služba zpracovává identifikátory zákazníků, metadata přihlášení, tokeny relací a autentizační události. Oprava musí proběhnout rychle, ale ovlivňuje produkční autentizaci, protokolování, chování relací a integraci se spravovaným cloudovým poskytovatelem identit.

Použijte tento postup.

Krok 1: Vytvořte a klasifikujte záznam změny

Otevřete změnu v centralizovaném systému řízení změn nebo v evidenci změn pro malé a střední podniky.

Tím se implementuje podnikový požadavek na důkazy z Politiky řízení změn a požadavky pro malé a střední podniky na evidenci změn a hodnocení rizika před schválením.

Krok 2: Propojte změnu se zranitelností a ošetřením rizika

Propojte změnu s tiketem zranitelnosti, registrem rizik, plánem ošetření rizik a Prohlášením o použitelnosti. Z hlediska ISO/IEC 27001:2022 to dokládá provoz procesu ošetření rizik. Z hlediska ISO/IEC 27002:2022 propojuje 8.8 Řízení technických zranitelností s 8.32 Řízení změn.

Záplatování není výjimkou z řízení změn. Je jedním z jeho nejdůležitějších případů použití.

Krok 3: Testujte v odděleném prostředí

Nasaďte opravenou knihovnu do stagingového prostředí. Proveďte testy úspěšné a neúspěšné autentizace, testy MFA, testy vypršení relace, ověření protokolování, ověření upozornění, kontroly kompatibility závislostí, výkonnostní smoke testy a regresní testy zákaznických integrací.

Nepoužívejte nemaskované produkční osobní údaje, pokud neexistuje dokumentovaný právní základ a bezpečností schválená ochranná opatření. Zásady GDPR Article 5, včetně minimalizace údajů, integrity, důvěrnosti a odpovědnosti, musí určovat rozhodnutí o testovacích datech.

Krok 4: Zdokumentujte rollback

Politika řízení změn pro malé a střední podniky vyžaduje:

Pro každou vysoce rizikovou změnu musí být zdokumentován plán rollbacku.

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.2.

U autentizační záplaty musí plán rollbacku zahrnovat předchozí verzi knihovny, artefakt nasazení, poznámky ke kompatibilitě databáze, zálohu konfigurace poskytovatele identit, stav feature flagu, rozhodnutí o zneplatnění relací, monitorovací kontrolní bod, vlastníka rollbacku a maximální tolerovatelnou dobu výpadku.

Krok 5: Schvalujte s viditelností rizika

U podniku vyžadujte schválení CAB, bezpečnosti, vlastníka produktu a vlastníka služby na základě rizika. U malého nebo středního podniku uplatněte požadavek na schválení generálním ředitelem u zásadních změn, změn s vysokým dopadem nebo změn napříč odděleními.

Schválení musí odpovědět na čtyři otázky: jaké je riziko nasazení, jaké je riziko nenasazení, jaká kompenzační opatření existují a jaké monitorování potvrdí úspěch?

Krok 6: Nasaďte, monitorujte a přezkoumejte

Nasaďte změnu prostřednictvím schválené pipeline. Zachyťte logy CI/CD, identitu schvalovatele, verzi artefaktu, časové razítko nasazení, tiket změny a metriky validace v produkci. Monitorujte chyby autentizace, latenci, neúspěšná přihlášení, objem upozornění, anomálie relací a tikety podpory.

Pokud změna způsobí významný incident, musí se aktivovat postup zvládání incidentů. NIS2 Article 23 vyžaduje odstupňované hlášení významných incidentů, včetně včasného varování do 24 hodin, oznámení incidentu do 72 hodin, průběžných aktualizací tam, kde jsou vyžadovány, a závěrečné zprávy do jednoho měsíce po 72hodinovém oznámení. DORA Articles 17 to 19 vyžadují řízení incidentů souvisejících s IKT, klasifikaci, eskalaci, hlášení závažných incidentů a komunikaci tam, kde je to vhodné.

Přezkum po implementaci musí ověřit, zda záplata fungovala, zda se objevily vedlejší účinky, zda byly logy dostatečné, zda byl potřeba rollback, zda se závislosti na dodavatelích chovaly podle očekávání a zda je třeba změnit provozní postup.

Auditní pohled: jak přezkoumávající osoby testují řízení změn

Zenith Blueprint poskytuje praktickou metodu vzorkování ve fázi Controls in Action, kroku 21:

Vyberte 2–3 nedávné systémové nebo konfigurační změny a ověřte, zda byly zpracovány prostřednictvím vašeho formálního postupu řízení změn.

Poté se ptá:

✓ Byla posouzena rizika?
✓ Byla zdokumentována schválení?
✓ Byl zahrnut plán rollbacku?

Auditoři také ověří, že změny byly implementovány podle plánu, neočekávané dopady byly zaznamenány, logy nebo rozdíly ve správě verzí byly uchovány a nástroje jako ServiceNow, Jira, Git nebo CI/CD platformy podporují souhrnný log záznamů změn.

Poučení je konzistentní: auditoři nechtějí pouze politiku. Chtějí důkaz, že se politika promítá do chování.

Časté vzorce selhání řízení změn

Selhání bezpečného řízení změn jsou obvykle předvídatelná. Objevují se, když je proces příliš těžkopádný pro běžnou práci, příliš vágní pro vysoce rizikovou práci nebo odpojený od skutečných inženýrských nástrojů.

Mezi časté vzorce patří:

• Nouzové změny, které nejsou nikdy následně přezkoumány
• Záplaty nasazované jako rutinní provozní úkoly bez schválení rizika
• Změny dodavatelů přijaté e-mailem, ale nikdy nezapsané do evidence změn
• Testování provedené, ale neuchované jako důkaz
• Plány rollbacku, které říkají pouze „obnovit předchozí verzi“
• Schválení CAB bez analýzy bezpečnostních dopadů
• Vývojová, testovací a produkční prostředí sdílející data, přihlašovací údaje nebo administrátorský přístup
• Konfigurační změny, které neaktualizují záznamy výchozí konfigurace
• Změny v cloudové konzoli provedené mimo infrastrukturu jako kód
• Změny pravidel monitorování bez informování procesu reakce na incidenty
• Osobní údaje používané v testovacích prostředích bez maskování nebo schválení
• Závislosti IKT kritické podle DORA chybějící v analýze dopadů
• Dohled vedení podle NIS2 omezený na každoroční schválení politiky

Nejde pouze o auditní problémy. Jsou to varovné signály provozní křehkosti.

Kontrolní seznam bezpečného řízení změn pro rok 2026

Použijte tento kontrolní seznam k ověření, zda váš proces podporuje očekávání ISO/IEC 27001:2022, kybernetické hygieny NIS2, rizik IKT podle DORA, bezpečnosti podle GDPR, NIST CSF 2.0 a COBIT 2019.

Zajistěte obhajitelnost své příští změny

Pokud by zítra někdo vybral jako vzorek vaše příští produkční vydání, aktualizaci cloudové konfigurace, nouzovou záplatu, migraci dodavatele nebo změnu poskytovatele identit, dokázali byste ukázat celý řetězec důkazů?

Začněte třemi kroky:

1. Vyberte tři nedávné produkční změny a posuďte je pomocí Zenith Blueprint, fáze Controls in Action, kroku 21.
2. Namapujte svůj postup řízení změn na opatření ISO/IEC 27002:2022 8.32, 8.9, 8.8, 8.25, 8.27, 8.29, 8.31, 5.21 a 5.37 pomocí Zenith Controls.
3. Přijměte nebo přizpůsobte Politiku řízení změn nebo Politiku řízení změn pro malé a střední podniky od Clarysec tak, aby se hodnocení rizik, schvalování, testování, rollback, přezkum dodavatelů, monitorování a uchovávání důkazů staly běžným provozním chováním.

Bezpečné řízení změn je místem, kde se setkávají soulad, inženýring, odolnost a důvěra. Organizace, které dokážou prokázat řízenou změnu, budou lépe připraveny na audity ISO/IEC 27001:2022, očekávání kybernetické hygieny NIS2, kontrolu rizik IKT podle DORA, odpovědnost podle GDPR a ujištění zákazníků.

Stáhněte si politiky řízení změn Clarysec, prozkoumejte Zenith Blueprint a Zenith Controls, nebo si objednejte posouzení Clarysec a proměňte řízení změn z pátečního odpoledního rizika v opakovatelný provozní systém odolnosti.