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

Upravljanje anonimizacijom i rizikom ponovne identifikacije

Igor Petreski
14 min read
Radni tijek upravljanja anonimizacijom i rizikom ponovne identifikacije

Projektu umjetne inteligencije trebalo je pet godina podataka. Revizoru su trebali dokazi.

Prijedlog je stigao na stol CISO-a Marije Kuznetsov s uvjerenjem da je riječ o poslovnom prioritetu koji je interno već prihvaćen. Tim za znanost o podacima želio je pet godina povijesti korisničkih transakcija i ponašanja za treniranje novog sustava umjetne inteligencije za personalizaciju. Produktni tim želio je preciznije predviđanje odljeva korisnika. Prodaja je željela agregirane usporedne pokazatelje za klijente. Financije su željele smanjiti izloženost pohrane brisanjem izvornih tablica, ali zadržati podatke o trendovima.

Jamstvo je bilo kratko i samouvjereno: „Ne brinite, anonimizirat ćemo podatke.”

Maria je znala da ta rečenica nije kontrola. Prema GDPR-u, „anonimno” nije oznaka u bazi podataka, skripta za maskiranje ni obećanje produktnog tima. Podaci su izvan GDPR-a samo kada osobe više nije moguće identificirati sredstvima za koja je razumno vjerojatno da će se upotrijebiti, uzimajući u obzir stvarni kontekst u kojem podaci postoje. Taj kontekst uključuje interne korisnike, sustave podrške, platforme dobavljača, analitičke alate, usluge u oblaku, javne evidencije, izvoze podataka o klijentima i buduće obogaćivanje.

Zatim je revizor privatnosti postavio pitanje koje je zaustavilo raspravu:

„Pokažite mi kako ste procijenili rizik ponovne identifikacije, tko je odobrio odluku o anonimizaciji i kako znate da skup podataka ostaje neidentificirajući nakon dodavanja novih izvora podataka.”

To je stvarni izazov upravljanja anonimizacijom prema ISO 27701:2025 i GDPR-u. Nije dovoljno ukloniti imena, adrese e-pošte i identifikatore računa. Organizacija mora tijekom vremena dokazati da transformirani podaci nisu razumno povezivi s osobom u njezinu poslovnom, tehničkom, pravnom i dobavljačkom okruženju.

Za CISO-e, DPO-e, rukovoditelje usklađenosti, revizore i poslovne vlasnike anonimizacija je privlačna jer podupire analitiku, smanjenje količine podataka, sigurnije testiranje, smanjenje rizika zadržavanja i vanjsko dijeljenje podataka. Istodobno je opasna kada se tretira kao čarobna oznaka. Slaba pseudonimizacija može se poništiti. Agregati i dalje mogu izdvojiti pojedince. Skupovi testnih podataka mogu se povezati s produkcijskim dnevničkim zapisima. Timovi za umjetnu inteligenciju i poslovnu inteligenciju mogu kombinirati „sigurne” skupove podataka u nešto što više nije sigurno.

Stajalište Claryseca jednostavno je: anonimizacijom i rizikom ponovne identifikacije mora se upravljati kao obradom rizika za privatnost unutar istog integriranog modela dokaza ISMS-a i PIMS-a koji podupire ISO/IEC 27001:2022, ISO 27701:2025, GDPR, NIS2, DORA, NIST CSF 2.0, COBIT 2019 i revizije klijenata.

Anonimizacija je upravljačka odluka, a ne korak u podatkovnom cjevovodu

Mnoge organizacije naizmjenično koriste pojmove privatnosti, čime stvaraju pravnu i revizijsku izloženost. Prvi je korak definirati što svako stanje podataka znači i koje upravljačko pitanje otvara.

PojamPraktično značenjeUpravljačko pitanje
MaskiranjeSakrivanje ili zamjena vrijednosti za konkretan slučaj uporabeJe li maskirani skup podataka i dalje poveziv s osobom preko drugih polja ili sustava?
PseudonimizacijaZamjena identifikatora uz zadržavanje mogućnosti ponovnog povezivanja u kontroliranim uvjetimaTko može provesti povratno povezivanje, gdje je ključ i koji revizijski trag dokazuje da je pristup bio opravdan?
DeidentifikacijaSmanjenje mogućnosti identifikacije uklanjanjem, transformacijom, agregiranjem ili kontrolamaKoji preostali rizik ponovne identifikacije ostaje i je li prihvatljiv?
AnonimizacijaTransformacija podataka tako da u kontekstu više nisu razumno identificirajućiKoji dokazi to sada potvrđuju i koji nadzor dokazuje da to ostaje točno?

GDPR ovu razliku čini ključnom. Article 4 široko definira osobne podatke kao informacije koje se odnose na identificiranu osobu ili osobu koju je moguće identificirati. Article 4(5) definira pseudonimizaciju kao obradu osobnih podataka tako da se više ne mogu pripisati određenoj osobi bez uporabe dodatnih informacija, pod uvjetom da se te dodatne informacije čuvaju odvojeno i štite. Pseudonimizirani podaci ostaju osobni podaci.

Uvodna izjava 26 pojašnjava visoku razinu zahtjeva za anonimizaciju. Načela GDPR-a ne primjenjuju se na informacije učinjene anonimnima tako da ispitanik nije ili više nije identificiran. Test nije jesu li izravni identifikatori uklonjeni. Test je ostaje li identifikacija razumno moguća.

Article 5 zatim podiže zahtjev u pogledu odgovornosti. Osobni podaci moraju se obrađivati zakonito, pošteno i transparentno, za određene svrhe, ograničeno na ono što je nužno, zadržani u obliku koji omogućuje identifikaciju samo onoliko dugo koliko je potrebno te primjereno zaštićeni. Article 5(2) zahtijeva da voditelj obrade dokaže usklađenost.

To znači da tvrdnja o anonimizaciji zahtijeva dokaze. Ako interni ključevi, rijetki atributi, vremenske oznake, geolokacija, slijedovi transakcija, otisci uređaja, tiketi korisničke podrške, javni skupovi podataka ili obogaćivanje od strane dobavljača mogu ponovno povezati podatke s osobom, skup podataka može i dalje biti osobni podatak.

Clarysecova politika za poslovna okruženja Politika zadržavanja, brisanja i zbrinjavanja osobnih podataka tretira anonimizaciju kao kontroliranu odluku o zadržavanju i zbrinjavanju, a ne kao prečac oko brisanja:

[Both] Vlasnik procesa / poslovni vlasnik MORA dokumentirati anonimizaciju, deidentifikaciju ili pseudonimizaciju kao mjeru smanjenja rizika zadržavanja ili ishod konačnog zbrinjavanja u REG02 prije transformacije osobnih podataka koji omogućuju identifikaciju osobe.

Iz odjeljka „Anonimizacija, deidentifikacija i minimizacija zadržavanja”, točka politike 4.5.1.

Ista politika zahtijeva odobrenje prije nego što se anonimizacija upotrijebi kao alternativa brisanju:

[Both] Voditelj privatnosti / voditelj PIMS-a MORA odobriti uporabu anonimizacije ili deidentifikacije kao alternative brisanju u REG02 prije nego što se izvorni osobni podaci koji omogućuju identifikaciju osobe zadrže izvan svoje svrhe ili roka zadržavanja.

Iz odjeljka „Anonimizacija, deidentifikacija i minimizacija zadržavanja”, točka politike 4.5.2.

To je revizijska točka koju mnoge organizacije propuštaju. Poslovni vlasnik ne može reći: „Anonimizirali smo ih, pa se zadržavanje više ne primjenjuje.” Dokazi moraju pokazati zašto je anonimizacija bila primjerena, što je transformirano, što se dogodilo s izvornim osobnim podacima koji omogućuju identifikaciju osobe, tko je odobrio odluku i kada će se preostali rizik pregledati.

Lanac odgovornosti prema GDPR-u iza rizika ponovne identifikacije

Dokaziv program upravljanja anonimizacijom počinje operativnom logikom GDPR-a.

Prvo, utvrdite primjenjuje li se GDPR. Article 3 proširuje GDPR na obradu u kontekstu poslovnog nastana u EU-u te na organizacije izvan EU-a koje nude robu ili usluge osobama u EU-u ili prate njihovo ponašanje u EU-u. SaaS, fintech, analitika, adtech, HR platforme, pružatelji usluga u oblaku i dobavljači sustava umjetne inteligencije mogu biti obuhvaćeni područjem primjene i kada su sjedište ili infrastruktura izvan EU-a.

Drugo, definirajte ulogu organizacije. Voditelj obrade određuje svrhe i sredstva. Izvršitelj obrade djeluje prema dokumentiranim uputama voditelja obrade. Zajednički voditelji obrade dijele odlučivanje i odgovornost. Podizvršitelji obrade nasljeđuju ugovorna ograničenja i tehničke obveze. To je važno jer se odluke o anonimizaciji razlikuju ovisno o ulozi:

  • Voditelj obrade mora obrazložiti svrhu, pravnu osnovu, zadržavanje, transparentnost i daljnju obradu.
  • Izvršitelj obrade mora slijediti upute klijenta i izbjegavati samostalnu ponovnu uporabu ako nema zakonitu ulogu.
  • Podizvršitelj obrade mora poštovati prenesena ograničenja, obveze brisanja i ograničenja daljnjeg dijeljenja.
  • Zajednički voditelji obrade moraju dokumentirati zajedničke odgovornosti i osigurati jasne transparentne informacije.

Treće, povežite anonimizaciju s Article 6. Ako se podaci ponovno koriste za analitiku, usporedne pokazatelje, treniranje modela ili sekundarnu operativnu uporabu, organizacija mora procijeniti pravnu osnovu i usklađenost sa svrhom. Anonimizacija može smanjiti rizik, ali ostaje pitanje je li izlazni rezultat stvarno anoniman ili samo transformirani osobni podatak.

Četvrto, identificirajte rizik posebnih kategorija podataka ili osjetljivog zaključivanja. Article 9 propisuje strože uvjete za zdravstvene podatke, biometrijske podatke za jedinstvenu identifikaciju, genetske podatke, politička mišljenja, vjeru, članstvo u sindikatu, rasno ili etničko podrijetlo, spolni život i seksualnu orijentaciju. Čak i kada su očiti identifikatori uklonjeni, rijetke kombinacije i izvedeni atributi mogu naštetiti osobama.

Clarysecova Politika zaštite podataka i privatnosti za MSP-ove postavlja to kao praktično očekivanje za obradu rizika:

Kontrole se moraju implementirati radi smanjenja identificiranih rizika, uključujući šifriranje, anonimizaciju, sigurno zbrinjavanje i ograničenja pristupa

Iz odjeljka „Obrada rizika i iznimke”, točka politike 7.2.1.

Za MSP-ove poruka je namjerno izravna. Anonimizacija je jedna zaštitna mjera među mnogima. Mora djelovati zajedno sa šifriranjem, ograničenjima pristupa, sigurnim zbrinjavanjem, kontrolama dobavljača, zapisivanjem događaja i pregledom.

Zašto je ISO/IEC 27001:2022 i dalje važan za dokaze PIMS-a prema ISO 27701:2025

Upravljanje privatnošću prema ISO 27701:2025 ovisi o okosnici sustava upravljanja. Standard proširuje obveze privatnosti kroz PIMS, ali snažni dokazi i dalje se oslanjaju na disciplinu ISMS-a prema ISO/IEC 27001:2022.

Najvažniji zahtjevi ISO/IEC 27001:2022 za anonimizaciju nisu samo tehnički. To su zahtjevi upravljanja:

  • Točke 4.1 do 4.4 uspostavljaju kontekst organizacije, zainteresirane strane, opseg, sučelja, ovisnosti i procese sustava upravljanja.
  • Točke 5.1 do 5.3 zahtijevaju vodstvo, politiku, uloge, odgovornosti, odgovornost i izvješćivanje.
  • Točke 6.1.1 do 6.1.3 zahtijevaju planiranje rizika i prilika, procjenu rizika informacijske sigurnosti, obradu rizika, odabir kontrola, Izjavu o primjenjivosti, planove obrade rizika i prihvaćanje preostalog rizika.

To znači da rizik anonimizacije pripada u registar rizika, plan obrade rizika i Izjavu o primjenjivosti, a ne samo u tiket podatkovnog inženjeringa.

Zenith Blueprint tu sljedivost izričito prikazuje u fazi upravljanja rizicima, koraku 13, planiranju obrade rizika i Izjavi o primjenjivosti:

SoA je zapravo premosni dokument: povezuje vašu procjenu/obradu rizika sa stvarnim kontrolama koje imate.

Iz faze upravljanja rizicima, korak 13: planiranje obrade rizika i Izjava o primjenjivosti.

Za anonimizaciju i rizik ponovne identifikacije taj most treba povezati:

  • aktivnost obrade i svrhu prema GDPR-u
  • ulogu voditelja obrade, izvršitelja obrade, zajedničkog voditelja obrade ili podizvršitelja obrade
  • obvezu PIMS-a prema ISO 27701:2025 i vlasnika privatnosti
  • scenarij rizika ponovne identifikacije i model napadača
  • kategorije podataka, sustave, primatelje i dobavljače
  • primijenjene zaštitne mjere, kao što su agregiranje, izuzimanje, maskiranje, pseudonimizacija, brisanje, kontrola pristupa, ugovorna ograničenja i nadzor
  • kontrole ISO/IEC 27002:2022 kao što su 5.9 Popis informacija i druge povezane imovine, 5.12 Klasifikacija informacija, 5.15 Kontrola pristupa, 5.18 Prava pristupa, 5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, 5.23 Informacijska sigurnost za uporabu usluga u oblaku, 5.34 Privatnost i zaštita osobnih podataka, 8.10 Brisanje informacija, 8.11 Maskiranje podataka, 8.12 Sprječavanje curenja podataka, 8.15 Zapisivanje događaja, 8.24 Uporaba kriptografije i 8.33 Testne informacije
  • prihvaćanje preostalog rizika i učestalost pregleda

Ako klijent pita zašto se anonimizirana telemetrija zadržava nakon zatvaranja računa, odgovor ne smije biti „zato što to treba proizvodu”. Odgovor treba biti unos u registar obrade, procjena rizika za privatnost, zapis o izvedivosti anonimizacije, odobrenje zbrinjavanja prema pravilima zadržavanja, tehnički dokazi, evidencije pristupa, ograničenja za dobavljače i prihvaćanje od strane uprave.

Clarysecova mapa kontrola za privatnost, brisanje, maskiranje i testne podatke

Upravljanje anonimizacijom postaje vjerodostojno kada su politika, rizik i tehničke kontrole međusobno mapirani.

Zenith Controls tretira kontrolu ISO/IEC 27002:2022 5.34, Privatnost i zaštita osobnih podataka, kao preventivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost. Usklađena je s konceptima Identify i Protect te djeluje kroz zaštitu informacija i pravne poslove i usklađenost.

Zenith Controls objašnjava da 5.34 ovisi o poznavanju mjesta na kojima postoje osobni podaci. Povezuje 5.34 s 5.9, Popis informacija i druge povezane imovine, jer baze podataka klijenata, HR datoteke, dnevnički zapisi, telemetrija, sigurnosne kopije, izvozi i zapisi podrške moraju biti uključeni u popise imovine. Bez popisa imovine mjere privatnosti kao što su upravljanje privolama, šifriranje, maskiranje, brisanje, anonimizacija i ograničenja za dobavljače promašit će spremišta podataka.

Zenith Controls također povezuje 5.34 s 8.11, Maskiranje podataka, jer maskiranje smanjuje izloženost stvarnih osobnih podataka u izvješćima, neprodukcijskim okruženjima, analitičkim platformama i radnim tijekovima dijeljenja. Za 8.11 Zenith Controls određuje je kao preventivnu kontrolu povjerljivosti u konceptu Protect, s operativnom sposobnošću u zaštiti informacija. Povezuje 8.11 s:

  • 5.12, Klasifikacija informacija, jer maskiranje ovisi o klasifikaciji osjetljivosti.
  • 5.34, Privatnost i zaštita osobnih podataka, jer maskiranje provodi ugrađenu zaštitu privatnosti.
  • 8.33, Testne informacije, jer sigurni skupovi testnih podataka trebaju biti sintetički, anonimizirani ili maskirani.

Za 8.10, Brisanje informacija, Zenith Controls povezuje brisanje s 8.11 Maskiranje podataka i 8.12 Sprječavanje curenja podataka, čime se oblikuje strategija životnog ciklusa: zaštititi podatke u uporabi, spriječiti curenje i osigurati da se podaci ne mogu oporaviti nakon što više nisu potrebni.

Područje kontroleZašto je važno za upravljanje anonimizacijom
Popis imovineNe možete anonimizirati, klasificirati ni izbrisati podatke koje niste identificirali.
KlasifikacijaOznake osjetljivosti i mogućnosti identifikacije usmjeravaju odluke o maskiranju, agregiranju i pristupu.
Privatnost i zaštita osobnih podatakaPIMS definira obveze privatnosti, uloge, odobrenja i dokaze.
Brisanje informacijaAnonimizacija može biti ishod konačnog zbrinjavanja, ali samo uz odobrenje i dokaz.
Maskiranje podatakaMaskiranje, pseudonimizacija i transformacija smanjuju izloženost, ali zahtijevaju provjeru.
Kontrola pristupa i prava pristupaPokušaji ponovne identifikacije, ključevi povezivanja i izvozi moraju biti ograničeni.
Zapisivanje događajaPovratno povezivanje, pristup, obogaćivanje, administrativne promjene i izvozi zahtijevaju revizijske tragove.
Sigurnost dobavljača i oblakaDobavljači ne smiju ponovno povezivati, obogaćivati, prenamjenjivati ni dalje dijeliti transformirane skupove podataka.
Testne informacijeNeprodukcijska okruženja ne smiju postati laboratoriji za ponovnu identifikaciju.

Zenith Blueprint to dodatno potvrđuje u fazi kontrole u praksi, koraku 21, kontrole 8.27 do 8.34:

U konačnici, kontrola 8.33 podsjeća nas da informacije ne gube vrijednost samo zato što su u sandbox okruženju.

Iz faze kontrole u praksi, korak 21: kontrole 8.27-8.34.

Ta rečenica pripada svakom radnom tijeku za testne podatke, osiguranje kvalitete, analitiku, poslovnu inteligenciju i strojno učenje.

Praktični Clarysec radni tijek za odobravanje anonimiziranog analitičkog skupa podataka

Marijin projekt umjetne inteligencije ne treba opću zabranu. Treba upravljano „da, ako”. Implementacija koju vodi Clarysec slijedila bi ponovljiv radni tijek.

1. Registrirajte aktivnost obrade

Koordinator za privatnost ili voditelj PIMS-a ažurira registar obrade kategorijama podataka, svrhom, pravnom osnovom, zadržavanjem, primateljima, sustavima, dobavljačima i ulogom u PIMS-u.

Clarysecova Politika zaštite podataka i privatnosti za MSP-ove zahtijeva ovu polaznu osnovu:

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

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.2.1.

Za dokaze PIMS-a u poslovnom okruženju zapis također treba utvrditi djeluje li organizacija kao voditelj obrade, izvršitelj obrade, zajednički voditelj obrade ili podizvršitelj obrade. Ako je pružatelj SaaS usluge izvršitelj obrade za korisničku telemetriju, možda će trebati uputu klijenta prije stvaranja anonimiziranih izvedenih skupova podataka. Ako je voditelj obrade za analitiku proizvoda, potrebna mu je dokumentacija o pravnoj osnovi i svrsi.

2. Dokažite da je obrada podataka koji omogućuju identifikaciju nužna

Prije nego što se osobni podaci koji omogućuju identifikaciju osobe odobre za analitiku, izvješćivanje, testiranje ili sekundarnu uporabu, poslovni vlasnik mora procijeniti je li izvediva obrada koja ne omogućuje identifikaciju.

Clarysecova politika za poslovna okruženja Politika ugrađene i zadane zaštite privatnosti navodi:

[Both] Vlasnik procesa / poslovni vlasnik MORA dokumentirati izvedivost deidentifikacije, pseudonimizacije, agregiranja ili obrade koja ne omogućuje identifikaciju u REG04 prije odobravanja osobnih podataka koji omogućuju identifikaciju osobe za testiranje, analitiku, izvješćivanje ili sekundarnu operativnu uporabu.

Iz odjeljka „Minimizacija podataka i dizajn zadane zaštite privatnosti”, točka politike 4.2.5.

Ovdje upravljanje sprječava prekomjerno prikupljanje. Tim za znanost o podacima možda ne treba izvorne vremenske oznake, točne lokacije, pune slijedove događaja, nemaskirane domene ili rijetke atribute segmenata. Grupiranje datuma, agregiranje, izuzimanje malih kohorti, generiranje sintetičkih značajki i uklanjanje jedinstvenih identifikatora uređaja mogu očuvati uporabljivost uz niži rizik.

3. Procijenite rizik ponovne identifikacije

Procjena rizika za privatnost treba ocijeniti izdvajanje pojedinaca, povezivost, zaključivanje, jedinstvenost, interni pristup, vanjske skupove podataka, pristup dobavljača i buduće obogaćivanje. Treba definirati realističan model napadača, uključujući znatiželjnog zaposlenika, analitičara dobavljača, klijenta s djelomičnim znanjem ili odlučnu vanjsku stranu.

Clarysecova politika za poslovna okruženja Politika zadržavanja, brisanja i zbrinjavanja osobnih podataka zahtijeva pregled pretpostavki za visokorizične ili izvana dijeljene podatke:

[Both] Službenik za zaštitu podataka / savjetnik za privatnost MORA pregledati pretpostavke rizika ponovne identifikacije u REG12 prije odobrenja anonimizacije ili deidentifikacije za visokorizične ili izvana dijeljene skupove podataka.

Iz odjeljka „Anonimizacija, deidentifikacija i minimizacija zadržavanja”, točka politike 4.5.4.

REG12 treba odgovoriti na praktična revizijska pitanja: koji su izravni identifikatori uklonjeni, koji kvaziidentifikatori ostaju, koji se pragovi agregiranja primjenjuju, izuzimaju li se male skupine, mogu li slijedovi događaja identificirati pojedince, mogu li zaposlenici povezati izlazni rezultat s produkcijskim sustavima, mogu li ga dobavljači obogatiti, postoje li zaključivanja o posebnim kategorijama podataka, koji preostali rizik ostaje, tko ga je prihvatio i kada će se pregledati.

4. Primijenite kontrole i zadržite tehničke dokaze

Tehnički dokazi mogu uključivati logiku transformacije, skripte za maskiranje, postavke alata za anonimizaciju, rezultate uzorkovanja, testiranje jedinstvenosti, provjere agregiranja, dnevničke zapise brisanja izvornih podataka, liste kontrole pristupa, odobrenja izvoza, dnevničke zapise spremišta ključeva i upozorenja iz nadzora.

Zenith Blueprint, faza kontrole u praksi, korak 19, tehnološke kontrole I, navodi da je maskiranje podataka usmjereno na „sprječavanje nepotrebne izloženosti unutar vaše organizacije” i preporučuje definiranje slučajeva uporabe u kojima su maskiranje ili anonimizacija obvezni, uključujući testna okruženja, platforme za strojno učenje ili poslovnu inteligenciju te podatke koji se dijele s vanjskim dobavljačima. Također navodi da dokazi mogu uključivati pohranjene skripte ili konfiguracije maskiranja, postavke alata ili dnevničke zapise te pisane postupke koji uređuju izradu sigurnih skupova podataka.

Ti dokazi pripadaju u registar dokaza PIMS-a i trebaju biti povezani s aktivnošću obrade, procjenom REG04, pretpostavkama REG12, registrom rizika, planom obrade rizika i SoA-om.

5. Upravljajte reverzibilnošću i ključevima

Ako je skup podataka pseudonimiziran, a ne anonimiziran, reverzibilnost mora biti iznimna, odobrena, evidentirana i odvojena.

Clarysecova politika za poslovna okruženja Politika maskiranja podataka i pseudonimizacije navodi:

Reverzibilnost pseudonimiziranih podataka nikada ne smije biti omogućena prema zadanim postavkama i mora se strogo upravljati, uključujući revizijske tragove i provedbu kontrole pristupa na temelju uloga.

Iz odjeljka „Obrada rizika i iznimke”, točka politike 7.5.

Verzija za MSP-ove ističe zabranjeno ili visokorizično ponašanje. Politika maskiranja podataka i pseudonimizacije za MSP-ove kao scenarij obrade rizika i iznimke navodi:

Ponovna identifikacija pseudonimiziranih podataka bez dokumentiranog odobrenja.

Iz odjeljka „Obrada rizika i iznimke”, točka politike 7.3.4.

Također označava slab reverzibilni dizajn:

Slaba ili reverzibilna pseudonimizacija zbog neodgovarajućeg upravljanja ključevima.

Iz odjeljka „Obrada rizika i iznimke”, točka politike 7.1.1.3.

Za revizore je to mjesto gdje privatnost postaje dokaz sigurnosne kontrole: upravljanje ključevima, razdvajanje dužnosti, odobrenja pristupa, zapisivanje događaja, upozoravanje i pregled iznimaka.

6. Zatvorite procjenu uz preostali rizik i okidače za pregled

Clarysecova politika za poslovna okruženja Politika procjene rizika za privatnost i DPIA-e zahtijeva disciplinirano zatvaranje:

[Both] Voditelj privatnosti / voditelj PIMS-a MORA osigurati da svaka procjena REG04 evidentira ocjenu rizika, odluku o obradi rizika, vlasnika, krajnji rok, preostali rizik, status odobrenja i datum pregleda prije zatvaranja.

Iz odjeljka „Provedba procjene rizika za privatnost i DPIA-e”, točka politike 4.3.7.

Ako se skup podataka naknadno obogaćuje, dijeli izvana, koristi za treniranje modela, povezuje s podacima podrške, premješta u drugu uslugu u oblaku ili kombinira s novim atributima klijenata, okidač za pregled treba ponovno otvoriti procjenu.

Testni podaci često su mjesto neuspjeha programa anonimizacije

Produkcijski sustavi obično imaju snažnije kontrole od testnih okruženja. Pripremna okruženja, osiguranje kvalitete, razvojna okruženja i analitički sandboxi često imaju širi pristup, slabiji nadzor, dijeljene vjerodajnice, opuštenija mrežna pravila, offshore testiranje, stare kopije baza podataka i nejasno vlasništvo.

Zato su testni podaci česta zona rizika ponovne identifikacije.

Clarysecova Politika testnih podataka i testnih okruženja za MSP-ove zahtijeva:

Podaci se moraju anonimizirati ili pseudonimizirati primjenom odgovarajućih alata

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.1.2.2.

Clarysecova politika za poslovna okruženja Politika testnih podataka i testnih okruženja ide dalje i zahtijeva da anonimizirani ili maskirani skupovi podataka budu:

Provjereni radi sprječavanja ponovne identifikacije putem unakrsnog povezivanja

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.2.1.2.

To znači da podatke za osiguranje kvalitete treba testirati prema realističnim napadima povezivanja. Može li razvojni inženjer identificirati VIP klijenta prema vremenu transakcije i gradu? Mogu li se tiketi podrške povezati s testnim zapisima? Mogu li rijetki obrasci uporabe proizvoda identificirati jednog poslovnog zakupca? Mogu li maskirane adrese e-pošte otkriti korisnička imena ili domene? Mogu li dnevnički zapisi, snimke zaslona ili tragovi za otklanjanje pogrešaka otkriti izvorne identifikatore? Mogu li se testne i produkcijske baze podataka spojiti preko zadržanih brojeva računa?

Dokazi PIMS-a prema ISO 27701:2025 trebaju pokazati pravilo, iznimku, odobrenje, zaštitnu mjeru i čišćenje.

Očekivanja mapiranja usklađenosti među okvirima za upravljanje anonimizacijom

Upravljanje anonimizacijom vodi se iz perspektive privatnosti, ali nije samo pitanje privatnosti.

NIS2 Article 21 zahtijeva da ključni i važni subjekti implementiraju primjerene i razmjerne tehničke, operativne i organizacijske mjere za upravljanje rizicima za mrežne i informacijske sustave te za smanjenje utjecaja incidenata. Te mjere uključuju analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, siguran razvoj, procjenu djelotvornosti kontrola, osposobljavanje, kriptografiju, kontrolu pristupa, upravljanje imovinom i autentifikaciju. NIS2 Article 23 također je važan jer incident ponovne identifikacije može postati prijavljiv ako uzrokuje značajan poremećaj u radu, financijski gubitak ili materijalnu ili nematerijalnu štetu osobama.

DORA se primjenjuje na mnoge financijske subjekte od 17. siječnja 2025. Articles 5 i 6 čine upravljanje IKT rizicima odgovornošću upravljačkog tijela i predmetom revizije. Articles 17 do 19 zahtijevaju otkrivanje, klasifikaciju, eskalaciju i prijavljivanje IKT incidenata, analizu temeljnog uzroka te obavješćivanje klijenata kada su pogođeni financijski interesi. Articles 28 do 30 zahtijevaju registre trećih strana u području IKT-a, dubinsku analizu dobavljača, ugovorne kontrole, povjerljivost, cjelovitost i dostupnost podataka, prava pristupa i oporavka, prava na reviziju i planiranje izlaska. Ako fintech dijeli deidentificirane skupove transakcijskih podataka s pružateljem analitike u oblaku, upravljanje anonimizacijom ujedno je i upravljanje otpornošću trećih strana.

NIST CSF 2.0 pomaže izvršnim rukovoditeljima prevesti rizik privatnosti u rizik organizacije. Njegova funkcija GOVERN uključuje GV.OC-03 za pravne, regulatorne, ugovorne, privatnosne i građanskopravne obveze, GV.RM-03 za integriranje kibernetičkog rizika u upravljanje rizicima organizacije, GV.RM-06 za standardizirani izračun i prioritizaciju rizika te GV.PO-01 i GV.PO-02 za uspostavu, provedbu, pregled i ažuriranje politika.

COBIT 2019 i ISACA perspektive osiguranja usmjerene su na ovlasti za odlučivanje, vlasništvo nad kontrolama, upravljanje životnim ciklusom podataka, operativnu djelotvornost kontrola, prihvaćanje rizika i pouzdanost dokaza. Pregledavatelj usmjeren na COBIT pitat će je li uprava definirala uloge, ciljeve uspješnosti, odgovornosti za nadzor i postupanje s iznimkama.

Potporni ISO standardi mogu ojačati implementaciju. Zenith Blueprint korak 19 upućuje na ISO/IEC 27555 za brisanje i pseudonimizaciju ili anonimizaciju osobnih podataka, ISO/IEC 20889 za tehnike deidentifikacije koje unapređuju privatnost, ISO/IEC 27018 za zaštitu osobnih podataka u javnim okruženjima oblaka i ISO/IEC 29134 za smjernice procjene učinka na privatnost.

Kako će revizori testirati upravljanje anonimizacijom i ponovnom identifikacijom

Različiti revizori mogu pregledavati isti skup podataka kroz različite perspektive, ali obrazac dokaza ostaje dosljedan.

Revizijska perspektivaŠto će revizor pitatiDokazi koje Clarysec priprema
ISO 27701:2025 PIMSJe li odluka o anonimizaciji bila uređena ulogama privatnosti, obvezama, procjenom rizika i odobrenjem?REG02 zbrinjavanje prema pravilima zadržavanja, REG04 procjena ugrađene zaštite privatnosti, REG12 pretpostavke ponovne identifikacije, mapiranje uloga PIMS-a, zapisi o odobrenju
ISO/IEC 27001:2022Je li anonimizacija povezana s rizicima, kontrolama, SoA-om, pristupom, zapisivanjem događaja, brisanjem, kontrolama dobavljača i poboljšanjem?Registar rizika, plan obrade rizika, mapiranja SoA-e, popis imovine, pregledi pristupa, dnevnički zapisi, nalazi interne revizije
Načelo odgovornosti prema GDPR-uMože li voditelj obrade dokazati ograničavanje svrhe, smanjenje količine podataka, ograničenje pohrane, sigurnost, pravnu osnovu i preostali rizik?Registar obrade, zapis o pravnoj osnovi, procjena usklađenosti sa svrhom, raspored zadržavanja, DPIA ili procjena rizika za privatnost
NIST CSF 2.0Jesu li obveze privatnosti i kibernetičke sigurnosti integrirane u upravljanje rizicima organizacije i uređene kroz politike i profile?Trenutačni i ciljni profili, plan praznina, skup politika upravljanja, metrike rizika, izvješćivanje izvršnom rukovodstvu
COBIT 2019 ili ISACADjeluju li ovlasti za odlučivanje, vlasništvo nad kontrolama, nadzor, osiguranje i postupci iznimaka učinkovito?RACI, rezultati testiranja kontrola, odobrenja iznimaka, zapisnici preispitivanja od strane uprave, KPI i KRI izvješćivanje
DORA ili NIS2Stvara li skup podataka IKT, dobavljački, incidentni ili rezilijentni rizik za regulirane usluge?Registar dobavljača, operativne upute za incidente, odredbe za treće strane, dokazi o nadzoru, izvješćivanje upravljačkom tijelu

Sljedeća tablica mapira uobičajena stanja podataka na status prema GDPR-u, rizik, upravljačku radnju i relevantne kontrole ISO/IEC 27002:2022.

Stanje deidentifikacijeStatus prema GDPR-uRizik ponovne identifikacijePotrebna upravljačka radnjaKljučne kontrole ISO/IEC 27002:2022
Neobrađeni produkcijski podaciOsobni podaciVisokStroga kontrola pristupa, uporaba samo za odobrenu svrhu, nadzor i zapisivanje pristupa.5.15 Kontrola pristupa, 5.18 Prava pristupa, 8.15 Zapisivanje događaja, 8.24 Uporaba kriptografije
Pseudonimizirani podaciOsobni podaciSrednji do visokFormalna procjena rizika, sigurno upravljanje ključevima, odobrenje za povratno povezivanje, ugovorne kontrole.8.11 Maskiranje podataka, 5.34 Privatnost i zaštita osobnih podataka, 5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, 8.24 Uporaba kriptografije
Agregirani podaciPotencijalno osobni podaci ili anonimni podaci, ovisno o kontekstuNizak do srednjiIzuzeti male kohorte, testirati jedinstvenost, procijeniti rizik povezivanja, dokumentirati pretpostavke.8.11 Maskiranje podataka, 5.12 Klasifikacija informacija, 5.34 Privatnost i zaštita osobnih podataka
Stvarno anonimizirani podaciIzvan GDPR-a ako osobe više nije moguće identificiratiZanemariv kada je provjerenDokumentirati stručnu procjenu, zadržati dokaze, definirati okidače za pregled kod obogaćivanja ili dijeljenja.8.10 Brisanje informacija, 8.11 Maskiranje podataka, 5.34 Privatnost i zaštita osobnih podataka

Revizor neće prihvatiti „uklonili smo imena” kao dostatno. Očekujte uzorkovanje, intervjue, uvid u logiku transformacije, pregled putova pristupa, testiranje izuzimanja malih kohorti, pregled ugovora s dobavljačima i provjeru da se anonimizacija ne koristi za zaobilaženje brisanja bez odobrenja.

Uobičajeni obrasci propusta koje treba ukloniti prije revizije

Najčešći propusti anonimizacije jesu propusti upravljanja prerušeni u inženjerske prečace:

  1. Izravni identifikatori uklonjeni, kvaziidentifikatori zanemareni. Imena i adrese e-pošte uklonjeni su, ali lokacija, dob, vrijeme transakcije, poslodavac, ID uređaja i slijed događaja ostaju jedinstveni.
  2. Pseudonimizacija se predstavlja kao anonimizacija. Postoji tablica za preslikavanje, spremište tokena ili reverzibilni ključ, ali dionici izlazni rezultat nazivaju anonimnim.
  3. Logika zadržavanja zaobiđena. Timovi anonimiziraju podatke kako bi ih zadržali zauvijek, bez dokumentiranja zašto je nastavak zadržavanja opravdan.
  4. Produkcijski podaci kopirani u test. Razvojni inženjeri koriste stvarne podatke jer je „to samo pripremno okruženje”, iako pripremno okruženje ima slabije kontrole.
  5. Obogaćivanje dobavljača nije procijenjeno. Dobavljač prima deidentificirane podatke, ali ih može kombinirati sa svojim skupovima podataka.
  6. Nema pregleda nakon novih izvora podataka. Skup podataka koji je nekoć bio niskorizičan postaje poveziv nakon dodavanja CRM-a, telemetrije, podrške ili marketinških podataka.
  7. Nema operativnih uputa za incidente ponovne identifikacije. Postupci za povrede postoje, ali kriteriji ne obuhvaćaju neovlašteno ponovno povezivanje, neuspjelu anonimizaciju ili zaključivanje s utjecajem na privatnost.
  8. Nema revizijskog traga za povratno povezivanje. Ključevi za pseudonimizaciju postoje, ali pristup nije odobren, evidentiran ni pregledan.

Obrazac korekcije dosljedan je: registrirati, klasificirati, procijeniti, obraditi, odobriti, dokazati, nadzirati i pregledati.

Praktični kontrolni popis za upravljanje anonimizacijom

Koristite ovaj kontrolni popis prije odobravanja analitike, treniranja modela umjetne inteligencije, usporednih pokazatelja za klijente, vanjskog dijeljenja, transformacije zadržavanja ili uporabe testnih podataka:

  • Potvrdite djeluje li organizacija kao voditelj obrade, izvršitelj obrade, zajednički voditelj obrade ili podizvršitelj obrade.
  • Identificirajte svrhu obrade, pravnu osnovu, procjenu usklađenosti sa svrhom ili uputu klijenta.
  • Ažurirajte registar aktivnosti obrade kategorijama podataka, sustavima, primateljima, dobavljačima i zadržavanjem.
  • Klasificirajte skup podataka prema osobnim podacima, posebnim kategorijama, povjerljivosti i poslovnoj osjetljivosti.
  • Odlučite je li obrada koja omogućuje identifikaciju doista nužna.
  • Procijenite izvedivost deidentifikacije, agregiranja, maskiranja, pseudonimizacije ili sintetičkih podataka.
  • Dokumentirajte pretpostavke rizika ponovne identifikacije, uključujući interne i vanjske modele napadača.
  • Provjerite izlazni rezultat u odnosu na rizik izdvajanja pojedinaca, povezivosti, zaključivanja, jedinstvenosti i unakrsnog povezivanja.
  • Definirajte minimalne pragove agregiranja i pravila izuzimanja malih kohorti.
  • Uklonite, generalizirajte ili grupirajte rijetke atribute, točne vremenske oznake, lokacije, identifikatore uređaja i visokorizične slijedove događaja.
  • Ograničite pristup transformiranom skupu podataka uporabom kontrole pristupa na temelju uloga i načela najmanjih privilegija.
  • Evidentirajte pristup, izvoze, povratna povezivanja, obogaćivanja, administrativne promjene i uporabu ključeva.
  • Odobrite svaku reverzibilnu pseudonimizaciju kroz dokumentirani radni tijek.
  • Povežite odluku s rasporedima zadržavanja, brisanjem izvornih podataka i dokazima o konačnom zbrinjavanju.
  • Obvežite dobavljače ugovornim ograničenjima ponovnog povezivanja, obogaćivanja, ponovne uporabe, daljnjeg dijeljenja i podugovaranja.
  • Pohranite dokaze u registar dokaza PIMS-a i povežite ih sa SoA-om.
  • Zakažite pregled nakon obogaćivanja, vanjskog dijeljenja, novih izvora podataka, incidenata, ponovnog treniranja modela ili većih promjena proizvoda.

Ovaj je kontrolni popis namjerno međufunkcionalan. Poslovni vlasnik definira svrhu. Voditelj privatnosti ili voditelj PIMS-a upravlja rizikom. DPO ili savjetnik za privatnost pregledava visokorizične pretpostavke. CISO osigurava sigurnosne kontrole. Pravni poslovi provjeravaju obveze. Inženjering implementira transformacije. Interna revizija testira dokaze.

Pretvorite anonimizaciju iz tvrdnje u dokaziv kontrolni sustav

Pritisak za uporabu podataka u analitici, umjetnoj inteligenciji, poboljšanju proizvoda, usporednim pokazateljima za klijente i operativnoj učinkovitosti samo će rasti. Odgovor nije blokiranje inovacija. Odgovor je upravljanje njima.

Clarysec pomaže organizacijama izgraditi upravljanje anonimizacijom i rizikom ponovne identifikacije uporabom:

Vaša sljedeća radnja jednostavna je: odaberite jedan visokovrijedan analitički, AI, referentni ili testni skup podataka i provedite ga kroz Clarysecov radni tijek upravljanja anonimizacijom. Ako ne možete pokazati registar obrade, procjenu minimizacije, pregled rizika ponovne identifikacije, zapis o odobrenju, tehničke dokaze o transformaciji, kontrole pristupa, odluku o zadržavanju, ograničenja za dobavljače i okidač za pregled, skup podataka nije spreman za reviziju.

Clarysec vam može pomoći da ga pripremite za reviziju.

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