Varstvo posameznikov pri obdelavi osebnih podatkov je pravica, zapisana v prvem odstavku 8. člena Listine Evropske unije o temeljnih pravicah. S tem jo torej smatramo kot eno temeljnih pravic.
V revizorski funkciji se glede zagotavljanja skladnosti obdelave osebnih podatkov najverjetneje srečujemo z obdelavo osebnih podatkov na dveh področjih, in sicer:
Pri drugi točki v tem uvodu poudarimo, da je notranji revizor član organizacije in s tem formalno del stranke, kot zunanji revizor pa glede na smernice o pogodbeni obdelavi Informacijskega pooblaščenca RS lahko kot revizor tako v vlogi obdelovalca (ko ga stranka najame za izvajanje notranje revizije) ali v vlogi upravljavca (ko izvaja zunanjo revizijo skladno z ZRev-2) (Informacijski pooblaščenec, 2020a).
Ne glede na to, katero področje je izpostavljeno pri obdelavi osebnih podatkov, pa moramo predpostaviti, da tako ena kot druga vloga zahteva vsaj osnovno poznavanje področja varstva osebnih podatkov in pogostih spodrsljajev pri tem.
V pričujočem članku poskušamo povzeti osnovne vidike varstva osebnih podatkov, predstaviti zahteve evropske in slovenske zakonodaje ter nekatere pasti varstva osebnih podatkov, na katere mora biti revizor pozoren tako z vidika zagotavljanja skladnosti svojega dela v revizijskih postopkih s predpisi kakor tudi z vidika preverjanja in potrjevanja skladnosti strank. Pri tem v članku na splošno ni opredeljena vrsta revizorja. Kjer je to potrebno, pa je poudarjeno.
Ker pisec članka nisem strokovnjak za izvajanje revizije poslovanja, ta članek ne more biti popolno navodilo, kako naj revizor ravna. Lahko pa je vodilo revizorju in opozorilo na področja, ki jih ob izvajanjih pregledov skladnosti varstva osebnih podatkov zaznavamo kot neskladna ali pomanjkljiva.
Kot dodatno omejitev članka je treba omeniti še trenutno spreminjajoče se stanje slovenske zakonodaje s področja varstva osebnih podatkov. Njena dinamika je pojasnjena na začetku naslednjega poglavja.
Uredba (EU) 2016/679 Evropskega parlamenta in sveta z dne 27. aprila 2016 o varstvu posameznikov pri obdelavi osebnih podatkov in prostem pretoku takih podatkov ter o razveljavitvi Direktive 95/46/ES oz. splošna uredba o varstvu osebnih podatkov ali GDPR postavlja še jasnejša načela obdelave osebnih podatkov in kot taka zagotavlja tisto raven zaščite zasebnosti, ki se pričakuje tudi v okviru 8. člena listine evropske unije o temeljnih pravicah.
Med pisanjem tega članka je Slovenija še zadnja država članica EU-ja, ki še ni sprejela zakonodajnega okvira, s katerim bi GDPR v celoti vpeljala v svoj pravni red. Tako je ta trenutek še vedno v veljavi Zakon o varstvu osebnih podatkov iz leta 2007 (ZvoP-1), ki pa ga GDPR zaradi svoje uredbene narave na več področjih neposredno zamenja. ZvoP-2 (Predlog ZvoP-2, 2022), ki bo dileme odnosa med GDPR-jem in pravnim redom Republike slovenije razrešil, je v tem času v obravnavi v parlamentu, tako da se še vedno lahko spremeni.
Pri obdelavah osebnih podatkov in njihovih izzivih je ključno, da se zavedamo in razumemo, kaj so osebni podatki. Po definiciji GDPR-ja dikcija osebni podatki »pomeni katero koli informacijo v zvezi z določenim ali določljivim posameznikom« in nadalje pojasni, da je določljiv posameznik »tisti, ki ga je mogoče neposredno ali posredno določiti, zlasti z navedbo identifikatorja, kot je ime, identifikacijska številka, podatki o lokaciji, spletni identifikator, ali z navedbo enega ali več dejavnikov, ki so značilni za fizično, fiziološko, genetsko, duševno, gospodarsko, kulturno ali družbeno identiteto tega posameznika« (GDPR, 4(1)(1)).
Pri tem GDPR ne navaja več omejitve, ki jo poznamo iz ZVoP-1: »pri čemer način identifikacije ne povzroča velikih stroškov, nesorazmerno velikega napora ali ne zahteva veliko časa« (ZvoP-1, 6(1)(2)).
Iz te opredelitve moramo torej kot napačne zavreči domneve, da neka informacija ne pomeni osebnega podatka, če v tem trenutku in s sredstvi, ki so nam (trenutno) na voljo, ne moremo določiti posameznika. Nasprotno, gledati moramo širše in si zastaviti vprašanje: Ali je na podlagi informacij, ko se obdelujejo, kakor koli mogoče določiti posameznika?
Če na to vprašanje ne moremo zanesljivo odgovoriti, da to ni mogoče, potem moramo predvideti, da govorimo o osebnih podatkih.
Prejšnje poglavje že nakazuje, da se pri svojih opravilih skoraj ne moremo izogniti osebnim podatkom. Vendar pa ta trenutek še ne moremo biti gotovi, kaj pomeni, da osebne podatke tudi obdelujemo.
Kot svetovalec opažam, da se na splošno šteje, da obdelava osebnih podatkov pomeni zgolj neko preoblikovanje, premikanje ali shranjevanje teh podatkov. Na srečo (ali žal) pa je dikcija GDPR-ja tudi pri tem jasna. Obdelava namreč »pomeni vsako dejanje ali niz dejanj, ki se izvaja v zvezi z osebnimi podatki ali nizi osebnih podatkov z avtomatiziranimi sredstvi ali brez njih, kot je zbiranje, beleženje, urejanje, strukturiranje, shranjevanje, prilagajanje ali spreminjanje, priklic, vpogled, uporaba, razkritje s posredovanjem, razširjanje ali drugačno omogočanje dostopa, prilagajanje ali kombiniranje, omejevanje, izbris ali uničenje« (GDPR, 4(1)(2)).
Torej je že jasno, da dikcija »obdelava (osebnih podatkov)« pomeni praktično vsako dejanje, pri katerem so prisotni osebni podatki.
Opozoriti je treba na pojme, ki so tudi v zgornji dikciji, namreč hramba, priklic in vpogled, ki se skladno s to definicijo že štejejo za obdelavo osebnih podatkov. Vse omenjene narave obdelave so pogosto prezrte tako pri obravnavi pravnih/pogodbenih pogojev obdelave kakor tudi pri vzpostavljanju sistemov za obdelavo osebnih podatkov, zato jim moramo v revizijskih postopkih posvetiti še posebno pozornost.
Osebni podatki morajo biti obdelani zakonito, pošteno in pregledno. Zakonitost obdelave pomeni, da je za vsako obdelavo potreben ustrezen pravni temelj, in je podrobneje obravnavana v naslednjem poglavju. Ob reviziji skladnosti s pravili varovanja osebnih podatkov v organizaciji moramo za obdelavo, za katero ni ustreznega pravnega temelja, to zapisati kot ugotovitev neskladnosti.
Na splošno poštenost (ali pravičnost) pomeni, da je treba z osebnimi podatki ravnati le na način, ki ga posamezniki upravičeno pričakujejo, nedopustno pa jih je uporabljati na načine, ki bi imeli za posameznike neupravičene škodljive učinke (Pirc Musar et al., 2020, komentar k členu 5).
Načelo preglednosti je podrobneje nakazano že v uvodni izjavi 39 GDPR-ja. Pri stranki se spoštovanje tega načela pokaže tako, da so obdelave primerno pojasnjene posameznikom v razumljivem, jasnem in preprostem jeziku. Nadzorni organ (ali revizor) to najpogosteje preverja s prisotnostjo in vsebino t. i. politik zasebnosti in informacij skladno s 13. ali 14. členom GDPR-ja.
Namen je eden ključnih parametrov, ki ga obravnavamo pri ugotavljanju zakonitosti obdelave. V poslu revizije varstva osebnih podatkov bo opredelitev namena najverjetneje dosegljiva v evidenci dejavnosti obdelave1 ali informacijah za posameznike2. Natančna omejitev in opredelitev namena je pomembna zato, ker posameznikom pomaga razumeti, kako bo upravljavec ravnal z njihovimi osebnimi podatki, in se posledično lažje odločijo, ali bodo svoje osebne podatke upravljavcu zaupali ali ne.
Najmanjši obseg podatkov in omejitev shranjevanja v točkah (c) in (e) pričakujeta, da upravljavec o posamezniku zbira samo tiste osebne podatke, ki so nujno potrebni za izvršitev namena obdelave (tako v smislu števila atributov kot vrstic) in samo toliko časa, kolikor so ti podatki potrebni. V praksi pogosto zaznamo kršitev teh dveh z zbiranjem podatkov, »ker jih bomo nekoč potrebovali«, in odsotnost brisanja, ker bodisi »ne znamo izbrisati« bodisi jih »bomo morda nekoč potrebovali«.
Stranka v vlogi upravljavca mora zagotavljati tudi točnost, celovitost in zaupnost osebnih podatkov, in to tako z vzpostavljenimi postopki kakor tudi s tehničnimi rešitvami. Pri tem mora biti sposobna dokazati, da ravna skladno z načeli varstva osebnih podatkov (princip odgovornosti).
Obdelava ima ustrezno pravno podlago (je zakonita), če je a) posameznik v obdelavo privolil, ali pa je obdelava potrebna za b) izvajanje pogodbe, c) izpolnitev zakonske obveznosti upravljavca, d) zaščito življenjskih interesov posameznika, e) opravljanje nalog v javnem interesu ali f) zakonitih interesov upravljavca. obdelava je zakonita, če je izpolnjen vsaj eden od pogojev, pri čemer so si pravne podlage enakopravne (GDPR, člen 6).
Če upravljavcu zbiranje osebnih podatkov nalaga zakon, je to podlaga, ki jo tudi revizor najlaže sprejme. Pri tem se mora revizor prepričati, kateri zakon in člen zakona zahtevata podatke, pa tudi, da so vsi atributi zbirke ustrezno pokriti z zakonom (ali drugo uporabljeno pravno podlago).
Če je pravna podlaga izvajanje (ali sklepanje) pogodbe, naj bo revizor pozoren predvsem na to, da mora obstajati neposredna in objektivna povezava med obdelavo osebnih podatkov in namenom izpolnitve pogodbe (Pirc Musar et al., 2020, komentar k členu 6), pri zakonitem (legitimnem) interesu pa na dejstvo, da je bilo dokumentirano izvedeno tehtanje zakonitega interesa, in rezultate tega.
Čeprav je privolitev najfleksibilnejša med pravnimi podlagami (posameznik lahko privoli v kar koli), se je treba zavedati, da ima tudi svoje omejitve. Biti mora namreč informirana, nedvoumna oz. izrecna, specifična in prostovoljna, posameznik pa jo lahko kadar koli brez posledic zase prekliče (GDPR, člen 7).
Poleg morebitnih negativnih posledic, ki bi jih za upravljavca lahko imel preklic privolitve (vključno z vsemi postopki, ki jih mora upravljavec ob tem zagotoviti), je revizor pozoren tudi na to, da privolitev morda ni dana povsem svobodno. Vprašanje svobodno dane privolitve je še posebej pomembno, če sta posameznik in upravljavec v neenakem odnosu. Primer takega odnosa je med delodajalcem in zaposlenim. Privolitev bo v takem primeru veljavna, če njena zavrnitev nima nikakršnih posledic na delovno razmerje oziroma na pravni položaj zaposlenega. Osebna privolitev v delovnih razmerjih torej je oziroma naj bo bolj izjema kot pravilo, saj je delodajalec v razmerju do delavca močnejša stranka in so možnosti za zlorabo tega instituta v delovnih razmerjih toliko večje. V takem primeru bo revizor ocenil, ali ta neenaki odnos sili posameznika k podajanju privolitve, in če vpliva, to zapisal kot ugotovitev neskladnosti.
Dodatne pogoje za obdelavo postavljajo t. i. posebne vrste osebnih podatkov. To so podatki, »ki razkrivajo rasno ali etnično poreklo, politično mnenje, versko ali filozofsko prepričanje ali članstvo v sindikatu, in obdelava genetskih podatkov, biometričnih podatkov za namene edinstvene identifikacije posameznika, podatkov v zvezi z zdravjem ali podatkov v zvezi s posameznikovim spolnim življenjem ali spolno usmerjenostjo« (GDPR, člen 9). Če se ob reviziji zazna obdelava posebnih vrst osebnih podatkov, je treba zakonitost in primernost obdelave teh preveriti tudi s pogoji, ki jih predstavlja že omenjeni 9. člen GDPR-ja.
Posebne vrste osebnih podatkov sicer šele skupaj s podatki v zvezi s kazenskimi obsodbami in prekrški (GDPR, člen 10) predstavljajo términ občutljivi osebni podatki, kot je zabeležen v obstoječem ZvoP-1 (ZvoP-1, 10. člen), na kar usmerja tudi predlog ZvoP-2 (Predlog ZvoP-2, 10. člen).
Splošna uredba v členu 30 določa, da je evidenca dejavnosti obdelave obvezna za vse upravljavce in predstavnike upravljavcev, z nekaj mogočimi izjemami v petem odstavku istega člena.
Evidenca dejavnosti obdelave vsebuje seznam vseh obdelav skupaj s podatki o njih in je tako po naših izkušnjah ključno orodje, s katerim si stranka (bodisi v vlogi upravljavca, predstavnika upravljavca bodisi obdelovalca) zagotavlja pregled nad svojimi obdelavami. Hkrati je orodje za dokazovanje skladnosti na področju varstva osebnih podatkov. Zato kljub izjemam, navedenim v GDPR-ju (GDPR, člen 30(5)), podpiramo pristop, da vodenje evidence dejavnosti obdelave zagotovi vsak subjekt, ki obdeluje osebne podatke.
Ker zagotavlja zbrane podatke o vseh obdelavah na enem mestu, je evidenca dejavnosti obdelave tudi za revizorja primerna vstopna točka, prek katere dobi vpogled v obdelave, ki jih stranka opravlja, in njegov pristop k skladnosti obdelav.
Ob tem moramo opozoriti, da evidenca dejavnosti obdelave ne pomeni beleženja, kaj je kdo s temi podatki počel; tak namen ima dnevnik obdelave ali revizijska sled.
Prav tako evidence dejavnosti obdelave ne moremo enačiti s katalogom oziroma opisi zbirk osebnih podatkov, ki so bili3 po ZVoP-1 obvezni za upravljavce s 50 ali več zaposlenimi (ZVoP-1, 7. in 26. člen) in katerih izhodišče je bila zbirka osebnih podatkov.
V evidenci dejavnosti obdelave izhodišče postaja obdelava osebnih podatkov, pri čemer je zbirka osebnih podatkov sestavni del te obdelave. Pri tem gre lahko za primere, v katerih ena obdelava poteka na več zbirkah, in tudi obratno, ko se podatki iz ene zbirke obdelujejo v več obdelavah. Zbirk ni več treba prijavljati v register informacijskega pooblaščenca, upravljavec (ali obdelovalec) pa mora pri sebi voditi evidenco dejavnosti obdelave.
Skladno z definicijo sedme alineje prvega odstavka 4. člena Splošne uredbe (EU) je upravljavec fizična ali pravna oseba, javni organ ali drugo telo, ki samo ali skupaj z drugimi določa namene in sredstva obdelave. Obdelovalec na drugi strani je fizična ali pravna oseba, javni organ ali drugo telo, ki obdeluje osebne podatke v imenu upravljavca (GDPR, člen 4(1)(7)).
Splošna uredba nadalje v členu 26 pojasni termin skupnih upravljavcev kot dva ali več upravljavcev, ki skupaj določajo namene in načine obdelave. Skupni upravljavci morajo na pregleden način z medsebojnim dogovorom določiti dolžnosti vsakega izmed njih. V dogovoru lahko določijo tudi kontaktno točko za posameznike, na katere se nanašajo podatki. Čeprav je kontaktna točka določena, pa sme posameznik zahtevati uresničevanje svoje pravice od vsakega soupravljavca in proti vsakemu od njih.
Člen 28 Splošne uredbe (EU) natančneje pojasni pravice in dolžnosti obdelovalcev in upravljavcev v odnosu upravljavec – obdelovalec. Glede na to, da pri obdelavi osebnih podatkov najpogosteje zasledimo odnos upravljavec – obdelovalec, je prav, da se seznanimo z zahtevami tega odnosa.
Pomembno je, da je v odnosu upravljavec – obdelovalec upravljavec odgovoren za delovanje obdelovalca. Kot upravljalec je to zmožen tudi dokazati, obdelovalec pa mu mora to omogočiti (GDPR, člen 28). Ta odnos partnerja zabeležita v t. i. pogodbo o obdelavi, ki je pogodba ali drug pravni akt v skladu s pravom Unije ali države članice.
Prisotnost pogodbe za vsako obdelavo osebnih podatkov je tako ena od praktično obveznih točk, ki se preverjajo v poslu revizije skladnosti s pravili varnosti osebnih podatkov. Ob tem je prav, da revizor preveri tudi vsebino pogodbe, pri čemer opozarjamo, da mora biti v pogodbi jasno zapisano, pod katerimi pogoji sme obdelovalec najemati podobdelovalce, pogoji iz tretjega odstavka 28. člena GDPR-ja pa niso dovolj, če so zapisani zgolj pavšalno v smislu kopiranja navedb člena, ampak s konkretnimi navedbami.
Prenos osebnih podatkov v tretje države4 ali mednarodne organizacije ureja poglavje v splošne uredbe.
Prvi korak prenosa v tretje države je še vedno obveznost upravljavca, da zagotovi osnovno pravno podlago za obdelavo osebnih podatkov skladno s členi 6, 9 in 28 GDPR-ja.
V drugem koraku je treba zagotoviti še pravno podlago za prenos podatkov, pri čemer se lahko naslonimo na tri hierarhično postavljene skupine podlag:
Poglavje prenosa v tretje države je postalo pomembno z odločitvijo sodišča (EU) v zadevi C-311/18. V njej je sodišče razveljavilo t. i. Privacy Shield, s čimer ZDA niso več na seznamu držav, v katere se osebne podatke lahko izvaža brez omejitve.
Uvodoma smo prebrali, da je notranji revizor pri izvajanju interne revizije lahko:
V prvem primeru za revizorja veljajo pravila obdelave osebnih podatkov ter pravice in dolžnosti, predvidene z internimi akti stranke, ki jih revizor sprejema glede na svojo zaposlitev.
V drugem primeru pa bo revizor v vlogi obdelovalca, kar pomeni, da bo stranka v okviru dogovora o sodelovanju predpisala tudi okvire obdelave osebnih podatkov pod pogoji, ki jih določa 28. člen GDPR-ja.
Kadar revizor izvaja zunanjo revizijo (npr. po ZRev-2), je – skladno s smernicami informacijskega pooblaščenca (informacijski pooblaščenec, 2020a) – praviloma postavljen v vlogo upravljavca. V tem primeru mora revizor najprej zagotoviti primerno pravno podlago za obdelavo osebnih podatkov, ki je v že omenjenem ZRev-2 lahko člen 6(1)(c) GDPR-ja (informacijski pooblaščenec, 2020b), pri drugi zakonodaji pa mora revizor kot upravljalec to predhodno preveriti.
Ko je revizor v vlogi upravljavca, mora seveda poskrbeti tudi za druge zahteve, ki jih pred upravljavce postavlja GDPR, kot so zagotavljanje pravic posameznikom, evidenca dejavnosti obdelave, ustrezni zaščitni ukrepi in navsezadnje tudi pogodbeni odnos z morebitnimi obdelovalci.
Če smo v prejšnjem poglavju obravnavali predvsem pravnopraktični pogled na obdelavo osebnih podatkov, se v tem poglavju lotimo nekaj dilem, ki so pogoste pri obdelavi osebnih podatkov z informacijskimi sistemi. Pri izbranih dilemah v naših pregledih zaznavamo največ odstopanj, zato bi jih moral poznati vsak revizor.
Upoštevanje teh dilem (ali bolje rečeno kar pogostih napak strank) je še posebej pomembno pri vlogi revizorja informacijskih sistemov, dilema revizije obdelovalca pa je lahko prisotna tudi pri drugih načinih obdelave.
Eno od osnovnih načel obdelave osebnih podatkov je načelo omejitve rokov hrambe. Po tem načelu se smejo osebni podatki obdelovati le toliko časa, kolikor časa je potrebno za namene, za katere se osebni podatki obdelujejo. Pri tem se osebni podatki lahko shranjujejo tudi za dlje časa, če bodo obdelani zgolj za arhiviranje v javnem interesu, za znanstveno- ali zgodovinskoraziskovalne ali statistične namene. Pri tem je treba izvajati ustrezne tehnične in organizacijske ukrepe, da se zaščitijo pravice in svoboščine posameznika.
Brisanje oz. anonimiziranje osebnih podatkov sicer zaznavamo kot eno ključnih pomanjkljivosti v naših organizacijah, še posebej na področju razumevanja razlike med psevdonimizacijo in anonimizacijo. Zato je smiselno, da pojasnimo razliko.
Skladno z definicijo splošne uredbe (eU) psevdonimizacija pomeni »obdelavo osebnih podatkov na tak način, da osebnih podatkov brez dodatnih informacij ni več mogoče pripisati specifičnemu posamezniku, na katerega se nanašajo osebni podatki, če se take dodatne informacije hranijo ločeno ter zanje veljajo tehnični in organizacijski ukrepi za zagotavljanje, da se osebni podatki ne pripišejo določenemu ali določljivemu posamezniku« (GDPR, člen 4(1)(5)).
Psevdonimizacija torej pomeni, da podatke, ki nam omogočajo določenost uporabnika, izločimo iz nabora osebnih podatkov, ki ga obdelujemo, in shranimo na nekem drugem mestu, ali pa teh podatkov že v osnovi nimamo v svojem naboru. Za to drugo mesto veljajo taki ukrepi, da podatkov z drugega mesta ne moremo enostavno združiti s podatki iz našega nabora. Tako zagotavljamo, da v našem naboru ne moremo enostavno določiti posameznika.
Tipičen primer takih podatkov so recimo naslovi internetnega protokola (IP naslovi) uporabnikov spletišča. Upravljavec spletišča sicer obdeluje te iP naslove, saj sicer ne bi mogel zagotoviti storitve, vendar pa v danem trenutku in brez drugih podatkov (še) ne more povezati iP naslova z določenim posameznikom.
Če pa bi upravljavcu spletišča od telekomunikacijskega ponudnika uspelo pridobiti podatke o tem, kateri uporabnik je med obiskom uporabljal dani iP naslov, bi to pomenilo, da smo iz psevdonimiziranega iP naslova pridobili določljivega posameznika.
Še hitreje bi obiskovalec spletišča lahko zagotovil določljivost obiskovalca – posameznika z zahtevo po vnosu osebnih podatkov (npr. v spletni maski), podatke pa shranil v nabor osebnih podatkov, ki ga obdeluje. V tem primeru bi revizor že moral izpostaviti tudi vprašanje, ali za iP naslove iz tega nabora še velja pravilo psevdonimizacije, saj informacije o določljivosti morda niso več hranjene (dovolj) ločeno, preveriti pa bi bilo treba tudi tehnične in organizacijske ukrepe ter se prepričati, da podatkov ni mogoče dovolj preprosto pripisati določenemu ali določljivemu posamezniku.
Psevdonimizacija kot taka torej ustreza navedbi člena 4(1)(2) GDPR-ja, ki pravi, da je posameznika mogoče posredno ali neposredno določiti. Zato moramo tudi psevdonimizirane osebne podatke obravnavati kot osebne podatke, do katerih pa je nekoliko težje priti. Da je psevdonimizacija zgolj eden od ukrepov za zaščito osebnih podatkov (ne pa tudi njihova odsotnost), je sicer razvidno tudi iz 32. člena GDPR-ja, ki navaja ukrepe za varnost obdelave.
Če revizor zazna navedbo, da ni osebnih podatkov, hkrati pa ob skrbnem pregledu ugotovi, da gre za psevdonimizirane podatke, bo to vsekakor zapisal kot ugotovitev.
Anonimizacija je sprememba osebnih podatkov na tak način, da posameznik, na katerega se nanašajo osebni podatki, ni več določljiv, ne glede na morebitne druge podatke.
Uvodna izjava 26 iz GDPR-ja ob tem pojasnjuje, da bi bilo pri ugotavljanju, ali je posameznik določljiv, treba upoštevati vsa sredstva, za katera se pričakuje, da jih bo upravljavec uporabil za posredno ali neposredno prepoznavo posameznika – torej za deanonimizacijo5. Pri tem je treba upoštevati vse objektivne dejavnike, kot so stroški identifikacije in čas, potreben za deanonimizacijo, skladno z razpoložljivo tehnologijo in tehnološkim razvojem v času obdelave.
V isti preambuli je tudi navedeno, da splošna uredba (EU) ne zadeva obdelave takih anonimiziranih informacij, vključno z informacijami v statistične in raziskovalne namene. Primerno izvedeno anonimizacijo torej lahko uporabimo tudi kot nadomestilo brisanja.
Ključno vprašanje, na katerega mora revizor ob reviziji anonimizacijskih postopkov odgovoriti, da bi lahko potrdil primernost anonimizacije, je zato: Ali je predlagani način anonimizacije dovolj dober, da se lahko razumno pričakuje, da deanonimizacija ni mogoča?
Za odgovor na to vprašanje priporočam poglobljen pogled mnenja delovne skupine 29 o tehnikah anonimizacije (WP29, 2014). Navajam pa le še primer neprimerne anonimizacije, ki je pogosta rešitev za nadomestilo brisanja.
Ker je večina strukturiranih podatkov v poslovnih informacijskih sistemih danes še vedno shranjena v relacijskih bazah, je vsaj zelo groba osnova poznavanja relacijskih baz nujno potrebna za razumevanje napak v anonimizaciji. Zato pred primerom na hitro (in površno) predstavimo, kaj so relacijske baze.
Relacijske baze so v sedemdesetih letih prejšnjega stoletja pomenile bistven napredek pri obdelavi informacij, saj so v prejšnje (običajno hierarhične) modele vnesle nove možnosti povezovanja podatkov. V relacijski bazi podatkov so vsi podatki shranjeni v tabelah, znotraj katerih imajo praviloma vse vrstice enako strukturo.
Med tabelami in njihovimi podatki so vzpostavljene relacije (zato poimenovanje relacijska baza), ki prek ključev povezujejo zapise. To nam omogoča, da v relacijski bazi hranimo zapise z različno strukturo6 in števnostjo7.
Primer ene od relacij bi bil zapis posameznika in njegovega bivališča. V tabeli »posamezniki« bi imeli podatke o posamezniku, v tabeli »poste« pa recimo podatke o poštnih številkah, imenih in naslovih pošt. Da bi ti dve tabeli povezali, bomo pri posamezniku dodali zunanji ključ (stolpec), ki bo programski opremi povedal, da je posameznikov naslov povezan s pošto, določeno s takim ključem.
Relacije z vzpostavitvijo odvisnosti med posameznimi entitetami omogočajo, da podvojene podatke zapišemo samo enkrat, da so vsi odvisni od samo enega ključa in med njimi ni tranzitivnih odvisnosti. Pravimo, da smo podatke spravili v eno od normalnih form (oblik).
V normalnih oblikah imamo tako shranjene podatke, katerih vrednosti so zapisane tako, da je del v eni tabeli, del v drugi, medsebojno odvisnost pa izražajo z relacijami.
Odvisnost med tabelami v relacijski bazi pomeni, da vrstic v t. i. nadrejeni tabeli ne moremo enostavno izbrisati, saj bodo s tem vsi zapisi v podrejenih tabelah postali »sirote« – tuji ključ, ki povezuje podrejene vrstice z vrstico v nadrejeni tabeli, kar naenkrat ne bo več obstajal.
Najbolje bi seveda bilo, da bi pred brisanjem vrstice v nadrejeni tabeli najprej pobrisali vse vrstice, ki se nanjo navezujejo v podrejenih tabelah, šele nato pa vrstico v nadrejeni tabeli. Teoretično niti ne tako kompleksen model se izkaže za zelo zahtevnega, ko ugotovimo, da je v tipični relacijski bazi lahko tudi več sto tabel, v razvoju programske opreme pa mnogokrat ni bilo poskrbljeno za njihovo primerno dokumentacijo.
Da bi se izognili takim izzivom, razvijalci programske opreme dostikrat uporabijo pristop, s katerim vrstic v nadrejeni tabeli ne odstranijo v celoti, ampak zgolj zamenjajo podatke, ki neposredno določajo posameznika, z naključnimi vrednostmi (trdijo, da »anonimizirajo«).
Tako bodo recimo ime »Primož« zamenjali z »#$#()#(#« in priimek »Govekar« z »asoidfu893«, ne bodo pa zamenjali relacij med drugimi zapisi. S tem pa ni nujno zagotovljena skladnost. Dovolj je že, da ostane relacija osebe s starši in rojstni datum, pa je posameznik povsem določljiv.
Večinoma bo revizija pristopa z »anonimizacijo« zelo hitro pokazala, da je deanonimizacija dovolj preprosta in hitro izvedljiva ter zato ne ustreza pogojem, ki jih v preambuli 39 navaja GDPR. Velikokrat se bo revizor moral precej poglobiti v iskanje potrditve, da deanonimizacija v resnici je ali ni mogoča.
Recimo, da imamo v relacijski bazi natančno pojasnjene relacije in vemo, katere podatke moramo izbrisati, če želimo v celoti pobrisati podatke posameznika. Kljub temu pa z gotovostjo še ne moremo potrditi, da to tudi smemo storiti.
Če smo prej govorili o nadrejeni tabeli (oz. tabelah) s podatki posameznika, moramo zdaj preveriti, ali smemo brisati vse podrejene podatke.
Splošni primer iz zavarovalništva bi moral pojasniti zadrego. Primož ima pri zavarovalnici Najboljša sklenjene tri zavarovalne produkte: zavarovanje za avto, za hišo in življenjsko zavarovanje. Po nekem času ugotovi, da mu zavarovalnica ni več tako všeč, zato zavarovanje za avto in hišo prenese drugam.
Zavarovalnica bo po preteku roka hrambe vsekakor dolžna pobrisati osebne podatke, ki so vezani na zavarovanje avtomobila in hiše, vendar pa (še) ne bo mogla pobrisati tudi podatkov o Primožu, saj jih še vedno potrebuje po pogodbi o življenjskem zavarovanju.
Zato je pomembno, da ima stranka že ob vzpostavljanju procesov, ki potrebujejo nove obdelave podatkov, jasno sliko, pod katerimi pogoji in kako bo te podatke brisala. Revizor preveri, ali to drži, in po potrebi to zapiše kot ugotovitev.
Tax-Fin-Lex d.o.o.
pravno-poslovni portal,
založništvo in
izobraževanja
Tax-Fin-Lex d.o.o.
Železna cesta 18
1000 Ljubljana
Slovenija
T: +386 1 4324 243
E: info@tax-fin-lex.si
PONUDBA
Predstavitev portala
Zakonodaja
Sodna praksa
Strokovne publikacije
Komentarji zakonov
Zgledi knjiženj
Priročniki
Obveščanja o zakonodajnih novostih
TFL AI
TFL IZOBRAŽEVANJA
TFL SVETOVANJE
TFL BREZPLAČNO
Brezplačne storitve
Preizkusite portal TFL
E-dnevnik Lex-Novice
E-tednik TFL Glasnik
Dodatni članki