⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

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

Igor Petreski
15 min read
Workflow správy a řízení PII pro ISO 27701 GDPR REG02 a REG08

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ý:

  1. Tým přidá do registračního formuláře nové pole, protože zlepšuje segmentaci.
  2. Nikdo nezaznamená, proč je právě toto pole nezbytné.
  3. Jiný tým později použije data pro jiný účel.
  4. Dodavatel obdrží export na základě široké smlouvy o službách.
  5. Záznamy o činnostech zpracování se aktualizují až po spuštění, pokud vůbec.
  6. 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í artefaktSpouštěč v politice ClarysecPraktický výsledek opatření
Jaké PII shromažďujeme?Záznam o zpracování v REG02Ustanovení PII09 4.1.1Shromažď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 REG02Ustanovení PII09 4.1.3Minimalizace údajů je doložena
Jak mohou týmy PII používat?Pravidla interního použití v REG02Ustanovení PII09 4.2.1Přístup a použití jsou vázány na účel
Můžeme PII znovu použít pro nový účel?Posouzení slučitelnosti v REG02Ustanovení PII09 4.3.1Sekundární využití je schváleno, podmíněno nebo zablokováno
Kdo externě obdrží PII?Záznam o zpřístupnění v REG08Ustanovení PII09 4.4.2Zpří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.1Pří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 REG02Příklad Project Wellness
Činnost zpracováníAnalytika finančního zdraví a funkce doporučení
Primární účelPoskytovat zákazníkům personalizované poznatky ke spoření a produktová doporučení
Kategorie subjektů PIIRetailoví zákazníci, majitelé účtů, oprávnění uživatelé
Kategorie PIIKategorie transakce, částka transakce, datum transakce, stav účtu, držené produkty
Zdroj nebo kanálPlatební platforma, záznamy zákaznických účtů, systémy používání produktů
Právní základUrč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 PIIOdůvodnění nezbytnostiRozhodnutí
Kategorie transakcePotřebná k identifikaci vzorců výdajů pro tipy ke spořeníSchváleno
Částka transakcePotřebná k výpočtu rozsahů trendů a relevance doporučeníSchváleno s prahovými hodnotami agregace
Datum transakcePotřebné pro analýzu trendůSchváleno na úrovni měsíce, kde je to možné
Název obchodníkaNení vyžadován pro první vydání a zvyšuje riziko opětovné identifikaceZamítnuto
Přesné časové razítkoNení nezbytné pro doporučení finančního zdravíZamítnuto
E-mail zákazníkaPotřebný pouze pro přiřazení k účtu, nikoli pro trénování modeluOmezeno
Držené produktyPotř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 REG08Požadovaný důkaz rozhodnutí
Identita příjemceNázev právnické osoby, vlastník služby a kontakt na dodavatele
Role příjemceZpracovatel, dílčí zpracovatel, samostatný správce nebo společný správce
Účel zpřístupněníDefinovaný analytický účel navázaný na Project Wellness
Kategorie PIIPouze 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:2022Název opatřeníProč je důležité pro správu a řízení PII
5.9Evidence informací a dalších souvisejících aktivDržené PII musí být známy dříve, než je lze chránit
5.12Klasifikace informacíPII musí být klasifikovány podle citlivosti a požadavků na nakládání
5.13Označování informacíŠtítky pomáhají vynucovat pravidla nakládání, sdílení a uchovávání
5.14Přenos informacíPohyb PII musí být autorizovaný, chráněný a dohledatelný
5.15Řízení přístupuPřístup k PII musí být omezen na schválené role a účely
5.16Správa identitUživatelé a servisní identity přistupující k PII musí být řízeni
5.19Bezpečnost informací ve vztazích s dodavateliRiziko dodavatelů týkající se PII musí být identifikováno a řízeno
5.20Řešení bezpečnosti informací ve smlouvách s dodavateliSmlouvy musí obsahovat bezpečnostní požadavky a požadavky na ochranu soukromí
5.21Řízení bezpečnosti informací v dodavatelském řetězci ICTRizika navazujících ICT a dílčích zpracovatelů musí být řízena
5.22Monitorová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.23Bezpečnost informací při používání cloudových služebSaaS a cloudové zpracování PII musí být řízeny
5.31Právní, zákonné, regulační a smluvní požadavkyGDPR, DORA, NIS2 a povinnosti vůči zákazníkům musí být identifikovány
5.34Ochrana soukromí a ochrana PIIOchrana PII musí být implementována podle požadavků na ochranu soukromí
8.11Maskování datSkutečné PII mají být skryty tam, kde nejsou úplná data nezbytná
8.12Prevence úniku datNeoprávněný pohyb PII má být detekován a předcházen
8.15ProtokolováníPřístup, změny a přenosy mají být doloženy
8.16Monitorovací činnostiPodezřelá nebo neoprávněná činnost má být detekována
8.24Používání kryptografiePII 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žimCo očekáváDůkazy Clarysec, které pomáhají
ISO/IEC 27701:2025 PIMSSpráva a řízení ochrany soukromí podle rolí pro povinnosti správce a zpracovateleUstanovení PII09, REG02, REG08, role ochrany soukromí, posouzení slučitelnosti
GDPROmezení úč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:2022Opatř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
NIS2Provozní 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 auditRegistry dodavatelů, smluvní doložky, řízení přístupu, důkazy o testování, logy zpřístupnění
NIST CSF 2.0Správa a řízení, právní požadavky, řízení rizik a výsledky ochrany datAktuální profil, cílový profil, mapování politik, registr rizik, akční plán opatření
COBIT 2019Odpovědnost za správu a řízení, vlastnictví procesů, zajištění a monitorování výkonnostiRACI, 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 auditoraKlíčové oblasti zaměřeníDůkazy, které bude požadovat
Auditor ISO 27001 a ISO 27701Integrace ISMS a PIMS, účinnost kontrol, dokumentované důkazyREG02, REG08, Prohlášení o použitelnosti, ošetření rizik, důkazy k 5.34, záznamy maskování
Regulační orgán pro GDPRPrávní základ, omezení účelu, minimalizace, transparentnost, odpovědnostPosouzení slučitelnosti, odůvodnění nezbytnosti, oznámení o ochraně osobních údajů, schválení zpřístupnění
Dohledový orgán podle DORARiziko ICT, odolnost třetích stran, dohled správní rady, smluvní kontrolyPrověrka dodavatelů, registr smluv ICT, práva na audit, plán ukončení, postupy pro incidenty
Hodnotitel NIS2Opatř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 ISACAVyspě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:

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

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

Share this article

Related Articles

Správa a řízení zabezpečení API: důkazní podklady pro ISO 27001 v roce 2026

Správa a řízení zabezpečení API: důkazní podklady pro ISO 27001 v roce 2026

Shadow API, slabé tokeny, chybějící omezování četnosti požadavků a nekonzistentní logy jsou dnes selháním správy a řízení. Tento hlavní průvodce ukazuje CISO, jak vytvořit důkazní podklady k zabezpečení API pro audity podle ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a audity sladěné s COBIT.