Mapiranje tokova podataka za RoPA u kontekstu GDPR-a, NIS2 i DORA

U utorak je 09:10, a direktor informacijske sigurnosti (CISO), službenik za zaštitu podataka (DPO), voditelj nabave i direktor operacija sudjeluju u istom videopozivu, ali ne gledaju iste dokaze.

DPO ima Evidenciju aktivnosti obrade (RoPA), u kojoj su navedeni uvođenje klijenata, obračun plaća zaposlenika, zahtjevi za podršku i marketinška analitika. CISO ima popis imovine u oblaku. Nabava ima ugovore s dobavljačima. Operacije imaju tablicu za neprekidnost poslovanja. Financije imaju Registar informacija prema DORA. Nitko ne može odgovoriti na osnovno povezano regulatorno pitanje:

Ako ova usluga uvođenja za plaćanja prestane raditi, koji su sustavi, dobavljači, kategorije podataka, podizvršitelji obrade, prekogranični prijenosi i kritične poslovne funkcije pogođeni?

To je stvarni test usklađenosti za 2026.

GDPR i dalje zahtijeva dokazive zapise prema Article 30. NIS2 je kibernetičku sigurnost pretvorio u pitanje odgovornosti upravljačkog tijela za ključne i važne subjekte. DORA od financijskih subjekata zahtijeva dokaze o IKT ovisnostima, kritičnim ili važnim funkcijama, IKT aranžmanima s trećim stranama, klasifikaciji incidenata i testiranju otpornosti. ISO/IEC 27001:2022 daje strukturu sustava upravljanja koja sve to može povezati, ali samo ako se RoPA i mapiranje tokova podataka tretiraju kao živi upravljački dokazi, a ne kao proračunske tablice tima za privatnost.

U Clarysecu isti obrazac vidimo kod brzo rastućih SaaS, fintech, cloud, MSP i B2B tehnoloških društava. Imaju dovoljno dokumentacije za odgovor na upitnik, ali nemaju dovoljno povezanih dokaza za nadzorni pregled, kibernetički incident, otkaz dobavljača ili unutarnju reviziju. Problem rijetko proizlazi iz nedostatka informacija. Problem je nedostatak povezanosti.

Rješenje je da RoPA i mapiranje tokova podataka postanu zajednički sloj dokaza za privatnost, kibernetičku otpornost, upravljanje dobavljačima, upravljanje oblakom i neprekidnost poslovanja.

Zašto su RoPA i mapiranje tokova podataka postali pitanje upravljanja u 2026.

RoPA se ranije promatrala kao artefakt privatnosti. Mape tokova podataka često su se izrađivale tijekom DPIA-e, migracije u oblak ili pregleda sigurnosne arhitekture, a zatim ostavljale da zastare. Taj pristup više ne funkcionira.

GDPR se široko primjenjuje na obradu osobnih podataka u kontekstu poslovnog nastana u EU, kao i na mnoge voditelje obrade ili izvršitelje obrade izvan EU koji nude robu ili usluge pojedincima u EU ili prate njihovo ponašanje. Osobni podaci obuhvaćaju informacije koje se odnose na identificiranu osobu ili osobu koju je moguće identificirati. Obrada uključuje prikupljanje, pohranu, uporabu, otkrivanje, ograničavanje, brisanje i uništenje. Voditelj obrade određuje svrhe i sredstva, dok izvršitelj obrade djeluje u ime voditelja obrade.

RoPA stoga nije samo popis baza podataka. To je zapis poslovnih svrha, kategorija podataka, uloga, primatelja, rokova zadržavanja, zaštitnih mjera i međunarodnih ovisnosti.

NIS2 dodaje perspektivu otpornosti usluga. U opseg uključuje mnoge srednje i velike organizacije u visokokritičnim i drugim kritičnim sektorima, uključujući digitalnu infrastrukturu, pružatelje usluga računalstva u oblaku, pružatelje usluga podatkovnih centara, mreže za isporuku sadržaja, pružatelje usluga povjerenja, pružatelje javnih elektroničkih komunikacija, pružatelje upravljanih usluga i pružatelje upravljanih sigurnosnih usluga. Prilog I uključuje i bankarstvo te infrastrukture financijskog tržišta. Neki subjekti mogu biti obuhvaćeni bez obzira na veličinu, uključujući određene pružatelje DNS, TLD, usluga povjerenja i javnih komunikacija, kao i subjekte čiji bi poremećaj mogao znatno utjecati na javnu sigurnost, javno zdravlje, sistemski rizik ili kritične društvene i gospodarske aktivnosti.

NIS2 Article 21 zahtijeva razmjerne tehničke, operativne i organizacijske mjere za mrežne i informacijske sustave koji se upotrebljavaju za poslovanje ili pružanje usluga. Minimalna područja uključuju analizu rizika, sigurnosne politike, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, siguran razvoj, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom i autentifikaciju.

Za subjekt obuhvaćen NIS2, RoPA bez pregleda ovisnosti usluga nije potpuna. Značajan incident mora se razumjeti kroz utjecaj na uslugu, operativni poremećaj, pogođene primatelje, dobavljače i prekogranične implikacije.

DORA dodatno izoštrava istu točku za financijske subjekte. Primjenjuje se od 17. siječnja 2025. i uspostavlja jedinstvene zahtjeve za upravljanje IKT rizicima, prijavljivanje većih incidenata povezanih s IKT-om, testiranje digitalne operativne otpornosti, razmjenu informacija o kibernetičkim prijetnjama i ranjivostima, IKT rizik trećih strana i ugovorne aranžmane s pružateljima IKT usluga trećih strana. DORA široko definira IKT usluge kao digitalne i podatkovne usluge koje se kontinuirano pružaju putem IKT sustava. Kritičnu ili važnu funkciju definira kao funkciju čiji bi poremećaj značajno narušio financijsku uspješnost, kontinuitet usluge ili obveze usklađenosti.

Za financijske subjekte koji su ujedno identificirani prema nacionalnoj transpoziciji NIS2, DORA se tretira kao sektorski poseban pravni akt Unije za ekvivalentne zahtjeve u pogledu IKT rizika, prijavljivanja incidenata, testiranja, razmjene informacija i rizika trećih strana. U praksi, fintech ne može graditi jedan skup dokaza za privatnost, drugi za DORA i treći za NIS2. Potreban mu je jedinstven sloj upravljanja podacima koji uzima u obzir ovisnosti.

Taj sloj čine RoPA i mapiranje tokova podataka.

ISO/IEC 27001:2022 kao okosnica

ISO/IEC 27001:2022 osmišljen je upravo za ovu vrstu integracije. Uspostavlja skalabilan sustav upravljanja informacijskom sigurnošću, odnosno ISMS, namijenjen očuvanju povjerljivosti, cjelovitosti i dostupnosti kroz upravljanje rizicima. Standard je predviđen za integraciju u organizacijske procese i skaliranje prema potrebama, veličini i strukturi organizacije.

Polazište nije alat za crtanje dijagrama. Polazište je opseg.

Točke 4.1 do 4.4 norme ISO/IEC 27001:2022 zahtijevaju da organizacija definira kontekst, zainteresirane strane, opseg ISMS-a i povezane procese. Opseg mora uzeti u obzir pravne, regulatorne i ugovorne obveze, kao i sučelja i ovisnosti između internih aktivnosti i aktivnosti koje obavljaju druge organizacije. Za RoPA-u i mapiranje tokova podataka to znači da opseg ISMS-a treba izričito obuhvatiti vanjsko ugovorene platforme u oblaku, procesore plaćanja, pružatelje identiteta, alate za podršku, pružatelje upravljanih sigurnosnih usluga i poslovno kritične SaaS integracije.

Točke 5.1 do 5.3 čine vodstvo odgovornim za politiku, resurse, dodjelu uloga i izvješćivanje. To odražava smjer NIS2 Article 20, koji zahtijeva da upravljačka tijela odobre mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i pohađaju obuku. Usklađeno je i s DORA Article 5, koji upravljačkom tijelu daje krajnju odgovornost za IKT rizik i nadzor nad politikama, strategijom otpornosti, planovima kontinuiteta, planovima revizije, IKT uslugama trećih strana i kanalima za prijavljivanje većih incidenata.

Točke 6.1.1 do 6.1.3 daju mehanizam planiranja: identificirati rizike za povjerljivost, cjelovitost i dostupnost, dodijeliti vlasnike rizika, analizirati posljedice i vjerojatnost, odabrati opcije obrade rizika, usporediti kontrole s Prilogom A, izraditi Izjavu o primjenjivosti i pribaviti odobrenje vlasnika rizika.

Tu RoPA postaje operativna. Svaka aktivnost obrade i svaki tok podataka trebaju se povezati s rizicima, kontrolama, dobavljačima, imovinom i kritičnim uslugama. Ako se to ne učini, ostat će popis privatnosti koji ne može podržati odgovor na incidente, testiranje otpornosti ili odluke o riziku dobavljača.

Clarysecov Zenith Blueprint: 30-koračni plan za revizore čini to praktičnim u fazi Upravljanje rizicima, korak 9, Identifikacija imovine, prijetnji i ranjivosti:

Za svaku imovinu evidentirajte ključne pojedinosti: naziv/opis, vlasnik, lokacija i klasifikacija (osjetljivost). Na primjer, imovina može biti „Baza podataka klijenata – u vlasništvu IT odjela – hostirana na AWS – sadrži osobne i financijske podatke (visoka osjetljivost).”

Isti korak 9 dodaje ključni uvid za usklađenost: imovina koja sadrži osobne podatke treba biti označena kao relevantna za GDPR, a imovina kritičnih usluga treba biti evidentirana radi moguće primjenjivosti NIS2 ako je organizacija u reguliranom sektoru. To je most između RoPA-e, popisa imovine i mapiranja ovisnosti kritičnih usluga.

Što RoPA spremna za reviziju mora sadržavati

Snažna RoPA ne mora biti složena, ali mora biti povezana.

GDPR Article 5 zahtijeva da se osobni podaci obrađuju zakonito, pošteno i transparentno, prikupljaju u određene i legitimne svrhe, ograniče na ono što je nužno, održavaju točnima, zadržavaju samo onoliko dugo koliko je potrebno i štite odgovarajućim tehničkim i organizacijskim mjerama. Article 5(2) zahtijeva da voditelj obrade bude odgovoran za usklađenost i da je može dokazati.

Article 6 zahtijeva pravnu osnovu, kao što su privola, nužnost ugovora, pravna obveza, vitalni interesi, javna zadaća ili legitimni interesi. Ako se obrada provodi u novu svrhu, usklađenost sa svrhom mora se procijeniti uzimajući u obzir izvornu i novu svrhu, kontekst prikupljanja, osjetljivost, posljedice za pojedince i zaštitne mjere poput šifriranja ili pseudonimizacije. Article 9 dodaje stroža pravila za posebne kategorije osobnih podataka, uključujući zdravstvene podatke, biometrijske podatke koji se upotrebljavaju za jedinstvenu identifikaciju i druge osjetljive kategorije.

Clarysecov skup politika za MSP-ove pretvara to u operativni zahtjev. Politika zaštite podataka i privatnosti za MSP-ove navodi:

Koordinator za privatnost mora održavati registar svih aktivnosti obrade osobnih podataka, uključujući kategorije podataka, svrhu, pravnu osnovu i rokove zadržavanja

To je iz odjeljka Zahtjevi upravljanja, točka 5.2.1. Za veće organizacije Clarysecova Politika zaštite podataka i privatnosti izravno dodjeljuje odgovornost:

Održava Evidenciju aktivnosti obrade (RoPA) u skladu s GDPR Article 30.

Ta formulacija dolazi iz odjeljka Uloge i odgovornosti, točka 4.2.2. Praktična poruka je jednostavna: vlasništvo nad RoPA-om mora biti dodijeljeno. Ne smije ostati napuštena tablica za usklađenost.

RoPA spremna za 2026. treba uključivati sljedeća polja.

Završni redci prebacuju RoPA-u iz dokumentacije privatnosti u dokaze kibernetičke otpornosti. Bez sustava, dobavljača, lokacija, kritičnosti i kontrola, RoPA može zadovoljiti uski kontrolni popis iz Article 30, ali neće izdržati čim incident, prekid usluge ili nadzorni pregled zatraže analizu utjecaja.

Mapiranje tokova podataka povezuje privatnost, oblak i kritične usluge

Ako RoPA odgovara na pitanje „koja obrada postoji i zašto”, mapa tokova podataka odgovara na pitanje „kamo se podaci kreću, tko im pristupa, što ih štiti i što se prekida ako tok stane”.

Clarysecova Politika maskiranja podataka i pseudonimizacije za MSP-ove nedvosmisleno postavlja zahtjev:

Mora se izraditi mapa tokova podataka.

To dolazi iz Zahtjeva upravljanja, točka 5.1.1.1. Verzija za poduzeća, Politika maskiranja podataka i pseudonimizacije, proširuje očekivanje u točki 5.2.1:

Održavati ažuran popis sustava i tokova podataka koji uključuju osjetljive podatke.

Točka 5.2.2 dodaje:

Mapirati gdje i kako se podaci transformiraju, dijele ili im se pristupa kroz okruženja.

Revizori i regulatori ne traže umjetničke dijagrame. Žele razumjeti transformacije, putove pristupa, dijeljenje, okruženja i zaštitne mjere.

U Zenith Blueprintu, faza Kontrole u praksi, korak 22, Organizacijske kontrole 5.1 do 5.18, smjernice za prijenos informacija objašnjavaju da organizacije moraju definirati dopuštene metode prijenosa, uskladiti ih s klasifikacijom i osigurati da strane razumiju svoje uloge i obveze. Primjeri uključuju šifriranu e-poštu, sigurne portale, SFTP, API-je i fizičku dostavu uz šifriranje. Također se napominje da osobni podaci koji se prenose preko granica moraju biti usklađeni s obvezama privatnosti i pravnim obvezama, a ne samo s internim preferencijama.

Isti korak povezuje prijenos informacija s klasifikacijom i označavanjem, sprječavanjem curenja podataka, odnosima s dobavljačima i kriptografijom. Time nastaje praktičan model za mapiranje tokova podataka:

1. Identificirajte izvorni sustav, poput CRM-a, platforme za plaćanje, HRIS-a ili sustava za podršku.
2. Identificirajte kategoriju podataka, uključujući osobne podatke, financijske podatke, podatke o zaposlenicima, posebne kategorije podataka ili vjerodajnice.
3. Identificirajte metodu prijenosa, poput API-ja, SFTP-a, e-pošte, sigurnog portala, ručnog izvoza ili replikacije sigurnosne kopije.
4. Identificirajte odredište, uključujući interni sustav, uslugu u oblaku, dobavljača, podizvršitelja obrade, podatkovno skladište ili arhivu.
5. Identificirajte zaštitu, poput šifriranja, pseudonimizacije, kontrole pristupa, zapisivanja događaja, DLP-a ili ugovornog ograničenja.
6. Identificirajte ovisnost, uključujući podržava li tok kritičnu poslovnu funkciju, kritičnu ili važnu funkciju, ključnu uslugu ili obvezu prijavljivanja incidenata.

Tri kontrole iz Priloga A norme ISO/IEC 27001:2022 ovdje su osobito važne. ISO/IEC 27002:2022 pruža smjernice za provedbu tih kontrola:

Clarysecov Zenith Controls: vodič za međusobnu usklađenost identificira 5.9, 5.14 i 5.34 kao tematski povezane kontrole za ovaj sloj upravljanja. Tretirajte ih kao sidrene kontrole, a zatim ih kroz svoju Izjavu o primjenjivosti povežite s kontrolama dobavljača, oblaka, incidenata, kontinuiteta, zapisivanja događaja, pristupa i kriptografije.

Zašto NIS2 i DORA trebaju više od registra privatnosti

Česta je pogreška izraditi RoPA-u koja je tehnički ispravna prema GDPR-u, ali beskorisna za NIS2 ili DORA. Razlika je u kritičnosti usluge.

NIS2 Article 23 zahtijeva da ključni i važni subjekti bez nepotrebnog odgađanja prijave značajne incidente. Model prijavljivanja uključuje rano upozorenje u roku od 24 sata, obavijest o incidentu u roku od 72 sata i završno izvješće u roku od mjesec dana. Značajni incidenti procjenjuju se prema ozbiljnom operativnom poremećaju, financijskom gubitku ili materijalnoj ili nematerijalnoj šteti za druge fizičke ili pravne osobe. Ta procjena ovisi o tome znate li koje su usluge, primatelji, države, sustavi i dobavljači pogođeni.

DORA Article 17 zahtijeva da financijski subjekti definiraju i provedu proces upravljanja incidentima povezanima s IKT-om koji otkriva, upravlja i prijavljuje incidente, evidentira incidente i značajne kibernetičke prijetnje, identificira temeljne uzroke, postavlja pokazatelje ranog upozorenja, klasificira incidente prema ozbiljnosti i kritičnosti pogođenih usluga, dodjeljuje uloge te uspostavlja komunikacijske i eskalacijske postupke. Article 18 zahtijeva klasifikaciju prema pogođenim klijentima ili drugim ugovornim stranama i transakcijama, trajanju i prekidu rada, geografskom opsegu, gubitku podataka koji utječe na dostupnost, autentičnost, cjelovitost ili povjerljivost, kritičnosti pogođenih usluga i gospodarskom utjecaju.

Incident ne možete brzo klasificirati ako ne poznajete tok podataka i lanac ovisnosti.

Clarysecova Politika neprekidnosti poslovanja i oporavka od katastrofe za MSP-ove upućuje na polje dokaza koje je organizacijama potrebno:

prioritizirane usluge i sustavi (kritične poslovne funkcije)

To dolazi iz Zahtjeva upravljanja, točka 5.2.1.2. Korporativna Politika neprekidnosti poslovanja i oporavka od katastrofe dodaje dimenziju ovisnosti u točki 5.2.4:

Kritične ovisnosti (sustavi, dobavljači, osoblje)

Za organizacije regulirane DORA-om to mora biti usklađeno s kritičnim ili važnim funkcijama, IKT uslugama, ugovornim aranžmanima i izlaznim strategijama. DORA Article 28 zahtijeva da se IKT rizikom trećih strana upravlja kao dijelom okvira IKT rizika. Propisuje registar ugovornih aranžmana za IKT usluge, zahtijeva dubinsku analizu dobavljača prije sklapanja ugovora i procjenu kritičnosti, rizika koncentracije, prikladnosti i sukoba interesa te zahtijeva izlazne strategije za IKT usluge koje podržavaju kritične ili važne funkcije.

DORA Article 30 propisuje minimalne uvjete IKT ugovora, uključujući opise usluga, uvjete podugovaranja, lokacije obrade i pohrane podataka, zaštitu podataka, pristup, oporavak i povrat podataka, razine usluge, pomoć pri incidentima, suradnju s tijelima, prava raskida, prava na reviziju i prijelazne ili izlazne aranžmane.

RoPA koja ne identificira dobavljače, lokacije, metode prijenosa, kritičnost i izlazne ovisnosti neće podržati dokaze za DORA.

Mapiranje dobavljača, oblaka i podizvršitelja obrade mjesto je gdje se dokazi često raspadaju

U stvarnim revizijama neuspjesi RoPA-e često se pojavljuju kao neuspjesi dobavljača. Aktivnost obrade kaže „korisnička podrška”. Mapa tokova podataka kaže „platforma za podršku”. Ali nitko ne može identificirati regiju hostinga, dodatak za AI transkripciju, analitičkog podizvršitelja obrade, rok zadržavanja privitaka u zahtjevima za podršku, model administratorskog pristupa ili izlazni postupak.

Clarysecova politika za MSP-ove o dobavljačima uspostavlja minimalne operativne dokaze. Politika sigurnosti trećih strana i dobavljača za MSP-ove navodi:

Registar dobavljača mora održavati i ažurirati administrativni kontakt ili kontakt za nabavu. Mora uključivati:

To dolazi iz Zahtjeva upravljanja, točka 5.4. Politika oblaka dodaje zaseban zahtjev za popis. Politika korištenja usluga u oblaku za MSP-ove navodi:

Registar usluga u oblaku mora održavati IT pružatelj ili glavni direktor. Mora evidentirati:

To dolazi iz Zahtjeva upravljanja, točka 5.3. Za rizik ovisnosti na razini poduzeća Clarysecova Politika upravljanja rizikom ovisnosti o dobavljačima izričitija je:

Registar ovisnosti o dobavljačima: VMO mora održavati ažuran registar svih kritičnih dobavljača, uključujući pojedinosti kao što su pružene usluge/proizvodi; je li dobavljač jedini izvor; dostupni alternativni dobavljači ili mogućnost zamjene; važeći ugovorni uvjeti; i procjena utjecaja ako dobavljač otkaže ili bude kompromitiran. Registar mora jasno identificirati dobavljače s visokom razinom ovisnosti (npr. one za koje ne postoji brzo dostupna alternativa).

Taj zahtjev, iz Zahtjeva provedbe, točka 6.1, upravo je ono što povezuje RoPA-u sa sigurnošću opskrbnog lanca prema NIS2 i IKT rizikom trećih strana prema DORA.

Zenith Blueprint, faza Kontrole u praksi, korak 23, Organizacijske kontrole 5.19 do 5.37, preporučuje izradu potpunog popisa dobavljača, klasifikaciju dobavljača na temelju pristupa sustavima, podacima ili operativnoj kontroli, ugrađivanje sigurnosnih očekivanja u ugovore, pregled podugovaratelja, uspostavu okidača za promjene dobavljača i izgradnju postupka procjene usluga u oblaku koji obuhvaća lokaciju podataka, model pristupa, zapisivanje događaja i šifriranje.

To CISO-u omogućuje da tijekom incidenta odgovori: „Koja kritična usluga koristi ovog dobavljača, koji su podaci bili izloženi, koje klijente moramo obavijestiti, kojem regulatoru možda trebamo podnijeti izvješće i koji alternativni dobavljač ili izlazni put postoji?”

Praktičan primjer: uvođenje klijenata u fintechu

Zamislite fintech koji pruža uvođenje za digitalni novčanik. Klijenti učitavaju identifikacijske dokumente, dobavljač provodi biometrijske provjere živosti, rezultati se pohranjuju u bazu podataka u oblaku, a korisnička podrška može vidjeti status provjere u alatu za zahtjeve za podršku.

Usluga uvođenja može biti kritična ili važna funkcija prema DORA jer poremećaj značajno utječe na kontinuitet usluge i regulatorne obveze. Ako je društvo u sektoru NIS2 ili pruža relevantne IKT usluge, to može biti i dio dokaza o kritičnoj usluzi.

Korisna mapa počinje jednim povezanim zapisom.

Sada dodajte sljedivost obrade rizika prema ISO/IEC 27001:2022.

U Zenith Blueprintu, faza Upravljanje rizicima, korak 13, Planiranje obrade rizika i Izjava o primjenjivosti, Clarysec opisuje SoA kao povezni dokument koji povezuje procjenu i obradu rizika sa stvarnim kontrolama. Preporučuje mapiranje kontrola na rizike i unakrsno upućivanje na propise poput GDPR-a, NIS2 ili DORA u Registru rizika ili napomenama SoA-a gdje je relevantno.

Za primjer uvođenja, scenarij rizika mogao bi glasiti: „Prekid rada ili kompromitacija pružatelja provjere identiteta ometa uvođenje i izlaže biometrijske podatke o identitetu.” Kontrole obrade rizika mogle bi uključivati dubinsku analizu dobavljača, ugovornu obvezu obavješćivanja o incidentu, šifriranje, kontrolu pristupa, zapisivanje događaja, sigurnosno kopiranje i oporavak, minimizaciju podataka, pseudonimizaciju, praćenje, planiranje izlaska i operativne upute za odgovor na incidente.

Napomena u SoA-u može navesti da skup kontrola podržava odgovornost prema GDPR-u, sigurnost opskrbnog lanca i spremnost za incidente prema NIS2 Article 21 te IKT rizik trećih strana i otpornost kritične funkcije prema DORA.

To je ono što revizori traže: sljedivost.

Mapiranje međusobne usklađenosti: jedan sloj dokaza, više pitanja

RoPA i mapiranje tokova podataka nisu odvojeni silosi usklađenosti. Oni podržavaju zajednički skup pitanja kroz GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 i COBIT 2019.

NIST CSF 2.0 koristan je kao organizacijski sloj. Njegovi CSF profili podržavaju analizu trenutačnog i ciljnog stanja koristeći ulaze kao što su politike, prioriteti rizika, registri utjecaja na poslovanje, zahtjevi, standardi, prakse, alati i radne uloge. Njegova funkcija GOVERN uključuje pravne, regulatorne, ugovorne, privatnosne obveze i obveze povezane s građanskim slobodama, ciljeve rizika, odgovornost vodstva, uloge, politike, nadzor i pregled učinkovitosti. Ishodi opskrbnog lanca zahtijevaju da dobavljači budu poznati i prioritizirani prema kritičnosti, da se ugovorni zahtjevi kibernetičke sigurnosti integriraju, da se dubinska analiza dobavljača provodi prije uspostave odnosa, da se rizici dobavljača evidentiraju i prate te da se dobavljači uključe u planiranje odgovora na incidente i oporavka.

To se uredno preslikava na Clarysecov operativni model RoPA-e. RoPA daje kontekst privatnosti. Popis imovine daje tehnički kontekst. Registri dobavljača i oblaka daju kontekst trećih strana. BIA daje kontekst kritičnosti. SoA daje kontekst kontrola.

Jedna kontrola iz Priloga A norme ISO/IEC 27001:2022 također može podržati više okvira. Kontrola 5.14, Prijenos informacija, dobar je primjer.

To je vrijednost Zenith Controls kao kompasa za međusobnu usklađenost. Pomaže organizacijama objasniti zašto jedna kontrolna praksa podržava više regulatornih i revizijskih očekivanja.

Kako će različiti revizori testirati istu mapu

Zrela RoPA i mapa tokova podataka mogu zadovoljiti više revizora, ali svaki će im pristupiti drugačije.

Revizor ISO/IEC 27001:2022 počet će s opsegom, zainteresiranim stranama, rizicima, dokumentiranim informacijama i odabirom kontrola. Pitat će jesu li identificirani pravni i ugovorni zahtjevi, jesu li osobni podaci i kritične usluge unutar opsega ISMS-a, imaju li imovine vlasnike i klasifikacije, je li procjena rizika razmotrila povjerljivost, cjelovitost i dostupnost te opravdava li SoA primjenjive kontrole.

Revizor za GDPR ili regulator privatnosti počet će s odgovornošću. Provjerit će odražava li RoPA stvarnu obradu, jesu li svrhe i pravne osnove dokumentirane, jesu li identificirane posebne kategorije podataka, primjenjuju li se rokovi zadržavanja, jesu li primatelji i izvršitelji obrade točni te postoje li odgovarajuće zaštitne mjere za prijenose i sigurnost.

Revizor usmjeren na NIS2 gledat će utjecaj na uslugu. Pitat će kako organizacija određuje kritične ili važne usluge, kako je uprava odobrila mjere rizika i nadzire ih, kako se uzimaju u obzir ranjivosti dobavljača i rizici pružatelja usluga, kako su kontinuitet i postupanje s incidentima povezani te može li organizacija podržati rokove za 24-satno, 72-satno i završno izvješćivanje pouzdanim dokazima.

Revizor za DORA gledat će upravljanje IKT rizicima i kritične ili važne funkcije. Provjerit će je li upravljačko tijelo odobrilo okvir IKT rizika i strategiju otpornosti, jesu li IKT aranžmani s trećim stranama registrirani, jesu li procijenjeni kritičnost i rizik koncentracije, uključuju li ugovori zahtijevane uvjete, obuhvaća li testiranje sustave koji podržavaju kritične ili važne funkcije te klasificiraju li se incidenti prema pogođenim klijentima, transakcijama, prekidu rada, geografiji, gubitku podataka, kritičnosti usluge i gospodarskom utjecaju.

Procjenitelj prema NIST CSF 2.0 često će koristiti profile. Usporedit će trenutačne i ciljne ishode kroz GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. RoPA i mape tokova podataka postaju ulazi za upravljanje pravnim obvezama, popise imovine, rizik dobavljača, zaštitu podataka, praćenje, komunikacije o incidentima i planiranje oporavka.

Revizor u stilu COBIT 2019 ili ISACA usredotočit će se na upravljanje, vlasništvo i sposobnost procesa. Provjerit će imaju li tokovi informacija vlasnike, jesu li prava odlučivanja jasna, primjenjuje li se apetit za rizik, prate li se kontrole, eskaliraju li se iznimke i jesu li dokazi dovoljno pouzdani za upravljačko osiguranje.

Uobičajeni obrasci neuspjeha

Najčešći neuspjesi RoPA-e i mapiranja tokova podataka predvidljivi su.

Prvo, RoPA navodi aktivnosti obrade, ali ne i sustave. Zbog toga je nemoguće povezati odgovornost prema GDPR-u s upravljanjem ranjivostima, pregledom pristupa, sigurnosnim kopiranjem, zapisivanjem događaja ili odgovorom na incidente.

Drugo, mape tokova podataka zaustavljaju se na prvom dobavljaču. Ne prikazuju podizvršitelje obrade, regije oblaka, pristup podrške, analitičke alate, platforme za praćenje ili lokacije sigurnosnih kopija.

Treće, planovi neprekidnosti poslovanja identificiraju sustave, ali ne i osobne podatke. Tijekom prekida organizacija razumije prioritet oporavka, ali ne i utjecaj na privatnost.

Četvrto, registri dobavljača bilježe vlasnike ugovora, ali ne i kritičnost, mogućnost zamjene, kategorije podataka, obveze obavješćivanja o incidentu ili izlazne opcije.

Peto, SoA je napisan kao certifikacijski dokument, a ne kao most kontrola. Navodi da su kontrole primjenjive, ali ne objašnjava koji problem dokaza za GDPR, NIS2 ili DORA pojedina kontrola pomaže riješiti.

Naposljetku, vlasništvo je fragmentirano. DPO je vlasnik RoPA-e, IT je vlasnik imovine, nabava je vlasnik dobavljača, operacije su vlasnik BIA-e, financije su vlasnik registara DORA, a nitko nije vlasnik integrirane mape ovisnosti.

Clarysecov pristup to rješava dodjelom objekata dokaza vlasnicima politika, a zatim korištenjem koraka iz Zenith Blueprinta za povezivanje imovine, rizika, kontrola i sljedivosti SoA-a.

Plan provedbe za 30 dana

Ne trebate rješavati sve odjednom. Počnite s uslugama koje su najvažnije.

1. tjedan: odaberite tri kritične ili visokorizične aktivnosti obrade. Dobri kandidati su uvođenje klijenata, obrada plaćanja, HR administracija zaposlenika, zahtjevi za podršku ili sigurnosno praćenje. Za svaku aktivnost provjerite unos u RoPA-u prema stvarnim sustavima, kategorijama podataka, svrhama, pravnim osnovama i pravilima zadržavanja.

2. tjedan: izradite mape tokova podataka za te aktivnosti. Identificirajte izvor, odredište, metodu prijenosa, okruženje, dobavljača, podizvršitelja obrade, lokaciju podataka, put pristupa, transformaciju i točku zadržavanja. Upotrijebite zahtjev iz Clarysecove Politike maskiranja podataka i pseudonimizacije za održavanje popisa sustava i tokova podataka koji uključuju osjetljive podatke.

3. tjedan: povežite svaki tok s imovinom, dobavljačima, uslugama u oblaku i kritičnim poslovnim funkcijama. Upotrijebite Zenith Blueprint korak 9 za vlasništvo nad imovinom i klasifikaciju. Upotrijebite zahtjeve politike za registre dobavljača i oblaka radi prikupljanja dokaza trećih strana. Upotrijebite politiku neprekidnosti poslovanja za identifikaciju prioritiziranih usluga i kritičnih ovisnosti.

4. tjedan: dodajte sljedivost rizika i kontrola. Za svaki tok izradite ili ažurirajte scenarije rizika. Mapirajte kontrole u SoA-u koristeći Zenith Blueprint korak 13. Dodajte napomene za odgovornost prema GDPR Article 30, mjere rizika prema NIS2 Article 21 i dokaze o IKT ovisnostima prema DORA gdje je primjenjivo.

Zatim provedite jednu stolnu vježbu: „Prekid rada dobavljača uz izloženost podataka u kritičnoj usluzi.” Testirajte podržavaju li vaši dokazi klasifikaciju incidenta, odluke o obavješćivanju, komunikaciju s klijentima, komunikaciju s regulatorom i prioritizaciju oporavka.

Do kraja 30 dana imat ćete ponovljiv model za ostatak organizacije.

Clarysecov pristup: pretvorite RoPA-u u žive dokaze otpornosti

RoPA i mapiranje tokova podataka više nisu samo administracija privatnosti. Oni su vezivno tkivo između odgovornosti prema GDPR-u, upravljanja kritičnim uslugama prema NIS2 i dokaza IKT ovisnosti prema DORA.

Organizacije koje će u 2026. biti najuspješnije neće biti one s najviše dokumenata. Bit će to one koje mogu povezati poslovnu uslugu s njezinim aktivnostima obrade, tokovima podataka, sustavima, dobavljačima, regijama oblaka, ugovorima, kontrolama, rizicima, pragovima incidenata i planovima oporavka.

Clarysec pomaže timovima izgraditi tu sljedivost bez nepotrebne birokracije. Naš paket politika dodjeljuje vlasništvo i zahtjeve za dokaze. Zenith Blueprint pruža plan provedbe, uključujući identifikaciju imovine, provedbu kontrola dobavljača i oblaka te sljedivost SoA-a. Zenith Controls pruža kompas za međusobnu usklađenost pri mapiranju kontrola iz Priloga A norme ISO/IEC 27001:2022 na očekivanja privatnosti, otpornosti, dobavljača, oblaka i revizije.

Vaš sljedeći korak je jednostavan: odaberite jednu kritičnu uslugu, jedan unos u RoPA-u i jedan tok podataka podržan dobavljačem. Mapirajte ga od početka do kraja. Ako na jednoj stranici ne možete objasniti podatke, ovisnost, kontrolu i utjecaj incidenta, vaš sloj dokaza nije spreman za 2026.

Clarysec vam može pomoći da ga pripremite. Istražite Zenith Blueprint, ojačajte svoje upravljanje uz Politiku zaštite podataka i privatnosti i Politiku upravljanja rizikom ovisnosti o dobavljačima te upotrijebite Zenith Controls kako biste fragmentirane dokaze o usklađenosti pretvorili u jedan operativni model spreman za reviziju.