Mapování RoPA a toků dat pro GDPR, NIS2 a DORA

Je úterý 09:10 a CISO, DPO, vedoucí nákupu a provozní ředitel jsou ve stejném videohovoru, ale nedívají se na stejné důkazy.

DPO má záznamy o činnostech zpracování (RoPA), které uvádějí onboarding zákazníků, zpracování mezd zaměstnanců, tikety podpory a marketingovou analytiku. CISO má evidenci cloudových aktiv. Nákup má smlouvy s dodavateli. Provoz má tabulku pro kontinuitu činností. Finance mají registr informací podle DORA. Nikdo nedokáže odpovědět na nejzákladnější propojenou otázku regulačního orgánu:

Pokud tato služba onboardingu plateb selže, které systémy, dodavatelé, kategorie dat, dílčí zpracovatelé, přeshraniční předávání dat a kritické podnikové funkce budou dotčeny?

Tato otázka je skutečným testem souladu pro rok 2026.

GDPR nadále vyžaduje prokazatelné záznamy podle Article 30. NIS2 změnila kybernetickou bezpečnost v otázku odpovědnosti řídicích orgánů u základních a významných subjektů. DORA vyžaduje, aby finanční subjekty dokládaly závislosti ICT, kritické nebo důležité funkce, ujednání s třetími stranami v oblasti ICT, klasifikaci incidentů a testování odolnosti. ISO/IEC 27001:2022 poskytuje strukturu systému řízení, která to celé drží pohromadě, avšak pouze tehdy, pokud jsou RoPA a mapování toků dat chápány jako živé důkazy správy a řízení, nikoli jako tabulky týmu ochrany soukromí.

V Clarysec vidíme stejný vzorec u rychle rostoucích SaaS, fintech, cloudových, MSP a B2B technologických společností. Mají dost dokumentace na vyplnění dotazníku, ale nemají dost propojených důkazů, aby obstály při přezkumu dozorovým orgánem, kybernetickém incidentu, selhání dodavatele nebo interním auditu. Problémem bývá málokdy nedostatek informací. Problémem je nedostatek propojení.

Řešením je udělat z RoPA a mapování toků dat společnou vrstvu důkazů pro ochranu soukromí, kybernetickou odolnost, řízení dodavatelů, správu cloudových služeb a kontinuitu činností.

Proč se RoPA a mapování toků dat staly otázkou správy a řízení pro rok 2026

RoPA byla dříve vnímána jako artefakt ochrany soukromí. Mapy toků dat se často vytvářely během DPIA, migrace do cloudu nebo přezkumu bezpečnostní architektury a poté zůstaly bez aktualizace. Tento přístup již nefunguje.

GDPR se široce vztahuje na zpracování osobních údajů v souvislosti s provozovnou v EU a také na mnoho správců nebo zpracovatelů mimo EU, kteří nabízejí zboží nebo služby osobám v EU nebo monitorují jejich chování. Osobní údaje zahrnují informace vztahující se k identifikované nebo identifikovatelné osobě. Zpracování zahrnuje shromažďování, ukládání, použití, zpřístupnění, omezení, výmaz a zničení. Správce určuje účely a prostředky, zatímco zpracovatel jedná jménem správce.

RoPA proto není jen seznam databází. Je to záznam obchodních účelů, kategorií údajů, rolí, příjemců, dob uchovávání, ochranných opatření a mezinárodních závislostí.

NIS2 přidává pohled odolnosti služeb. Do působnosti zahrnuje řadu středních a větších organizací ve vysoce kritických a dalších kritických odvětvích, včetně digitální infrastruktury, poskytovatelů cloudových služeb, poskytovatelů služeb datových center, sítí pro doručování obsahu, poskytovatelů služeb vytvářejících důvěru, poskytovatelů veřejných elektronických komunikací, poskytovatelů řízených služeb a poskytovatelů řízených bezpečnostních služeb. Příloha I zahrnuje také bankovnictví a infrastruktury finančních trhů. Některé subjekty mohou spadat do působnosti bez ohledu na velikost, včetně vybraných poskytovatelů DNS, TLD, služeb vytvářejících důvěru a veřejných komunikací a subjektů, jejichž narušení by mohlo významně ovlivnit veřejnou bezpečnost, veřejné zdraví, systémové riziko nebo kritické společenské a ekonomické činnosti.

NIS2 Article 21 vyžaduje přiměřená technická, provozní a organizační opatření pro sítě a informační systémy používané k provozu nebo poskytování služeb. Minimální oblasti zahrnují analýzu rizik, bezpečnostní politiky, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečný vývoj, hodnocení účinnosti, kybernetickou hygienu, kryptografii, bezpečnost lidských zdrojů, řízení přístupu, správu aktiv a autentizaci.

U subjektu podle NIS2 je RoPA bez pohledu na závislosti služeb neúplná. Významný incident musí být pochopen z hlediska dopadu na služby, provozního narušení, dotčených příjemců, dodavatelů a přeshraničních dopadů.

DORA stejný bod pro finanční subjekty dále zpřesňuje. Použije se od 17. ledna 2025 a stanoví jednotné požadavky na řízení rizik v oblasti ICT, oznamování závažných incidentů souvisejících s ICT, testování digitální provozní odolnosti, sdílení informací o kybernetických hrozbách a zranitelnostech, rizika třetích stran v oblasti ICT a smluvní ujednání s poskytovateli služeb ICT z řad třetích stran. DORA vymezuje služby ICT široce jako digitální a datové služby poskytované prostřednictvím systémů ICT na průběžném základě. Kritickou nebo důležitou funkci vymezuje jako funkci, jejíž narušení by podstatně zhoršilo finanční výkonnost, kontinuitu služby nebo povinnosti v oblasti souladu.

U finančních subjektů, které jsou zároveň identifikovány podle vnitrostátní transpozice NIS2, se DORA považuje za odvětvový právní akt Unie pro rovnocenné požadavky na rizika ICT, oznamování incidentů, testování, sdílení informací a rizika třetích stran. V praxi nemůže fintech budovat jednu sadu důkazů pro ochranu soukromí, druhou pro DORA a třetí pro NIS2. Potřebuje jednu vrstvu správy dat, která zohledňuje závislosti.

Touto vrstvou je RoPA plus mapování toků dat.

ISO/IEC 27001:2022 je páteří

ISO/IEC 27001:2022 je pro tento typ integrace navržena. Zavádí škálovatelný systém řízení bezpečnosti informací (ISMS), určený k zachování důvěrnosti, integrity a dostupnosti prostřednictvím řízení rizik. Norma je určena k začlenění do procesů organizace a ke škálování podle jejích potřeb, velikosti a struktury.

Výchozím bodem není nástroj pro kreslení diagramů. Výchozím bodem je rozsah.

Kapitoly ISO/IEC 27001:2022 4.1 až 4.4 vyžadují, aby organizace definovala kontext, zainteresované strany, rozsah ISMS a vzájemně působící procesy. Rozsah musí zohlednit právní, regulační a smluvní povinnosti, stejně jako rozhraní a závislosti mezi interními činnostmi a činnostmi vykonávanými jinými organizacemi. Pro RoPA a mapování toků dat to znamená, že rozsah ISMS má výslovně zachytit outsourcované cloudové platformy, zpracovatele plateb, poskytovatele identit, nástroje podpory, poskytovatele řízených bezpečnostních služeb a SaaS integrace kritické pro podnikání.

Kapitoly 5.1 až 5.3 činí vedení odpovědným za politiku, zdroje, přiřazení rolí a reportování. To odpovídá směru NIS2 Article 20, který vyžaduje, aby řídicí orgány schvalovaly opatření řízení kybernetických rizik, dohlížely na jejich zavedení a absolvovaly školení. Je to také v souladu s DORA Article 5, který dává řídicímu orgánu konečnou odpovědnost za rizika ICT a dohled nad politikami, strategií odolnosti, plány kontinuity, plány auditů, službami ICT poskytovanými třetími stranami a kanály pro hlášení závažných incidentů.

Kapitoly 6.1.1 až 6.1.3 poskytují plánovací mechanismus: identifikovat rizika pro důvěrnost, integritu a dostupnost, přiřadit vlastníky rizik, analyzovat dopady a pravděpodobnost, vybrat možnosti ošetření, porovnat opatření s přílohou A, vytvořit Prohlášení o použitelnosti a získat schválení vlastníka rizika.

Zde se RoPA stává provozním nástrojem. Každá činnost zpracování a každý tok dat musí být propojeny s riziky, opatřeními, dodavateli, aktivy a kritickými službami. Pokud tomu tak není, zůstane RoPA evidencí pro ochranu soukromí, která nedokáže podpořit reakci na incidenty, testování odolnosti ani rozhodnutí o dodavatelských rizicích.

Clarysec Zenith Blueprint: 30krokový plán auditora to převádí do praxe ve fázi řízení rizik, krok 9, Identifikace aktiv, hrozeb a zranitelností:

U každého aktiva zaznamenejte klíčové údaje: název/popis, vlastník, umístění a klasifikace (citlivost). Aktivem může být například „Databáze zákazníků – vlastněná IT oddělením – hostovaná na AWS – obsahuje osobní a finanční údaje (vysoká citlivost).“

Stejný krok 9 přidává klíčový poznatek pro soulad: aktiva obsahující osobní údaje mají být označena z hlediska relevance pro GDPR a aktiva kritických služeb mají být zaznamenána pro možnou použitelnost NIS2, pokud organizace působí v regulovaném odvětví. To je most mezi RoPA, evidencí aktiv a mapováním závislostí kritických služeb.

Co musí obsahovat auditovatelná RoPA

Silná RoPA nemusí být složitá, ale musí být propojená.

GDPR Article 5 vyžaduje, aby osobní údaje byly zpracovávány zákonně, korektně a transparentně, shromažďovány pro určené a legitimní účely, omezeny na nezbytný rozsah, udržovány přesné, uchovávány pouze po nezbytně dlouhou dobu a zabezpečeny vhodnými technickými a organizačními opatřeními. Article 5(2) vyžaduje, aby správce odpovídal za soulad a byl schopen jej doložit.

Article 6 vyžaduje právní základ, například souhlas, nezbytnost pro plnění smlouvy, právní povinnost, životně důležité zájmy, úkol prováděný ve veřejném zájmu nebo oprávněné zájmy. Pokud zpracování probíhá pro nový účel, musí být posouzena slučitelnost s ohledem na původní a nový účel, kontext shromažďování, citlivost, dopady na fyzické osoby a záruky, jako je šifrování nebo pseudonymizace. Article 9 doplňuje přísnější pravidla pro zvláštní kategorie osobních údajů, včetně údajů o zdravotním stavu, biometrických údajů používaných k jedinečné identifikaci a dalších citlivých kategorií.

Sada politik Clarysec pro SME z toho činí provozní požadavek. Politika ochrany dat a soukromí - SME uvádí:

Koordinátor ochrany soukromí musí vést registr všech činností zpracování osobních údajů, včetně kategorií dat, účelu, právního základu a dob uchovávání.

Toto ustanovení pochází ze sekce Požadavky na správu a řízení, kapitola 5.2.1. Pro větší organizace přiřazuje Politika ochrany dat a soukromí odpovědnost přímo:

Vede záznamy o činnostech zpracování (RoPA) v souladu s GDPR Article 30.

Toto znění pochází z části Role a odpovědnosti, kapitola 4.2.2. Praktické sdělení je jednoduché: vlastnictví RoPA musí být přiřazeno. Nesmí jít o osiřelou tabulku pro soulad.

RoPA připravená pro rok 2026 by měla obsahovat následující pole.

Poslední řádky posouvají RoPA z dokumentace ochrany soukromí do důkazů kybernetické odolnosti. Bez systémů, dodavatelů, umístění, kritičnosti a opatření může RoPA splnit úzký kontrolní seznam podle Article 30, ale selže, jakmile incident, výpadek nebo přezkum dozorovým orgánem vyžaduje analýzu dopadů.

Mapování toků dat propojuje ochranu soukromí, cloud a kritické služby

Pokud RoPA odpovídá na otázku „jaké zpracování existuje a proč“, mapa toků dat odpovídá na otázku „kam data tečou, kdo s nimi pracuje, co je chrání a co se pokazí, pokud se tok zastaví“.

Clarysec Politika maskování dat a pseudonymizace - SME stanoví požadavek jednoznačně:

Mapa toku dat musí být vytvořena.

Toto pochází z části Požadavky na správu a řízení, kapitola 5.1.1.1. Podniková verze, Politika maskování dat a pseudonymizace, rozšiřuje očekávání v kapitole 5.2.1:

Udržovat aktuální evidenci systémů a toků dat zahrnujících citlivá data.

Kapitola 5.2.2 doplňuje:

Mapovat, kde a jak jsou data transformována, sdílena nebo zpřístupňována napříč prostředími.

Auditoři a regulační orgány nehledají umělecké diagramy. Chtějí rozumět transformacím, cestám přístupu, sdílení, prostředím a ochranným opatřením.

V Zenith Blueprint, ve fázi Controls in Action, krok 22, Organizační opatření 5.1 až 5.18, metodika přenosu informací vysvětluje, že organizace musí definovat povolené metody přenosu, sladit je s klasifikací a zajistit, aby strany rozuměly svým rolím a povinnostem. Uvádí příklady, jako je šifrovaný e-mail, zabezpečené portály, SFTP, rozhraní API a fyzické doručení se šifrováním. Zároveň upozorňuje, že osobní údaje předávané přes hranice musí splňovat povinnosti v oblasti ochrany soukromí a právní povinnosti, nikoli jen interní preference.

Stejný krok propojuje přenos informací s klasifikací a označováním, prevencí úniku dat, vztahy s dodavateli a kryptografií. Tím vzniká praktický model pro mapování toků dat:

1. Identifikujte zdrojový systém, například CRM, platební platformu, HRIS nebo servisní pracoviště.
2. Identifikujte kategorii dat, včetně osobních údajů, finančních údajů, údajů zaměstnanců, údajů zvláštní kategorie nebo přihlašovacích údajů.
3. Identifikujte způsob přenosu, například API, SFTP, e-mail, zabezpečený portál, manuální export nebo replikaci záloh.
4. Identifikujte cílové místo, včetně interního systému, cloudové služby, dodavatele, dílčího zpracovatele, datového skladu nebo archivu.
5. Identifikujte ochranu, například šifrování, pseudonymizaci, řízení přístupu, protokolování, DLP nebo smluvní omezení.
6. Identifikujte závislost, včetně toho, zda tok podporuje kritickou podnikovou funkci, kritickou nebo důležitou funkci, základní službu nebo oznamovací povinnost k incidentům.

Tři opatření přílohy A ISO/IEC 27001:2022 jsou zde obzvlášť důležitá. ISO/IEC 27002:2022 poskytuje implementační pokyny pro tato opatření:

Clarysec Zenith Controls: Průvodce křížovým souladem identifikuje 5.9, 5.14 a 5.34 jako tematicky související opatření pro tuto vrstvu správy a řízení. Zacházejte s nimi jako s kotevními opatřeními a poté je prostřednictvím Prohlášení o použitelnosti propojte s opatřeními pro dodavatele, cloud, incidenty, kontinuitu, protokolování, přístup a kryptografii.

Proč NIS2 a DORA potřebují víc než registr ochrany soukromí

Častou chybou je vytvořit RoPA, která je technicky správná podle GDPR, ale nepoužitelná pro NIS2 nebo DORA. Rozdílem je kritičnost služby.

NIS2 Article 23 vyžaduje, aby základní a významné subjekty oznamovaly významné incidenty bez zbytečného odkladu. Model hlášení zahrnuje včasné varování do 24 hodin, oznámení incidentu do 72 hodin a závěrečnou zprávu do jednoho měsíce. Významné incidenty se posuzují podle závažného provozního narušení, finanční ztráty nebo materiální či nemateriální újmy jiným fyzickým nebo právnickým osobám. Toto posouzení závisí na znalosti toho, které služby, příjemci, země, systémy a dodavatelé jsou dotčeni.

DORA Article 17 vyžaduje, aby finanční subjekty definovaly a implementovaly proces řízení incidentů souvisejících s ICT, který detekuje, řídí a oznamuje incidenty, zaznamenává incidenty a významné kybernetické hrozby, identifikuje kořenové příčiny, stanovuje indikátory včasného varování, klasifikuje incidenty podle závažnosti a kritičnosti dotčených služeb, přiřazuje role a vytváří komunikační a eskalační postupy. Article 18 vyžaduje klasifikaci s využitím dotčených klientů nebo protistran a transakcí, trvání a doby výpadku, geografického rozsahu, ztráty dat ovlivňující dostupnost, autenticitu, integritu nebo důvěrnost, kritičnosti dotčených služeb a ekonomického dopadu.

Incident nelze rychle klasifikovat, pokud neznáte tok dat a řetězec závislostí.

Clarysec Politika kontinuity činností a obnovy po havárii - SME upozorňuje na důkazní pole, která organizace potřebují:

prioritizované služby a systémy (kritické podnikové funkce)

Toto pochází z části Požadavky na správu a řízení, kapitola 5.2.1.2. Podniková Politika kontinuity činností a obnovy po havárii doplňuje rozměr závislostí v kapitole 5.2.4:

Kritické závislosti (systémy, dodavatelé, personál)

U organizací regulovaných DORA to musí být sladěno s kritickými nebo důležitými funkcemi, službami ICT, smluvními ujednáními a exit strategiemi. DORA Article 28 vyžaduje, aby riziko třetích stran v oblasti ICT bylo řízeno jako součást rámce rizik ICT. Nařizuje registr smluvních ujednání o službách ICT, vyžaduje předuzavírací prověrku dodavatelů a posouzení kritičnosti, rizika koncentrace, vhodnosti a střetů zájmů a vyžaduje exit strategie pro služby ICT podporující kritické nebo důležité funkce.

DORA Article 30 stanoví minimální smluvní podmínky pro ICT, včetně popisu služeb, podmínek subdodávek, umístění zpracování a ukládání dat, ochrany údajů, přístupu, obnovy a vrácení dat, úrovní služeb, pomoci při incidentech, spolupráce s orgány, práv na ukončení, práv na audit a přechodných nebo exit ujednání.

RoPA, která neidentifikuje dodavatele, umístění, metody přenosu, kritičnost a exit závislosti, nepodpoří důkazy podle DORA.

Mapování dodavatelů, cloudu a dílčích zpracovatelů je místem, kde důkazy často selhávají

Ve skutečných auditech se selhání RoPA často projeví jako selhání u dodavatelů. Činnost zpracování uvádí „zákaznická podpora“. Mapa toků dat uvádí „platforma podpory“. Nikdo však nedokáže určit hostingový region, doplněk pro AI transkripci, analytického dílčího zpracovatele, dobu uchovávání příloh tiketů, model administrátorského přístupu nebo postup ukončení.

Politika Clarysec pro dodavatele v prostředí SME vytváří minimální provozní důkazy. Bezpečnostní politika dodavatelů a poskytovatelů služeb třetích stran - SME uvádí:

Registr dodavatelů musí být veden a aktualizován administrativním kontaktem nebo kontaktem pro nákup. Musí obsahovat:

Toto pochází z části Požadavky na správu a řízení, kapitola 5.4. Politika cloudu doplňuje samostatný požadavek na evidenci. Politika používání cloudových služeb - SME uvádí:

Registr cloudových služeb musí být veden poskytovatelem IT služeb nebo generálním ředitelem. Musí zaznamenávat:

Toto pochází z části Požadavky na správu a řízení, kapitola 5.3. Pro podnikové riziko závislostí je Clarysec Politika řízení rizik závislostí na dodavatelích výslovnější:

Registr závislostí na dodavatelích: VMO musí vést aktuální registr všech kritických dodavatelů, včetně podrobností, jako jsou poskytované služby/produkty; zda je dodavatel jediným zdrojem; dostupní alternativní dodavatelé nebo zastupitelnost; aktuální smluvní podmínky; a posouzení dopadu, pokud by dodavatel selhal nebo byl kompromitován. Registr musí jasně identifikovat dodavatele s vysokou mírou závislosti (např. ty, u nichž neexistuje rychlá alternativa).

Tento požadavek z kapitoly 6.1 Požadavků na implementaci přesně propojuje RoPA se zabezpečením dodavatelského řetězce podle NIS2 a rizikem třetích stran v oblasti ICT podle DORA.

Zenith Blueprint, ve fázi Controls in Action, krok 23, Organizační opatření 5.19 až 5.37, doporučuje sestavit úplný seznam dodavatelů, klasifikovat dodavatele podle přístupu k systémům, datům nebo provozní kontrole, začlenit bezpečnostní očekávání do smluv, přezkoumávat subdodavatele, stanovit spouštěče změn u dodavatelů a vybudovat proces hodnocení cloudových služeb pokrývající umístění dat, model přístupu, protokolování a šifrování.

To umožňuje CISO během incidentu odpovědět: „Která kritická služba tohoto dodavatele používá, která data byla exponována, které zákazníky je třeba informovat, kterému regulačnímu orgánu může být nutné podat hlášení a jaký alternativní dodavatel nebo exit cesta existuje?“

Praktický příklad: onboarding zákazníků ve fintechu

Uvažujme fintech, který poskytuje onboarding digitálních peněženek. Zákazníci nahrávají doklady totožnosti, kontrolu biometrické živosti provádí dodavatel, výsledky jsou ukládány v cloudové databázi a zákaznická podpora může zobrazit stav ověření v nástroji pro správu tiketů.

Služba onboardingu může být podle DORA kritickou nebo důležitou funkcí, protože její narušení významně ovlivňuje kontinuitu služby a regulační povinnosti. Pokud je společnost v odvětví podle NIS2 nebo poskytuje relevantní služby ICT, může být také součástí důkazů o kritické službě.

Užitečná mapa začíná jedním propojeným záznamem.

Nyní doplňte dohledatelnost ošetření rizik podle ISO/IEC 27001:2022.

V Zenith Blueprint, ve fázi řízení rizik, krok 13, Plánování ošetření rizik a Prohlášení o použitelnosti, Clarysec popisuje SoA jako spojovací dokument propojující posouzení rizik a jejich ošetření se skutečnými opatřeními. Doporučuje mapovat opatření na rizika a v registru rizik nebo poznámkách SoA křížově odkazovat právní předpisy, jako jsou GDPR, NIS2 nebo DORA, kde je to relevantní.

Pro příklad onboardingu může rizikový scénář znít: „Výpadek nebo kompromitace poskytovatele ověření identity naruší onboarding a exponuje biometrická identifikační data.“ Opatření ošetření mohou zahrnovat prověrku dodavatele, smluvní oznamování incidentů, šifrování, řízení přístupu, protokolování, zálohování a obnovu, minimalizaci údajů, pseudonymizaci, monitorování, plánování ukončení spolupráce a playbooky reakce na incidenty.

Poznámka SoA může uvést, že soubor opatření podporuje odpovědnost podle GDPR, připravenost na dodavatelský řetězec a incidenty podle NIS2 Article 21 a riziko třetích stran v oblasti ICT a odolnost kritických funkcí podle DORA.

To je to, co auditoři chtějí: dohledatelnost.

Mapování křížového souladu: jedna vrstva důkazů, více otázek

RoPA a mapování toků dat nejsou oddělená sila souladu. Podporují společnou sadu otázek napříč GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 a COBIT 2019.

NIST CSF 2.0 je užitečný jako organizační vrstva. Jeho profily CSF podporují analýzu aktuálního a cílového stavu s využitím vstupů, jako jsou politiky, priority rizik, registry dopadů na podnikání, požadavky, normy, postupy, nástroje a pracovní role. Funkce GOVERN zahrnuje právní, regulační, smluvní povinnosti, povinnosti ochrany soukromí a občanských svobod, cíle rizik, odpovědnost vedení, role, politiku, dohled a přezkum výkonnosti. Výsledky pro dodavatelský řetězec vyžadují, aby dodavatelé byli známi a prioritizováni podle kritičnosti, aby byly integrovány smluvní požadavky na kybernetickou bezpečnost, aby před zahájením vztahů proběhla náležitá péče, aby byla rizika dodavatelů zaznamenávána a monitorována a aby byli dodavatelé zahrnuti do plánování reakce na incidenty a obnovy.

To se přesně mapuje na provozní model Clarysec RoPA. RoPA poskytuje kontext ochrany soukromí. Evidence aktiv poskytuje technický kontext. Registry dodavatelů a cloudových služeb poskytují kontext třetích stran. BIA poskytuje kontext kritičnosti. SoA poskytuje kontext opatření.

Jedno opatření přílohy A ISO/IEC 27001:2022 může také podporovat několik rámců. Dobrým příkladem je opatření 5.14, Přenos informací.

To je hodnota Zenith Controls jako kompasu křížového souladu. Pomáhá organizacím vysvětlit, proč jedna praxe opatření podporuje více regulačních a auditních očekávání.

Jak různí auditoři otestují stejnou mapu

Vyspělá RoPA a mapa toků dat mohou uspokojit více auditorů, každý k nim však přistoupí jinak.

Auditor ISO/IEC 27001:2022 začne rozsahem, zainteresovanými stranami, riziky, dokumentovanými informacemi a výběrem opatření. Bude se ptát, zda byly identifikovány právní a smluvní požadavky, zda osobní údaje a kritické služby spadají do rozsahu ISMS, zda aktiva mají vlastníky a klasifikace, zda posouzení rizik zohlednilo důvěrnost, integritu a dostupnost a zda SoA odůvodňuje použitelná opatření.

Auditor GDPR nebo regulační orgán pro ochranu soukromí začne odpovědností. Ověří, zda RoPA odráží skutečné zpracování, zda jsou dokumentovány účely a právní základy, zda jsou identifikována data zvláštní kategorie, zda jsou uplatňovány doby uchovávání, zda jsou příjemci a zpracovatelé přesní a zda existují vhodná ochranná opatření pro předávání a bezpečnost.

Auditor zaměřený na NIS2 se podívá na dopad na služby. Zeptá se, jak organizace určuje kritické nebo důležité služby, jak vedení schválilo riziková opatření a dohlíží na ně, jak jsou zohledněny zranitelnosti dodavatelů a rizika poskytovatelů služeb, jak jsou propojeny kontinuita a zvládání incidentů a zda organizace dokáže podpořit 24hodinové, 72hodinové a závěrečné lhůty pro hlášení spolehlivými důkazy.

Auditor DORA se zaměří na řízení rizik ICT a kritické nebo důležité funkce. Ověří, zda řídicí orgán schválil rámec rizik ICT a strategii odolnosti, zda jsou registrována ujednání s třetími stranami v oblasti ICT, zda je posuzována kritičnost a riziko koncentrace, zda smlouvy obsahují požadované podmínky, zda testování pokrývá systémy podporující kritické nebo důležité funkce a zda jsou incidenty klasifikovány podle dotčených klientů, transakcí, doby výpadku, geografie, ztráty dat, kritičnosti služby a ekonomického dopadu.

Hodnotitel NIST CSF 2.0 bude často používat profily. Porovná aktuální a cílové výsledky napříč funkcemi GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. RoPA a mapy toků dat se stávají vstupy do řízení právních povinností, evidence aktiv, dodavatelského rizika, ochrany údajů, monitorování, komunikace při incidentech a plánování obnovy.

Auditor podle COBIT 2019 nebo ve stylu ISACA se zaměří na správu a řízení, vlastnictví a způsobilost procesů. Ověří, zda mají informační toky vlastníky, zda jsou jasná rozhodovací práva, zda se uplatňuje ochota podstupovat riziko, zda jsou opatření monitorována, zda jsou výjimky eskalovány a zda jsou důkazy dostatečně spolehlivé pro ujištění vedení.

Časté vzorce selhání

Nejčastější selhání RoPA a mapování toků dat jsou předvídatelná.

Zaprvé, RoPA uvádí činnosti zpracování, ale ne systémy. To znemožňuje propojit odpovědnost podle GDPR s řízením zranitelností, přezkumem přístupových práv, zálohováním, protokolováním nebo reakcí na incidenty.

Zadruhé, mapy toků dat končí u prvního dodavatele. Nezobrazují dílčí zpracovatele, cloudové regiony, přístup podpory, analytické nástroje, monitorovací platformy ani umístění záloh.

Zatřetí, plány kontinuity činností identifikují systémy, ale ne osobní údaje. Během výpadku organizace rozumí prioritě obnovy, ale nikoli dopadu na ochranu soukromí.

Začtvrté, registry dodavatelů zachycují vlastníky smluv, ale ne kritičnost, zastupitelnost, kategorie dat, povinnosti oznamování incidentů nebo možnosti ukončení.

Zapáté, SoA je napsáno jako certifikační dokument, nikoli jako most mezi opatřeními. Říká, že opatření jsou použitelná, ale nevysvětluje, který problém důkazů podle GDPR, NIS2 nebo DORA dané opatření pomáhá řešit.

Nakonec je roztříštěné vlastnictví. DPO vlastní RoPA, IT vlastní aktiva, nákup vlastní dodavatele, provoz vlastní BIA, finance vlastní registry DORA a nikdo nevlastní integrovanou mapu závislostí.

Přístup Clarysec to řeší přiřazením důkazních objektů vlastníkům politik a následným použitím kroků Zenith Blueprint k propojení aktiv, rizik, opatření a dohledatelnosti SoA.

30denní plán implementace

Nemusíte řešit vše najednou. Začněte službami, na kterých záleží nejvíce.

Týden 1: Vyberte tři kritické nebo vysoce rizikové činnosti zpracování. Vhodnými kandidáty jsou onboarding zákazníků, zpracování plateb, správa HR zaměstnanců, ticketing podpory nebo bezpečnostní monitorování. U každé činnosti ověřte záznam RoPA vůči skutečným systémům, kategoriím dat, účelům, právním základům a pravidlům uchovávání.

Týden 2: Vytvořte mapy toků dat pro tyto činnosti. Identifikujte zdroj, cíl, způsob přenosu, prostředí, dodavatele, dílčího zpracovatele, umístění dat, cestu přístupu, transformaci a retenční bod. Využijte požadavek Clarysec Politiky maskování dat a pseudonymizace na vedení evidence systémů a toků dat zahrnujících citlivá data.

Týden 3: Propojte každý tok s aktivy, dodavateli, cloudovými službami a kritickými podnikovými funkcemi. Použijte Zenith Blueprint krok 9 pro vlastnictví a klasifikaci aktiv. Použijte požadavky politik na registr dodavatelů a registr cloudových služeb k zachycení důkazů třetích stran. Použijte politiku kontinuity činností k identifikaci prioritizovaných služeb a kritických závislostí.

Týden 4: Doplňte dohledatelnost rizik a opatření. Pro každý tok vytvořte nebo aktualizujte rizikové scénáře. Namapujte opatření v SoA s využitím Zenith Blueprint kroku 13. Tam, kde je to relevantní, doplňte poznámky k odpovědnosti podle GDPR Article 30, opatřením řízení rizik podle NIS2 Article 21 a důkazům závislostí ICT podle DORA.

Poté proveďte jedno tabletop cvičení: „Výpadek dodavatele plus expozice dat v kritické službě.“ Otestujte, zda vaše důkazy podporují klasifikaci incidentu, rozhodnutí o oznámení, komunikaci se zákazníky, komunikaci s regulačním orgánem a prioritizaci obnovy.

Na konci 30 dnů budete mít opakovatelný model pro zbytek organizace.

Přístup Clarysec: proměňte RoPA v živé důkazy odolnosti

RoPA a mapování toků dat už nejsou jen administrativou ochrany soukromí. Jsou pojivovou tkání mezi odpovědností podle GDPR, správou a řízením kritických služeb podle NIS2 a důkazy závislostí ICT podle DORA.

Organizace, které budou v roce 2026 nejúspěšnější, nebudou ty s největším počtem dokumentů. Budou to ty, které dokážou dohledat obchodní službu až k jejím činnostem zpracování, tokům dat, systémům, dodavatelům, cloudovým regionům, smlouvám, opatřením, rizikům, prahovým hodnotám incidentů a plánům obnovy.

Clarysec pomáhá týmům budovat tuto dohledatelnost bez zbytečné byrokracie. Naše sada politik přiřazuje vlastnictví a požadavky na důkazy. Zenith Blueprint poskytuje implementační roadmapu, včetně identifikace aktiv, implementace opatření pro dodavatele a cloud a dohledatelnosti SoA. Zenith Controls poskytuje kompas křížového souladu pro mapování opatření přílohy A ISO/IEC 27001:2022 na očekávání v oblasti ochrany soukromí, odolnosti, dodavatelů, cloudu a auditu.

Váš další krok je jednoduchý: vyberte jednu kritickou službu, jeden záznam RoPA a jeden tok dat podporovaný dodavatelem. Zmapujte jej end-to-end. Pokud nedokážete na jedné stránce vysvětlit data, závislost, opatření a dopad incidentu, vaše vrstva důkazů není připravena na rok 2026.

Clarysec vám ji může pomoci připravit. Prozkoumejte Zenith Blueprint, posilte svou správu a řízení pomocí Politiky ochrany dat a soukromí a Politiky řízení rizik závislostí na dodavatelích a využijte Zenith Controls k proměně roztříštěných důkazů souladu v jeden auditovatelný provozní model.