Co tato stránka je a co není
Stránka sleduje
skutečnou strukturu vyhlášky č. 409/2025 Sb. (3 části, 29 paragrafů, 6 příloh) pro režim vyšších povinností. U každého § uvádíme oficiální nadpis, naši stručnou parafrázi předmětu úpravy a samostatnou vysvětlivku CypherOn s praktickým dopadem.
Není to úřední znění ani úplný text vyhlášky. Pro definitivní formulaci a aktuální stav vždy ověřte v
e-Sbírce nebo na
zákony pro lidi. Pro nižší povinnosti existuje samostatná
vyhláška 410/2025 Sb.
Žádný paragraf neodpovídá hledanému výrazu.
Část první
Úvodní ustanovení
§ 1
Předmět právní úpravy
¶
Vyhláška upravuje obsah a způsob zavádění bezpečnostních opatření poskytovatele regulované služby v režimu vyšších povinností. Transponuje směrnici (EU) 2022/2555 (NIS 2).
Vysvětlivka CypherOn
Pokud spadáte do vyššího režimu (zařadila vás do něj NÚKIB rozhodnutím o registraci dle § 6 zákona), tato vyhláška je váš primární implementační dokument. Lhůta na zavedení opatření: 1 rok od registrace (§ 13 zákona) + přechodná lhůta § 28 této vyhlášky.
Definuje pracovní pojmy: uživatel, administrátor, primární a podpůrné aktivum, hodnocení rizik, systém řízení bezpečnosti informací (ISMS) a další.
Vysvětlivka CypherOn
Definice navazují na § 2 zákona, ale upřesňují technické termíny. Klíčové dělení primární aktivum (data, informace, procesy) vs podpůrné aktivum (HW, SW, sítě, lidé) určuje, jak strukturujete inventář aktiv (§ 7) a hodnocení rizik (§ 8).
Část druhá · Hlava I
Organizační opatření
§ 3
Systém řízení bezpečnosti informací
¶
Povinnost zavést a provozovat systém řízení bezpečnosti informací (ISMS) jako rámec pro stanovení cílů, řízení rizik a uplatňování přiměřených opatření v rozsahu řízení kybernetické bezpečnosti.
Vysvětlivka CypherOn
ISMS je „kostra" pro vyšší režim. V praxi vyhraďte rozsah ISMS v jednom dokumentu — co je v rozsahu a co ne. Mapujte na ISO 27001 Annex A kontroly — i když nejdete na ISO certifikaci, struktura je užitečná. ISMS funguje na principu PDCA (Plan-Do-Check-Act): roční plán, průběžná implementace a sledování, roční přezkum vedením (§ 4) — bez přezkumu vedením ISMS na auditu spadne.
§ 4
Požadavky na vrcholné vedení
¶
Odpovědnost statutárního orgánu / vedení za schvalování dokumentace, alokaci zdrojů, dohled nad ISMS a strategické rozhodování o rizicích.
Vysvětlivka CypherOn
Toto je kotva pro osobní odpovědnost statutárního orgánu dle § 33 a § 58 zákona. V praxi: statutární orgán musí prokazatelně schválit bezpečnostní strategii, dostávat periodické přehledy (kvartálně) a mít evidenci klíčových rozhodnutí v zápisech z představenstva. Pozor na D&O pojištění — standardní pojistky nekryjí porušení regulatorních povinností.
§ 5
Stanovení bezpečnostních rolí
¶
Určení rolí a jejich odpovědností: manažer kybernetické bezpečnosti (MKB), architekt KB, auditor KB, garant aktiva. Včetně požadavků na nezávislost a kvalifikaci.
Vysvětlivka CypherOn
Vyhláška jmenuje konkrétní role: manažer kybernetické bezpečnosti (MKB), architekt KB, auditor KB, garant aktiva. Klíčový princip: oddělení rolí. MKB nesmí být současně CIO ani IT vedoucím, který by schvaloval vlastní opatření — auditor / NÚKIB tuto kombinaci zpochybní. Auditor KB nesmí auditovat oblast, kterou sám provozuje (souvisí se § 16). Externí MKB (CISO-as-a-Service) je legitimní volba, ale musí mít smluvně zakotvenou kapacitu a SLA pro reaktivní situace + písemné pověření vedením. V praxi mnoho organizací doplňuje neformální „výbor pro řízení KB" jako rozhodovací orgán, ale to není zákonný požadavek vyhlášky.
§ 6
Řízení bezpečnostní politiky a bezpečnostní dokumentace
¶
Zpracování, schvalování, aktualizace, distribuce a evidence bezpečnostních politik, směrnic a podpůrné dokumentace ISMS.
Vysvětlivka CypherOn
Realisticky 8–12 dokumentů: zastřešující politika informační bezpečnosti, řízení přístupu, řízení změn, řešení incidentů, řízení dodavatelů, klasifikace dat, kryptografie, mobilní zařízení, řízení zranitelností. Doporučujeme strukturu: politika (co a proč, pro vedení) + standard (jak konkrétně, technické) + procedura (krok po kroku). Verzování + roční přezkum + strukturovaný protokol potvrzeného seznámení zaměstnanců: kdo, kdy a s jakou verzí dokumentu prokazatelně souhlasil — ne volný e-mail. Realisticky: HR systém s acknowledgement workflow nebo dedikované compliance nástroje (Vanta, Drata).
Identifikace, evidence, klasifikace a stanovení garantů primárních a podpůrných aktiv. Pravidla manipulace, přenosu a likvidace. Odkazy na Přílohu č. 1 (hodnocení aktiv) a Přílohu č. 2 (likvidace informací a dat).
Vysvětlivka CypherOn
Pro střední firmu 50–200 řádků v hlavní evidenci. Doporučujeme automatizovat HW/SW evidenci přes nástroj pro inventarizaci (Microsoft Intune, Lansweeper, Snipe-IT) a ručně udržovat business-level aktiva (procesy, klíčové datové sady, kritičtí dodavatelé). Klíčový atribut: garant aktiva (vlastník) — bez něj aktivum visí na MKB. Klasifikace v dimenzích důvěrnost / integrita / dostupnost (CIA) podle Přílohy č. 1.
Proces identifikace zranitelností a hrozeb, hodnocení rizik, plán zvládání rizik a jeho pravidelná revize. Odkazy na Přílohu č. 3 (zranitelnosti a hrozby) a Přílohu č. 4 (hodnocení rizik).
Vysvětlivka CypherOn
Praktická forma: tabulka v Excelu / SharePoint List / dedikovaný GRC nástroj. Pro každé riziko: ID, popis hrozby, dopady, pravděpodobnost, aktuální skóre, opatření, zbytkové skóre, vlastník, termín, stav. Autorita pro akceptaci zbytkového rizika musí být formálně definovaná: nízké riziko akceptuje MKB, střední vedení společnosti, vysoké statutární orgán — vždy s písemným záznamem. Strategie ošetření: zmírnit (zavést opatření), převést (pojištění, smluvně na dodavatele), vyhnout se (zrušit aktivitu), akceptovat (jen pro nízká rizika, po formálním schválení).
Hodnocení významnosti dodavatele, smluvní bezpečnostní požadavky, kontrola plnění a řízení rizik dodavatelského řetězce. Odkaz na Přílohu č. 5.
Vysvětlivka CypherOn
Klasifikace dodavatelů: kritický (výpadek = výpadek vaší služby) → roční bezpečnostní přezkum + smluvní právo auditu; významný → dvouletý přezkum + DPA / DPIA; standardní → smluvní DPA, bez aktivní kontroly. Příloha č. 5 dává vzor smluvních ustanovení. Modernější přístup jde dál než jednorázový dotazník — průběžné sledování (SecurityScorecard, BitSight) odhalí zhoršení stavu dodavatele mezi přezkumy. Pro software supply chain očekávejte SBOM (CycloneDX / SPDX) a u kritických komponent podepsané artefakty (SLSA, Sigstore).
§ 10
Bezpečnost lidských zdrojů
¶
Bezpečnostní povinnosti při náboru, nástupu, změně a ukončení pracovního poměru. Plán rozvoje bezpečnostního povědomí. Odkaz na Přílohu č. 6.
Vysvětlivka CypherOn
Realisticky: vstupní školení v rámci nástupu, roční školení bezpečnostního povědomí pro všechny zaměstnance (KnowBe4, Cofense, vzdělávací portál NÚKIB), specializovaná školení pro vývojáře (secure coding) a admin role (privileged access). Phishing simulace 2–4× ročně s eskalací. Off-boarding rozlišujte podle scénáře: privilegovaný účet + nedobrovolný odchod = odebrat v hodině, ideálně před oznámením; standardní + dobrovolný = ≤ 24 h. Měsíční audit aktivních účtů proti HR datům najde „zombie" účty.
Formalizovaný proces posouzení dopadu změn aktiv a procesů na bezpečnost, jejich schvalování, testování a dokumentace.
Vysvětlivka CypherOn
I lehký RFC proces v Jira / Linear / GitLab je lepší než ad-hoc změny. Pro většinu firem: PR review + ticket s checkboxy „bezpečnostní dopad / plán návratu / komunikace". Auditor se ptá: ukažte mi 5 posledních změn produkčního prostředí a jejich schválení. Pro vyšší režim doporučujeme Change Advisory Board (CAB) nebo ekvivalent pro významné změny.
§ 12
Akvizice, vývoj a údržba
¶
Bezpečnostní požadavky pro pořizování, vývoj a údržbu technických aktiv. Včetně Secure SDLC, oddělení vývoje / testu / produkce, řízení verzí.
Vysvětlivka CypherOn
Praktická sada nástrojů v CI/CD pro vlastní vývoj: SAST (Snyk Code, SonarQube, GitHub CodeQL), SCA (Snyk Open Source, Dependabot), skenování tajných klíčů (gitleaks, GitHub native), DAST (OWASP ZAP, Burp Suite Enterprise) na staging, skenování kontejnerů (Trivy, Snyk Container). Pre-commit hooks pro posun bezpečnosti na začátek vývoje (princip „shift-left" — najít zranitelnost při psaní kódu místo až v produkci). Klíčová pravidla: žádný admin přístup z dev VPN do prod, maskování / anonymizace dat pro testovací prostředí (ne kopie z prod), infrastructure-as-code s politikami jako kód (OPA, Sentinel) pro automatickou kontrolu shody.
Pravidla pro přidělování, kontrolu a odebírání přístupu uživatelů a administrátorů k aktivům. Principy nutné potřeby a oddělení rolí.
Vysvětlivka CypherOn
Doporučení: Microsoft Entra ID nebo Okta jako poskytovatel identit, SSO ke všem klíčovým aplikacím (přes SAML / OIDC), automatické provisioning přes SCIM. Pravidelná recertifikace privilegovaných účtů kvartálně, ostatních ročně. Conditional access pravidla: zařízení musí splňovat politiku (zapsané v MDM + nedávné ohlášení), blokovat starší autentizační protokoly (POP3 / IMAP / SMTP basic auth), geo-blokování pro státy mimo provoz, na základě rizika (vysoké riziko → výzva k MFA nebo blok). Zero trust není projekt na rok, je to architektura — zavádějte iteračně. Pro privilegované účty PAM (CyberArk, BeyondTrust, Microsoft PIM) s just-in-time elevací.
§ 14
Zvládání kybernetických bezpečnostních událostí a incidentů
¶
Proces detekce, klasifikace, hlášení (i NÚKIB), reakce, řešení, eskalace a poučení z incidentů.
Vysvětlivka CypherOn
Klíčové playbooky: ransomware, BEC / podvod, únik dat, DDoS, vnitřní hrozba, kompromitace dodavatelského řetězce. Pro každý: detekční signály, eskalační kontakty, prvotní kroky (max 4–6 bodů), rozhodovací matice (kdy zapojit právníka / komunikaci / NÚKIB / klienty). IRP = stručný runbook, ne dlouhý dokument. Lhůty hlášení (24h/72h/30d) plynou ze § 16 zákona. Praktická rada: připravte si předvyplněnou šablonu hlášení s IČO, kontakty, sektorem — v krizi nemáte čas tohle dohledávat.
§ 15
Řízení kontinuity činností
¶
Analýza dopadů (BIA), plány kontinuity a obnovy regulované služby, jejich testování a aktualizace.
Vysvětlivka CypherOn
Pro každý kritický proces: RTO (Recovery Time Objective — jak rychle musí běžet), RPO (Recovery Point Objective — kolik dat lze ztratit), scénáře (výpadek datacentra, ransomware, klíčový dodavatel mimo, pandemie). DR test min. 1× ročně end-to-end, pro klíčové systémy 2× ročně. Měsíční test obnovy vzorku dat ze záloh. Zálohy podle pravidla 3-2-1 + neměnná (immutable) kopie (např. Veeam Hardened Repository, AWS S3 Object Lock v compliance režimu) — online dostupné zálohy ransomware šifruje současně s produkcí, navíc moderní ransomware aktivně cílí na zálohovací infrastrukturu (krádež přihlašovacích údajů Veeam byl konkrétní vektor v 2024).
§ 16
Provádění auditu kybernetické bezpečnosti
¶
Pravidelné interní audity ISMS. Požadavky na nezávislost auditora, plánování, výstupy a opatření k nápravě.
Vysvětlivka CypherOn
Klíčový princip: auditor nesmí auditovat oblast, kterou sám provozuje. MKB tedy nemůže provádět audit ISMS, který sám řídí — buď zajistěte druhého kvalifikovaného interního auditora (typicky z funkce kvality nebo compliance), nebo audit zadejte externě. Roční plán pokrývající všechny domény ISMS po 2-letém cyklu. Nálezy: major (riziko ohrožení regulované služby), minor (mezera v procesu), pozorování (zlepšení). Každý nález má vlastníka, termín, stav. Pro externí audit doporučujeme přípravu s ročním předstihem: gap analýza, plán nápravy, pre-audit dry run 3 měsíce před oficiálním auditem.
Část druhá · Hlava II
Technická opatření
§ 17
Fyzická bezpečnost
¶
Ochrana fyzického perimetru, vstupů, prostor s aktivy a podpůrné infrastruktury (napájení, klimatizace) proti neoprávněnému přístupu a mimořádným událostem.
Vysvětlivka CypherOn
V cloud-first prostředí se fyzická bezpečnost často omezuje na ochranu kanceláří a notebooků. Klíčové: MDM s vynucenými politikami (šifrovaný disk, firewall, antivirus, zámek obrazovky), conditional access vázaný na compliance device, automatická inventarizace + vzdálené smazání (remote wipe). Notebooky šifrované od prvního zapnutí (BitLocker / FileVault / LUKS). Přístup do serverovny (pokud existuje) jen autorizovaným osobám, evidence návštěvníků v citlivých prostorech. Pro datacentra spoléhejte na certifikace dodavatele (SOC 2 Type II, ISO 27001).
§ 18
Bezpečnost komunikačních sítí
¶
Segmentace, řízení toku dat, ochrana perimetru sítě, zabezpečení vzdáleného přístupu a bezdrátových přenosů.
Vysvětlivka CypherOn
Klíčové zóny: internet ↔ DMZ ↔ vnitřní aplikace ↔ databáze, oddělená správní VLAN jen z bastion hostů, guest WiFi izolovaná. V cloudu mikrosegmentace přes security groups / network policies. Roční přezkum firewall pravidel — odstraňte zapomenutá „temporary allow ANY" pravidla, která tam zůstala 5 let. Pro vyšší režim v multi-cloud prostředí zvažte CNAPP (Cloud-Native Application Protection Platform — Wiz, Prisma Cloud, Defender for Cloud) jako sjednocující vrstvu CSPM + CWPP + CIEM.
§ 19
Správa a ověřování identit
¶
Pravidla pro správu identit uživatelů a administrátorů. Požadavky na autentizaci včetně vícefaktorové (MFA) a správu hesel.
Vysvětlivka CypherOn
MFA na admin účtech, VPN, RDP, cloud konzoli a e-mailu. Pro privilegované role phishing-resistant MFA (FIDO2 / WebAuthn / hardware klíč) jako primární faktor — SMS a TOTP jsou stále lepší než nic, ale proti pokročilému phishingu / AiTM nejsou dostatečné. Pro nouzový (break-glass) admin: hardware token + offline PIN + uložení v sejfu. SMS MFA jen jako záložní metoda — výměna SIM karty je reálné riziko. Pro M365/Entra prostředí přidejte vrstvu ITDR (Identity Threat Detection & Response — Defender for Identity, Falcon Identity Protection, Semperis): klasický IAM stack předpokládá, že IdP je důvěryhodný kořen, ale moderní útoky cílí přímo na něj (krádež tokenů, OAuth consent phishing, AiTM po MFA).
§ 20
Řízení přístupových práv a oprávnění
¶
Přidělování, dokumentace, periodická revize a odebírání oprávnění. Oddělení provozního a privilegovaného účtu.
Vysvětlivka CypherOn
Praktická realizace: RBAC přes role (sales, marketing, dev, admin) místo individuálních přidělení. Separované admin účty (jan@ pro běžnou práci, jan-admin@ pro IT operace). Recertifikace 1× ročně review aktivních účtů a oprávnění. Identifikujte „accumulators" (lidé, kteří přibrali oprávnění napříč rolemi přes léta) — typický slabý článek. Pro privilegované role just-in-time elevation místo trvalého přístupu, session recording pro kritické operace, vault pro servisní účty (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault).
§ 21
Detekce kybernetických bezpečnostních událostí
¶
Nasazení nástrojů sledování, IDS/IPS, antimalware a obecně schopnost včas detekovat anomálie a incidenty.
Vysvětlivka CypherOn
EDR / XDR na všech koncových stanicích a serverech. Volba podle prostředí: Microsoft Defender for Endpoint (cena a integrace v M365 stacku), CrowdStrike Falcon (špička detekce, ale dražší), SentinelOne, ESET (česky mluvící podpora). Telemetrie centralizovaná, alerting napojen na SOC nebo MDR. Detekční pravidla mapovaná na MITRE ATT&CK framework — to vám umožní měřit detection coverage a identifikovat slepá místa. Pro essential entity by měla být detekční schopnost s 24/7 pokrytím — interní SOC, MSSP, nebo hybridní model.
§ 22
Zaznamenávání událostí
¶
Povinnosti vytváření, ochrany před modifikací a uchovávání bezpečnostních a provozních záznamů (logů) po stanovenou dobu.
Vysvětlivka CypherOn
Centralizovaný sběr ze všech relevantních zdrojů (AD/Entra, EDR, firewall, e-mailová brána, cloud audit logs, aplikační logy). Retence víceúrovňově: hot (rychle dostupné) ≥ 90 dnů, warm 12 měsíců, archiv 2–3 roky podle sektoru a regulace. Integrita logů je klíčová — útočníci se snaží logy mazat: použijte WORM / append-only úložiště (S3 Object Lock, Azure Immutable Blob, Splunk SmartStore append-only) a hash-chain ověřování.
§ 23
Vyhodnocování kybernetických bezpečnostních událostí
¶
Korelace a analýza záznamů, postupy vyhodnocení a předávání výstupů do procesu zvládání incidentů (§ 14).
Vysvětlivka CypherOn
Volba SIEM: Microsoft Sentinel (platba za GB, dobrá integrace), Splunk (nejvíc možností, drahé), Elastic Security (open-core), Wazuh (open-source). Detekční pravidla + SOAR playbooky. Mějte minimálně tyto případy užití: nemožné cestování, eskalace oprávnění, brute force, únik dat, známé škodlivé IP. Pravidla spravujte jako kód — Sigma rules v Gitu, CI/CD pipeline pro nasazení do SIEM (detection-as-code).
§ 24
Aplikační bezpečnost
¶
Bezpečnostní požadavky na aplikace a webové služby (validace vstupů, ochrana proti známým útokům, bezpečnostní testování).
Vysvětlivka CypherOn
Pro vývoj odkazujeme na § 12 (Secure SDLC). V provozu: WAF na vystavených webech, OWASP ZAP / Burp Suite pro pravidelné skenování, bug bounty program nebo penetrační testy 1–2× ročně. Runtime ochrana kontejnerů — SAST/SCA/SBOM řeší build-time, ale produkční kontejner potřebuje vlastní detekční vrstvu: Falco nebo Tetragon (eBPF-based detekce neobvyklých syscallů a procesů), Wiz Runtime Sensor, Sysdig Secure, Defender for Cloud runtime.
§ 25
Kryptografické algoritmy
¶
Používání důvěryhodných algoritmů, řízení klíčů, ochrana přenosu i uložených dat. Soulad s pravidly NÚKIB pro kryptografii.
Vysvětlivka CypherOn
Současný výchozí stav (2025–2026): symetrické AES-256-GCM; asymetrické RSA ≥ 3072 nebo ECC P-256+; hash SHA-256 a vyšší (NIKDY MD5 ani SHA-1); TLS 1.2 minimum, 1.3 preferováno. Post-quantum kryptografie přestala být teorií — NIST v srpnu 2024 finalizoval FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) a FIPS 205 (SLH-DSA). Pro essential entity doporučujeme do roku 2026: inventarizace kryptografických aktiv, kryptografická pružnost v designu (možnost vyměnit algoritmus bez přepisu aplikace), hybridní KEM (klasický + ML-KEM) pro data s dlouhou dobou důvěrnosti — kvůli „Harvest Now, Decrypt Later" útokům. Klíče v cloud KMS (AWS KMS, Azure Key Vault, GCP KMS) nebo HSM. Rotace: TLS certifikáty trend zkracování — CA/Browser Forum schválil v dubnu 2025 postupné snížení maximální životnosti veřejných TLS certifikátů (398 → 200 → 100 → 47 dnů) do 15. března 2029, takže plná automatizace přes ACME je už dnes nutnost; SSH / API klíče ≤ 90 dnů pro automatizaci, ≤ 1 rok pro lidské.
§ 26
Zajišťování dostupnosti regulované služby
¶
Opatření proti přetížení, redundance, ochrana proti DDoS a obecně udržení dostupnostních cílů služby.
Vysvětlivka CypherOn
Praktická minima: redundance kritických komponent (HA pro DB, load balancer + 2+ aplikační servery), CDN s DDoS ochranou (Cloudflare, Akamai, AWS Shield), DNS s anycast a failoverem, SLA monitoring s alerty. Pro vyšší režim počítejte s formálním monitorováním dostupnosti (SLA dashboard, MTTR/MTBF reporting do statutárního orgánu). Pro strategicky významné služby viz § 33 zákona — dostupnost z území ČR.
§ 27
Zabezpečení průmyslových, řídících a podobných specifických technických aktiv
¶
Specifika pro OT/ICS prostředí — segmentace od IT, sledování, omezení vzdáleného přístupu, zachování provozní bezpečnosti.
Vysvětlivka CypherOn
OT prostředí (průmyslové řídící systémy — SCADA, DCS, PLC) je mimo rozsah většiny IT-zaměřených doporučení v této vyhlášce — IT nástroje (EDR, MDM) na PLC a HMI nefungují. Pro OT/ICS držte se norem IEC 62443 (v ČR ČSN EN 62443) a NIST SP 800-82. Specializovaní dodavatelé sledování OT: Claroty, Nozomi Networks, Dragos, Tenable.OT. Klíčové principy: Purdue model pro segmentaci, jednosměrné brány (data diody) mezi OT a IT zónou, pasivní sledování bez aktivního skenování (asset discovery na PLC může způsobit výpadek), řízení změn jen v plánovaných servisních oknech (firmware PLC nikdy neaktualizujte ad-hoc — vždy s plánem návratu a ověřením v testovacím prostředí). Pokud máte OT prostředí, doporučujeme samostatný OT bezpečnostní program s vlastní governance — IT MKB obvykle OT plně nepokryje.
Část třetí
Přechodná a závěrečná ustanovení
§ 28
Přechodná ustanovení
¶
Lhůta (cca 1 rok) pro uvedení stávajících systémů, dokumentace a procesů do souladu s vyhláškou. Do té doby se postupuje podle dosavadních pravidel.
Vysvětlivka CypherOn
Pokud jste byli regulovaní podle staré vyhlášky 82/2018 Sb. (která byla zrušena § 72 zákona), máte přechodnou dobu na zavedení nových opatření z 409/2025. Aktualizujte interní dokumentaci, odkazy v politikách (z 82/2018 na 409/2025) a plánujte gap analýzu vůči novým strukturálním změnám.
Vyhláška nabývá účinnosti dnem 1. listopadu 2025.
Vysvětlivka CypherOn
Společně se zákonem 264/2025 Sb. a vyhláškou 410/2025 Sb. (nižší). Lhůty pro zavádění opatření plynou z § 13 odst. 4 zákona (1 rok od registrace) a § 28 této vyhlášky.
Příloha č. 1
Hodnocení aktiv
¶
Metodika pro stanovení úrovní (klasifikace) primárních i podpůrných aktiv podle důvěrnosti, integrity a dostupnosti.
Vysvětlivka CypherOn
Praktická škála pro střední firmu: C (důvěrnost): veřejné / vnitřní / důvěrné / přísně důvěrné; I (integrita): standardní / vysoká / kritická; A (dostupnost): nízká / standardní / vysoká / 24/7. Z klasifikace se odvozují konkrétní opatření: šifrování (C ≥ důvěrné = at-rest), zálohování (A vysoká = denní), MFA (C důvěrné = MFA povinná). Klasifikujte na úrovni úložišť / kategorií, ne každý dokument zvlášť.
Příloha č. 2
Likvidace informací a dat
¶
Pravidla a způsoby bezpečné likvidace nosičů a dat odpovídající úrovni klasifikace aktiv.
Vysvětlivka CypherOn
Pro důvěrná data: kryptografické vymazání (rotace klíčů → původní data nečitelná), fyzická destrukce nosičů u nejcitlivějších (degausser, drcení). Pro běžná data postačí standardní formát (ATA Secure Erase pro SSD/HDD). Mějte certifikát o likvidaci od dodavatele — auditor se ptá, jak jste prokazatelně zlikvidovali data ze zařízení vyřazených před 2 lety.
Příloha č. 3
Zranitelnosti a hrozby
¶
Referenční katalog typových zranitelností a hrozeb používaný při identifikaci rizik podle § 8.
Vysvětlivka CypherOn
Vyhláška dává startovní katalog. V praxi jej rozšiřte o aktuální threat intelligence (CISA KEV, MITRE ATT&CK, sledované advisories NÚKIB / CSIRT.cz). Doporučujeme udržovat „top 20" hrozeb relevantních pro váš sektor a ročně je revidovat — threat landscape se mění.
Příloha č. 4
Hodnocení rizik
¶
Metodika pro analýzu a hodnocení rizik (pravděpodobnost × dopad) a stanovení akceptovatelné úrovně rizika.
Vysvětlivka CypherOn
Doporučujeme vycházet z metodiky vyhlášky a doplnit principy ISO 27005. Klíčové dimenze: pravděpodobnost (1–5), dopad (1–5 — finanční, reputační, právní, provozní), akceptační kritérium (typicky skóre rizika ≥ 12 nelze akceptovat bez schválení statutárního orgánu).
Příloha č. 5
Řízení dodavatelů — bezpečnostní opatření pro smluvní vztahy
¶
Vzorový rozsah bezpečnostních ustanovení a požadavků pro smlouvy s dodavateli regulované služby.
Vysvětlivka CypherOn
Smluvní balíček, který by měl být součástí každé klíčové dodavatelské smlouvy: definice incidentu, lhůta hlášení (typicky 24 h), obsah hlášení, právo auditu po incidentu, sankce za nehlášení, klauzule o ukončení, povinnosti při subdodávkách, ustanovení o předání dat a logů (návaznost na § 24 zákona). Pro mezinárodní dodavatele (přenos osobních údajů mimo EU) doplňte SCC nebo BCR.
Příloha č. 6
Témata pro rozvoj bezpečnostního povědomí
¶
Doporučený obsah školení a osvěty pro uživatele, administrátory a osoby v bezpečnostních rolích.
Vysvětlivka CypherOn
Vyhláška dává seznam témat — phishing a sociální inženýrství, zabezpečení zařízení a hesel, MFA, cloud, e-mailová komunikace, BYOD, oznamování incidentů, aktuální hrozby. Pokrytí běžnými programy: KnowBe4, Cofense, vzdělávací portál NÚKIB. Měřte míru kliknutí na phishing — cíl < 5 % po 12 měsících programu. Specializovaná školení: pro vývojáře (secure coding), finance (BEC awareness), vedení (governance, rozhodování v incidentech).