Klasifikace dat pro ISO 27001, GDPR, NIS2 a DORA

Auditní okamžik roku 2026: „Ukažte mi důkazy“
Je únor 2026 a čtvrtletní jednání představenstva v rychle rostoucí fintech SaaS společnosti neprobíhá tak hladce, jak CISO očekával.
Společnost nedávno získala certifikaci ISO/IEC 27001:2022. Má zavedenou MFA, ochranu koncových bodů, skenování zranitelností, přezkumy přístupových práv, postupy reakce na incidenty a propracovanou zprávu o připravenosti na DORA. Poté generální ředitel položí otázku, která změní atmosféru v místnosti.
„Náš hlavní investor se ptá, jak dokážeme prokázat, že finanční data zákazníků jsou konzistentně chráněna napříč AWS, Azure, naší SaaS platformou podpory a analytickým datovým skladem. Pokud auditor vybere jeden soubor z objektového úložiště a druhý ze sdílené složky pro spolupráci, jak víme, že se na ně vztahují stejná pravidla?“
CISO otevře registr aktiv. Ten obsahuje databáze, cloudové účty, aplikace, SaaS platformy a úložiště. Pole klasifikace je však neúplné. Některé složky jsou pojmenovány podle oddělení, nikoli podle citlivosti. Exporty zákaznických dat leží vedle interních reportovacích souborů. Některé podpůrné tabulky obsahují identifikátory zákazníků, platební reference a poznámky k případům, ale jsou označeny jako „interní“. Pravidla DLP existují, ale spouštějí se pouze při zjevných vzorech. Cloudová politika stanoví, že osobní údaje z EU musí zůstat ve schválených regionech, ale tým nedokáže doložit, že pravidla pro umístění dat jsou řízena klasifikačními metadaty.
Poté manažer compliance doplní regulační pohled: „Bude to stačit pro článek 32 GDPR, článek 21 NIS2 a důkazy o řízení rizik v oblasti ICT podle DORA?“
Upřímná odpověď zní: zatím ne.
Právě této mezeře v roce 2026 čelí mnoho organizací. Mají bezpečnostní opatření, ale chybí jim vrstva správy a řízení, která každému opatření říká, co má chránit, jak silně to má chránit a jak to prokázat. Touto vrstvou správy a řízení je klasifikace dat a označování informací.
V terminologii ISO/IEC 27001:2022 nejsou klasifikace a označování kosmetickými postupy správy dokumentů. Jsou praktickým propojením mezi posouzením rizik, řízením přístupu, šifrováním, uchováváním, DLP, umístěním dat v cloudu, due diligence dodavatelů, monitorováním a hlášením incidentů. V implementačním modelu Clarysec stojí uprostřed důkazního řetězce ISMS: zaevidovat aktivum, přiřadit vlastníka, klasifikovat je, označit je, uplatnit pravidla nakládání, monitorovat výjimky a auditorům ukázat dohledatelnost.
Proč jsou klasifikace a označování nyní opatřeními na úrovni řídicích orgánů
Regulační orgány i zákazníci stále častěji očekávají, že organizace prokážou, že bezpečnostní opatření odpovídají citlivosti dat, kritičnosti služby a obchodním dopadům selhání.
GDPR to výslovně stanoví prostřednictvím zásady odpovědnosti. Článek 5 vyžaduje, aby osobní údaje byly zpracovávány zákonně, korektně a transparentně, omezeny na nezbytný rozsah, uchovávány pouze po nezbytnou dobu a chráněny odpovídajícími technickými a organizačními opatřeními. Správce musí být zároveň schopen soulad doložit. Článek 32 GDPR je obtížné doložit bez znalosti toho, které systémy zpracovávají osobní údaje, která data jsou vysoce riziková nebo patří do zvláštní kategorie, kde jsou uložena a která ochranná opatření se na ně vztahují.
NIS2 zvyšuje nároky na správu a řízení. Článek 20 vyžaduje, aby řídicí orgány základních a důležitých subjektů schvalovaly opatření pro řízení kybernetických rizik, dohlížely na jejich implementaci a absolvovaly školení. Článek 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, bezpečnostních politik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečnosti při pořizování a vývoji, posouzení účinnosti, kybernetické hygieny, školení, kryptografie, personální bezpečnosti, řízení přístupu a správy aktiv. Klasifikace v tomto seznamu není samostatnou kontrolní položkou. Je to rozhodovací systém, díky němuž jsou tato opatření přiměřená.
DORA uplatňuje stejnou logiku na finanční subjekty a fintech ekosystémy. Od 17. ledna 2025 DORA vyžaduje dokumentovaný rámec řízení rizik v oblasti ICT, odpovědnost řídicího orgánu, politiky pro důvěrnost, integritu, dostupnost a autenticitu, klasifikaci incidentů, testování odolnosti a řízení rizik třetích stran v oblasti ICT. Pro finanční subjekty regulované DORA může DORA fungovat jako odvětvový právní akt Unie nahrazující překrývající se povinnosti NIS2 v oblasti řízení rizik a hlášení, očekávání ohledně důkazů však zůstává stejné: ukažte, jak jsou kritické informace a aktiva ICT identifikovány, chráněny, testovány, monitorovány a spravovány.
ISO/IEC 27001:2022 se pro tyto důkazy dobře hodí jako provozní systém. Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměla interním a externím otázkám, požadavkům zainteresovaných stran, regulačním a smluvním povinnostem a rozhraním s jinými organizacemi. Kapitoly 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, výběr bezpečnostních opatření, Prohlášení o použitelnosti a uchovávané důkazy. ISO/IEC 27001:2022
Pokud se GDPR, NIS2 a DORA ptají: „Proč jste tato opatření uplatnili?“, ISO/IEC 27001:2022 pomáhá odpovědět: „Protože nás k tomu dovedla tato aktiva, datové typy, rizika, povinnosti a rozhodnutí o ošetření rizik.“
Klasifikace je rozhodnutí o riziku. Označování je provozní signál.
Clarysec odděluje klasifikaci a označování, protože auditoři je oddělují také.
Klasifikace je rozhodnutí o citlivosti, hodnotě a kritičnosti informací. Označování toto rozhodnutí činí viditelným, trvalým a vymahatelným v každodenním provozu.
Clarysec Politika klasifikace dat a označování pro SME formuluje účel jasně:
Tato politika definuje, jak musí být všechny informace zpracovávané organizací klasifikovány a označovány, aby byla po celý jejich životní cyklus zachována jejich důvěrnost, integrita a dostupnost.
Stejná Politika klasifikace dat a označování pro SME vyžaduje, aby organizace:
Vyžadovala klasifikaci každého datového aktiva podle jeho citlivosti a odpovídající označení, které určuje správné nakládání, ukládání a přístup.
Pro podniková prostředí definuje Clarysec P13 Politika klasifikace dat a označování minimální klasifikační model:
Organizace musí udržovat standardizované klasifikační schéma s jasně definovanými úrovněmi. Minimálně musí být používány následující klasifikační stupně: 5.1.1 Veřejné: informace určené k otevřenému zveřejnění a neomezené distribuci 5.1.2 Interní: neveřejné informace organizace, které nejsou určeny k externímu zveřejnění 5.1.3 Důvěrné: citlivá obchodní, smluvní nebo zákaznická data vyžadující přísné řízení přístupu 5.1.4 Vyhrazené (nebo Vysoce důvěrné): kritické nebo regulované informace, u nichž by neoprávněné zpřístupnění mohlo vést k významné újmě nebo právní odpovědnosti
Na tomto rozlišení záleží. Klasifikace „Důvěrné“ může vyžadovat šifrování, přístup na základě rolí a smluvní ochranná opatření. Klasifikace „Vyhrazené“ může spustit MFA, schválení CISO pro externí sdílení, rozšířené protokolování, přísnější správu uchovávání, oddělení a prioritní eskalaci incidentu.
Podniková politika výslovně řeší provozní označování:
Všechna informační aktiva musí být označena způsobem, který je: 6.2.1.1 Trvalý: nelze jej snadno odstranit nebo přepsat 6.2.1.2 Viditelný: jasný pro uživatele v místě použití 6.2.1.3 Strojově čitelný: tam, kde je to možné, musí být podporováno označování pomocí metadat
Strojově čitelné štítky jsou bodem, kde program přechází od povědomí k prosazování. Pokud jsou štítky založeny na metadatech, mohou na ně reagovat cloudové platformy, systémy DLP, e-mailové brány, nástroje pro správu identit, pravidla SIEM, platformy CASB a retenční nástroje. Pokud jsou štítky pouze zápatím v dokumentu, mohou uživatelům pomoci, ale nedokážou spolehlivě prosazovat pravidla ve velkém měřítku.
Kam klasifikace patří v roadmapě Clarysec
Clarysec Zenith Blueprint: 30kroková roadmapa auditora umisťuje klasifikaci do rané fáze životního cyklu řízení rizik, nikoli až po nasazení technologií. Ve fázi řízení rizik, v kroku 9 „Identifikace aktiv, hrozeb a zranitelností“, roadmapa vede týmy k evidenci informačních aktiv a zaznamenání vlastníka, umístění a klasifikace.
Tím se předchází častému selhání: organizace má cloudovou evidenci, ale nemá evidenci informací. Databáze, tenant služby SaaS nebo datový sklad jsou technologická aktiva. Zákaznické záznamy, zaměstnanecké spisy, platební logy, datové sady pro trénování modelů, přepisy komunikace podpory a důkazy incidentů uvnitř nich jsou informační aktiva. Klasifikace existuje právě na této informační úrovni.
Pokyny Zenith Blueprint k opatření ISO/IEC 27002:2022 5.12, Klasifikace informací, vysvětlují princip:
Každé opatření bezpečnosti informací, omezení přístupu, šifrování, zálohování, monitorování nebo likvidace, které kdy bylo napsáno, předpokládá jednu věc: že organizace ví, co chrání. Opatření 5.12 vyžaduje, aby informace byly klasifikovány na základě své hodnoty, citlivosti a kritičnosti, čímž vzniká základ pro všechna následná rozhodnutí v rámci ISMS.
U opatření ISO/IEC 27002:2022 5.13, Označování informací, tatáž roadmapa převádí klasifikaci do každodenního chování:
Označování je způsob, jak převést abstraktní politiku do provozní reality. Je to okamžik, kdy uživatel při pohledu na dokument, e-mail, databázové pole nebo tištěnou zprávu okamžitě pozná: co tato informace je, jak je citlivá a jak s ní má být nakládáno.
Poslední vazba v roadmapě se objevuje v kroku 13 „Plánování ošetření rizik a Prohlášení o použitelnosti“. Zenith Blueprint popisuje SoA jako most mezi riziky, ošetřením a opatřeními. Právě zde se klasifikace stává auditní dohledatelností. Rizikový scénář, například „neoprávněné zpřístupnění finančních dat zákazníků ze sdíleného cloudového úložiště“, lze namapovat na klasifikaci, označování, řízení přístupu, šifrování, protokolování, DLP, používání cloudu, požadavky na dodavatele a reakci na incidenty.
Vazby mezi opatřeními, které auditoři očekávají
V Clarysec Zenith Controls: průvodce napříč požadavky souladu je opatření ISO/IEC 27002:2022 5.12, Klasifikace informací, namapováno jako preventivní opatření podporující důvěrnost, integritu a dostupnost. Je spojeno s funkcí kybernetické bezpečnosti Identify, provozní schopností Information Protection a bezpečnostními doménami Protection and Defense.
U opatření ISO/IEC 27002:2022 5.13, Označování informací, Zenith Controls mapuje opatření jako preventivní, zaměřené na Protect, se stejnými vlastnostmi bezpečnosti informací a provozní schopností Information Protection.
Klíčové zjištění je, že klasifikace a označování nejsou izolované. Díky nim jsou okolní opatření obhajitelná.
| Oblast opatření ISO/IEC 27002:2022 | Proč závisí na klasifikaci nebo označování | Důkazy, které může auditor požadovat |
|---|---|---|
| 5.9 Evidence informací a dalších souvisejících aktiv | Klasifikační metadata mají být základním polem v evidenci aktiv | Registr aktiv s vlastníkem, umístěním, stavem životního cyklu a klasifikací |
| 5.12 Klasifikace informací | Definuje citlivost, hodnotu a kritičnost | Schválené klasifikační schéma, kritéria, příklady a záznamy o přezkumu |
| 5.13 Označování informací | Zviditelňuje klasifikaci a umožňuje její prosazování | Konfigurace štítků, vzorky označených souborů, e-mailové štítky, SaaS značky a pokyny pro uživatele |
| 5.14 Přenos informací | Určuje, zda je vyžadováno schválení externího sdílení, šifrování nebo další kontrola | Pravidla přenosu podle klasifikace, schválené kanály a záznamy o výjimkách |
| 5.15 Řízení přístupu | Přístupová oprávnění mají respektovat hranice klasifikace | Matice rolí, přezkumy přístupových práv, pravidla privilegovaného přístupu a historie schválení |
| 5.25 Posouzení a rozhodnutí o událostech bezpečnosti informací | Závažnost incidentu částečně závisí na citlivosti dotčených dat | Kritéria třídění incidentů využívající klasifikaci a kritičnost služby |
| 5.34 Soukromí a ochrana osobně identifikovatelných údajů (PII) | Kategorie osobních údajů potřebují specifické nakládání z hlediska ochrany soukromí | Registr PII, mapování právního základu, pravidla uchovávání a kontroly zpracovatele |
| 8.15 Protokolování | Přístup k datům klasifikovaným jako Vyhrazené vyžaduje silnější dohledatelnost | Logy přístupu k datům, nastavení uchovávání logů a důkazy o přezkumu |
| 8.16 Monitorovací činnosti | Priorita monitorování se mění, když jsou dotčena data klasifikovaná jako Vyhrazené | Případy použití SIEM, prahové hodnoty upozornění a eskalační záznamy |
Zenith Controls mapuje opatření 5.12 na článek 32 GDPR a bod odůvodnění 83, článek 21(2)(a) a 21(2)(f) NIS2, ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 a PM-11, FIPS 199 a NIST SP 800-60 a COBIT 2019 DSS06.06 a APO13.01. Opatření 5.13 mapuje na článek 32 GDPR, článek 21(2)(a) a 21(2)(f) NIS2, článek 9(1) a 9(2) DORA, NIST SP 800-53 MP-3 a COBIT 2019 DSS06.06.
To znamená, že jedna sada důkazů může odpovědět na více ověřovacích otázek.
| Požadavek souladu | Přínos klasifikace a označování | Praktický důkaz |
|---|---|---|
| Článek 32 GDPR | Ukazuje, které osobní údaje vyžadují ochranná opatření pro důvěrnost, integritu, dostupnost a odolnost | Klasifikace PII, pravidla šifrování, omezení přístupu, mapování uchovávání a kritéria třídění porušení zabezpečení |
| Článek 21 NIS2 | Podporuje analýzu rizik, bezpečnostní politiky, posouzení účinnosti, řízení přístupu, správu aktiv a přiměřená opatření | Politika schválená vedením, evidence aktiv, školení, metriky přezkumu a otestovaná pravidla nakládání |
| Řízení rizik v oblasti ICT podle DORA | Podporuje identifikaci a ochranu informací a aktiv ICT, klasifikaci incidentů a řízení rizik třetích stran v oblasti ICT | Registr aktiv ICT, kritičnost dat, smluvní požadavky na dodavatele, rozsah testování a kritéria závažnosti incidentů |
| NIST CSF 2.0 | Podporuje výstupy GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER | Aktuální a cílové profily s mezerami v klasifikaci a prioritizovanými nápravnými opatřeními |
| COBIT 2019 | Podporuje správu a procesní kontroly pro bezpečnost, nakládání s daty a provozní účinnost kontrol | Cíle kontrol, vlastnictví procesů, testování ujištění a správa výjimek |
Registr aktiv je místo, kde se klasifikace stává důkazem
Mnoho klasifikačních programů selhává proto, že klasifikační schéma existuje pouze v politice. Přístup Clarysec začíná evidencí aktiv.
Clarysec P12 Politika správy aktiv vyžaduje, aby evidence aktiv zahrnovala úroveň klasifikace jako minimální pole:
Evidence aktiv musí minimálně obsahovat: 5.3.1 Identifikátor aktiva, kategorii a typ 5.3.2 Sériové číslo nebo jedinečný štítek (u fyzických aktiv) 5.3.3 Verzi softwaru nebo licenční klíč (u softwarových aktiv) 5.3.4 Vlastník aktiva 5.3.5 Úroveň klasifikace (Veřejné, Interní, Důvěrné, Vyhrazené) 5.3.6 Umístění (fyzické, virtuální, cloudové) 5.3.7 Stav životního cyklu (aktivní, v údržbě, vyřazené)
To přímo navazuje na plánování rizik podle ISO/IEC 27001:2022. Pokud nedokážete identifikovat informační aktivum, jeho vlastníka, umístění a klasifikaci, nemůžete konzistentně posoudit pravděpodobnost, dopad, prioritu ošetření ani zbytkové riziko. Nemůžete také spolehlivě rozhodnout, zda dodavatelské ujednání, cloudová služba nebo integrace SaaS ovlivňuje regulované informace.
Pro GDPR to podporuje odpovědnost. Záznamy o činnostech zpracování podle článku 30 a bezpečnostní opatření podle článku 32 jsou důvěryhodnější, když registr aktiv identifikuje, kde se osobní údaje zpracovávají a jak jsou chráněny. Pro DORA tentýž registr podporuje kritičnost aktiv a služeb ICT, rozsah testování odolnosti a analýzu závislostí na třetích stranách. Pro NIS2 podporuje analýzu rizik, řízení přístupu a správu aktiv.
| Pole | Příklad záznamu |
|---|---|
| Název aktiva | Databáze zákaznické fakturace |
| Vlastník aktiva | Vedoucí platformního inženýrství |
| Obchodní proces | Fakturace předplatného a vystavování faktur |
| Umístění | Cloudový region EU, spravovaná databázová služba |
| Klasifikace | Vyhrazené |
| Kategorie dat | Identifikátory zákazníků, fakturační kontaktní údaje, reference transakcí |
| Relevance pro GDPR | Osobní údaje, kontext správce a zpracovatele |
| Kritičnost | Podporuje výnosové operace a zákaznický servis |
| Klíčová opatření | MFA, šifrování v klidu, šifrování při přenosu, schvalování privilegovaného přístupu, auditní protokolování, testování záloh |
| Závislost na dodavateli | Poskytovatel cloudové databáze, zpracovatel plateb |
| Periodicita přezkumu | Čtvrtletní přezkum přístupových práv, každoroční přezkum klasifikace, přezkum při změně systému |
Takový záznam mění průběh auditu. Namísto tvrzení „Domníváme se, že citlivá data jsou chráněna“ může organizace ukázat, o jaká data jde, kdo je vlastní, proč jsou klasifikována jako Vyhrazené, která opatření se na ně vztahují a kdy byla tato opatření naposledy přezkoumána.
Štítky musí řídit pravidla nakládání v cloudu a SaaS
Většina citlivých dat dnes prochází cloudovými platformami, SaaS aplikacemi, analytickými datovými toky a nástroji pro spolupráci. Politika, která uživatelům říká „nakládejte s důvěrnými daty opatrně“, nestačí.
Clarysec P27 Politika používání cloudových služeb přímo propojuje používání cloudu s klasifikací a umístěním dat:
Klasifikace a umístění dat 6.6.1 Žádná data nesmí být přesunuta na cloudovou platformu bez klasifikace v souladu s Politikou klasifikace dat a označování (P13). 6.6.2 Požadavky na umístění dat musí být vynuceny smluvně (např. ukládání pouze v EU pro data regulovaná GDPR). 6.6.3 Přeshraniční přenosy dat musí být v souladu s Chapter V GDPR a případně s článkem 28 DORA.
Je to důležité, protože cloudové riziko často vzniká z pohodlnosti. Tým exportuje datovou sadu do nového analytického nástroje. Prodej synchronizuje seznamy zákazníků do automatizační platformy. Vývojář zkopíruje produkční data do testovacího prostředí. Bez klasifikace a označování tyto kroky nemusí spustit právní přezkum, bezpečnostní schválení ani kontroly dodavatele.
Politika klasifikace dat a označování pro SME dává menším organizacím jednoduchý implementační vzor:
Sdílené složky nebo cloudová úložiště musí používat názvy složek nebo značky pro vyjádření klasifikace (např. „/Clients_Confidential“).
Ve vyspělejších prostředích mají být názvy složek doplněny strojově čitelnými štítky, politikami podmíněného přístupu, blokováním externího sdílení, šifrováním, retenčními štítky, pravidly DLP a protokolováním. Cílem není informace pouze označit. Cílem je, aby byl štítek využitelný pro prosazování pravidel.
Štítek „Vyhrazené“ může spustit blokování externího sdílení, šifrování v klidu i při přenosu, MFA, omezení stahování na nespravovaná zařízení, uchovávání auditních záznamů, upozornění SIEM, retenční pravidla, limity umístění u dodavatelů a eskalaci závažnosti incidentu.
P13 Politika klasifikace dat a označování stanoví základní pravidlo:
Veškeré nakládání s informacemi, jejich přenos, přístup, ukládání a likvidace musí odpovídat jejich úrovni klasifikace. Minimálně platí: 6.3.1.1 Veřejné: lze volně zpřístupnit; nevyžaduje se zvláštní nakládání 6.3.1.2 Interní: sdílené v rámci organizace; uložené v zabezpečených interních systémech 6.3.1.3 Důvěrné: 6.3.1.3.1 Přístup omezen pouze na oprávněný personál 6.3.1.3.2 Musí být šifrováno při přenosu i v klidu 6.3.1.3.3 Externě může být sdíleno pouze na základě NDA nebo rovnocenných smluvních ochranných opatření 6.3.1.4 Vyhrazené: 6.3.1.4.1 Uplatňují se nejvyšší bezpečnostní požadavky 6.3.1.4.2 Vyžadují se silná opatření řízení přístupu, vícefaktorová autentizace (MFA) a auditní protokolování 6.3.1.4.3 Fyzické a logické oddělení tam, kde je to proveditelné 6.3.1.4.4 Externí sdílení je zakázáno bez schválení CISO
Každý štítek má své chování. Každé chování má bezpečnostní opatření. Každé opatření má důkazy.
Praktický příklad prosazování
Představte si fintech analytika, který vytvoří soubor Q3_2026_Customer_Churn_Analysis.xlsx. Tabulka obsahuje ID zákazníků, objemy transakcí a prediktivní skóre odchodovosti.
Analytik jej klasifikuje jako Důvěrné, protože obsahuje zákaznická data a strategickou analýzu. Pomocí firemního nástroje pro ochranu informací aplikuje štítek Důvěrné. Protože je štítek trvalý, viditelný a strojově čitelný, opatření se aktivují automaticky.
Soubor je šifrován v klidu na zařízení i v cloudovém úložišti. Viditelné záhlaví jej označuje jako Důvěrné. Když se jej analytik pokusí synchronizovat do osobního cloudového úložiště, pravidlo DLP akci zablokuje a pokus zaloguje. Když se jej pokusí odeslat e-mailem na externí doménu mimo partnerský okruh, e-mailová brána zprávu umístí do karantény a upozorní bezpečnostní provoz. Pokud je soubor později reklasifikován jako Vyhrazené, protože obsahuje regulovaná data finančních transakcí, externí sdílení je zakázáno, pokud CISO nebo vlastník dat neschválí výjimku.
To je důkaz, který generální ředitel potřeboval. Je dohledatelný, automatizovaný a navázaný na politiku schválenou představenstvem. Zároveň je v souladu s P27 Politika používání cloudových služeb, protože žádný přesun do cloudu není povolen bez klasifikace a přeshraniční přenosy musí splňovat Chapter V GDPR a případně článek 28 DORA.
Vytvořte matici klasifikace a opatření za jeden týden
Kompletní program vyžaduje čas, ale cílený sprint dokáže vytvořit páteř důkazů před auditem, zákaznickým přezkumem nebo regulačním posouzením.
Den 1: Potvrďte klasifikační schéma
Začněte čtyřmi úrovněmi: Veřejné, Interní, Důvěrné a Vyhrazené. Jako výchozí použijte P13 Politika klasifikace dat a označování. Definujte kritéria podle obchodního dopadu, právního dopadu, smluvní citlivosti, rizika osobních údajů, kritičnosti služby a finanční újmy.
| Klasifikace | Typické příklady | Riziková logika |
|---|---|---|
| Veřejné | Schválený marketingový obsah, tiskové zprávy, pracovní inzeráty | Určeno k neomezené distribuci |
| Interní | Interní postupy, projektové poznámky, interní oznámení | Neveřejné informace organizace |
| Důvěrné | Zákaznické smlouvy, HR spisy, neveřejné finanční reporty | Citlivá obchodní, smluvní nebo zákaznická data |
| Vyhrazené | Osobní údaje zvláštní kategorie, platební údaje, autentizační tajemství, produkční zákaznické databáze | Kritické nebo regulované informace s významným právním nebo obchodním dopadem |
Den 2: Vyberte deset kritických informačních aktiv
Použijte Zenith Blueprint krok 9. Zahrňte zákaznickou databázi, systém podpůrných tiketů, HR platformu, poskytovatele identit, export plateb, datový sklad, cloudové úložiště, složku s reporty pro představenstvo, repozitář zdrojového kódu a repozitář důkazů incidentů. Zaznamenejte vlastníka, umístění, klasifikaci a relevanci pro GDPR.
Den 3: Namapujte pravidla nakládání
Definujte požadavky na nakládání pro přístup, ukládání, přenos, monitorování a likvidaci.
| Klasifikace | Přístup | Ukládání | Přenos | Monitorování | Likvidace |
|---|---|---|---|---|---|
| Veřejné | Otevřené nebo schválené publikační role | Schválené veřejné kanály | Po schválení bez zvláštního omezení | Základní monitorování integrity | Standardní mazání |
| Interní | Zaměstnanci a schválení dodavatelé | Spravované systémy | Interní kanály | Standardní logy přístupu | Standardní harmonogram uchovávání údajů |
| Důvěrné | Přístup na principu potřeby znát | Schválené zabezpečené repozitáře | Šifrování a NDA nebo smluvní ochranná opatření | Přezkum přístupových práv a upozornění DLP | Bezpečné mazání |
| Vyhrazené | Zásada nejmenších oprávnění s MFA a schválením vlastníka | Oddělené nebo zpřísněně zabezpečené systémy | Externí sdílení zakázáno, pokud není schváleno | Rozšířené auditní protokolování a upozorňování SIEM | Ověřené bezpečné zničení |
Den 4: Nakonfigurujte jednu cestu technického prosazování
Vyberte jednu platformu, například cloudový dokumentový repozitář, e-mailový systém nebo objektové úložiště. Implementujte viditelné a strojově čitelné štítky. Nakonfigurujte jedno pravidlo pro data klasifikovaná jako Důvěrné a jedno pravidlo pro data klasifikovaná jako Vyhrazené. Například vyžadujte šifrování u externích e-mailů s klasifikací Důvěrné a blokujte externí sdílení souborů klasifikovaných jako Vyhrazené.
Den 5: Aktualizujte registr rizik a SoA
Použijte Zenith Blueprint krok 13. Přidejte opatření klasifikace a označování do Prohlášení o použitelnosti. Propojte je s riziky, jako je neoprávněné zpřístupnění, chybná konfigurace cloudu, nadměrná expozice dodavatelům, selhání uchovávání dat a nedostatečné hlášení incidentu.
Den 6: Otestujte opatření
Vytvořte testovací soubor označený jako Vyhrazené. Pokuste se jej externě sdílet z nespravovaného zařízení. Ověřte, zda nástroj blokuje, varuje, loguje nebo eskaluje. Zachyťte snímky obrazovky, záznamy logů a důkazy z tiketu. Pokud opatření selže, zaznamenejte výjimku a plán nápravy.
Den 7: Proškolte uživatele první linie
Školení musí být specifické pro role. Vývojáři musí vědět, kdy produkční data nesmí být použita v testovacích prostředích. HR musí rozumět tomu, proč jsou zaměstnanecké spisy Důvěrné nebo Vyhrazené. Prodej musí vědět, proč exporty zákazníků nelze nahrávat do neschválených SaaS nástrojů. Vrcholové vedení musí rozumět tomu, proč materiály pro představenstvo, akviziční soubory a data investorů vyžadují přísnější nakládání.
Tento sprint nedokončí celý program, ale vytvoří páteř důkazů: politiku, evidenci, štítky, pravidla nakládání, technické prosazování, dohledatelnost rizik a školení.
Jak budou auditoři testovat klasifikaci a označování
Auditoři zřídka testují klasifikaci izolovaně. Sledují data.
Auditor ISO/IEC 27001:2022 propojí klasifikaci s rozsahem ISMS, požadavky zainteresovaných stran, právními a smluvními povinnostmi, posouzením rizik a Prohlášením o použitelnosti. Bude očekávat důkazy pro opatření ISO/IEC 27002:2022 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 a relevantní technická opatření. Typické důkazy zahrnují schválené politiky, záznamy evidence aktiv, položky registru rizik, označené vzorky, pravidla nakládání, přezkumy přístupových práv, zjištění interního auditu a nápravná opatření.
Přezkum podle GDPR se zaměří na osobní údaje. Posuzovatel se bude ptát, zda jsou osobní údaje identifikovány, zda jsou odlišena data zvláštní kategorie, zda pravidla uchovávání odpovídají účelu a zda jsou bezpečnostní opatření podle článku 32 přiměřená. Klasifikace pomáhá oddělit běžné informace organizace od osobních údajů, citlivých osobních údajů, důvěrných zákaznických dat a regulovaných záznamů. Označování pomáhá provozním týmům předcházet náhodnému zpřístupnění, nadměrnému uchovávání a neoprávněnému přenosu.
Hodnotitel NIST CSF 2.0 pravděpodobně zařadí klasifikaci pod GOVERN, IDENTIFY a PROTECT. Může se ptát, zda aktuální a cílové profily definují vyhledávání citlivých dat, zda prosazování štítků funguje napříč SaaS a cloudovými systémy, zda dodavatelé nakládají s daty podle klasifikace a zda se priority monitorování upravují podle citlivosti.
Auditor ve stylu COBIT 2019 nebo ISACA bude klást důraz na cíle správy a řízení, vlastnictví procesu, návrh kontrol a provozní účinnost. Zenith Controls mapuje opatření evidence 5.9 na COBIT 2019 BAI09.01, BAI09.02 a DSS05.04 a odkazuje na ISACA ITAF 2204 a 2301. U klasifikace Zenith Controls mapuje opatření 5.12 na COBIT 2019 DSS06.06 a APO13.01, zatímco označování mapuje na DSS06.06. Auditor se bude ptát, kdo proces vlastní, jak se schvalují výjimky, zda se monitoruje výkonnost a zda vedení dostává reporty.
Přezkum zaměřený na DORA se bude ptát, která informační aktiva podporují kritické nebo důležité funkce, která data jsou klasifikována jako Vyhrazené, kteří poskytovatelé služeb třetích stran v oblasti ICT tato data ukládají nebo přenášejí, zda smlouvy definují umístění a bezpečnostní opatření, zda je testování vymezeno podle kritických dat a zda jsou incidenty klasifikovány částečně podle ztráty dat napříč dostupností, autenticitou, integritou a důvěrností.
Pokud odpovědi vycházejí z jednoho důkazního modelu aktiv a dodavatelů řízeného klasifikací, audity jsou rychlejší, konzistentnější a lépe obhajitelné.
Časté vzorce selhání
Selhání klasifikace obvykle nastávají proto, že organizace považují štítky za nástroje zvyšování povědomí, nikoli za signály pro opatření.
Za prvé, klasifikují dokumenty, ale ne databáze, rozhraní API, logy, zálohy, exporty nebo záznamy v SaaS. Citlivá data v ladicím logu mohou způsobit stejnou škodu jako citlivá data v tabulce.
Za druhé, označují informace, ale nepropojují štítky s řízením přístupu. Štítek Vyhrazené při otevřeném přístupu dokládá, že organizace znala citlivost, ale neprosadila pravidlo nakládání.
Za třetí, migrace do cloudu probíhají před klasifikací. Týmy přesouvají data do nových SaaS nástrojů bez potvrzení umístění dat, podmínek dodavatele, přístupu dílčích zpracovatelů, požadavků na přeshraniční přenosy nebo práv na výmaz. P27 Politika používání cloudových služeb to řeší přímo tím, že zakazuje přesun na cloudové platformy bez klasifikace.
Za čtvrté, plány reakce na incidenty ignorují klasifikaci. Pokud kritéria závažnosti nezahrnují citlivost dat, týmy reakce na incidenty ztrácejí během krize čas zjišťováním, co bylo dotčeno. Analýza porušení zabezpečení podle GDPR, zvládání incidentů podle NIS2 a klasifikace incidentů podle DORA těží z rychlého datového kontextu.
Za páté, SoA nevysvětluje, proč jsou opatření klasifikace a označování použitelná. Organizace mohla štítky implementovat, ale SoA je nepropojuje s článkem 32 GDPR, článkem 21 NIS2, rizikem v oblasti ICT podle DORA, zákaznickými smlouvami nebo konkrétními rizikovými scénáři.
Reportování vedení: zviditelněte klasifikaci
NIS2 a DORA činí z kybernetické bezpečnosti otázku odpovědnosti vedení. ISO/IEC 27001:2022 zároveň vyžaduje závazek vedení, sladění politik, zdroje, role a reportování výkonnosti. Metriky klasifikace proto mají vstupovat do přezkoumání vedením.
Užitečné metriky zahrnují:
- Procento kritických informačních aktiv s přiřazenými vlastníky.
- Procento aktiv se schválenou klasifikací.
- Počet aktiv klasifikovaných jako Vyhrazené bez rozšířeného protokolování.
- Počet repozitářů Důvěrné nebo Vyhrazené s povoleným externím sdílením.
- Procento dodavatelů zpracovávajících data Důvěrné nebo Vyhrazené s aktualizovanými smluvními doložkami.
- Počet výjimek klasifikace a opožděných nápravných opatření.
- Incidenty DLP podle štítku.
- Dokončení přezkumů přístupových práv pro aktiva klasifikovaná jako Vyhrazené.
- Umístění cloudových úložišť pro data regulovaná GDPR.
- Cvičení reakce na incidenty, která použila kritéria závažnosti založená na klasifikaci.
Tyto metriky podporují přezkoumání vedením podle ISO/IEC 27001:2022, dohled vedení podle NIS2, reporting správy a řízení podle DORA a ujištění zákazníků. Zároveň činí klasifikaci srozumitelnou pro vrcholové vedení. Vedení může jednat rychleji, když vidí, že více repozitářů klasifikovaných jako Vyhrazené nemá otestovanou obnovu nebo že kritičtí dodavatelé zpracovávají zákaznická data bez potvrzeného ukládání v EU.
Od politiky k důkazu
Implementační vzor Clarysec je veden důkazy:
- Definujte klasifikační schéma v P13 Politika klasifikace dat a označování nebo začněte s Politika klasifikace dat a označování pro SME.
- Přidejte klasifikaci do evidence aktiv pomocí P12 Politika správy aktiv.
- Uplatněte omezení pro cloud a požadavky na umístění dat prostřednictvím P27 Politika používání cloudových služeb.
- Použijte Zenith Blueprint krok 9 k identifikaci informačních aktiv, vlastníků, umístění a citlivosti.
- Použijte Zenith Blueprint krok 13 k mapování rizik na opatření v SoA.
- Použijte Zenith Blueprint krok 22 k implementaci opatření ISO/IEC 27002:2022 5.12 a 5.13 v každodenním provozu.
- Použijte Zenith Controls k mapování stejných důkazů na GDPR, NIS2, DORA, NIST CSF, COBIT 2019 a podpůrné normy.
- Otestujte prosazování štítků, omezení přístupu, protokolování, DLP a třídění incidentů.
- Reportujte výkonnost klasifikace vedení.
- Přezkoumejte klasifikaci po významných změnách systémů, procesů, dodavatelů nebo právních předpisů.
Funguje to proto, že klasifikace se stává společným jazykem mezi obchodní hodnotou, právní povinností, technickým opatřením a auditními důkazy.
Pokud se vaše organizace připravuje na certifikaci ISO/IEC 27001:2022, ujištění podle GDPR, připravenost na NIS2, due diligence zákazníků podle DORA nebo kombinovaný audit souladu, začněte jednou otázkou:
Dokážete u každého kritického informačního aktiva ukázat, co to je, kdo je vlastní, kde se nachází, jak je klasifikováno, jak je označeno, kdo k němu může přistupovat, jak je chráněno, jak dlouho je uchováváno, který dodavatel se ho dotýká a co se stane, pokud bude zpřístupněno?
Pokud odpověď zní zatím ne, Clarysec vám může pomoci vybudovat důkazní řetězec rychle a obhajitelně.
Použijte Politiku klasifikace dat a označování pro SME, P13 Politiku klasifikace dat a označování, P12 Politiku správy aktiv, P27 Politiku používání cloudových služeb, Zenith Blueprint: 30krokovou roadmapu auditora a Zenith Controls: průvodce napříč požadavky souladu, abyste přeměnili klasifikaci ze statické politiky na provozní vrstvu opatření pro článek 32 GDPR, řízení kybernetických rizik podle NIS2 a důkazy o rizicích v oblasti ICT podle DORA.
Nejlepší čas klasifikovat data byl před příchodem požadavku auditora. Druhý nejlepší čas je před další migrací do cloudu, zařazením dodavatele, zákaznickým dotazníkem nebo incidentem.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


