GDPR i web bezbednost: Koje tehničke mere propisuje zakon

← Blog

GDPR Član 32: Bezbednost obrade

Član 32 GDPR-a nalaže svim organizacijama koje obrađuju lične podatke da implementiraju "odgovarajuće tehničke i organizacione mere" uzimajući u obzir "stanje tehnike", troškove i rizike. Ovo namerno ostavljanje prostora za tumačenje znači da ne postoji tačna lista obaveza — ali postoji sudska praksa i smernice regulatora koje nam govore šta se očekuje.

Šta Član 32 eksplicitno pominje

• Pseudonimizacija i enkripcija ličnih podataka
• Sposobnost osiguravanja trajne poverljivosti, integriteta, dostupnosti i otpornosti sistema
• Sposobnost brze obnove pristupa podacima u slučaju incidenta
• Redovni postupci testiranja, procjene i evaluacije efektivnosti mera

Kazne koje je EU izrekla zbog web bezbednosti

• British Airways (2020): £20 miliona — napad kroz XSS na payment page, podaci 500.000 putnika
• Marriott International (2020): £18.4 miliona — curenje baze podataka, nedovoljne tehničke kontrole
• Haga Hospital, Holandija (2019): €460.000 — nedovoljna two-factor autentifikacija za pristup medicinskim podacima
• Deutsche Wohnen (2019): €14.5 miliona — sistem bez mogućnosti brisanja zastarelih podataka

Koje tehničke mere regulatori očekuju

1. Enkripcija podataka u prenosu i mirovanju

HTTPS za sav saobraćaj (sa HSTS), enkripcija baze podataka, enkripcija backup-ova, šifrovani cloud storage. Lozinke se nikada ne čuvaju kao plain text — bcrypt, Argon2 ili scrypt.

2. Access control i autentifikacija

MFA za administratorski pristup, princip minimalne privilegije, redovni review pristupa. Zaposleni ima pristup samo podacima koji su mu potrebni za radne zadatke.

3. Vulnerability management

"Redovni postupci testiranja efektivnosti mera" iz Čl. 32(1)(d) direktno znači redovni vulnerability assessment i penetration testing. EDPB (European Data Protection Board) smernicama sugeriše godišnje pentestove za visokorizične sisteme.

4. Incident response plan

GDPR Član 33 zahteva prijavljivanje povrede podataka regulatoru u roku od 72 sata od otkrivanja. Bez plana, ovaj rok je nemoguće ispoštovati.

5. Data minimization i retention

Čuvajte samo podatke koji su neophodni, samo onoliko dugo koliko je neophodno. Redundantne baze podataka sa ličnim podacima su i bezbednosni i GDPR rizik.

6. Logging i monitoring

Ko je pristupao ličnim podacima, kada, šta je promenio. Bez logova, nemoguće je poštovati obavezu obaveštavanja i dokazati compliance regulatoru.

Privacy by Design

GDPR Član 25 nalaže "Privacy by Design": bezbednost i privatnost moraju biti ugrađeni u sistem od samog početka razvoja, ne dodati kao naknadna misao. Ovo podrazumeva threat modeling u ranim fazama, security code review, i integraciju bezbednosnih testova u CI/CD pipeline.

Shieldome Scout assessment pruža dokumentovanu evidenciju redovnog vulnerability scanning programa — ključan element za dokazivanje "odgovarajućih tehničkih mera" u slučaju regulatornog ispitivanja.

← Blog

GDPR Article 32: Security of Processing

Article 32 of the GDPR requires all organizations processing personal data to implement "appropriate technical and organizational measures" taking into account "state of the art," costs, and risks. This intentional room for interpretation means there is no exact list of obligations — but there is case law and regulatory guidance telling us what to expect.

What Article 32 Explicitly Mentions

• Pseudonymization and encryption of personal data
• Ability to ensure ongoing confidentiality, integrity, availability, and resilience of systems
• Ability to restore access to data quickly in the event of an incident
• Regular processes for testing, assessing, and evaluating the effectiveness of measures

EU Fines Issued for Web Security Failures

• British Airways (2020): £20 million — XSS attack on the payment page, 500,000 passengers' data
• Marriott International (2020): £18.4 million — database breach, insufficient technical controls
• Haga Hospital, Netherlands (2019): €460,000 — insufficient two-factor authentication for medical record access

What Technical Measures Regulators Expect

• Encryption in transit and at rest: HTTPS (with HSTS), database encryption, backup encryption, encrypted cloud storage
• Access control and authentication: MFA for admin access, principle of least privilege, regular access reviews
• Vulnerability management: The "regular processes for testing" in Art. 32(1)(d) directly means regular vulnerability assessment and penetration testing
• Incident response plan: GDPR Art. 33 requires reporting a data breach to the regulator within 72 hours of discovery
• Logging and monitoring: Who accessed personal data, when, what they changed

Privacy by Design

GDPR Article 25 requires "Privacy by Design": security and privacy must be built into the system from the very beginning of development, not added as an afterthought. This includes threat modeling in early phases, security code review, and integration of security tests in the CI/CD pipeline.

A Shieldome Scout assessment provides documented evidence of a regular vulnerability scanning program — a key element for demonstrating "appropriate technical measures" in the event of regulatory scrutiny.