RODO dla developerów - szkolenie które powinien

Piszesz kod, który przetwarza dane użytkowników. Zapisujesz je w bazach danych, przesyłasz przez API, logujesz w systemach monitoringu. Ale czy kiedykolwiek przeszedłeś szkolenie z RODO? Większość programistów projektuje architektury systemów, wybiera sposoby przechowywania danych i decyduje o mechanizmach bezpieczeństwa - a wszystko to ma bezpośredni wpływ na zgodność z przepisami o ochronie danych osobowych. Problem w tym, że RODO wciąż jest traktowane jako “sprawa dla prawników i IOD”, podczas gdy to właśnie decyzje techniczne developerów określają, czy firma będzie narażona na kary sięgające 20 milionów euro lub 4% rocznego obrotu.

Na skróty

RODO to nie tylko temat dla działu prawnego - programiści podejmują kluczowe decyzje architektoniczne wpływające na ochronę danych osobowych
Privacy by Design musi być w kodzie - zasady minimalizacji danych, pseudonimizacji i szyfrowania należy implementować od pierwszej linii kodu
10 najczęstszych błędów to logowanie danych osobowych, przechowywanie zbędnych danych, brak szyfrowania, hardcoded tokeny, brak mechanizmu usuwania danych
Prawo do bycia zapomnianym to wyzwanie architektoniczne w świecie mikrousług, rozproszoných baz danych i backup-ów
Kary są realne - tylko w 2023 roku nałożono kary GDPR na kwotę ponad 2,1 miliarda euro, a większość naruszeń miała podłoże techniczne
EITT przeszkoliło już 500+ ekspertów z ochrony danych osobowych, realizując 2500+ szkoleń z oceną 4.8/5

Dlaczego RODO dotyczy programistów

Kiedy mówimy o RODO, większość firm myśli o prawnikach, Inspektorze Ochrony Danych i działach HR. Tymczasem to programiści są pierwszą linią obrony - to oni decydują, czy dane będą szyfrowane, czy logi będą zawierać dane osobowe, czy użytkownik będzie mógł usunąć swoje konto.

Decyzje techniczne = decyzje o zgodności z RODO

Wybierając sposób przechowywania haseł, decydujesz o bezpieczeństwie danych osobowych użytkowników. Projektując strukturę bazy danych, określasz, jak łatwo będzie wykonać żądanie usunięcia danych (prawo do bycia zapomnianym). Implementując system logowania, ustalasz, czy firma będzie narażona na wyciek danych osobowych w logach produkcyjnych.

Spójrzmy na konkretny przykład: developer decyduje się na zapisywanie pełnych obiektów requestów HTTP w systemie monitoringu błędów. W requestach znajdują się dane użytkowników - email, numer telefonu, czasem nawet PESEL. System monitoringu przechowuje te dane przez 90 dni, bez szyfrowania, dostępne dla całego zespołu technicznego. To już trzy naruszenia RODO:

Brak minimalizacji danych - do debugowania wystarczyłby ID użytkownika
Brak odpowiednich zabezpieczeń - dane osobowe przechowywane bez szyfrowania
Nadmierny dostęp - wszyscy w zespole widzą dane osobowe, choć nie wszyscy ich potrzebują

Odpowiedzialność nie leży tylko po stronie IOD

Wielu programistów uważa, że za RODO odpowiada Inspektor Ochrony Danych lub dział prawny. To błędne przekonanie. IOD nadzoruje zgodność i doradza, ale to zespoły techniczne implementują rozwiązania. Jeśli Twój kod powoduje wyciek danych osobowych, to firma ponosi odpowiedzialność - niezależnie od tego, czy IOD wiedział o problemie.

W praktyce oznacza to, że każdy developer musi znać:

Co jest daną osobową (nie tylko imię i nazwisko - także IP, cookie ID, biometria)
Jakie są podstawy prawne przetwarzania (zgoda, umowa, prawnie uzasadniony interes)
Jakie prawa przysługują użytkownikom (dostęp, sprostowanie, usunięcie, przenoszenie)
Jakie środki bezpieczeństwa są wymagane (szyfrowanie, kontrola dostępu, audyt)

Privacy by Design i Privacy by Default w praktyce developera

Privacy by Design to nie buzzword - to konkretne zasady projektowania systemów, które chronią dane osobowe “z pudełka”. W praktyce oznacza to, że ochrona danych musi być wbudowana w architekturę aplikacji od samego początku, nie dodawana później jako “łatka”.

Minimalizacja danych w kodzie

Zasada minimalizacji mówi: zbieraj tylko te dane, które są rzeczywiście potrzebne do realizacji celu. W praktyce oznacza to pytanie “czy naprawdę potrzebuję tego pola?” przy każdym modelu danych.

Źle:

// Rejestracja użytkownika - zbieramy wszystko "na wszelki wypadek"
const user = {
  email,
  password,
  firstName,
  lastName,
  phoneNumber,
  dateOfBirth,
  address,
  pesel,
  mothersMaidenName,
  favoriteColor
}

Dobrze:

// Zbieramy tylko to, co potrzebne do realizacji usługi
const user = {
  email, // potrzebny do logowania
  password, // potrzebny do uwierzytelnienia
  firstName // potrzebny do personalizacji
}
// Reszta danych zbierana tylko jeśli i gdy będzie potrzebna

Pseudonimizacja i anonimizacja

Jeśli możesz przetwarzać dane w sposób, który uniemożliwia identyfikację osoby bez dodatkowych informacji - zrób to. W praktyce często oznacza to używanie ID zamiast danych osobowych.

Źle:

-- Log aktywności z danymi osobowymi
INSERT INTO activity_log (user_email, action, timestamp)
VALUES ('jan.kowalski@example.com', 'login', NOW());

Dobrze:

-- Log aktywności z ID użytkownika
INSERT INTO activity_log (user_id, action, timestamp)
VALUES (uuid_v4(), 'login', NOW());

Szyfrowanie danych w spoczynku i ruchu

Dane osobowe powinny być szyfrowane zarówno podczas przesyłania (TLS/SSL), jak i przechowywania. To podstawa, ale wciąż wiele aplikacji tego nie robi.

Minimum:

HTTPS w całej aplikacji (nie tylko na stronie logowania)
Hasła haszowane (bcrypt, argon2 - nigdy MD5 lub SHA-1)
Dane wrażliwe szyfrowane w bazie danych (karty płatnicze, dane zdrowotne)
Szyfrowanie backupów baz danych

Przykład szyfrowania wrażliwych pól:

from cryptography.fernet import Fernet

class EncryptedField:
    def __init__(self, key):
        self.cipher = Fernet(key)

    def encrypt(self, data: str) -> bytes:
        return self.cipher.encrypt(data.encode())

    def decrypt(self, encrypted_data: bytes) -> str:
        return self.cipher.decrypt(encrypted_data).decode()

# Użycie w modelu
class User:
    email = models.EmailField()
    encrypted_phone = models.BinaryField()  # Zaszyfrowany numer telefonu

Kontrola dostępu na poziomie kodu

Nie każdy w firmie potrzebuje dostępu do wszystkich danych osobowych. Zasada “need to know” powinna być implementowana na poziomie aplikacji.

Przykład:

@require_permission('view_user_personal_data')
def get_user_details(user_id):
    user = User.objects.get(id=user_id)
    return {
        'email': user.email,
        'phone': user.phone,  # Widoczne tylko dla osób z uprawnieniem
        'address': user.address
    }

@require_permission('view_user_public_data')
def get_user_public_profile(user_id):
    user = User.objects.get(id=user_id)
    return {
        'username': user.username,
        'avatar_url': user.avatar_url
        # Brak danych osobowych
    }

10 najczęstszych błędów developerów naruszających RODO

1. Logowanie danych osobowych w plaintext

Problem: Logi produkcyjne zawierają dane osobowe użytkowników - email, imię, nazwisko, a czasem nawet hasła czy numery kart płatniczych. Rozwiązanie: Nigdy nie loguj danych osobowych. Jeśli musisz - zaloguj tylko ID użytkownika, a dane pobieraj z bazy w razie potrzeby.

# ŹLE
logger.info(f"User {user.email} logged in from {user.ip_address}")

# DOBRZE
logger.info(f"User {user.id} logged in", extra={'user_id': user.id})

2. Przechowywanie zbędnych danych

Problem: “A może się przyda” - aplikacja zbiera więcej danych niż potrzebuje, naruszając zasadę minimalizacji. Rozwiązanie: Przed dodaniem pola do formularza zapytaj: “Czy to jest absolutnie konieczne do świadczenia usługi?” Jeśli nie - nie zbieraj.

3. Brak szyfrowania danych wrażliwych

Problem: Dane osobowe (zwłaszcza szczególnych kategorii - dane zdrowotne, biometryczne) przechowywane w plaintext. Rozwiązanie: Szyfruj dane wrażliwe w bazie danych. Używaj szyfrowania na poziomie aplikacji, nie tylko TDE (Transparent Data Encryption).

4. Hardcoded credentials i tokeny

Problem: API keys, hasła do bazy danych, tokeny zapisane w kodzie źródłowym - często trafiają do repozytoriów Git, skąd mogą wyciec. Rozwiązanie: Używaj zmiennych środowiskowych, secret managers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault).

# ŹLE
DB_PASSWORD = "super_secret_123"

# DOBRZE
DB_PASSWORD = os.environ.get('DB_PASSWORD')

5. Brak mechanizmu usuwania danych

Problem: Aplikacja nie ma funkcji usuwania konta użytkownika lub “usuwanie” to tylko soft delete (flaga deleted=true). Rozwiązanie: Implementuj prawdziwe usuwanie danych + procedury na usunięcie danych z backupów, logów, cache.

6. Przekazywanie danych osobowych w URL

Problem: Dane osobowe w query params lub path parameters - trafiają do logów serwerów, proxy, przeglądarek. Rozwiązanie: Dane osobowe tylko w body requestów POST/PUT, nigdy w URL.

// ŹLE
fetch(`/api/users?email=${email}&phone=${phone}`)

// DOBRZE
fetch('/api/users', {
  method: 'POST',
  body: JSON.stringify({ email, phone })
})

7. Brak ograniczeń czasowych przechowywania

Problem: Dane przechowywane “na zawsze” - stare konta nieaktywnych użytkowników, logi sprzed 5 lat. Rozwiązanie: Implementuj data retention policies - automatyczne usuwanie starych danych po określonym czasie.

# Cron job usuwający nieaktywne konta po 2 latach
def cleanup_inactive_accounts():
    two_years_ago = datetime.now() - timedelta(days=730)
    User.objects.filter(
        last_login__lt=two_years_ago,
        account_deleted=False
    ).delete()

8. Udostępnianie baz danych testowych z prawdziwymi danymi

Problem: Deweloperzy używają kopii produkcyjnej bazy danych na środowiskach dev/test/staging. Rozwiązanie: Anonimizuj dane przed skopiowaniem do środowisk nieprod lub używaj syntetycznych danych testowych.

-- Anonimizacja danych przed eksportem
UPDATE users SET
  email = CONCAT('user_', id, '@example.com'),
  phone = CONCAT('+48', LPAD(id, 9, '0')),
  first_name = 'Test',
  last_name = CONCAT('User', id);

9. Brak walidacji zgód użytkowników

Problem: Aplikacja przetwarza dane bez sprawdzenia, czy użytkownik wyraził zgodę (jeśli zgoda jest podstawą prawną). Rozwiązanie: Przechowuj informacje o zgodach w bazie danych + timestamp + treść zgody + sposób wyrażenia.

class Consent(models.Model):
    user = models.ForeignKey(User)
    purpose = models.CharField(max_length=255)  # np. "marketing"
    granted = models.BooleanField()
    granted_at = models.DateTimeField()
    consent_text = models.TextField()  # Treść zgody w momencie wyrażenia
    ip_address = models.GenericIPAddressField()  # Dowód wyrażenia zgody

10. Brak audytu dostępu do danych osobowych

Problem: Nikt nie wie, kto i kiedy uzyskał dostęp do danych osobowych użytkownika. Rozwiązanie: Loguj wszystkie operacje na danych osobowych - kto, kiedy, jakie dane, w jakim celu.

@audit_access('personal_data_view')
def view_user_profile(request, user_id):
    user = User.objects.get(id=user_id)
    # Automatycznie logowane: request.user.id, user_id, timestamp, IP
    return render(request, 'profile.html', {'user': user})

Jak budować aplikacje zgodne z RODO - checklist dla developera

Faza planowania i projektowania

Przeprowadź Data Protection Impact Assessment (DPIA) jeśli aplikacja przetwarza dane na dużą skalę lub dane szczególnych kategorii
Zidentyfikuj wszystkie dane osobowe które będą przetwarzane w systemie
Określ podstawę prawną dla każdego celu przetwarzania (zgoda, umowa, obowiązek prawny, interes administratora)
Zaprojektuj model danych z myślą o minimalizacji - tylko niezbędne pola
Zaplanuj architekturę z oddzielnymi bazami/tabelami dla różnych kategorii danych (publiczne, osobowe, wrażliwe)

Faza implementacji

Używaj HTTPS w całej aplikacji - wymuszaj redirect z HTTP na HTTPS
Implementuj secure password hashing (bcrypt, argon2, min. 10 rund)
Szyfruj dane wrażliwe w bazie danych (dane zdrowotne, biometryczne, finansowe)
Nie loguj danych osobowych - tylko ID użytkowników
Waliduj i sanityzuj wszystkie inputy - ochrona przed SQL injection, XSS
Implementuj mechanizmy kontroli dostępu - role-based lub attribute-based access control
Dodaj rate limiting - ochrona przed brute force i scraping-iem danych
Używaj prepared statements - ochrona przed SQL injection
Implementuj secure session management - HTTPOnly, Secure, SameSite cookies

Funkcjonalności zgodności z RODO

Prawo dostępu - endpoint/funkcja do pobrania wszystkich danych użytkownika w czytelnym formacie (JSON, PDF)
Prawo do sprostowania - możliwość edycji danych osobowych przez użytkownika
Prawo do usunięcia - funkcja usuwania konta + wszystkich powiązanych danych
Prawo do przenoszenia danych - eksport danych w formacie maszynowo czytelnym (JSON, CSV, XML)
Prawo do ograniczenia przetwarzania - możliwość zablokowania konta bez usuwania danych
Prawo do sprzeciwu - możliwość cofnięcia zgody na przetwarzanie
Zarządzanie zgodami - interfejs do wyrażania/cofania zgód + audit log
Data retention policies - automatyczne usuwanie starych/nieaktywnych danych

Bezpieczeństwo i monitorowanie

Implementuj audit logging - kto, kiedy, jakie dane, jaka operacja
Skonfiguruj alerting na podejrzane aktywności - masowy dostęp do danych, nietypowe zapytania
Regularnie aktualizuj zależności - skanuj vulnerabilities (Dependabot, Snyk)
Przeprowadzaj code review z focus na security - sprawdzaj każdy PR pod kątem wycieku danych
Testuj security - penetration testing, vulnerability scanning
Przygotuj plan incident response - co zrobić w razie wycieku danych

Dokumentacja

Dokumentuj przetwarzanie danych - jakie dane, w jakim celu, jak długo, kto ma dostęp
Przygotuj politykę prywatności - w języku zrozumiałym dla użytkowników
Dokumentuj zgody użytkowników - co użytkownik zaakceptował i kiedy
Prowadź rejestr czynności przetwarzania (jeśli firma zatrudnia 250+ osób lub przetwarza dane na dużą skalę)

Deployment i operacje

Szyfruj backupy - dane osobowe w backupach są równie wrażliwe
Ograniczaj dostęp do produkcji - only senior engineers, z audit log
Anonimizuj dane przed kopiowaniem do środowisk nonprod
Monitoruj access logs - kto i kiedy logował się do systemów zawierających dane osobowe
Regularnie rób security audits infrastruktury

Prawo do bycia zapomnianym - wyzwanie architektoniczne

Prawo do usunięcia danych (potocznie “prawo do bycia zapomnianym”) to jeden z najtrudniejszych wymogów RODO do implementacji w nowoczesnych, rozproszonych systemach. W teorii proste: użytkownik żąda usunięcia danych, usuwasz dane. W praktyce: gdzie są wszystkie dane tego użytkownika?

Wyzwanie 1: Rozproszone bazy danych

W architekturze mikrousług dane użytkownika mogą być rozproszone w dziesiątkach serwisów, każdy ze swoją bazą danych. Usunięcie użytkownika wymaga orkiestracji operacji we wszystkich serwisach.

Rozwiązanie: Event-driven data deletion

# User service publikuje event
def delete_user(user_id):
    user = User.objects.get(id=user_id)
    user.delete()

    # Publikuj event do wszystkich serwisów
    publish_event('user.deleted', {
        'user_id': user_id,
        'timestamp': datetime.now().isoformat()
    })

# Każdy serwis subskrybuje event i usuwa swoje dane
@subscribe('user.deleted')
def handle_user_deleted(event):
    user_id = event['user_id']
    Order.objects.filter(user_id=user_id).delete()
    Review.objects.filter(user_id=user_id).delete()
    # ...

Wyzwanie 2: Logi systemowe

Logi mogą zawierać dane osobowe (jeśli nie przestrzegałeś wcześniejszych rad) i są zazwyczaj niemutowalne. Jak usunąć dane z logów?

Rozwiązanie: Nie loguj danych osobowych

Jeśli już zalogowałeś - musisz:

Zidentyfikować wszystkie pliki logów zawierające dane użytkownika
Usunąć odpowiednie linie z logów (trudne w systemach typu Elasticsearch, Splunk)
Usunąć dane z archiwów logów

Lepiej: nie loguj danych osobowych od początku. Używaj tylko ID użytkowników.

Wyzwanie 3: Backupy baz danych

Backupy mogą zawierać dane usuniętego użytkownika przez miesiące lub lata (w zależności od retention policy).

Rozwiązanie: Backup encryption + exception list

Szyfruj backupy kluczem, który może być rotowany
Prowadź listę “usuniętych użytkowników” - przy odtwarzaniu z backupu, sprawdź tę listę i nie przywracaj danych tych użytkowników
Alternatywnie: nie przywracaj danych osobowych z backupów starszych niż X miesięcy

Wyzwanie 4: Cache i kolejki

Dane użytkownika mogą być w Redis, Memcached, RabbitMQ, Kafka. Jak je usunąć?

Rozwiązanie: Cache invalidation + time-to-live

def delete_user(user_id):
    # Usuń z bazy danych
    User.objects.filter(id=user_id).delete()

    # Usuń z cache
    cache.delete(f'user:{user_id}')
    cache.delete(f'user_profile:{user_id}')
    cache.delete(f'user_orders:{user_id}')

    # Publikuj event do kolejek
    publish_event('user.deleted', {'user_id': user_id})

Ustaw TTL na cache - dane osobowe nie powinny być cache’owane przez długi czas.

Wyzwanie 5: Third-party services

Jeśli przekazujesz dane do zewnętrznych serwisów (analytics, CRM, email marketing), musisz zapewnić usunięcie danych także tam.

Rozwiązanie: Data Processing Agreements + API deletions

Zawrzyj DPA (Data Processing Agreement) z każdym procesorem
Implementuj automatyczne usuwanie danych przez API procesorów
Dokumentuj proces usuwania

def delete_user_from_third_parties(user_id, email):
    # Google Analytics
    ga_client.user_deletion_request(user_id)

    # Mailchimp
    mailchimp_client.delete_member(email)

    # Intercom
    intercom_client.delete_user(user_id)

    # Segment
    segment_client.track_deletion(user_id)

Best practice: “Tombstone” pattern

Zamiast natychmiastowego usunięcia, oznacz użytkownika jako “do usunięcia”, a następnie uruchom proces asynchroniczny, który usuwa dane ze wszystkich systemów.

class User(models.Model):
    # ... pola użytkownika
    deleted_at = models.DateTimeField(null=True)
    deletion_completed = models.BooleanField(default=False)

def mark_user_for_deletion(user_id):
    user = User.objects.get(id=user_id)
    user.deleted_at = datetime.now()
    user.save()

    # Uruchom asynchroniczny task
    delete_user_data_task.delay(user_id)

@celery_app.task
def delete_user_data_task(user_id):
    # Usuń z wszystkich serwisów
    delete_from_service_a(user_id)
    delete_from_service_b(user_id)
    delete_from_cache(user_id)
    delete_from_third_parties(user_id)

    # Oznacz jako ukończone
    User.objects.filter(id=user_id).update(deletion_completed=True)

Kary za naruszenie RODO - przykłady

Kary za naruszenie RODO to nie abstrakcyjne zagrożenie - to realne konsekwencje finansowe i wizerunkowe, które dotknęły setki firm w Europie. Maksymalna kara to 20 milionów euro lub 4% rocznego globalnego obrotu (w zależności od tego, która kwota jest wyższa).

Amazon (2021): 746 milionów euro Naruszenie: Nielegalne przetwarzanie danych osobowych użytkowników do celów reklamowych. Amazon nie uzyskał odpowiedniej zgody na personalizację reklam na podstawie zachowań użytkowników.

Lekcja dla developerów: Implementuj granularną kontrolę zgód - użytkownik musi móc wyrazić osobną zgodę na każdy cel przetwarzania.

Meta (Facebook, 2023): 1,2 miliarda euro Naruszenie: Przekazywanie danych użytkowników europejskich do USA bez odpowiednich zabezpieczeń. Brak zgodności z wyrokiem TSUE w sprawie Schrems II.

Lekcja dla developerów: Jeśli przesyłasz dane poza EOG - musisz mieć odpowiednią podstawę prawną (Standard Contractual Clauses) i środki techniczne (szyfrowanie, pseudonimizacja).

Google (2019): 50 milionów euro Naruszenie: Brak transparentności i nieprawidłowe uzyskiwanie zgód na przetwarzanie danych do celów personalizacji reklam w systemie Android.

Lekcja dla developerów: Zgoda musi być świadoma, konkretna i jednoznaczna. “Zgadzam się na wszystko” to nie jest prawidłowa zgoda.

British Airways (2020): 22,5 miliona euro Naruszenie: Wyciek danych 400 000 klientów (w tym danych kart płatniczych) przez atak na stronę internetową. Niewystarczające środki bezpieczeństwa.

Lekcja dla developerów: Podstawowe zabezpieczenia to za mało. Musisz implementować defense in depth - wielowarstwowe zabezpieczenia danych.

H&M (2020): 35,3 miliona euro Naruszenie: Nadmierne monitorowanie pracowników - szczegółowe zapisy rozmów z przełożonymi o życiu prywatnym, przechowywane na udostępnionym serwerze.

Lekcja dla developerów: Zasada minimalizacji dotyczy także danych pracowników. Nie zbieraj i nie przechowuj więcej niż potrzeba.

Naruszenia o podłożu technicznym

Większość kar GDPR wynika z błędów technicznych, które można było uniknąć:

Brak szyfrowania - British Airways, Marriott
Niewystarczająca kontrola dostępu - H&M, Danish taxi company
Brak walidacji zgód - Google, Meta
Przekazywanie danych poza EOG bez zabezpieczeń - Meta, Google
Nadmierne zbieranie danych - TikTok, Clearview AI
Brak mechanizmu usuwania danych - różne firmy e-commerce

Jak uniknąć kar?

Traktuj bezpieczeństwo jako priorytet od pierwszej linii kodu
Implementuj wszystkie prawa użytkowników (dostęp, usunięcie, przenoszenie, sprostowanie)
Dokumentuj wszystko - jakie dane, w jakim celu, na jakiej podstawie, jak długo
Szkolenie zespołu - każdy developer musi rozumieć podstawy RODO
Audytuj regularnie - code review, penetration testing, vulnerability scanning
Miej plan incident response - co zrobić w razie wycieku danych (72h na zgłoszenie do UODO)

Szkolenie RODO dla zespołów deweloperskich w EITT

RODO to nie tylko przepisy i paragrafy - to konkretne wyzwania techniczne, z którymi developerzy mierzą się na co dzień. EITT przeszkoliło już 500+ ekspertów IT, realizując 2500+ szkoleń z oceną 4.8/5. Nasze szkolenia RODO dla programistów to nie nudny wykład prawniczy - to praktyczne warsztaty pokazujące, jak implementować ochronę danych w realnym kodzie.

Co obejmuje szkolenie?

Moduł 1: RODO dla developerów - podstawy

Czym są dane osobowe w kontekście aplikacji webowych i mobile
Podstawy prawne przetwarzania - kiedy potrzebujesz zgody, a kiedy nie
Prawa użytkowników i jak je implementować technicznie
Kary za naruszenia - case studies z branży IT

Moduł 2: Privacy by Design w praktyce

Projektowanie architektury zgodnej z RODO
Minimalizacja danych na poziomie modelu danych
Pseudonimizacja i anonimizacja - kiedy, jak, po co
Szyfrowanie danych w spoczynku i w ruchu - best practices
Kontrola dostępu na poziomie aplikacji

Moduł 3: Secure coding dla RODO

Jak nie logować danych osobowych (i co zamiast tego)
Bezpieczne przechowywanie haseł i tokenów
Ochrona przed atakami - SQL injection, XSS, CSRF w kontekście RODO
Walidacja zgód użytkowników w kodzie
Implementacja data retention policies

Moduł 4: Prawa użytkowników - implementacja

Prawo dostępu - jak zbudować funkcję “pobierz moje dane”
Prawo do usunięcia - wyzwanie architektoniczne w mikrousługach
Prawo do przenoszenia danych - formaty, API, eksport
Prawo do sprostowania i ograniczenia przetwarzania
Audyt dostępu do danych osobowych

Moduł 5: Incident response i audyty

Co zrobić w razie wycieku danych - 72h na zgłoszenie
Jak przygotować plan incident response
Monitorowanie i wykrywanie naruszeń
Penetration testing i vulnerability scanning
Code review z perspektywy RODO

Moduł 6: RODO w praktyce zespołu

Git security - jak nie commitować danych osobowych i credentials
Środowiska dev/test/staging - anonimizacja danych
Third-party services i Data Processing Agreements
Cloud compliance - AWS, Azure, GCP w kontekście RODO
Checklist RODO dla code review

Dla kogo jest to szkolenie?

Developerzy (junior, mid, senior) - którzy piszą kod przetwarzający dane osobowe
Tech Leadzi - odpowiedzialni za compliance zespołu
Architekci - projektujący systemy zgodne z RODO
DevOps Engineers - zabezpieczający infrastrukturę
QA/Testers - testujący zgodność z RODO
Product Managers - definiujący wymagania funkcjonalne uwzględniające RODO

Korzyści ze szkolenia

Unikniesz kar - GDPR fines sięgają miliardów euro, większość z powodu błędów technicznych
Przyspiesz development - zamiast przepisywać kod, zacznij od zgodności z RODO
Zwiększ zaufanie użytkowników - ochrona danych to competitive advantage
Przygotuj się na audyty - będziesz wiedzieć, co sprawdzają audytorzy
Rozwiń kompetencje - security i privacy to must-have skills w 2026
Certyfikat - potwierdź swoje kompetencje w CV

Format szkolenia

Szkolenia stacjonarne - 2 dni intensywnych warsztatów (16h)
Szkolenia online - 4 sesje po 4h (elastyczne terminy)
Warsztaty in-house - dostosowane do potrzeb Twojego zespołu i stack’a technologicznego
Code review jako część szkolenia - przeanalizujemy Twój kod pod kątem RODO

Dlaczego EITT?

EITT to 500+ przeszkolonych ekspertów i 2500+ zrealizowanych szkoleń z oceną 4.8/5. Nasi trenerzy to nie tylko prawnicy - to praktycy z doświadczeniem w developmencie, którzy rozumieją Twoje wyzwania. Szkolenia prowadzimy w oparciu o realne case studies, przykłady kodu i hands-on exercises.

Sprawdź dostępne terminy szkoleń z RODO lub skontaktuj się z nami i omówmy indywidualny program dla Twojego zespołu.

FAQ

Czy jako developer muszę znać RODO?

Tak. Jeśli Twój kod przetwarza dane osobowe użytkowników (email, imię, IP, cookie ID, itd.), podejmujesz decyzje wpływające na zgodność firmy z RODO. Wybór sposobu przechowywania haseł, projektowanie struktury bazy danych, implementacja systemu logowania - to wszystko ma bezpośredni wpływ na ochronę danych osobowych. IOD i dział prawny mogą doradzać, ale to Ty implementujesz rozwiązania. Brak wiedzy o RODO nie zwalnia z odpowiedzialności.

Jakie dane są uważane za dane osobowe?

Szerzej niż myślisz. Dane osobowe to każda informacja pozwalająca zidentyfikować osobę fizyczną - bezpośrednio lub pośrednio. To oczywiście imię, nazwisko, email, telefon, PESEL. Ale także: adres IP, cookie ID, user ID (jeśli można go powiązać z osobą), geolokalizacja, device fingerprint, dane biometryczne, zdjęcia twarzy, historia zakupów, historia przeglądania. Zasada: jeśli można na podstawie tych danych ustalić tożsamość osoby (samodzielnie lub łącząc z innymi danymi) - to są dane osobowe.

Czy muszę usuwać dane z backupów?

Technicznie RODO wymaga usunięcia danych “we wszystkich systemach”, ale przewiduje wyjątek dla backupów - pod warunkiem, że są one zaszyfrowane, zabezpieczone i nie są wykorzystywane do normalnego przetwarzania danych. W praktyce: musisz zapewnić, że przy odtwarzaniu z backupu nie przywrócisz danych użytkowników, którzy zażądali usunięcia. Rozwiązanie: prowadź listę “usuniętych użytkowników” i nie przywracaj ich danych z backupów lub nie odtwarzaj danych osobowych z backupów starszych niż X miesięcy.

Co grozi za nieprawidłowe logowanie danych osobowych?

Jeśli logi zawierają dane osobowe i dojdzie do wycieku (np. przez nieautoryzowany dostęp do systemu monitoringu), to naruszenie RODO. Kara może wynieść do 10 milionów euro lub 2% rocznego obrotu. Przykład: firma logowała pełne requesty HTTP zawierające dane kart płatniczych. Logi wyciekły przez niezabezpieczone Elasticsearch. Efekt: kara GDPR + pozwy użytkowników + zniszczona reputacja. Rozwiązanie: nie loguj danych osobowych - tylko ID użytkowników, które możesz rozwinąć na dane w razie potrzeby (z audit log).

Czy zgoda użytkownika na wszystko rozwiązuje problem zgodności?

Nie. Po pierwsze, zgoda musi być dobrowolna, konkretna, świadoma i jednoznaczna. “Zgadzam się na wszystko” nie jest prawidłową zgodą. Po drugie, nawet jeśli masz zgodę, musisz przestrzegać zasad: minimalizacji danych, bezpieczeństwa, ograniczonego czasu przechowywania. Po trzecie, użytkownik może cofnąć zgodę w każdej chwili - musisz mieć mechanizm na obsłużenie tego. I po czwarte, dla niektórych celów (np. wykonanie umowy) zgoda nie jest potrzebna - można przetwarzać dane na innej podstawie prawnej. Krótko: zgoda nie jest uniwersalnym rozwiązaniem.

Jak długo mogę przechowywać dane osobowe?

Tylko tak długo, jak jest to konieczne do realizacji celu, dla którego zostały zebrane. Jeśli użytkownik ma konto - możesz przechowywać dane przez czas trwania relacji. Jeśli wykonujesz umowę - przez czas obowiązywania umowy + czas wymagany przepisami (np. 5 lat dla dokumentacji księgowej). Jeśli masz zgodę na marketing - do momentu jej cofnięcia. Po tym czasie musisz usunąć dane lub zanonimizować je (tak, żeby nie można było zidentyfikować osoby). W praktyce: implementuj data retention policies - automatyczne usuwanie starych danych po określonym czasie.

Bezpieczeństwo danych osobowych to nie luksus, tylko standard, który powinien być wbudowany w każdą linię kodu. RODO to nie przeszkoda w developmencie - to framework, który pomaga budować aplikacje godne zaufania użytkowników. W EITT przeszkolimy Twój zespół tak, żeby RODO przestało być abstrakcyjnym zagrożeniem, a stało się naturalną częścią procesu tworzenia oprogramowania. Sprawdź nasze szkolenia lub skontaktuj się z nami - porozmawiajmy, jak możemy pomóc Twojemu zespołowi.

Przeczytaj również

Rozwijaj swoje kompetencje

Chcesz pogłębić wiedzę z tego obszaru? Sprawdź nasze szkolenie prowadzone przez doświadczonych trenerów EITT.

➡️ Ochrona Danych Osobowych w Praktyce - RODO — szkolenie EITT