Mapiranje podatkovnih tokov za RoPA pri GDPR, NIS2 in DORA

Torek je, ura je 09:10, odgovorna oseba za informacijsko varnost (CISO), pooblaščena oseba za varstvo podatkov (DPO), vodja nabave in direktor operative pa so na istem videoklicu, vendar ne gledajo istih dokazil.

DPO ima evidenco dejavnosti obdelave oziroma RoPA, ki navaja uvajanje strank, obračun plač zaposlenih, zahtevke za podporo in trženjsko analitiko. CISO ima evidenco sredstev v oblaku. Nabava ima pogodbe z dobavitelji. Operativa ima preglednico za neprekinjeno poslovanje. Finance imajo register informacij po DORA. Nihče pa ne zna odgovoriti na najosnovnejše povezano vprašanje regulatorja:

Če ta storitev uvajanja plačil odpove, kateri sistemi, dobavitelji, kategorije podatkov, podobdelovalci, čezmejni prenosi in kritične poslovne funkcije so prizadeti?

To vprašanje je pravi preizkus skladnosti za leto 2026.

GDPR še vedno zahteva evidence za dokazovanje odgovornosti po Article 30. NIS2 je kibernetsko varnost spremenil v vprašanje odgovornosti poslovodnih organov pri bistvenih in pomembnih subjektih. DORA od finančnih subjektov zahteva dokazila o odvisnostih IKT, kritičnih ali pomembnih funkcijah, dogovorih s tretjimi ponudniki storitev IKT, razvrščanju incidentov in testiranju odpornosti. ISO/IEC 27001:2022 zagotavlja strukturo sistema upravljanja, ki vse to poveže, vendar le, če se RoPA in mapiranje podatkovnih tokov obravnavata kot živa dokazila upravljanja, ne kot preglednice ekipe za zasebnost.

V Clarysec vidimo enak vzorec v hitro rastočih podjetjih SaaS, fintech podjetjih, ponudnikih storitev v oblaku, MSP in B2B tehnoloških podjetjih. Imajo dovolj dokumentacije za odgovor na vprašalnik, vendar ne dovolj povezanih dokazil za nadzorni pregled, kibernetski incident, odpoved dobavitelja ali notranjo revizijo. Težava redko pomeni pomanjkanje informacij. Težava je pomanjkanje povezav.

Rešitev je, da RoPA in mapiranje podatkovnih tokov postaneta skupna plast dokazil za zasebnost, kibernetsko odpornost, upravljanje dobaviteljev, upravljanje storitev v oblaku in neprekinjeno poslovanje.

Zakaj sta RoPA in mapiranje podatkovnih tokov leta 2026 postala vprašanje upravljanja

RoPA se je včasih obravnavala kot artefakt zasebnosti. Zemljevidi podatkovnih tokov so bili pogosto pripravljeni med DPIA, migracijo v oblak ali pregledom varnostne arhitekture, nato pa prepuščeni zastaranju. Tak pristop ne deluje več.

GDPR se široko uporablja za obdelavo osebnih podatkov v okviru dejavnosti poslovne enote v EU ter tudi za številne upravljavce ali obdelovalce zunaj EU, ki posameznikom v EU ponujajo blago ali storitve ali spremljajo njihovo vedenje. Osebni podatki zajemajo informacije, ki se nanašajo na določeno ali določljivo osebo. Obdelava vključuje zbiranje, hrambo, uporabo, razkritje, omejitev, izbris in uničenje. Upravljavec določa namene in sredstva, obdelovalec pa deluje v imenu upravljavca.

RoPA zato ni zgolj seznam podatkovnih baz. Je evidenca poslovnih namenov, kategorij podatkov, vlog, prejemnikov, rokov hrambe, varovalnih ukrepov in mednarodnih odvisnosti.

NIS2 dodaja pogled skozi odpornost storitev. V področje uporabe vključuje številne srednje velike in večje organizacije v visoko kritičnih in drugih kritičnih sektorjih, vključno z digitalno infrastrukturo, ponudniki storitev računalništva v oblaku, ponudniki storitev podatkovnih centrov, omrežji za dostavo vsebin, ponudniki storitev zaupanja, ponudniki javnih elektronskih komunikacijskih omrežij ali storitev, ponudniki upravljanih storitev in ponudniki upravljanih varnostnih storitev. Priloga I vključuje tudi bančne infrastrukture in infrastrukture finančnega trga. Nekateri subjekti so lahko zajeti ne glede na velikost, vključno z določenimi ponudniki DNS, TLD, storitev zaupanja in javnih komunikacij ter subjekti, katerih motnja bi lahko znatno vplivala na javno varnost, javno zdravje, sistemsko tveganje ali kritične družbene in gospodarske dejavnosti.

NIS2 Article 21 zahteva sorazmerne tehnične, operativne in organizacijske ukrepe za omrežne in informacijske sisteme, ki se uporabljajo za delovanje ali zagotavljanje storitev. Minimalna področja vključujejo analizo tveganj, varnostne politike, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varen razvoj, ocenjevanje učinkovitosti, kibernetsko higieno, kriptografijo, varnost kadrov, nadzor dostopa, upravljanje sredstev in avtentikacijo.

Za subjekt NIS2 je RoPA brez pogleda na odvisnosti storitev nepopolna. Pomemben incident je treba razumeti z vidika vpliva na storitev, operativne motnje, prizadetih prejemnikov, dobaviteljev in čezmejnih posledic.

DORA za finančne subjekte isto zahtevo še izostri. Uporablja se od 17. januarja 2025 in vzpostavlja enotne zahteve za upravljanje IKT-tveganj, poročanje o pomembnih incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti, izmenjavo informacij o kibernetskih grožnjah in ranljivostih, tveganje tretjih ponudnikov storitev IKT ter pogodbene dogovore s tretjimi ponudniki storitev IKT. DORA storitve IKT opredeljuje široko kot digitalne in podatkovne storitve, ki se stalno zagotavljajo prek sistemov IKT. Kritično ali pomembno funkcijo opredeljuje kot funkcijo, katere motnja bi bistveno poslabšala finančno uspešnost, neprekinjeno izvajanje storitev ali obveznosti skladnosti.

Za finančne subjekte, ki so opredeljeni tudi po nacionalnem prenosu NIS2, se DORA obravnava kot sektorski pravni akt Unije za enakovredne zahteve glede IKT-tveganj, poročanja o incidentih, testiranja, izmenjave informacij in tveganj tretjih oseb. V praksi fintech podjetje ne more vzpostaviti enega nabora dokazil za zasebnost, drugega za DORA in tretjega za NIS2. Potrebuje enotno plast upravljanja podatkov, ki upošteva odvisnosti.

Ta plast je RoPA skupaj z mapiranjem podatkovnih tokov.

ISO/IEC 27001:2022 je hrbtenica

ISO/IEC 27001:2022 je zasnovan za tovrstno integracijo. Vzpostavlja razširljiv sistem upravljanja informacijske varnosti oziroma ISMS, namenjen ohranjanju zaupnosti, celovitosti in razpoložljivosti z obvladovanjem tveganj. Standard je namenjen integraciji v organizacijske procese ter prilagoditvi potrebam, velikosti in strukturi organizacije.

Izhodišče ni orodje za risanje diagramov. Izhodišče je obseg.

Klavzule ISO/IEC 27001:2022 od 4.1 do 4.4 zahtevajo, da organizacija opredeli kontekst, zainteresirane strani, obseg ISMS in medsebojno povezane procese. Obseg mora upoštevati zakonske, regulativne in pogodbene obveznosti ter vmesnike in odvisnosti med notranjimi dejavnostmi in dejavnostmi, ki jih izvajajo druge organizacije. Za RoPA in mapiranje podatkovnih tokov to pomeni, da mora obseg ISMS izrecno zajeti zunanje izvajane oblačne platforme, obdelovalce plačil, ponudnike identitet, orodja za podporo, ponudnike upravljanih varnostnih storitev in poslovno kritične integracije SaaS.

Klavzule od 5.1 do 5.3 vodstvo zavezujejo k odgovornosti za politiko, vire, dodelitev vlog in poročanje. To odraža usmeritev NIS2 Article 20, ki zahteva, da poslovodni organi odobrijo ukrepe za upravljanje kibernetskih tveganj, nadzorujejo izvajanje in se usposabljajo. Usklajeno je tudi z DORA Article 5, ki poslovodnemu organu nalaga končno odgovornost za IKT-tveganja ter nadzor nad politikami, strategijo odpornosti, načrti neprekinjenega poslovanja, načrti presoj, storitvami tretjih ponudnikov IKT in kanali za poročanje o večjih incidentih.

Klavzule od 6.1.1 do 6.1.3 zagotavljajo načrtovalni mehanizem: identificirati tveganja za zaupnost, celovitost in razpoložljivost, določiti lastnike tveganj, analizirati posledice in verjetnost, izbrati možnosti obravnave, primerjati kontrole s Prilogo A, pripraviti Izjavo o uporabnosti in pridobiti odobritev lastnika tveganja.

Tu RoPA postane operativna. Vsaka dejavnost obdelave in vsak podatkovni tok se morata povezati s tveganji, kontrolami, dobavitelji, sredstvi in kritičnimi storitvami. Če te povezave ni, RoPA ostane evidenca za zasebnost, ki ne more podpreti odziva na incidente, testiranja odpornosti ali odločitev o tveganju dobaviteljev.

Clarysecov Zenith Blueprint: 30-koračni načrt za presojevalce to praktično predstavi v fazi Upravljanje tveganj, korak 9, Identifikacija sredstev, groženj in ranljivosti:

Za vsako sredstvo zabeležite ključne podatke: ime/opis, lastnik, lokacija in razvrstitev (občutljivost). Primer sredstva je lahko »Podatkovna baza strank – v lasti oddelka IT – gostovana na AWS – vsebuje osebne in finančne podatke (visoka občutljivost)«.

Isti korak 9 dodaja ključen uvid za skladnost: sredstva z osebnimi podatki je treba označiti kot relevantna za GDPR, sredstva kritičnih storitev pa kot potencialno relevantna za NIS2, če organizacija deluje v reguliranem sektorju. To je most med RoPA, evidenco sredstev in mapiranjem odvisnosti kritičnih storitev.

Kaj mora vsebovati RoPA, pripravljena na revizijo

Dobra RoPA ni nujno zapletena, mora pa biti povezana.

GDPR Article 5 zahteva, da se osebni podatki obdelujejo zakonito, pošteno in pregledno, zbirajo za določene in zakonite namene, omejijo na potrebno, ohranjajo točni, hranijo le toliko časa, kolikor je potrebno, ter varujejo z ustreznimi tehničnimi in organizacijskimi ukrepi. Article 5(2) zahteva, da je upravljavec odgovoren za skladnost in jo mora biti sposoben dokazati.

Article 6 zahteva pravno podlago, kot so privolitev, nujnost za izvajanje pogodbe, zakonska obveznost, življenjski interesi, naloga v javnem interesu ali legitimni interesi. Če je obdelava namenjena novemu namenu, je treba združljivost presoditi glede na prvotni in novi namen, kontekst zbiranja, občutljivost, posledice za posameznike in varovalne ukrepe, kot sta šifriranje ali psevdonimizacija. Article 9 dodaja strožja pravila za posebne vrste osebnih podatkov, vključno z zdravstvenimi podatki, biometričnimi podatki, uporabljenimi za enolično identifikacijo, in drugimi občutljivimi kategorijami.

Clarysecov nabor politik za MSP to pretvori v operativno zahtevo. Politika varstva podatkov in zasebnosti za MSP določa:

Koordinator za zasebnost mora vzdrževati register vseh dejavnosti obdelave osebnih podatkov, vključno s kategorijami podatkov, namenom, pravno podlago in roki hrambe.

To izhaja iz razdelka Zahteve upravljanja, klavzula 5.2.1. Za večje organizacije Clarysecova Politika varstva podatkov in zasebnosti odgovornost določa neposredno:

Vzdržuje evidenco dejavnosti obdelave (RoPA) v skladu z GDPR Article 30.

To besedilo izhaja iz razdelka Vloge in odgovornosti, klavzula 4.2.2. Praktično sporočilo je preprosto: lastništvo RoPA mora biti dodeljeno. Ne sme biti osirotela preglednica za skladnost.

RoPA, pripravljena za leto 2026, mora vključevati naslednja polja.

Zadnje vrstice RoPA premaknejo iz dokumentacije zasebnosti v dokazila kibernetske odpornosti. Brez sistemov, dobaviteljev, lokacij, kritičnosti in kontrol lahko RoPA izpolni ozki kontrolni seznam Article 30, odpove pa takoj, ko incident, izpad ali nadzorni pregled zahteva analizo vpliva.

Mapiranje podatkovnih tokov povezuje zasebnost, oblak in kritične storitve

Če RoPA odgovarja na vprašanje »katera obdelava obstaja in zakaj«, zemljevid podatkovnih tokov odgovarja na vprašanje »kam se podatki premikajo, kdo se jih dotika, kaj jih varuje in kaj se poruši, če se tok ustavi«.

Clarysecova Politika maskiranja podatkov in psevdonimizacije za MSP zahtevo določa nedvoumno:

Zemljevid podatkovnih tokov mora biti izdelan.

To izhaja iz Zahtev upravljanja, klavzula 5.1.1.1. Podjetniška različica, Politika maskiranja podatkov in psevdonimizacije, pričakovanje razširi v klavzuli 5.2.1:

Vzdrževati je treba ažuren popis sistemov in podatkovnih tokov, ki vključujejo občutljive podatke.

Klavzula 5.2.2 dodaja:

Mapirati je treba, kje in kako se podatki transformirajo, delijo ali se do njih dostopa v različnih okoljih.

Presojevalci in regulatorji ne iščejo umetniških diagramov. Razumeti želijo transformacije, poti dostopa, deljenje, okolja in varovalne ukrepe.

V Zenith Blueprint, faza Kontrole v praksi, korak 22, Organizacijski ukrepi 5.1 do 5.18, smernice za prenos informacij pojasnjujejo, da morajo organizacije opredeliti dovoljene metode prenosa, jih uskladiti z razvrstitvijo ter zagotoviti, da strani razumejo svoje vloge in obveznosti. Primeri vključujejo šifrirano e-pošto, varne portale, SFTP, API-je in fizično dostavo s šifriranjem. Smernice opozarjajo tudi, da morajo prenosi osebnih podatkov prek meja upoštevati obveznosti glede zasebnosti in zakonodaje, ne le notranje preference.

Isti korak povezuje prenos informacij z razvrščanjem in označevanjem, preprečevanjem uhajanja podatkov, odnosi z dobavitelji in kriptografijo. To ustvari praktičen model za mapiranje podatkovnih tokov:

1. Identificirajte izvorni sistem, kot so CRM, plačilna platforma, HRIS ali služba za podporo uporabnikom.
2. Identificirajte kategorijo podatkov, vključno z osebnimi podatki, finančnimi podatki, podatki zaposlenih, posebnimi vrstami podatkov ali poverilnicami.
3. Identificirajte metodo prenosa, kot so API, SFTP, e-pošta, varen portal, ročni izvoz ali replikacija varnostnih kopij.
4. Identificirajte cilj, vključno z notranjim sistemom, storitvijo v oblaku, dobaviteljem, podobdelovalcem, podatkovnim skladiščem ali arhivom.
5. Identificirajte zaščito, kot so šifriranje, psevdonimizacija, nadzor dostopa, beleženje, DLP ali pogodbena omejitev.
6. Identificirajte odvisnost, vključno s tem, ali tok podpira kritično poslovno funkcijo, kritično ali pomembno funkcijo, bistveno storitev ali obveznost poročanja o incidentih.

Tri kontrole iz Priloge A ISO/IEC 27001:2022 so tu posebej pomembne. ISO/IEC 27002:2022 zagotavlja smernice za izvajanje teh kontrol:

Clarysecov Zenith Controls: vodnik za navzkrižno skladnost opredeljuje 5.9, 5.14 in 5.34 kot tematsko povezane kontrole za to plast upravljanja. Obravnavajte jih kot sidrne kontrole, nato pa jih prek Izjave o uporabnosti povežite s kontrolami dobaviteljev, oblaka, incidentov, neprekinjenega poslovanja, beleženja, dostopa in kriptografije.

Zakaj NIS2 in DORA potrebujeta več kot register zasebnosti

Pogosta napaka je vzpostaviti RoPA, ki je po GDPR tehnično pravilna, za NIS2 ali DORA pa neuporabna. Razlika je kritičnost storitve.

NIS2 Article 23 od bistvenih in pomembnih subjektov zahteva, da pomembne incidente priglasijo brez nepotrebnega odlašanja. Model poročanja vključuje zgodnje opozorilo v 24 urah, obvestilo o incidentu v 72 urah in končno poročilo v enem mesecu. Pomembni incidenti se presojajo glede na hudo operativno motnjo, finančno izgubo ali materialno oziroma nematerialno škodo drugim fizičnim ali pravnim osebam. Ta presoja je odvisna od poznavanja prizadetih storitev, prejemnikov, držav, sistemov in dobaviteljev.

DORA Article 17 od finančnih subjektov zahteva, da opredelijo in uvedejo proces upravljanja incidentov, povezanih z IKT, ki zazna, upravlja in priglaša incidente, evidentira incidente in pomembne kibernetske grožnje, ugotavlja temeljne vzroke, določa kazalnike zgodnjega opozarjanja, razvršča incidente po resnosti in kritičnosti prizadetih storitev, dodeljuje vloge ter vzpostavlja postopke komuniciranja in eskalacije. Article 18 zahteva razvrščanje glede na prizadete stranke ali nasprotne stranke in transakcije, trajanje in izpad, geografsko razširjenost, izgubo podatkov, ki vpliva na razpoložljivost, avtentičnost, celovitost ali zaupnost, kritičnost prizadetih storitev in gospodarski vpliv.

Incidenta ne morete hitro razvrstiti, če ne poznate podatkovnega toka in verige odvisnosti.

Clarysecova Politika neprekinjenega poslovanja in obnovitve po nesreči za MSP kaže na polje dokazil, ki ga organizacije potrebujejo:

prednostno razvrščene storitve in sistemi (kritične poslovne funkcije)

To izhaja iz Zahtev upravljanja, klavzula 5.2.1.2. Podjetniška Politika neprekinjenega poslovanja in obnovitve po nesreči v klavzuli 5.2.4 dodaja dimenzijo odvisnosti:

Kritične odvisnosti (sistemi, dobavitelji, osebje)

Za organizacije, regulirane z DORA, mora biti to usklajeno s kritičnimi ali pomembnimi funkcijami, storitvami IKT, pogodbenimi dogovori in izstopnimi strategijami. DORA Article 28 zahteva, da se tveganje tretjih ponudnikov storitev IKT upravlja kot del okvira IKT-tveganj. Zahteva register pogodbenih dogovorov za storitve IKT, predpogodbeni skrbni pregled in oceno kritičnosti, tveganja koncentracije, ustreznosti in nasprotij interesov ter izstopne strategije za storitve IKT, ki podpirajo kritične ali pomembne funkcije.

DORA Article 30 določa minimalna pogodbena določila za IKT, vključno z opisi storitev, pogoji podizvajanja, lokacijami obdelave in hrambe podatkov, varstvom podatkov, dostopom, obnovitvijo in vračilom podatkov, ravnmi storitev, podporo pri incidentih, sodelovanjem z organi, pravicami do odpovedi, pravicami do revizije ter prehodnimi ali izstopnimi dogovori.

RoPA, ki ne identificira dobaviteljev, lokacij, metod prenosa, kritičnosti in izstopnih odvisnosti, ne bo podprla dokazil za DORA.

Mapiranje dobaviteljev, oblaka in podobdelovalcev je mesto, kjer dokazila pogosto odpovejo

V dejanskih revizijah se pomanjkljivosti RoPA pogosto pokažejo kot pomanjkljivosti pri dobaviteljih. Dejavnost obdelave pravi »podpora strankam«. Zemljevid podatkovnih tokov pravi »platforma za podporo«. Nihče pa ne zna opredeliti regije gostovanja, dodatka za prepis z umetno inteligenco, podobdelovalca za analitiko, hrambe priponk v zahtevkih, modela administratorskega dostopa ali izstopnega postopka.

Clarysecova politika za dobavitelje za MSP vzpostavlja minimalna operativna dokazila. Politika varnosti tretjih oseb in dobaviteljev za MSP določa:

Evidenco dobaviteljev mora vzdrževati in posodabljati administrativni ali nabavni kontakt. Vključevati mora:

To izhaja iz Zahtev upravljanja, klavzula 5.4. Politika uporabe oblaka dodaja ločeno zahtevo glede popisa. Politika uporabe storitev v oblaku za MSP določa:

Evidenco storitev v oblaku mora vzdrževati ponudnik IT ali generalni direktor. Evidentirati mora:

To izhaja iz Zahtev upravljanja, klavzula 5.3. Za tveganje odvisnosti na ravni podjetja je Clarysecova Politika upravljanja tveganj odvisnosti od dobaviteljev bolj izrecna:

Register odvisnosti od dobaviteljev: pisarna za upravljanje dobaviteljev (VMO) mora vzdrževati ažuren register vseh kritičnih dobaviteljev, vključno s podatki, kot so zagotovljene storitve/produkti; ali je dobavitelj edini vir; razpoložljivi alternativni dobavitelji ali zamenljivost; veljavni pogodbeni pogoji; ter ocena vpliva, če bi dobavitelj odpovedal ali bil kompromitiran. Register mora jasno opredeliti dobavitelje z visoko stopnjo odvisnosti (npr. tiste, pri katerih hitra alternativa ne obstaja).

Ta zahteva iz Zahtev za implementacijo, klavzula 6.1, je natanko tisto, kar poveže RoPA z varnostjo dobavne verige po NIS2 in tveganjem tretjih ponudnikov storitev IKT po DORA.

Zenith Blueprint, faza Kontrole v praksi, korak 23, Organizacijski ukrepi 5.19 do 5.37, priporoča pripravo celotnega seznama dobaviteljev, razvrščanje dobaviteljev glede na dostop do sistemov, podatkov ali operativnega nadzora, vključitev varnostnih pričakovanj v pogodbe, pregled podizvajalcev, vzpostavitev sprožilcev za spremembe dobaviteljev in oblikovanje procesa ocenjevanja storitev v oblaku, ki zajema lokacijo podatkov, model dostopa, beleženje in šifriranje.

To CISO omogoči, da med incidentom odgovori: »Katera kritična storitev uporablja tega dobavitelja, kateri podatki so bili izpostavljeni, katere stranke je treba obvestiti, kateri regulator bi lahko zahteval poročilo in kateri alternativni dobavitelj ali izstopna pot obstaja?«

Praktični primer: uvajanje strank v fintech podjetju

Predstavljajte si fintech podjetje, ki zagotavlja uvajanje digitalne denarnice. Stranke naložijo identifikacijske dokumente, dobavitelj izvede biometrično preverjanje živosti, rezultati se shranijo v podatkovno bazo v oblaku, podpora strankam pa lahko v orodju za upravljanje zahtevkov vidi status preverjanja.

Storitev uvajanja je lahko kritična ali pomembna funkcija po DORA, ker motnja bistveno vpliva na neprekinjeno izvajanje storitev in regulativne obveznosti. Če je podjetje v sektorju NIS2 ali zagotavlja relevantne storitve IKT, je lahko tudi del dokazil o kritični storitvi.

Uporaben zemljevid se začne z enim povezanim zapisom.

Zdaj dodajte sledljivost obravnave tveganj po ISO/IEC 27001:2022.

V Zenith Blueprint, faza Upravljanje tveganj, korak 13, Načrtovanje obravnave tveganj in Izjava o uporabnosti, Clarysec opisuje SoA kot povezovalni dokument, ki oceno tveganja in obravnavo povezuje z dejanskimi kontrolami. Priporoča mapiranje kontrol na tveganja ter navzkrižno sklicevanje na predpise, kot so GDPR, NIS2 ali DORA, v registru tveganj ali opombah SoA, kadar je relevantno.

Za primer uvajanja bi bil scenarij tveganja lahko: »Izpad ali kompromitacija ponudnika preverjanja identitete prekine uvajanje in izpostavi biometrične identitetne podatke.« Kontrole obravnave bi lahko vključevale skrbni pregled dobaviteljev, pogodbeno obveščanje o incidentih, šifriranje, nadzor dostopa, beleženje, varnostno kopiranje in obnovitev, minimizacijo podatkov, psevdonimizacijo, spremljanje, izstopno načrtovanje in odzivne priročnike za incidente.

Opomba SoA lahko navede, da nabor kontrol podpira odgovornost po GDPR, varnost dobavne verige in pripravljenost na incidente po NIS2 Article 21 ter tveganje tretjih ponudnikov storitev IKT in odpornost kritičnih funkcij po DORA.

To presojevalci iščejo: sledljivost.

Mapiranje navzkrižne skladnosti: ena plast dokazil, več vprašanj

RoPA in mapiranje podatkovnih tokov nista ločena silosa skladnosti. Podpirata skupen nabor vprašanj v okviru GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 in COBIT 2019.

NIST CSF 2.0 je uporaben kot organizacijska plast. Njegovi profili CSF podpirajo analizo trenutnega in ciljnega stanja z uporabo vhodov, kot so politike, prioritete tveganj, registri vpliva na poslovanje, zahteve, standardi, prakse, orodja in delovne vloge. Funkcija GOVERN vključuje zakonske, regulativne, pogodbene, zasebnostne in državljanske obveznosti, cilje tveganj, odgovornost vodstva, vloge, politiko, nadzor in pregled uspešnosti. Rezultati za dobavno verigo zahtevajo, da so dobavitelji znani in prednostno razvrščeni po kritičnosti, da so pogodbene zahteve kibernetske varnosti vključene, da se skrbni pregled opravi pred vzpostavitvijo razmerij, da se tveganja dobaviteljev evidentirajo in spremljajo ter da so dobavitelji vključeni v načrtovanje odziva na incidente in obnovitve.

To se dobro preslika v operativni model RoPA po Clarysec. RoPA zagotavlja kontekst zasebnosti. Evidenca sredstev zagotavlja tehnični kontekst. Evidence dobaviteljev in storitev v oblaku zagotavljajo kontekst tretjih oseb. BIA zagotavlja kontekst kritičnosti. SoA zagotavlja kontekst kontrol.

Ena kontrola iz Priloge A ISO/IEC 27001:2022 lahko podpira tudi več okvirov. Kontrola 5.14, Prenos informacij, je dober primer.

To je vrednost Zenith Controls kot kompasa za navzkrižno skladnost. Organizacijam pomaga pojasniti, zakaj ena kontrolna praksa podpira več regulativnih in revizijskih pričakovanj.

Kako bodo različni presojevalci testirali isti zemljevid

Zrela RoPA in zemljevid podatkovnih tokov lahko zadostita več presojevalcem, vendar bo vsak pristopil drugače.

Presojevalec ISO/IEC 27001:2022 bo začel z obsegom, zainteresiranimi stranmi, tveganji, dokumentiranimi informacijami in izborom kontrol. Vprašal bo, ali so bile zakonske in pogodbene zahteve identificirane, ali so osebni podatki in kritične storitve vključeni v obseg ISMS, ali imajo sredstva lastnike in razvrstitve, ali je ocena tveganja upoštevala zaupnost, celovitost in razpoložljivost ter ali SoA utemeljuje uporabne kontrole.

Presojevalec GDPR ali regulator zasebnosti bo začel z odgovornostjo. Preveril bo, ali RoPA odraža dejansko obdelavo, ali so nameni in pravne podlage dokumentirani, ali so posebne vrste podatkov identificirane, ali se roki hrambe uporabljajo, ali so prejemniki in obdelovalci točni ter ali obstajajo ustrezni varovalni ukrepi za prenose in varnost.

Presojevalec, osredotočen na NIS2, bo gledal vpliv na storitev. Vprašal bo, kako organizacija določa kritične ali pomembne storitve, kako je vodstvo odobrilo in nadzoruje ukrepe za tveganja, kako se upoštevajo ranljivosti dobaviteljev in tveganja ponudnikov storitev, kako sta povezana neprekinjeno poslovanje in obravnavanje incidentov ter ali lahko organizacija podpre 24-urne, 72-urne in končne roke poročanja z zanesljivimi dokazili.

Presojevalec DORA bo gledal upravljanje IKT-tveganj in kritične ali pomembne funkcije. Preveril bo, ali je poslovodni organ odobril okvir IKT-tveganj in strategijo odpornosti, ali so dogovori s tretjimi ponudniki storitev IKT evidentirani, ali sta kritičnost in tveganje koncentracije ocenjena, ali pogodbe vključujejo zahtevana določila, ali testiranje zajema sisteme, ki podpirajo kritične ali pomembne funkcije, ter ali so incidenti razvrščeni glede na prizadete stranke, transakcije, izpad, geografijo, izgubo podatkov, kritičnost storitve in gospodarski vpliv.

Ocenjevalec NIST CSF 2.0 bo pogosto uporabljal profile. Primerjal bo trenutne in ciljne rezultate v funkcijah GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER. RoPA in zemljevidi podatkovnih tokov postanejo vhodni podatki za upravljanje zakonskih obveznosti, evidence sredstev, tveganje dobaviteljev, varstvo podatkov, spremljanje, komunikacije ob incidentih in načrtovanje obnovitve.

Presojevalec po COBIT 2019 ali pristopu ISACA se bo osredotočil na upravljanje, lastništvo in zmožnost procesa. Preveril bo, ali so informacijski tokovi v lastništvu, ali so pravice odločanja jasne, ali se uporablja apetit po tveganju, ali se kontrole spremljajo, ali se izjeme eskalirajo in ali so dokazila dovolj zanesljiva za zagotovila vodstva.

Pogosti vzorci neuspeha

Najpogostejše pomanjkljivosti RoPA in mapiranja podatkovnih tokov so predvidljive.

Prvič, RoPA navaja dejavnosti obdelave, ne pa sistemov. Zaradi tega odgovornosti po GDPR ni mogoče povezati z upravljanjem ranljivosti, pregledom pravic dostopa, varnostnim kopiranjem, beleženjem ali odzivom na incidente.

Drugič, zemljevidi podatkovnih tokov se ustavijo pri prvem dobavitelju. Ne prikažejo podobdelovalcev, regij v oblaku, dostopa podpore, analitičnih orodij, platform za spremljanje ali lokacij varnostnih kopij.

Tretjič, načrti neprekinjenega poslovanja identificirajo sisteme, ne pa osebnih podatkov. Med izpadom organizacija razume prioriteto obnovitve, ne pa vpliva na zasebnost.

Četrtič, evidence dobaviteljev zajamejo lastnike pogodb, ne pa kritičnosti, zamenljivosti, kategorij podatkov, obveznosti obveščanja o incidentih ali izstopnih možnosti.

Petič, SoA je napisana kot certifikacijski dokument, ne kot most med kontrolami. Navaja, da so kontrole uporabne, ne pojasni pa, kateri problem dokazil za GDPR, NIS2 ali DORA kontrola pomaga rešiti.

Nazadnje je lastništvo razdrobljeno. DPO je lastnik RoPA, IT je lastnik sredstev, nabava je lastnik dobaviteljev, operativa je lastnik BIA, finance so lastnik registrov DORA, nihče pa ni lastnik integriranega zemljevida odvisnosti.

Clarysecov pristop to odpravi z dodelitvijo objektov dokazil lastnikom politik, nato pa s koraki Zenith Blueprint poveže sredstva, tveganja, kontrole in sledljivost SoA.

30-dnevni izvedbeni načrt

Ni treba zavreti oceana. Začnite s storitvami, ki so najpomembnejše.

1. teden: izberite tri kritične ali visoko tvegane dejavnosti obdelave. Dobri kandidati so uvajanje strank, obdelava plačil, kadrovska administracija zaposlenih, upravljanje zahtevkov za podporo ali varnostno spremljanje. Za vsako dejavnost preverite vnos RoPA glede na dejanske sisteme, kategorije podatkov, namene, pravne podlage in pravila hrambe.

2. teden: izdelajte zemljevide podatkovnih tokov za te dejavnosti. Identificirajte izvor, cilj, metodo prenosa, okolje, dobavitelja, podobdelovalca, lokacijo podatkov, pot dostopa, transformacijo in točko hrambe. Uporabite zahtevo Clarysecove Politike maskiranja podatkov in psevdonimizacije za vzdrževanje popisov sistemov in podatkovnih tokov, ki vključujejo občutljive podatke.

3. teden: povežite vsak tok s sredstvi, dobavitelji, storitvami v oblaku in kritičnimi poslovnimi funkcijami. Uporabite Zenith Blueprint korak 9 za lastništvo sredstev in razvrstitev. Uporabite zahteve politik za evidence dobaviteljev in storitev v oblaku za zajem dokazil tretjih oseb. Uporabite politiko neprekinjenega poslovanja za identifikacijo prednostnih storitev in kritičnih odvisnosti.

4. teden: dodajte sledljivost tveganj in kontrol. Za vsak tok ustvarite ali posodobite scenarije tveganj. Mapirajte kontrole v SoA z uporabo Zenith Blueprint korak 13. Dodajte opombe za odgovornost po GDPR Article 30, ukrepe za tveganja po NIS2 Article 21 in dokazila o odvisnostih IKT po DORA, kjer je to relevantno.

Nato izvedite eno namizno vajo: »Izpad dobavitelja in izpostavitev podatkov v kritični storitvi.« Preverite, ali vaša dokazila podpirajo razvrstitev incidenta, odločitve o obveščanju, komuniciranje s strankami, komuniciranje z regulatorjem in določanje prioritet obnovitve.

Po 30 dneh boste imeli ponovljiv model za preostanek organizacije.

Clarysecov pristop: spremenite RoPA v živa dokazila odpornosti

RoPA in mapiranje podatkovnih tokov nista več samo administracija zasebnosti. Sta vezno tkivo med odgovornostjo po GDPR, upravljanjem kritičnih storitev po NIS2 in dokazili o odvisnostih IKT po DORA.

Organizacije, ki bodo v letu 2026 najuspešnejše, ne bodo tiste z največ dokumenti. To bodo tiste, ki lahko poslovno storitev sledljivo povežejo z njenimi dejavnostmi obdelave, podatkovnimi tokovi, sistemi, dobavitelji, regijami v oblaku, pogodbami, kontrolami, tveganji, pragovi incidentov in načrti obnovitve.

Clarysec ekipam pomaga vzpostaviti to sledljivost brez nepotrebne birokracije. Naš nabor politik dodeljuje lastništvo in zahteve glede dokazil. Zenith Blueprint zagotavlja izvedbeni časovni načrt, vključno z identifikacijo sredstev, implementacijo kontrol za dobavitelje in oblak ter sledljivostjo SoA. Zenith Controls zagotavlja kompas za navzkrižno skladnost pri mapiranju kontrol iz Priloge A ISO/IEC 27001:2022 na pričakovanja glede zasebnosti, odpornosti, dobaviteljev, oblaka in revizij.

Vaš naslednji korak je preprost: izberite eno kritično storitev, en vnos RoPA in en podatkovni tok, ki ga podpira dobavitelj. Mapirajte ga od začetka do konca. Če podatkov, odvisnosti, kontrole in vpliva incidenta ne morete pojasniti na eni strani, vaša plast dokazil ni pripravljena za leto 2026.

Clarysec vam jo lahko pomaga pripraviti. Raziščite Zenith Blueprint, okrepite svoje upravljanje s Politiko varstva podatkov in zasebnosti in Politiko upravljanja tveganj odvisnosti od dobaviteljev ter uporabite Zenith Controls, da razdrobljena dokazila skladnosti pretvorite v enoten, na revizijo pripravljen operativni model.