Správa kryptografických klíčů pro ISO 27001, NIS2 a DORA

V pondělí ráno v 08:17 obdrží CISO evropské společnosti poskytující SaaS zprávu od vedoucího vývoje: „O víkendu jsme provedli rotaci šifrovacího klíče databáze, ale jedna integrace přestala dešifrovat záznamy. Vrátili jsme změnu pomocí starého klíče z trezoru.“

O deset minut později se DPO ptá, zda dotčené záznamy obsahují osobní údaje z EU. Finance se ptají, zda by z toho mohl vzniknout provozní incident podléhající hlášení u regulovaného zákazníka. Nákup se ptá, zda klíč spravovaný zákazníkem vlastní poskytovatel cloudových služeb, nebo společnost. CEO pokládá jedinou otázku, na které ve správní radě záleží: „Dokážeme doložit, že jsme to řídili správně?“

To je okamžik, kdy věta „používáme šifrování“ přestává být uklidňujícím tvrzením a stává se otázkou důkazů.

V roce 2026 se správa kryptografických klíčů nachází na průsečíku opatření ISO/IEC 27001:2022, kybernetické hygieny podle NIS2, řízení rizik ICT podle DORA, důkazů o zabezpečení zpracování podle GDPR Article 32, sdílené odpovědnosti v cloudu a plánování postkvantové kryptoagility. Skutečnou otázkou není, zda šifrování existuje. Skutečnou otázkou je, zda organizace dokáže na základě záznamů prokázat, že klíče jsou bezpečně generovány, přiřazeny vlastníkům, ukládány ve schválených prostředích KMS nebo HSM, rotovány podle harmonogramu, bezpečně obnovovány, revokovány při kompromitaci a mapovány na obchodní riziko.

Clarysec při práci na připravenosti opakovaně vidí stejný vzorec. Šifrování je implementováno systém po systému, ale správa klíčů a související governance jsou roztříštěné. Certifikáty žijí v tabulkách. Oprávnění ke cloudovému KMS se dědí ze starých projektů. Vývojáři vědí, která tajemství jsou důležitá, ale ISMS nikoli. Auditoři dostávají snímky obrazovky místo důkazů o životním cyklu. Týmy NIS2 a DORA mluví o odolnosti, týmy ochrany soukromí o šifrování a pseudonymizaci podle GDPR a nikdo nevlastní řídicí rovinu kryptografických opatření od začátku do konce.

Zralou odpovědí není izolovaně přidávat další kryptografii. Je jí řízená správa kryptografických klíčů propojená s ošetřením rizik, cloudovou architekturou, dohledem nad dodavateli, řízením přístupu, protokolováním, reakcí na incidenty a regulatorními důkazy.

Proč je správa klíčů nyní otázkou správy a řízení

NIS2 zařazuje politiky kryptografie a šifrování mezi minimální opatření pro řízení rizik kybernetické bezpečnosti u základních a důležitých subjektů. Article 21 vyžaduje přiměřená a úměrná technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity, zabezpečení dodavatelského řetězce, bezpečného vývoje, kybernetické hygieny, řízení přístupu, správy aktiv a politik kryptografie a šifrování. Zároveň vyžaduje, aby řídicí orgány schvalovaly opatření pro řízení rizik kybernetické bezpečnosti a dohlížely na ně.

U poskytovatelů SaaS, cloudových služeb, řízených služeb a kyberbezpečnostních služeb může být použitelnost širší, než si mnoho týmů předpokládá. NIS2 se vztahuje na sektory, jako je digitální infrastruktura, poskytovatelé služeb cloud computingu, poskytovatelé datových center, poskytovatelé DNS, poskytovatelé služeb vytvářejících důvěru, poskytovatelé řízených služeb, poskytovatelé řízených bezpečnostních služeb, online tržiště, internetové vyhledávače a platformy sociálních sítí, pokud jsou splněny prahové hodnoty velikosti nebo kritičnosti.

DORA zvyšuje nároky na finanční subjekty. Od 17. ledna 2025 DORA vyžaduje dokumentovaný rámec řízení rizik ICT, odpovědnost vedoucích orgánů, kontinuitu činností v oblasti ICT a plány reakce a obnovy, testování digitální provozní odolnosti, řízení rizik třetích stran v oblasti ICT a hlášení incidentů. U finančních subjektů identifikovaných podle vnitrostátních pravidel NIS2 funguje DORA jako odvětvový právní akt Unie pro rovnocenné povinnosti podle NIS2. Fintech by neměl provozovat oddělenou kryptografickou správu pro NIS2, DORA a ISO. Potřebuje jeden obhajitelný model kontrol.

GDPR přidává důkazní rozměr ochrany soukromí. GDPR Article 32 je místem, kde se šifrování běžně hodnotí jako bezpečnostní opatření zabezpečení zpracování, ale tvrzení „data jsou šifrována“ není úplná odpověď. Regulátoři a auditoři se ptají, kdo kontroluje klíče, jak je omezen přístup, jak se detekuje kompromitace, jak funguje obnova a zda návrh odpovídá riziku pro fyzické osoby.

ISO/IEC 27001:2022 poskytuje organizacím systém řízení, který tyto povinnosti propojuje. Kapitoly 4.1 až 4.4 vyžadují kontext, požadavky zainteresovaných stran, rozsah ISMS a vzájemně působící procesy. Kapitoly 5.1 až 5.3 vyžadují vedení, politiku, zdroje a přiřazené odpovědnosti. Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, výběr opatření, Prohlášení o použitelnosti a schválení vlastníkem rizika. Kapitoly 8.1 až 8.3 vyžadují řízený provoz, opětovné posouzení rizik při změnách, implementaci plánů ošetření rizik a uchovávání dokumentovaných výsledků.

Pro správu kryptografických klíčů musí ISMS odpovědět na pět otázek:

1. Která informační aktiva, datové toky a služby vyžadují kryptografickou ochranu?
2. Které klíče, certifikáty, tajné údaje a kryptografické služby je chrání?
3. Kdo tato kryptografická aktiva vlastní, spravuje, schvaluje a monitoruje?
4. Jak jsou řízeny generování, ukládání, používání, rotace, úschova, obnova, revokace a zničení?
5. Jaké důkazy prokazují, že opatření fungovala podle návrhu?

Osa opatření ISO 27001 pro správu kryptografických klíčů

Clarysec považuje správu kryptografických klíčů za řetězec opatření, nikoli za jedno samostatné opatření. V Zenith Controls: The Cross-Compliance Guide Zenith Controls se toto téma primárně mapuje na opatření 8.24 ISO/IEC 27002:2022, používání kryptografie, s důležitými podpůrnými vazbami na 5.17, autentizační informace, a 5.23, bezpečnost informací při využívání cloudových služeb.

Na této vazbě záleží. Selhání správy klíčů je málokdy jen „špatné šifrování“. Často jde o problém autentizace, problém cloudové governance, problém dodavatele, mezeru v protokolování nebo selhání řízení změn.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint toto převádí do provozní praxe ve fázi řízení rizik, krok 14, politiky ošetření rizik a regulační křížové odkazy. Vzor kryptografické politiky uvádí, že organizace má definovat, kde je kryptografie potřebná, schvalovat algoritmy a protokoly, vymezit správu klíčů, pokrýt případy použití, jako je šifrování celého disku a bezpečná komunikace, a propojit politiku s GDPR Article 32.

„Šifrovací klíče musí být bezpečně uloženy, například v trezoru klíčů nebo HSM, a přístup musí být omezen na autorizovaný personál.“
Zdroj: Zenith Blueprint, fáze řízení rizik, krok 14, politiky ošetření rizik a regulační křížové odkazy Zenith Blueprint

Ve fázi Opatření v praxi, krok 20, jde Zenith Blueprint hlouběji. Kryptografie není o „zapnutí šifrování“. Jde o zabudování kryptografie do návrhu, politiky a řízení životního cyklu. To zahrnuje data v klidu, data při přenosu, autentizaci identit a transakcí, schválené algoritmy, trezory klíčů, HSM, plánovanou rotaci, revokaci a validaci prostřednictvím penetračního testování a přezkumu kódu.

Co auditoři očekávají, když žádají důkazy ke klíčům

Většina zjištění auditu začíná jednoduchou žádostí: „Ukažte mi vaši šifrovací politiku a záznamy o správě klíčů.“

Slabé odpovědi zahrnují:

• „Poskytovatel cloudových služeb všechno šifruje ve výchozím nastavení.“
• „Používáme TLS.“
• „Tajné údaje jsou v trezoru.“
• „Rotaci řeší vývojový tým.“
• „Klíč spravuje aplikace.“

Tato tvrzení mohou být technicky pravdivá, ale nejsou úplným důkazem. Auditor ISO propojí správu klíčů zpět na posouzení rizik, Prohlášení o použitelnosti, požadavky politik, provozní řízení a uchovávanou dokumentaci. Hodnotitel NIST CSF se zeptá, zda jsou kryptografická aktiva identifikována, chráněna, monitorována a obnovitelná. Auditor DORA bude hledat řízení rizik ICT schválené vedoucím orgánem, závislosti na třetích stranách, řízení incidentů a testování odolnosti. Přezkum podle GDPR se zaměří na to, zda šifrování a oddělení klíčů snižují riziko pro fyzické osoby a zda správce dokáže prokázat odpovědnost.

Podniková Politika kryptografických opatření společnosti Clarysec Politika kryptografických opatření přímo řeší mezeru v důkazech:

„Musí být udržován centralizovaný registr správy klíčů, který zaznamenává všechny kryptografické klíče, jejich stav životního cyklu, přiřazené správce aktiv a kontexty použití.“
Zdroj: podniková politika, Politika kryptografických opatření, požadavky na správu a řízení, kapitola 5.2 Politika kryptografických opatření

Tato věta mění auditní rozhovor. Místo dohledávání neformálních znalostí může organizace předložit registr, který propojuje klíče s aktivy, vlastníky, klasifikací dat, systémy, cloudovými účty, daty rotace, kontexty použití a důkazy.

Pro malé a střední podniky škáluje Clarysec Politiku kryptografických opatření-sme Politika kryptografických opatření-sme – SME stejné očekávání:

„Poskytovatel IT podpory musí udržovat aktuální inventář používaných kryptografických nástrojů a certifikátů.“
Zdroj: politika pro malé a střední podniky, Politika kryptografických opatření-sme, požadavky na správu a řízení, kapitola 5.1.2 Politika kryptografických opatření-sme – SME

Regulovaná finanční instituce může potřebovat ceremonie HSM, rozdělenou znalost, dvojí kontrolu, formální jmenování správců aktiv a čtvrtletní přezkumy přístupových práv. Menší poskytovatel SaaS může začít udržovanou evidencí, schválenými algoritmy, dokumentovaným vlastnictvím KMS a důkazy o rotaci. Oba potřebují správu a řízení úměrné riziku.

Životní cyklus klíčů, který musí váš ISMS řídit

Praktický program správy klíčů sleduje životní cyklus. Každá fáze potřebuje vlastníka, schválenou metodu, technické opatření, záznam změny a auditní důkazy.

Podniková Politika kryptografických opatření posiluje bezpečné generování:

„Generování klíčů: provádí se pomocí bezpečných hardwarových nebo softwarových modulů, například HSM nebo systémů validovaných podle FIPS 140-2.“
Zdroj: podniková politika, Politika kryptografických opatření, požadavky na implementaci politiky, kapitola 6.3.1 Politika kryptografických opatření

Také stanoví rotaci:

„Rotace klíčů: vyžaduje se v definovaných intervalech nebo okamžitě při kompromitaci či změně role.“
Zdroj: podniková politika, Politika kryptografických opatření, požadavky na implementaci politiky, kapitola 6.3.4 Politika kryptografických opatření

Pro malé a střední podniky je stejný princip vyjádřen jednodušším provozním jazykem:

„Rotace klíčů musí probíhat v souladu s harmonogramy expirace nebo při podezření na kompromitaci.“
Zdroj: politika pro malé a střední podniky, Politika kryptografických opatření-sme, požadavky na implementaci politiky, kapitola 6.3.4 Politika kryptografických opatření-sme – SME

Tato ustanovení jsou pro NIS2 a DORA důležitá, protože zastaralé nebo nedostatečně řízené klíče nejsou pouze slabinami důvěrnosti. Mohou se stát překážkami reakce na incidenty, problémy závislosti na dodavatelích, selháními obnovy po havárii a problémy s oznamováním zákazníkům.

Cloudové KMS, HSM a BYOK: past sdílené odpovědnosti

Cloudové šifrování je jedním z nejčastějších zdrojů falešného ujištění. Poskytovatel cloudových služeb může šifrovat úložiště ve výchozím nastavení, ale to automaticky neznamená, že vaše organizace má klíč pod kontrolou.

Zenith Blueprint, fáze Opatření v praxi, krok 23, vysvětluje opatření 5.23 podle ISO/IEC 27002:2022 se zaměřením na cloudovou správu a řízení, viditelnost a sdílenou odpovědnost. Zdůrazňuje, že poskytovatel může zabezpečovat infrastrukturu, ale zákazník zůstává odpovědný za data, konfigurace, politiky přístupu a připravenost na reakci na incidenty.

„Poskytovatelé cloudových služeb zabezpečují infrastrukturu, ale vy stále odpovídáte za svá data, své konfigurace, své politiky přístupu a svou připravenost na reakci na incidenty.“
Zdroj: Zenith Blueprint, fáze Opatření v praxi, krok 23, organizační opatření 5.19-5.37 Zenith Blueprint

Právě zde se odpovědnost za cloudové klíče stává rizikem na úrovni vedoucího orgánu. Společnost SaaS může používat šifrování spravované poskytovatelem pro nízkorizikové logy, klíče spravované zákazníkem pro zákaznické databáze, BYOK pro regulované tenanty a kořenové klíče podpořené HSM pro podepisování nebo tokenizaci. Každá volba má dopady na soulad.

Podniková Politika používání cloudových služeb společnosti Clarysec Politika používání cloudových služeb poskytuje jasný směr kontrol:

„Klíče spravované zákazníkem (CMK) nebo Bring Your Own Key (BYOK) se použijí tam, kde je poskytovatel cloudových služeb podporuje.“
Zdroj: podniková politika, Politika používání cloudových služeb, požadavky na implementaci politiky, kapitola 6.4.2 Politika používání cloudových služeb

Neznamená to, že každá cloudová služba musí používat BYOK. Znamená to, že organizace musí rozhodovat záměrně na základě rizika, závazků vůči zákazníkům, smluvních požadavků a obnovitelnosti.

DORA Article 28 a Article 30 jsou pro finanční subjekty zvlášť relevantní. Vyžadují řízení rizik třetích stran v oblasti ICT, registry smluvních ujednání ICT, due diligence, práva na audit a inspekci, podporu při incidentech, ochranu dat a přístup, ustanovení o obnově a ukončení. Pokud poskytovatel cloudových služeb nebo dodavatel SaaS spravuje šifrovací klíče pro kritickou nebo důležitou funkci, musí být tento vztah viditelný v registru třetích stran v oblasti ICT a ve smluvních kontrolách.

NIS2 také vyžaduje zabezpečení dodavatelského řetězce, včetně zranitelností specifických pro dodavatele, postupů kybernetické bezpečnosti a postupů bezpečného vývoje. Pokud kritický dodavatel drží vaše klíče, provozuje vaše KMS, poskytuje vaše HSM, spravuje životní cyklus vašich certifikátů nebo hostuje šifrované zálohy, je tento dodavatel součástí vašeho prostředí kryptografických opatření.

Schvalování algoritmů a kryptoagilita v roce 2026

Politika správy klíčů v roce 2026 by neměla pouze uvádět „AES-256“ a „TLS 1.2 nebo novější“. Měla by zavést proces schvalování a přezkumu, který podporuje kryptoagilitu. Kryptoagilita znamená, že organizace dokáže identifikovat, kde se používají algoritmy, protokoly, certifikáty a délky klíčů, posoudit expozici vůči slabinám nebo zastarávání a migrovat bez paniky.

Politika Clarysec pro malé a střední podniky uvádí:

„Používat lze pouze algoritmy a protokoly odpovídající osvědčeným postupům v odvětví a schválené poskytovatelem IT podpory, například AES-256, RSA 2048, TLS 1.2 nebo novější.“
Zdroj: politika pro malé a střední podniky, Politika kryptografických opatření-sme, požadavky na implementaci politiky, kapitola 6.2.1 Politika kryptografických opatření-sme – SME

Vyžaduje také dokumentaci:

„Všechny metody šifrování, například AES-256, TLS 1.2+, a procesy správy klíčů musí být dokumentovány.“
Zdroj: politika pro malé a střední podniky, Politika kryptografických opatření-sme, požadavky na správu a řízení, kapitola 5.3.1 Politika kryptografických opatření-sme – SME

Auditně připravenou verzí je schválený kryptografický standard obsahující:

• Povolené algoritmy a protokoly pro data v klidu, data při přenosu, podpisy, hashování hesel, tokenizaci a zálohy.
• Zakázané algoritmy, protokoly a knihovny.
• Minimální délky klíčů a doby platnosti certifikátů.
• Schválené KMS, HSM, certifikační autority a platformy pro správu tajemství.
• Požadavky na bezpečné generování náhodných čísel.
• Pokyny pro vývojáře ke kryptografickým knihovnám.
• Proces výjimek pro starší systémy.
• Spouštěče přezkumu při zranitelnostech, regulačních změnách, změnách dodavatelů a plánování postkvantové transformace.

Postkvantové plánování nevyžaduje, aby každá organizace okamžitě nahradila veškerou kryptografii. Vyžaduje však evidenci. Bez kryptografické evidence nelze zjistit, které systémy používají dlouhodobé šifrování veřejným klíčem, které certifikáty chrání kritické služby, kde se nacházejí podpisové klíče ani kteří dodavatelé musí podporovat migraci. Registr správy klíčů není byrokracie. Je základem kryptoagility.

Devadesátiminutový sprint důkazů pro správu klíčů

Clarysec často používá krátký sprint důkazů s vedením, bezpečnostními, cloudovými a compliance týmy. Cílem je rychle převést roztříštěné znalosti o klíčích na auditní důkazy.

Krok 1: Vyberte jednu kritickou službu

Zvolte systém, který je relevantní pro NIS2, DORA nebo GDPR. Příklady zahrnují zákaznickou identitu, zpracování plateb, monitorování transakcí, produkční zákaznickou databázi, platformu šifrovaného zálohování nebo zákaznicky dostupné API.

Krok 2: Otevřete registr správy klíčů

Použijte požadavek Politiky kryptografických opatření na centralizovaný registr jako strukturu. Pokud jej ještě nemáte, vytvořte jednoduchý registr s těmito poli:

Krok 3: Sledujte přístup a dvojí kontrolu

U kryptografických operací s vysokým dopadem uplatněte dvojí kontrolu a zásadu minimálních oprávnění. Podniková Politika kryptografických opatření uvádí:

„Na citlivé kryptografické operace, například import kořenových klíčů nebo správu HSM, musí být uplatňovány principy dvojí kontroly a minimálních oprávnění.“
Zdroj: podniková politika, Politika kryptografických opatření, požadavky na implementaci politiky, kapitola 6.6.2 Politika kryptografických opatření

Zeptejte se:

• Kdo může klíč deaktivovat nebo smazat?
• Kdo může změnit politiku klíče?
• Kdo může data přímo dešifrovat?
• Jsou role nouzového přístupu „break-glass“ monitorované a časově omezené?
• Je pro privilegované operace s klíči vynucena MFA?
• Jsou privilegované akce protokolovány a přezkoumávány?

Krok 4: Získejte pět důkazních záznamů

Shromážděte pět záznamů, které prokazují, že opatření funguje:

1. Log vytvoření nebo importu klíče.
2. Aktuální politika přístupu ke KMS nebo HSM.
3. Poslední změnový tiket rotace klíče.
4. Dotaz v SIEM zobrazující použití klíče nebo administrátorské akce.
5. Důkaz o testu obnovy.

Krok 5: Namapujte na riziko a regulaci

Přidejte krátké vyjádření rizika: „Neoprávněné použití nebo ztráta tohoto klíče by mohly zpřístupnit osobní údaje z EU, narušit zákaznickou službu a zhoršit obnovu kritických systémů.“ Poté jej namapujte na příslušné povinnosti.

Za 90 minut tým obvykle dokáže zjistit, zda je správa a řízení klíčů skutečné, nebo pouze předpokládané.

Hlášení incidentů: kdy kompromitace klíče spouští lhůtu

Podezření na kompromitaci klíče není automaticky porušením podléhajícím oznámení, ale může spustit regulatorní lhůtu.

Podle NIS2 musí základní a důležité subjekty bez zbytečného odkladu oznamovat významné incidenty ovlivňující poskytování služeb. Fázový model zahrnuje včasné varování do 24 hodin od zjištění, oznámení incidentu do 72 hodin, aktualizace stavu na vyžádání a závěrečnou zprávu nejpozději jeden měsíc po oznámení incidentu.

Podle DORA musí finanční subjekty detekovat, řídit a oznamovat incidenty související s ICT, zaznamenávat incidenty a významné kybernetické hrozby, klasifikovat incidenty podle závažnosti a kritičnosti dotčené služby, komunikovat se zainteresovanými stranami, hlásit závažné incidenty vrcholovému vedení a příslušným orgánům, provést analýzu kořenové příčiny a zajistit nápravu. Outsourcing hlášení může být možný, odpovědnost však zůstává finančnímu subjektu.

Podle GDPR se otázka mění na to, zda došlo k porušení zabezpečení osobních údajů, tedy k náhodnému nebo protiprávnímu zničení, ztrátě, změně, neoprávněnému zpřístupnění nebo přístupu k osobním údajům. Silné šifrování s nekompromitovanými klíči může podstatně změnit analýzu rizika porušení. Slabá správa klíčů může tento argument podkopat.

Playbooky kompromitace klíčů musí definovat:

• Jak se detekuje podezření na expozici klíče.
• Kdo vyhlašuje kryptografický incident.
• Jak se identifikují dotčená data, služby, zákazníci a jurisdikce.
• Jak jsou klíče revokovány nebo rotovány.
• Jak jsou obnoveny závislé systémy.
• Jak je zachována integrita důkazů.
• Jak se přijímají právní, regulatorní a zákaznická rozhodnutí o oznámení.

Registr správy klíčů se během tohoto procesu stává nezbytným. Bez něj týmy reakce ztrácejí čas zjišťováním, co klíč chránil. S ním mohou rychle vymezit dopad.

Auditní pohled: jeden soubor opatření, mnoho příjemců důkazů

Různí auditoři přistupují ke správě kryptografických klíčů z různých odborných prostředí, ale sbíhají se u stejných důkazů.

Silný auditní balíček pro správu kryptografických klíčů obvykle obsahuje:

• Schválenou Politiku kryptografických opatření.
• Schválenou Politiku používání cloudových služeb, pokud je relevantní cloudové šifrování.
• Kryptografický standard a seznam algoritmů.
• Registr správy klíčů.
• Evidenci certifikátů a tajných údajů.
• Architekturu KMS, HSM a trezorů.
• Důkazy o přezkumu IAM a privilegovaných přístupů.
• Záznamy o rotaci a revokaci.
• Důkazy o zálohování, úschově a testech obnovy.
• Pravidla protokolování a monitorování aktivit klíčů.
• Mapování dodavatelů a sdílené odpovědnosti v cloudu.
• Incidentní playbook pro podezření na kompromitaci klíče.
• Výjimky a akceptace rizik.
• Záznamy z přezkoumání vedením a nápravných opatření z auditu.

Tento balíček převádí tvrzení o opatření na důkaz.

Častá zjištění při auditech správy klíčů

Nejčastějším zjištěním lze předejít:

1. Neexistuje jednotná evidence klíčů, certifikátů a kryptografických nástrojů.
2. Výchozí šifrování poskytovatele cloudových služeb je považováno za plnou správu a řízení klíčů.
3. Produkční klíče nemají přiřazeného vlastníka ani správce.
4. Rotace existuje pro certifikáty, ale ne pro aplikační klíče nebo databázové CMK.
5. Tajné údaje a klíče jsou smíchány ve stejném trezoru bez klasifikace.
6. Vývojáři mohou vytvářet klíče mimo schválené vzory.
7. Neexistují důkazy, že správci KMS jsou přezkoumáváni.
8. Postupy obnovy existují, ale nikdy nebyly otestovány.
9. Kompromitace klíče není zahrnuta v playboocích reakce na incidenty.
10. Starší algoritmy zůstávají v interních službách, protože nikdo nevlastní nápravu.
11. Závazky BYOK jsou sjednány v zákaznických smlouvách, ale nejsou promítnuty do provozu.
12. Šifrování spravované dodavatelem není zahrnuto v přezkumech rizik dodavatelů.

Každé zjištění se mapuje zpět na správu a řízení. Proto nelze kryptografii považovat za čistě inženýrský projekt. Musí být propojena s rozsahem ISMS, ošetřením rizik, politikami, dodavateli, cloudem, přístupem, protokolováním, incidenty a kontinuitou.

Připravte správu klíčů na audit před dalším incidentem

Pokud se vaše organizace připravuje na NIS2, DORA, důkazy podle GDPR Article 32, certifikaci ISO/IEC 27001:2022 nebo postkvantovou kryptoagilitu, začněte jednou otázkou: dokážete dnes předložit úplný registr správy klíčů?

Pokud ne, Clarysec vám může pomoci vybudovat kolem něj systém kontrol.

Použijte Zenith Blueprint Zenith Blueprint ke strukturování práce ve fázi řízení rizik, krok 14, a ve fázi Opatření v praxi, krok 20. Použijte Zenith Controls Zenith Controls k mapování opatření ISO/IEC 27002:2022 8.24, 5.17 a 5.23 napříč NIS2, DORA, GDPR, NIST a auditními očekáváními. Použijte Politiku kryptografických opatření společnosti Clarysec Politika kryptografických opatření, Politiku kryptografických opatření-sme Politika kryptografických opatření-sme – SME a Politiku používání cloudových služeb Politika používání cloudových služeb k převedení požadavků na provozní pravidla.

Praktický další krok je jednoduchý: vyberte jednu kritickou službu, zaevidujte její klíče, doložte vlastnictví, ověřte přístup, získejte důkazy o rotaci a otestujte obnovu. Pokud to trvá déle než jeden den, vaše správa a řízení kryptografie vyžadují pozornost dříve, než stejnou otázku pod tlakem položí regulátor, auditor nebo tým reakce na incidenty.