GDPR usklađenost sajtova: šta je zaista potrebno izgraditi

Većina saveta o GDPR-u na internetu pisana je za pravnike ili za one koji kupuju generator politika. Vrlo malo toga pisano je za osobu koja mora da otvori editor i nešto promeni.

Ovaj vodič je druge vrste. Prolazi kroz ono što Opšta uredba o zaštiti podataka traži od sajta i sistema iza njega, izraženo kao stvari koje gradite, konfigurišete ili brišete. Radimo ovaj posao za kompanije u EU otkako je uredba počela da se primenjuje 2018, a obrazac onoga što pođe naopako gotovo se nije menjao.

Jedna napomena na početku: GDPR nije postao lakši zato što su stigli noviji propisi. Postao je važniji, jer skoro sve u aktuelnom talasu EU digitalnih pravila pretpostavlja da su vam lični podaci već sređeni.

Počnite od poštenog popisa podataka

Skoro svaki neuspeli GDPR projekat koji smo nasledili propao je na istom mestu. Tim je prvo napisao politiku, a podatke otkrio kasnije.

Pre svega ostalog, mapirajte koje lične podatke vaš sajt zaista prikuplja. Ne ono što piše u specifikaciji proizvoda. Ono što je u bazi, logovima, analitičkoj platformi, CRM-u, alatu za podršku, marketinškom stack-u, trackeru grešaka, CDN logovima i skriptama trećih strana na stranici.

U praksi to znači:

• Pročešljati šemu. Svaku kolonu koja bi mogla identifikovati osobu, sama ili u kombinaciji sa drugom.
• Pročitati mrežni tab pri stvarnom učitavanju stranice. Svaki odlazni zahtev ka domenu koji ne kontrolišete potencijalni je prenos ličnih podataka, jer su IP adresa plus user agent lični podaci.
• Proveriti šta hvata tracker grešaka. Stack trace rutinski sadrži imejl adrese, tokene i tela zahteva.
• Proveriti čuvanje logova. Logovi pristupa sa IP adresama čuvani zauvek jedan su od najčešćih nalaza i jedan od najlakših za ispravku.

Zapišite to kao evidenciju aktivnosti obrade. Član 30 to ionako zahteva od većine organizacija, a verzija korisna programerima je tabela sa sistemom, podacima, svrhom, pravnim osnovom, rokom čuvanja i primaocima.

Birajte pravni osnov po svrsi, ne po sistemu

Član 6 daje šest pravnih osnova. Najčešća greška je izabrati jedan za ceo proizvod.

Gotovo sigurno imate više svrha koje teku istovremeno. Izvršenje porudžbine je ugovor. Provere prevare obično su legitimni interes ili zakonska obaveza. Čuvanje faktura zakonski rok je zakonska obaveza. Marketinški imejl je pristanak u većini država članica. Neobavezna analitika je pristanak, zbog ePrivacy pravila o pristupu terminalnoj opremi, a ne zbog samog GDPR-a.

Praktična posledica je da vaš model podataka mora znati kojoj svrsi služi svaki zapis. Ako ne možete da razdvojite marketinški profil od zapisa porudžbine, ne možete ispoštovati marketinški prigovor bez rušenja istorije porudžbina. To razdvajanje je odluka o šemi i bolno je za naknadnu ugradnju.

Pristanak mora biti stvaran i mora biti zabeležen

Ako se oslanjate na pristanak, mora biti dobrovoljan, konkretan, informisan i nedvosmislen, i morate ga kasnije umeti dokazati.

Konkretno:

• Ništa neobavezno se ne pokreće pre nego što korisnik nešto uradi. To uključuje analitički snippet, reklamni piksel, chat widget, font sa CDN-a treće strane i skriptu za A/B testiranje.
• Odbijanje mora biti jednako lako kao prihvatanje. Isti sloj, ista istaknutost, isti broj klikova. Regulatori sve drugo tretiraju kao mračni obrazac i u tome su dosledni.
• Pristanak je po svrsi. Jedan prekidač koji pokriva „analitiku i marketing i personalizaciju" nije konkretan.
• Povlačenje je jednako lako kao davanje. Trajan link ili plutajuće dugme, ne imejl podršci.
• Sačuvajte dokaz: vremensku oznaku, string pristanka ili stanje svake kategorije, verziju banera i tekst koji je korisniku prikazan. Bez verzije ne možete odbraniti dvogodišnji zapis pristanka.

Sprovođenje ovde nije teorijsko. U septembru 2025. francuski organ je istog dana kaznio Google sa 325 miliona evra i Shein sa 150 miliona zbog praksi sa kolačićima. Oba slučaja ticala su se mehanike, a ne teksta politike: kolačići postavljani pre bilo kakve interakcije i dugmad za odbijanje koja zapravo nisu odbijala.

I pravila su u pokretu. Predlog Digital Omnibusa preneo bi pristanak za terminalnu opremu u sam GDPR i učinio signale pregledača obavezujućim. Šta bi se promenilo obradili smo u pristanak za kolačiće posle Digital Omnibusa.

Izgradite mašineriju prava lica rano

Članovi 15 do 22 daju ljudima pravo na pristup, ispravku, brisanje, ograničenje, prenosivost i prigovor. Imate mesec dana za odgovor, uz produženje na tri u složenim slučajevima.

Timovi obično prve zahteve rešavaju ručno, što radi tačno do trenutka kada prestane. Šta treba imati mnogo pre nego što stigne obim:

Resolver koji pronalazi osobu kroz sve sisteme. Za datu imejl adresu vratiti sve: nalog, porudžbine, tikete podrške, marketinški profil, analitički identifikator, logove. Ako čovek mora da pamti da postoji i platforma za recenzije treće strane sa podacima, neko će jednom zaboraviti.

Putanju brisanja koja poštuje obaveze čuvanja. Brisanje nije apsolutno. Fakture obično moraju preživeti iz poreskih razloga. Treba vam meko brisanje sa tvrdim brisanjem vezanim za svrhu, da uklonite marketinški profil zadržavajući računovodstveni zapis i da taj zapis sam istekne na vreme.

Prenosiv izvoz. Strukturiran, uobičajen, mašinski čitljiv. JSON je u redu. PDF renderovane HTML stranice nije.

Zastavicu prigovora koju čita ceo sistem. Prigovor na profilisanje mora zaista zaustaviti profilisanje, uključujući i batch posao koji radi u tri ujutru i ne proverava zastavicu.

Čuvanje je posao, a ne red u politici

Ograničenje čuvanja je načelo koje najčešće krše inače dobro izgrađeni sistemi, jer brisanje zahteva da neko napiše i zakaže posao koji niko ne traži.

Dajte svakoj kategoriji podataka definisan vek, pa to sprovedite. Logovi pristupa, sesije, napuštene korpe, nepotvrđene registracije, zatvoreni tiketi, stari bekapi i sirovi analitički podaci svi treba da imaju rok isteka. Bekapi zaslužuju posebnu pažnju: ako vaš proces vraćanja oživljava obrisane lične podatke, vaše brisanje je nepotpuno, a uobičajen odgovor je dokumentovana rotacija bekapa sa maksimalnom starošću plus ponovna primena brisanja posle svakog vraćanja.

Prenosi, podobrađivači i gde vam stack zaista radi

Prenosi izvan EEP zahtevaju pravni mehanizam, obično okvir EU i SAD za zaštitu podataka za sertifikovane američke primaoce ili standardne ugovorne klauzule uz procenu uticaja prenosa u ostalim slučajevima.

Inženjerski ugao je jednostavniji od pravnog: znati gde su vaši podaci fizički. To znači cloud region svake usluge, lokaciju bekapa, region upravljane baze, konfiguraciju CDN ivica i, važno, model podrške svakog SaaS alata koji koristite. Provajder hostovan u Frankfurtu čiji tim podrške pristupa produkciji izvan EEP i dalje je prenos.

Uglavnom preporučujemo držanje ličnih podataka u EU regionima kada nema jakog razloga za suprotno. To uklanja celu kategoriju rasprave, a razlika u ceni obično je šum.

Vodite listu podobrađivača i držite je ažurnom. Član 28 zahteva pisani ugovor sa svakim, a ta lista je i ono što će vaši klijenti tražiti u dubinskoj analizi.

Bezbednost podrazumevano, izražena kao konfiguracija

Član 32 traži odgovarajuće tehničke i organizacione mere. To je namerno neodređeno, ali osnova za sajt u 2026. nije predmet pregovora:

• TLS svuda, HSTS uključen, bez mešanog sadržaja.
• Lozinke heširane modernom memorijski zahtevnom funkcijom i višefaktorska autentikacija dostupna za naloge sa ličnim podacima.
• Enkripcija u mirovanju za baze i bekape.
• Pristup produkcionim ličnim podacima ograničen ulogom i logovan, uz preglede koji se zaista dešavaju.
• Pseudonimizacija gde je moguća: heširati identifikator u analitici, tabelu mapiranja držati odvojeno i sa ograničenim pristupom.
• Testirano vraćanje, a ne samo bekap.

Zaštita podataka po dizajnu i podrazumevano iz člana 25 znači da je opcija koja štiti privatnost ona koju dobijate ne radeći ništa. Polje za newsletter neoznačeno. Vidljivost profila privatna. Opciona polja opciona.

Prijava povreda traži priručnik

Sedamdeset dva sata od saznanja do prijave nadzornom organu nije mnogo, naročito ako se povreda otkrije u petak uveče. Predlog Digital Omnibusa pomerio bi to na devedeset šest sati, ali to još nije pravo.

Pripremite unapred: ko proglašava incident, ko procenjuje da li su lični podaci zahvaćeni, ko kontaktira regulatora, šta prijava sadrži i kako obaveštavate pogođena lica ako je rizik visok. Napišite to kao priručnik sa imenovanim ulogama i uvežbajte jednom. Prvo korišćenje ne bi trebalo da bude prvo čitanje.

Površina samog sajta

Deo GDPR-a vidljiv je na stranici i vredi te detalje uraditi kako treba, jer se upravo oni prijavljuju.

Vaše obaveštenje o privatnosti mora navesti identitet i kontakt rukovaoca, svrhe i pravne osnove, primaoce i kategorije primalaca, mehanizme prenosa, rokove čuvanja, potpunu listu prava uključujući pravo na pritužbu nadzornom organu i da li postoji automatizovano odlučivanje. Pišite jezikom koji običan čovek može da prati. Slojevita obaveštenja, sa kratkom verzijom koja vodi na detalje, rade bolje od zida teksta.

Formulari treba da prikupljaju samo ono što vam treba. Svako polje je opravdanje koje ćete možda morati da date. Ako je polje za marketinški pristanak u istom slanju kao porudžbina, mora biti odvojeno neoznačeno i odvojeno formulisano.

Ugrađeni sadržaj trećih strana je tiha greška. YouTube u režimu pojačane privatnosti, mape iza čuvara koji se učitava na klik, fontovi hostovani kod vas umesto sa CDN-a treće strane. Svaka od tih izmena je mala i uklanja jedan nalaz.

Šta najčešće vidimo da ne valja

Posle dovoljno provera, iskrsava ista kratka lista:

1. Analitika koja se učitava pre pristanka, obično zato što je tag manager podesio marketing, a inženjering ga nikada nije pregledao.
2. Dugmad za odbijanje koja ipak pokreću pristanak zbog podrazumevanog ponašanja skripte treće strane.
3. Nikakvi poslovi čuvanja, ni na jednoj tabeli.
4. Brisanje koje promašuje bekape, logove i CRM.
5. Obaveštenje o privatnosti koje opisuje tok podataka promenjen pre osamnaest meseci.
6. Liste podobrađivača koje staju na tri očigledna dobavljača.
7. Zapisi pristanka bez verzije prikazanog teksta.

Ništa od ovoga nije težak problem. To je samo posao koji niko nije dodelio.

Kako do pomoći

Ako želite drugi par očiju na postojeći sajt, radimo tehničke GDPR provere koje daju prioritizovan backlog umesto izveštaja: šta popraviti, kojim redom, sa procenom uz svaku stavku. Ako gradite nešto novo, znatno je jeftinije odmah dobro postaviti model podataka i arhitekturu pristanaka.

Pokrivamo i širu površinu EU usklađenosti, uključujući pristupačnost i ulazak na evropsko tržište. Nađite nas na office@c9group.dev.

Gradimo softver. Ne dajemo pravne savete, a tumačenje konkretnog zahteva pripada vašim pravnicima. Ono što možemo jeste da obezbedimo da sistem radi ono što vaši pravnici kažu.