Správa a řízení PII pro ISO 27701:2025 a GDPR

Požadavek dorazil do schránky CISO se zdánlivou jednoduchostí: „Project Wellness.“ Rychle rostoucí fintech chtěl analyzovat stávající transakční data zákazníků, aby mohl poskytovat personalizované tipy ke spoření, doporučení produktů a poznatky o riziku odchodu zákazníků. Marketing v tom viděl zapojení zákazníků. Produktový tým inovaci. Vedení konkurenční výhodu.
CISO viděl nášlapnou minu v oblasti správy a řízení.
Transakční data byla shromážděna pro zpracování plateb na základě definovaného účelu a právního základu. Nyní je podnik chtěl znovu využít pro analytiku finančního zdraví, personalizaci kampaní a prediktivní skórování. Aby se dodání urychlilo, tým chtěl také předat pseudonymizovanou datovou sadu externímu dodavateli analytiky AI.
V síti nebyl žádný útočník. Žádná databáze neunikla. Žádný incidentní tiket nesvítil červeně.
Právě zde však často začínají selhání odpovědnosti podle GDPR.
Problém nespočívá v tom, zda má organizace oznámení o ochraně osobních údajů, pověřence pro ochranu osobních údajů, registr právních základů nebo harmonogram uchovávání údajů. Hlubší otázka je provozní: kdo schvaluje nové shromažďování PII, kdo potvrzuje nezbytnost, kdo definuje povolené interní použití, kdo rozhoduje, zda je sekundární využití slučitelné, kdo autorizuje zpřístupnění dodavateli a kdo dokáže toto rozhodnutí později doložit?
Právě tuto mezeru v kontrolách musí uzavřít implementace systému řízení informací o soukromí podle ISO/IEC 27701:2025, tedy PIMS. Článek 5 GDPR vyžaduje, aby osobní údaje byly zpracovávány zákonně, korektně a transparentně, shromažďovány pro určité, výslovně vyjádřené a legitimní účely, omezeny na nezbytný rozsah, přesné, uchovávané pouze po nezbytnou dobu, přiměřeně chráněné a spravované v rámci odpovědnosti správce. Článek 6 GDPR doplňuje právní základ a logiku slučitelnosti pro další zpracování. Tyto zásady jsou však obhajitelné až tehdy, když jsou převedeny do workflow, registrů, schválení, pravidel přístupu, kontrol dodavatelů, monitorování a důkazů.
Přístup Clarysec je jednoduchý: ke správě shromažďování, používání a zpřístupňování PII přistupovat jako k řízenému provoznímu modelu, nikoli jako k právnímu memorandu. Model je zasazen do páteře ISMS podle ISO/IEC 27001:2022, rozšiřuje se do rolí PIMS podle ISO/IEC 27701:2025 a je dokládán prostřednictvím politik, registrů, Zenith Blueprint: 30krokový plán auditora a Zenith Controls: průvodce souladem napříč rámci od Clarysec.
Proč správa a řízení PII selhává, i když dokumentace k ochraně soukromí existuje
Většina programů ochrany soukromí neselhává proto, že by nikdo nevěděl o existenci GDPR. Selhávají proto, že rozhodnutí týkající se ochrany soukromí vznikají v produktových tiketech, e-mailech k onboardingu dodavatelů, exportech tabulek, experimentech v řídicích panelech a pilotech AI bez opakovatelné kontrolní brány.
Typický vzorec je dobře známý:
- Tým přidá do registračního formuláře nové pole, protože zlepšuje segmentaci.
- Nikdo nezaznamená, proč je právě toto pole nezbytné.
- Jiný tým později použije data pro jiný účel.
- Dodavatel obdrží export na základě široké smlouvy o službách.
- Záznamy o činnostech zpracování se aktualizují až po spuštění, pokud vůbec.
- Při auditu organizace dokáže předložit oznámení o ochraně osobních údajů, ale nedokáže předložit důkazy o rozhodnutí.
Články 4 a 5 GDPR definují zpracování široce. Patří sem shromažďování, zaznamenávání, ukládání, používání, zpřístupnění, výmaz i zničení. Článek 5 také výslovně stanoví odpovědnost. Správci musí být schopni doložit soulad se zásadami.
Auditní otázka tedy nezní pouze: „Máte politiku?“ Zní: „Ukažte mi, jak byl tento konkrétní datový prvek schválen, proč byl potřebný, jak byl použit, kdo jej obdržel a jaká opatření zabránila zneužití.“
Clarysec P17 Politika ochrany dat a soukromí jasně stanoví očekávání pro celý životní cyklus:
Formalizuje odpovědnosti podniku podle mezinárodních norem a regulačních rámců a zajišťuje, aby osobně identifikovatelné informace (PII) byly shromažďovány, zpracovávány, uchovávány, sdíleny a likvidovány zákonně, bezpečně a transparentně.
Pro malé a střední podniky převádí Clarysec Politika ochrany dat a soukromí pro SME stejný princip do praktického provozního pravidla:
Osobní údaje smí být shromažďovány pouze tehdy, jsou-li nezbytné pro legitimní, zákonný nebo smluvní účel.
A pro minimalizaci:
Shromažďovat a uchovávat se smí pouze minimální nezbytný rozsah osobních údajů.
Tato ustanovení mají sílu pouze tehdy, jsou-li uplatněna před zahájením zpracování. Jinak zůstávají jazykem ochrany soukromí bez provozního důkazu.
Kontrolní cíl: zastavit neřízené zpracování ve třech branách
Silný PIMS má řídit rozhodnutí o PII ve třech bodech: před shromažďováním, před použitím a před zpřístupněním.
Před shromažďováním musí organizace vědět, co chce shromažďovat, od koho, jakým kanálem, za jakým účelem, na jakém právním základě a proč je každé pole nezbytné.
Před použitím musí organizace definovat povolená pravidla interního použití. Podpora, péče o zákazníky, marketing, prevence podvodů, finance a vývoj zpravidla nepotřebují stejnou viditelnost ani stejné oprávnění jednat na základě PII.
Před zpřístupněním musí organizace vědět, kdo je příjemcem, jakou roli plní, proč je zpřístupnění nezbytné, kde zpracování probíhá, jaké kategorie PII se sdílejí, jak často ke sdílení dochází a jaký zdroj oprávnění sdílení umožňuje.
Clarysec PII09 Politika shromažďování, používání, zpřístupňování a sdílení PII je navržena právě pro tuto vrstvu správy a řízení. Používá označování rolí PIMS, zejména roli správce, protože rozhodnutí o shromažďování, používání a zpřístupňování obvykle náleží organizaci, která určuje účely a prostředky.
Pro omezení shromažďování PII09 Politika shromažďování, používání, zpřístupňování a sdílení PII vyžaduje:
[Správce] Vlastník procesu / vlastník společnosti MUSÍ v REG02 zaznamenat účel shromažďování, zdroj nebo kanál, kategorie PII, kategorie subjektů PII a minimální datové prvky před zahájením jakékoli nové činnosti shromažďování nebo významné změny shromažďování.
Následně činí minimalizaci testovatelnou:
[Správce] Vlastník procesu / vlastník společnosti MUSÍ v REG02 zaznamenat odůvodnění nezbytnosti pro každý datový prvek PII před tím, než je tento prvek shromážděn.
Požadavek na „každý datový prvek PII“ je rozdílem mezi obecným inventářem zpracování a důkazem odpovědnosti na úrovni jednotlivých polí.
Pro interní použití stejná politika vyžaduje:
[Správce] Vlastník procesu / vlastník společnosti MUSÍ v REG02 zaznamenat schválená pravidla interního použití pro každou činnost zpracování před zahájením použití.
Pro sekundární využití:
[Správce] Vlastník procesu / vlastník společnosti MUSÍ v REG02 zaznamenat posouzení slučitelnosti sekundárního využití před použitím PII pro účel, který dosud nebyl pro danou činnost zpracování schválen.
A pro externí zpřístupnění:
[Správce] Vlastník dodavatele / vlastník nákupu MUSÍ v REG08 zaznamenat identitu příjemce, roli příjemce, účel zpřístupnění, kategorie PII, frekvenci sdílení, lokalitu zpracování a zdroj oprávnění před zahájením opakovaného externího sdílení.
Tato ustanovení vytvářejí jasnou odpověď pro vedení, když se ptá, zda podnik může rychle inovovat: ano, pokud rozhodnutí projde dokumentovaným workflow správy a řízení a opatření odpovídají schválení.
REG02 a REG08: řetězec politika–opatření v Clarysec
V implementacích Clarysec není REG02 pasivní evidence činností zpracování. Je to záznam o rozhodnutí pro účel shromažďování, právní základ, kategorie PII, nezbytnost, pravidla interního použití, sladění s uchováváním a slučitelnost sekundárního využití.
REG08 je kontrolní registr zpřístupnění a sdílení. Je obzvlášť důležitý pro dodavatele, partnery, společnosti ve skupině, orgány veřejné moci, dílčí zpracovatele, integrace a opakované exporty.
Společně vytvářejí řetězec politika–opatření, který mohou testovat týmy ochrany soukromí, bezpečnosti, nákupu a auditu.
| Otázka správy a řízení | Důkazní artefakt | Spouštěč v politice Clarysec | Praktický výsledek opatření |
|---|---|---|---|
| Jaké PII shromažďujeme? | Záznam o zpracování v REG02 | Ustanovení PII09 4.1.1 | Shromažďování je definováno před spuštěním |
| Proč je každé pole potřebné? | Odůvodnění nezbytnosti datového prvku v REG02 | Ustanovení PII09 4.1.3 | Minimalizace údajů je doložena |
| Jak mohou týmy PII používat? | Pravidla interního použití v REG02 | Ustanovení PII09 4.2.1 | Přístup a použití jsou vázány na účel |
| Můžeme PII znovu použít pro nový účel? | Posouzení slučitelnosti v REG02 | Ustanovení PII09 4.3.1 | Sekundární využití je schváleno, podmíněno nebo zablokováno |
| Kdo externě obdrží PII? | Záznam o zpřístupnění v REG08 | Ustanovení PII09 4.4.2 | Zpřístupnění je dohledatelné a autorizované |
| Jsou dodavatelé omezeni na princip potřeby znát? | Přezkum přístupu dodavatelů | Ustanovení politiky třetích stran 6.2.1 | Přístup dodavatelů je minimalizován |
Tento model přirozeně navazuje na ISO/IEC 27001:2022. Kapitoly 4 až 10 vyžadují, aby organizace rozuměla kontextu, požadavkům zainteresovaných stran, rozsahu, odpovědnostem vedení, posouzení rizik, ošetření rizik, operativnímu řízení, hodnocení výkonnosti a zlepšování. Povinnosti v oblasti ochrany soukromí podle GDPR a ISO/IEC 27701:2025 se tak stávají součástí systému řízení, nikoli samostatným ostrovem ochrany soukromí.
ISO/IEC 27002:2022 tento provozní model rovněž podporuje. Opatření 5.31, Legal, statutory, regulatory and contractual requirements, ukotvuje GDPR a odvětvové povinnosti. Opatření 5.34, Privacy and protection of PII, řeší ochranu specifickou pro soukromí. Opatření 5.9, Inventory of information and other associated assets, podporuje povědomí o datech. Opatření 5.12 a 5.13 podporují klasifikaci a označování. Opatření 5.14 řídí přenos informací. Opatření 5.19 až 5.23 pokrývají vztahy s dodavateli, smlouvy s dodavateli, dodavatelský řetězec ICT, monitorování služeb dodavatelů a cloudové služby. Opatření 8.11 podporuje maskování dat, 8.12 podporuje prevenci úniku dat, 8.15 protokolování, 8.16 monitorovací činnosti a 8.24 používání kryptografie.
Zenith Blueprint zasazuje tato opatření do implementační cesty. Ve fázi Controls in Action pokrývá krok 23 organizační opatření 5.19 až 5.37, včetně opatření 5.34 pro Privacy and protection of PII. Blueprint vysvětluje:
V dnešním světě řízeném daty nejsou osobně identifikovatelné údaje jen dalším typem dat; jsou hluboce citlivým vyjádřením důvěry. Jména, adresy, identifikátory, zdravotní záznamy, finanční údaje — tato data vyprávějí příběh o skutečných lidech.
Poté stanoví provozní základ:
Základem tohoto opatření je povědomí o datech. Organizace musí vědět, jaké PII shromažďuje, kde se nacházejí, proč jsou zpracovávány a kdo k nim má přístup.
Právě to REG02 a REG08 poskytují, pokud jsou vedeny jako živé záznamy správy a řízení.
Praktický příklad: schválení Project Wellness bez ztráty kontroly
Vraťme se ke scénáři fintechu. Podnik chce analyzovat transakční data zákazníků pro personalizovaná doporučení finančního zdraví. Marketing chce výstupy používat pro kampaně. Produktový tým chce vytvářet skóre odchodu a zapojení. Externí platforma analytiky AI bude zpracovávat část datové sady.
Takto by Clarysec požadavek řídil.
Krok 1: Vytvořit nebo aktualizovat činnost zpracování v REG02
Vlastník procesu otevře REG02 a zaznamená činnost zpracování před zahájením prací.
| Pole REG02 | Příklad Project Wellness |
|---|---|
| Činnost zpracování | Analytika finančního zdraví a funkce doporučení |
| Primární účel | Poskytovat zákazníkům personalizované poznatky ke spoření a produktová doporučení |
| Kategorie subjektů PII | Retailoví zákazníci, majitelé účtů, oprávnění uživatelé |
| Kategorie PII | Kategorie transakce, částka transakce, datum transakce, stav účtu, držené produkty |
| Zdroj nebo kanál | Platební platforma, záznamy zákaznických účtů, systémy používání produktů |
| Právní základ | Určuje právní poradce pro ochranu soukromí nebo vlastník ochrany soukromí podle kontextu správce |
| Uchovávání | Napojeno na schválený harmonogram uchovávání údajů |
| Pravidla interního použití | Produktový tým smí používat agregované poznatky; marketing vyžaduje schválení sekundárního využití; vývoj musí používat maskované datové sady |
Důležité je načasování. REG02 se aktualizuje před zahájením nového zpracování, nikoli až poté, co je funkce již v produkci.
Krok 2: Zaznamenat odůvodnění nezbytnosti na úrovni polí
Marketing původně žádá pět let úplné historie transakcí včetně názvů obchodníků, přesných časových razítek, metadat karet a atributů zákaznických profilů. Tým správy a řízení zpochybní každé pole.
| Prvek PII | Odůvodnění nezbytnosti | Rozhodnutí |
|---|---|---|
| Kategorie transakce | Potřebná k identifikaci vzorců výdajů pro tipy ke spoření | Schváleno |
| Částka transakce | Potřebná k výpočtu rozsahů trendů a relevance doporučení | Schváleno s prahovými hodnotami agregace |
| Datum transakce | Potřebné pro analýzu trendů | Schváleno na úrovni měsíce, kde je to možné |
| Název obchodníka | Není vyžadován pro první vydání a zvyšuje riziko opětovné identifikace | Zamítnuto |
| Přesné časové razítko | Není nezbytné pro doporučení finančního zdraví | Zamítnuto |
| E-mail zákazníka | Potřebný pouze pro přiřazení k účtu, nikoli pro trénování modelu | Omezeno |
| Držené produkty | Potřebné k zamezení nerelevantních doporučení | Schváleno s omezením přístupu |
Toto je minimalizace údajů jako důkaz, nikoli jako aspirace. Podnik stále získá užitečnou analytiku, ale datová sada je zúžena na rozsah nezbytný pro schválený účel.
Krok 3: Klasifikovat a označit datovou sadu
Datová sada je klasifikována podle Clarysec Politika klasifikace dat a označování. Verze pro SME vyžaduje:
Externí sdílení musí být výslovně autorizováno a zalogováno.
Podniková Politika klasifikace dat a označování doplňuje ochranné opatření pro citlivé informace:
Smí být externě sdíleny pouze na základě dohody o mlčenlivosti nebo rovnocenných smluvních záruk.
V praxi nelze datovou sadu Project Wellness jen tak exportovat do platformy AI. Vyžaduje schválený záznam o zpřístupnění, smluvní záruky, technická opatření pro přenos a logy.
Zenith Blueprint v kroku 22 pro opatření 5.12 Classification of information vysvětluje, proč je to důležité:
Každé opatření bezpečnosti informací, které kdy bylo napsáno — omezení přístupu, šifrování, zálohování, monitorování nebo likvidace — předpokládá jednu věc: že organizace ví, co chrání.
Bez klasifikace se omezení přístupu, šifrování, DLP a pravidla uchovávání mění v odhady.
Krok 4: Definovat pravidla interního použití před produkčním vydáním
Vlastník procesu zaznamená schválená pravidla interního použití v REG02. Právě zde se často zastaví plíživé rozšiřování účelu.
Obhajitelná sada pravidel může stanovit:
- Produktový tým smí používat agregované metriky výkonnosti doporučení.
- Zákaznická podpora smí vidět, zda bylo zákazníkovi zobrazeno doporučení při řešení požadavku podpory.
- Marketing nesmí používat individuální skóre finančního zdraví pro segmentaci kampaní, pokud není dokončeno posouzení slučitelnosti sekundárního využití.
- Finance nesmí přistupovat k detailní analytice finančního zdraví, pokud neexistuje samostatný schválený účel.
- Vývojáři nesmí používat produkční PII v testovacích prostředích.
- Hodnocení modelu AI musí tam, kde je to proveditelné, používat maskované, pseudonymizované nebo agregované datové sady.
Poslední dvě pravidla navazují na opatření 8.11 ISO/IEC 27002:2022, Data masking. Zenith Blueprint, krok 19, popisuje maskování dat jako praktickou metodu prevence zbytečné expozice v testovacích prostředích, tréninkových datových sadách, analytických platformách, integracích třetích stran a testovacích pipeline CI/CD.
Krok 5: Provést posouzení slučitelnosti sekundárního využití
Marketing později požádá o použití skóre finančního zdraví pro cílené kampaně. To je nový účel. Podle PII09 Politika shromažďování, používání, zpřístupňování a sdílení PII, ustanovení 4.3.1, musí vlastník společnosti zaznamenat posouzení slučitelnosti v REG02 před zahájením nového použití.
Posouzení má vyhodnotit:
- zda je marketing finančního zdraví slučitelný s původním účelem zpracování;
- co bylo zákazníkům sděleno při shromažďování a v oznámení o ochraně osobních údajů;
- zda mohou být inference odvozené z transakcí citlivé nebo neočekávané;
- zda by nové použití mohlo vytvářet tlak, vyloučení nebo nespravedlivé profilování;
- zda ochranná opatření, jako je agregace, opt-out, pseudonymizace nebo segmentace na úrovni účtu, snižují riziko;
- zda právní základ zůstává platný;
- zda jsou vyžadovány aktualizace transparentních informací nebo mechanismy souhlasu.
Výsledkem může být schválení, schválení s ochrannými opatřeními nebo zamítnutí. Hodnota spočívá v tom, že rozhodnutí je zdokumentováno před zahájením použití.
Krok 6: Schválit externí zpřístupnění prostřednictvím REG08
Pokud má dodavatel analytiky AI obdržet data, vlastník dodavatele nebo vlastník nákupu zaznamená v REG08:
| Pole REG08 | Požadovaný důkaz rozhodnutí |
|---|---|
| Identita příjemce | Název právnické osoby, vlastník služby a kontakt na dodavatele |
| Role příjemce | Zpracovatel, dílčí zpracovatel, samostatný správce nebo společný správce |
| Účel zpřístupnění | Definovaný analytický účel navázaný na Project Wellness |
| Kategorie PII | Pouze schválená pole, s vyloučením zamítnutých datových prvků |
| Frekvence sdílení | Jednorázový přenos, dávková frekvence nebo tok přes API |
| Lokalita zpracování | Země a hostingové regiony |
| Zdroj oprávnění | Smlouva, DPA, dokumentovaný pokyn nebo jiný schválený základ |
| Bezpečnostní požadavky | Šifrování, omezení přístupu, protokolování, výmaz a oznámení incidentu |
| Požadavky při ukončení | Vrácení, výmaz, součinnost při přechodu a auditní důkazy |
Clarysec Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran pro SME posiluje minimalizovaný přístup dodavatelů:
Dodavatelům musí být udělen přístup pouze k minimálnímu rozsahu systémů a dat potřebnému k výkonu jejich funkce.
Toto je minimalizace v oblasti ochrany soukromí aplikovaná na přístup dodavatelů a zpřístupnění.
Krok 7: Doplnit technické vynucování
Záznamy správy a řízení musí být podpořeny technickými opatřeními. Pro Project Wellness by Clarysec typicky doporučil pravidla DLP pro exporty, omezení přístupu na základě rolí, protokolování událostí přístupu a přenosu, maskované datové sady pro vývoj, šifrování při přenosu a uložení, přezkumy přístupů dodavatelů, prověrku zabezpečení cloudu a pravidelné vzorkování REG02 a REG08 proti skutečnému chování systémů.
Tak se odpovědnost podle ISO/IEC 27701:2025 a GDPR stává provozními důkazy.
Mapování opatření: od rozhodnutí o soukromí k bezpečnostnímu vynucování
Správa a řízení PII není jedno izolované opatření. Je to vazba mezi požadavky ochrany soukromí, bezpečnostními opatřeními, správou dodavatelů a auditními důkazy.
Zenith Controls považuje opatření 5.34 ISO/IEC 27002:2022, Privacy and protection of PII, za preventivní opatření podporující důvěrnost, integritu a dostupnost, s koncepty kybernetické bezpečnosti Identify a Protect a provozními schopnostmi v ochraně informací a právním souladu.
Pro 5.34 Zenith Controls mapuje okolní ekosystém opatření včetně inventáře, klasifikace, přenosu, přístupu, identity, cloudu, bezpečnosti dodavatelů, maskování, prevence úniku, protokolování, monitorování a kryptografie.
| Opatření ISO/IEC 27002:2022 | Název opatření | Proč je důležité pro správu a řízení PII |
|---|---|---|
| 5.9 | Evidence informací a dalších souvisejících aktiv | Držené PII musí být známy dříve, než je lze chránit |
| 5.12 | Klasifikace informací | PII musí být klasifikovány podle citlivosti a požadavků na nakládání |
| 5.13 | Označování informací | Štítky pomáhají vynucovat pravidla nakládání, sdílení a uchovávání |
| 5.14 | Přenos informací | Pohyb PII musí být autorizovaný, chráněný a dohledatelný |
| 5.15 | Řízení přístupu | Přístup k PII musí být omezen na schválené role a účely |
| 5.16 | Správa identit | Uživatelé a servisní identity přistupující k PII musí být řízeni |
| 5.19 | Bezpečnost informací ve vztazích s dodavateli | Riziko dodavatelů týkající se PII musí být identifikováno a řízeno |
| 5.20 | Řešení bezpečnosti informací ve smlouvách s dodavateli | Smlouvy musí obsahovat bezpečnostní požadavky a požadavky na ochranu soukromí |
| 5.21 | Řízení bezpečnosti informací v dodavatelském řetězci ICT | Rizika navazujících ICT a dílčích zpracovatelů musí být řízena |
| 5.22 | Monitorování, přezkum a řízení změn služeb dodavatelů | Služby dodavatelů musí být přezkoumávány a změny posuzovány |
| 5.23 | Bezpečnost informací při používání cloudových služeb | SaaS a cloudové zpracování PII musí být řízeny |
| 5.31 | Právní, zákonné, regulační a smluvní požadavky | GDPR, DORA, NIS2 a povinnosti vůči zákazníkům musí být identifikovány |
| 5.34 | Ochrana soukromí a ochrana PII | Ochrana PII musí být implementována podle požadavků na ochranu soukromí |
| 8.11 | Maskování dat | Skutečné PII mají být skryty tam, kde nejsou úplná data nezbytná |
| 8.12 | Prevence úniku dat | Neoprávněný pohyb PII má být detekován a předcházen |
| 8.15 | Protokolování | Přístup, změny a přenosy mají být doloženy |
| 8.16 | Monitorovací činnosti | Podezřelá nebo neoprávněná činnost má být detekována |
| 8.24 | Používání kryptografie | PII mají být chráněny při uložení a přenosu tam, kde je to vyžadováno |
K maskování Zenith Controls uvádí:
Maskování dat (8.11) je technika často používaná k ochraně PII v neprodukčních prostředích nebo při sdílení dat. Přímo podporuje 5.34 tím, že snižuje expozici skutečných osobních údajů, a tím snižuje riziko pro soukromí.
K prevenci úniku dat průvodce vysvětluje praktickou hranici:
DLP hraje přímou roli při ochraně osobních údajů. Opatření 8.12 vynucuje hranice toho, jak mohou být PII zpřístupňovány, sdíleny nebo přesouvány, a zajišťuje, že osobní údaje nemohou uniknout neautorizovanými kanály.
Auditor testující správu zpřístupnění proto nemusí požadovat pouze REG08, ale také politiky DLP, logy zablokovaných přenosů, kontroly odchozích e-mailů, omezení sdílení v cloudu, požadavky na šifrování, záznamy o přístupu dodavatelů a důkazy o schválených výjimkách.
Hodnota pro soulad napříč rámci: GDPR, ISO 27701, NIS2, DORA, NIST a COBIT
Správa shromažďování, používání a zpřístupňování PII je vedena ochranou soukromí, ale její důkazy podporují širší povinnosti v oblasti kybernetické bezpečnosti, odolnosti a správy a řízení.
Články 2 a 3 GDPR definují širokou věcnou a územní působnost, která může zahrnovat SaaS, fintech a poskytovatele digitálních služeb mimo EU, pokud poskytují služby osobám v EU nebo monitorují jejich chování. Článek 5 vyžaduje omezení účelu, minimalizaci údajů, přesnost, omezení uložení, integritu, důvěrnost a odpovědnost. Článek 6 vyžaduje právní základ a posouzení slučitelnosti pro další zpracování. Článek 9 přidává přísnější podmínky pro zvláštní kategorie údajů, relevantní tam, kde se uplatňuje profilování, údaje blízké zdravotním údajům, biometrický onboarding nebo citlivé atributy.
Článek 21 NIS2 vyžaduje, aby základní a důležité subjekty zavedly přiměřená technická, provozní a organizační opatření k řízení rizik. Minimální oblasti zahrnují analýzu rizik, politiky bezpečnosti informačních systémů, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečný vývoj, účinnost kontrol, školení, kryptografii, bezpečnost lidských zdrojů, řízení přístupu, správu aktiv a autentizaci.
DORA vyžaduje, aby finanční subjekty udržovaly rámec řízení rizik v oblasti ICT, odpovědnost vedoucího orgánu, identifikaci ICT aktiv a závislostí, ochranná a preventivní opatření, detekci, reakci, obnovu, zálohování, učení se, řízení incidentů, testování a řízení rizik třetích stran v oblasti ICT. Vyžaduje také registry informací pro smlouvy o ICT službách, náležitou péči, práva na audit, bezpečnostní požadavky a strategie ukončení.
NIST Cybersecurity Framework 2.0 poskytuje sjednocující jazyk správy a řízení. Jeho funkce GOVERN očekává, že právní, regulační a smluvní požadavky, včetně povinností v oblasti ochrany soukromí, budou pochopeny a řízeny. Pokrývá také strategii rizik, role, politiky, dohled a řízení rizik dodavatelů.
Auditoři COBIT 2019 hledají cíle správy a řízení, rozhodovací práva, odpovědnost, vlastnictví procesů, ukazatele výkonnosti a důkazy o zajištění. U správy a řízení PII to znamená, že požadavky ochrany soukromí musí být začleněny do správy a řízení podniku, nikoli řízeny jako vedlejší proces.
| Rámec nebo režim | Co očekává | Důkazy Clarysec, které pomáhají |
|---|---|---|
| ISO/IEC 27701:2025 PIMS | Správa a řízení ochrany soukromí podle rolí pro povinnosti správce a zpracovatele | Ustanovení PII09, REG02, REG08, role ochrany soukromí, posouzení slučitelnosti |
| GDPR | Omezení účelu, minimalizace, právní základ, odpovědnost a bezpečné zpracování | Odůvodnění nezbytnosti, pravidla interního použití, schválení zpřístupnění, DLP, logy přístupu |
| ISO/IEC 27001:2022 a ISO/IEC 27002:2022 | Opatření ISMS založená na rizicích pro PII, dodavatele, přenosy, přístup, maskování a monitorování | Prohlášení o použitelnosti, plán ošetření rizik, 5.34, 5.12, 5.14, 8.11, 8.12 |
| NIS2 | Provozní a organizační opatření k řízení kybernetických rizik, bezpečnost dodavatelů a odpovědnost vedení | Evidence aktiv, kontroly dodavatelů, incidentní a monitorovací kontroly, reporting správní radě |
| DORA | Řízení rizik v oblasti ICT, ochrana dat, riziko třetích stran, testování odolnosti a práva na audit | Registry dodavatelů, smluvní doložky, řízení přístupu, důkazy o testování, logy zpřístupnění |
| NIST CSF 2.0 | Správa a řízení, právní požadavky, řízení rizik a výsledky ochrany dat | Aktuální profil, cílový profil, mapování politik, registr rizik, akční plán opatření |
| COBIT 2019 | Odpovědnost za správu a řízení, vlastnictví procesů, zajištění a monitorování výkonnosti | RACI, KPI opatření, auditní vzorky, zápisy z přezkoumání vedením, sledování výjimek |
Jak auditoři testují stejnou vrstvu správy a řízení
Silná implementace PIMS musí obstát v různých auditních stylech.
Auditor ISO/IEC 27001:2022 a ISO/IEC 27701:2025 začne rozsahem, zainteresovanými stranami, právními a smluvními požadavky, posouzením rizik, Prohlášením o použitelnosti, operativním plánováním a dokumentovanými důkazy. Může vzorkovat činnosti zpracování z REG02 a testovat, zda jsou opatření jako 5.34, 5.12, 5.14, 5.19 až 5.23, 8.11, 8.12, 8.15, 8.16 a 8.24 implementována a monitorována.
Auditor nebo regulační orgán zaměřený na GDPR bude testovat odpovědnost. Může začít oznámením o ochraně osobních údajů, stížností, žádostí subjektu údajů nebo zpřístupněním dodavateli a postupovat zpětně. Proč byla tato data shromážděna? Jaký právní základ se použil? Byl účel určen? Bylo pozdější použití slučitelné? Byl příjemce autorizován? Byly fyzické osoby informovány? Byly záznamy aktualizovány před zahájením zpracování?
Dohledový orgán podle DORA se tam, kde je to použitelné, zaměří na podnikové funkce podporované ICT, poskytovatele ICT služeb třetích stran, smluvní doložky, práva na audit, ochranu dat, komunikaci incidentů, testování odolnosti a plánování ukončení. Pokud jsou PII zákazníků sdílena s kritickým poskytovatelem analytiky nebo cloudu, stávají se REG08, prověrka dodavatelů a smluvní kontroly klíčovými důkazy.
Hodnotitel NIST CSF zasadí problém do výsledků správy a řízení. Jsou právní a regulační požadavky řízeny? Jsou role a odpovědnosti jasné? Jsou politiky udržovány a uplatňovány? Jsou řízena rizika dodavatelů? Fungují výsledky ochrany dat, monitorování a reakce?
Auditor ve stylu COBIT nebo ISACA se zeptá, zda jsou definována rozhodovací práva, zda vlastníci společnosti akceptují riziko pro soukromí, zda se měří výkonnost kontrol, zda se sledují výjimky a zda vedení dostává smysluplný reporting.
| Typ auditora | Klíčové oblasti zaměření | Důkazy, které bude požadovat |
|---|---|---|
| Auditor ISO 27001 a ISO 27701 | Integrace ISMS a PIMS, účinnost kontrol, dokumentované důkazy | REG02, REG08, Prohlášení o použitelnosti, ošetření rizik, důkazy k 5.34, záznamy maskování |
| Regulační orgán pro GDPR | Právní základ, omezení účelu, minimalizace, transparentnost, odpovědnost | Posouzení slučitelnosti, odůvodnění nezbytnosti, oznámení o ochraně osobních údajů, schválení zpřístupnění |
| Dohledový orgán podle DORA | Riziko ICT, odolnost třetích stran, dohled správní rady, smluvní kontroly | Prověrka dodavatelů, registr smluv ICT, práva na audit, plán ukončení, postupy pro incidenty |
| Hodnotitel NIS2 | Opatření k řízení kybernetických rizik, dodavatelský řetězec, připravenost na incidenty, odpovědnost vedení | Přezkumy dodavatelů, důkazy o monitorování, řízení přístupu, evidence aktiv, incidentní playbooky |
| Auditor COBIT nebo ISACA | Vyspělost správy a řízení, role, vlastnictví procesů, metriky, zajištění | RACI, zápisy ze správy a řízení, KPI, sledování výjimek, záznamy z přezkoumání vedením |
Časté nedostatky, které Clarysec nachází v implementacích
Prvním nedostatkem je zacházení s evidencí činností zpracování jako s dokumentačním cvičením, nikoli jako se schvalovací branou. Pokud je REG02 aktualizován po spuštění, nemůže prokázat předchozí správu a řízení.
Druhým je vágní vymezení účelu. „Analytika“, „zlepšování služby“ nebo „zákaznické poznatky“ jsou jen zřídka dostatečně konkrétní pro řízení interního použití nebo sekundárního využití.
Třetím je chybějící nezbytnost na úrovni polí. Minimalizaci údajů nelze prokázat tvrzením, že každé pole je užitečné. Podnik musí vysvětlit, proč je každé pole nezbytné pro schválený účel.
Čtvrtým je neřízené sekundární využití. Data shromážděná pro správu účtu se tiše stávají obchodní analytikou, poté marketingovou segmentací a nakonec trénováním AI. Každá změna účelu vyžaduje analýzu slučitelnosti a v některých případech nový právní základ nebo aktualizaci transparentních informací.
Pátým je slabá správa zpřístupnění. Seznamy dodavatelů nejsou totéž co záznamy o zpřístupnění. REG08 propojuje příjemce, roli, účel, kategorie PII, lokalitu, frekvenci a zdroj oprávnění do jedné schvalovací stopy.
Šestým je chybějící technické vynucování. Politiky mohou říkat, že PII nemají opouštět schválené kanály, ale e-mail, exporty, sdílené disky a analytické nástroje to často umožňují. Zde se stávají nezbytnými opatření ISO/IEC 27002:2022 5.14, 8.12, 8.15, 8.16 a 8.24.
Praktický 30denní startovací plán
Organizace nemusí řešit vše najednou. Začněte jednou vysoce rizikovou činností zpracování, ideálně takovou, která zahrnuje profilování zákazníků, analytiku AI, citlivé atributy, přeshraniční přenos nebo platformu třetí strany.
V prvním týdnu identifikujte činnost zpracování, vlastníka, kategorie PII, systémy, dodavatele a aktuální účel. Ověřte, zda je činnost již zastoupena v REG02 a zda je zpřístupnění zastoupeno v REG08.
Ve druhém týdnu doplňte odůvodnění nezbytnosti na úrovni polí. Zpochybněte nadměrné datové prvky. Potvrďte klasifikaci a označování. Určete, zda maskování, agregace nebo pseudonymizace mohou snížit riziko.
Ve třetím týdnu definujte pravidla interního použití a proveďte případná posouzení slučitelnosti sekundárního využití. Rozhodněte, zda je třeba aktualizovat oznámení o ochraně osobních údajů, posouzení právního základu nebo kontroly pro subjekty údajů.
Ve čtvrtém týdnu validujte záznamy externího zpřístupnění, přístup dodavatelů, smluvní záruky, podmínky DPA, opatření pro přenos, protokolování, DLP a povinnosti výmazu. Poté vzorkujte skutečné chování systému proti schválením.
Na konci 30 dnů má mít vedení konkrétní balíček důkazů: REG02, REG08, záznamy klasifikace, matice přístupů, důkazy DLP a protokolování, prověrku dodavatelů, smluvní záruky, posouzení slučitelnosti a otevřená nápravná opatření.
Od politiky k důkazu
Správa shromažďování, používání a zpřístupňování PII je místem, kde se ochrana soukromí stává skutečností. Je to rozdíl mezi tvrzením „jsme v souladu s GDPR“ a prokázáním, že každé rozhodnutí o shromažďování, použití, opětovném využití a zpřístupnění bylo řízeno před tím, než zpracování proběhlo.
Sada nástrojů Clarysec poskytuje týmům ochrany soukromí, bezpečnosti a compliance praktickou cestu:
- Použijte PII09 Politika shromažďování, používání, zpřístupňování a sdílení PII k definování povinných schvalovacích bran.
- Použijte P17 Politika ochrany dat a soukromí nebo Politika ochrany dat a soukromí pro SME k ukotvení zákonného, korektního, transparentního a minimalizovaného zpracování.
- Použijte Politika klasifikace dat a označování a Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran pro SME k řízení klasifikace, sdílení a přístupu dodavatelů.
- Postupujte podle Zenith Blueprint: 30krokový plán auditora, abyste implementovali kontrolní prostředí ve správném pořadí.
- Použijte Zenith Controls: průvodce souladem napříč rámci, abyste pochopili, jak opatření ISO/IEC 27002:2022, jako jsou 5.34, 5.12, 5.14, 8.11 a 8.12, podporují GDPR, NIS2, DORA, NIST a auditní očekávání.
Pokud se vás příští audit, požadavek zákazníka na prověrku nebo přezkum správní radou zeptá, jak řídíte, jaké PII se shromažďují, jak se používají a kdy se zpřístupňují, nespoléhejte pouze na prohlášení v politikách.
Začněte jednou vysoce rizikovou činností. Vytvořte záznam REG02. Odůvodněte každý datový prvek. Definujte pravidla interního použití. Proveďte posouzení slučitelnosti sekundárního využití. Vytvořte záznam zpřístupnění REG08. Poté otestujte, zda přístup, DLP, maskování, protokolování, šifrování a kontroly dodavatelů odpovídají rozhodnutí.
Tak se odpovědnost podle ISO/IEC 27701:2025 a GDPR stává důkazem.
Prozkoumejte sadu nástrojů Clarysec PIMS, začněte s PII09 Politika shromažďování, používání, zpřístupňování a sdílení PII a použijte Zenith Blueprint, abyste správu a řízení ochrany soukromí převedli ze záměru politiky do auditovatelných důkazů.
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


