RODO w aplikacjach webowych: jak budujemy systemy zgodne z przepisami
Autor:
Paweł Matusiak
·
RODO to nie tylko polityka prywatności na stronie. To sposób, w jaki aplikacja zbiera, przechowuje, udostępnia i usuwa dane. W Laravelu da się to zaprojektować od pierwszego dnia — taniej niż naprawiać po audycie.
Wiele firm załatwia RODO PDF-em w stopce. To za mało, gdy aplikacja trzyma kartoteki klientów, historię zamówień, dokumenty albo dane medyczne i kadrowe. Unijne rozporządzenie wymaga, żeby ochrona danych była wbudowana w system (privacy by design i by default — art. 25), a nie doklejona na końcu jako checkbox „akceptuję wszystko”. W praktyce oznacza to decyzje przy pierwszej tabeli w bazie: jakie pola są potrzebne, kto je widzi, jak długo żyją i co się dzieje po żądaniu usunięcia.
GESOFT buduje panele na Laravelu między innymi dlatego, że role, logi, szyfrowanie i retencję da się zapisać w kodzie, a nie w regulaminie, którego aplikacja nie egzekwuje. Poniżej: co RODO oznacza dla oprogramowania (art. 5 i 25), jak to mapujemy na zgody, uprawnienia, usuwanie i hosting, i czego nie da się tanio dokleić, gdy baza już urosła. Nie zastępujemy kancelarii — mówimy, co system musi umieć, żeby prawnik miał co podpisać.
Co RODO oznacza w praktyce dla oprogramowania
Rozporządzenie 2016/679 nie jest listą technologii. Jest listą zasad. Art. 5 wymaga m.in. legalności i przejrzystości, ograniczenia celu, minimalizacji, prawidłowości, ograniczenia przechowywania, integralności i poufności oraz rozliczalności. Art. 25 każe wdrożyć środki techniczne i organizacyjne już przy projektowaniu środków przetwarzania — z uwzględnieniem stanu wiedzy, kosztu wdrożenia i ryzyka. Privacy by default: domyślnie przetwarzasz tylko to, co niezbędne do konkretnego celu, w odpowiednim zakresie, czasie i dostępności.
- Minimalizacja — zbierasz tylko to, czego naprawdę potrzebujesz do konkretnego celu. Pesel w formularzu newslettera nie jest potrzebny. Data urodzenia w sklepie B2B — też zwykle nie.
- Podstawa prawna — zgoda, umowa, obowiązek prawny albo uzasadniony interes muszą być jasne i możliwe do wykazania. Inna podstawa do faktury, inna do newslettera.
- Ograniczenie celu — danych z formularza kontaktowego nie używasz potem do innego marketingu bez zgody. Aplikacja nie powinna mieć jednego worka „zgoda na wszystko”.
- Prawo dostępu i usunięcia (art. 15 i 17) — użytkownik może dostać kopię danych i zażądać ich skasowania, z wyjątkami (np. obowiązek podatkowy).
- Przenoszalność (art. 20) — eksport w ustrukturyzowanym formacie, nie zrzut niedziałającego PDF-a z trzech tabel naraz.
- Bezpieczeństwo (art. 32) — szyfrowanie w transporcie, kontrola dostępu, kopie, zdolność do przywrócenia, zgłaszanie naruszeń (art. 33: 72 godziny do organu).
Szczególne kategorie danych (art. 9) — zdrowie, dane biometryczne, przynależność związkowa — wymagają dodatkowej podstawy i ostrzejszej kontroli dostępu. Dlatego panele dla gabinetów, HR i ubezpieczeń projektujemy inaczej niż prosty CRM wizytówek: węższe role, osobne zgody, krótsza ścieżka do logów. Nie udajemy, że „zwykły hosting shared” zamyka ten temat.
Jak to wygląda w aplikacji Laravel
Zgody i rejestr czynności
Zgody marketingowe i regulamin zapisujemy z datą, treścią wersji i źródłem (formularz, panel, import, rozmowa zapisana przez pracownika). Nie wystarczy checkbox akceptuję wszystko. Osobno zgoda na przetwarzanie w ramach umowy, osobno newsletter, osobno profilowanie — jeśli w ogóle jest potrzebne. Cofnięcie zgody jest tak samo łatwe jak jej udzielenie: jeden klik w panelu klienta albo mail, który naprawdę działa, nie adres, którego nikt nie czyta.
Rejestr czynności przetwarzania (art. 30) to obowiązek administratora, nie software house’u. My dostarczamy surowiec: jakie zbiory są w bazie, jakie pola, jakie retencje, jakie odbiorcy (kurier, bramka płatności, SMS). Bez tego prawnik rysuje rejestr z głowy, a aplikacja żyje własnym życiem.
Role zamiast wspólnego hasła do wszystkiego
Pracownik biura nie powinien widzieć danych płacowych. Księgowość nie potrzebuje pełnej historii czatu z klientem. Recepcja gabinetu nie potrzebuje wyników badań, których nie obsługuje. W Laravelu role i policies pozwalają ograniczyć dostęp do konkretnych zasobów po stronie API, nie tylko przez ukrycie pozycji w menu. To jeden z najskuteczniejszych sposobów na zmniejszenie skutków wycieku — atakujący z kontem o niskich uprawnieniach nie zabiera całej bazy. To też A01 z OWASP Top 10, nie tylko paragraf RODO.
Prawo do usunięcia i anonimizacja
Usuń konto nie może zostawiać imienia, e-maila i numeru telefonu w pięciu tabelach plus w logach plus w starym eksporcie na dysku księgowej. Projektujemy ścieżkę: co kasujemy, co anonimizujemy (żeby zachować faktury i dokumenty wymagane przez prawo — w Polsce ewidencja i faktury to lata, nie tygodnie), co zostaje w kopiach zapasowych i na jak długo. Kopie też mają retencję: backup trzymany wiecznie z pełnymi danymi osobowymi jest drugim, zapomnianym zbiorem.
To trzeba ustalić, zanim baza urośnie do setek tysięcy rekordów. Po fakcie anonimizacja to skrypt, który boi się ruszyć produkcję, i trzy tygodnie ręcznego sprawdzania, czy w tabeli notatek nie został numer PESEL. Taniej jest mieć kolumny i kaskady przemyślane na starcie.
Logi, ale nie za dużo
Log audytowy (kto zmienił adres klienta) jest potrzebny do rozliczalności i do art. 32. Logowanie pełnych numerów PESEL, treści haseł albo treści wiadomości medycznej — już nie. Hasła nigdy nie trafiają do logów. Dane wrażliwe maskujemy albo w ogóle ich nie zapisujemy. Retencja logów jest osobną decyzją: za krótka i nie odtworzysz incydentu, za długa i trzymasz zbiór, którego nie umiesz uzasadnić.
Naruszenia, 72 godziny i co system musi umieć
Art. 33 wymaga zgłoszenia naruszenia organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości w 72 godziny od stwierdzenia. Aplikacja nie wyśle tego zgłoszenia za Ciebie, ale może sprawić, że wiesz: które konto, jaki zakres, czy dane były zaszyfrowane, czy da się powiadomić osoby (art. 34). Bez logów i bez inwentarza zbiorów 72 godziny zjadają się na zgadywaniu. Dlatego w panelach, które trzymają dane szczególnych kategorii, od początku projektujemy alert przy masowym eksporcie, przy logowaniu admina z nowego IP i przy serii nieudanych resetów hasła.
Szyfrowanie w transporcie (TLS) jest minimum. Szyfrowanie wybranych pól w spoczynku — tam, gdzie wyciek bazy (dump, backup, kopia u księgowego na pendrive) byłby szczególnie bolesny. Laravel ma encrypted casts na modelach; klucz nie może leżeć w tym samym dumpie co dane. Kopie poza serwerem produkcyjnym, testowane odtwarzanie — to samo, o czym piszemy przy audycie bezpieczeństwa.
Czego nie da się dokleić później tanio
Szyfrowanie dysku i certyfikat SSL można dodać w każdy moment. Trudniej dodać: spójny model zgód, retencję danych, eksport na żądanie, rozdzielenie ról i ślad audytowy. Dlatego w nowych aplikacjach Laravel te elementy planujemy na etapie analizy — zanim powstanie pierwsza tabela w bazie. Stary panel da się poprawić (HTTPS, kopie, limity logowań), ale „prawo do bycia zapomnianym” na bazie bez kluczy obcych i bez decyzji, co jest fakturą, a co marketingiem, to projekt sam w sobie.
- Jedno pole zgoda_rodo = 1 nic nie mówi, której wersji regulaminu dotyczyło i czy obejmowało newsletter.
- Wspólne konto biuro uniemożliwia wykazanie, kto udostępnił dane — i łamie zasadę rozliczalności.
- Eksport wszystko do CSV bez 2FA to nie udogodnienie dla księgowej, tylko gotowy wektor wycieku.
- Logi z hasłami albo pełnym PESEL są gorsze niż brak logów: sam zbiór jest naruszeniem czekającym na kopię zapasową.
Privacy by design na analizie, nie w aneksie
Art. 25 nie każe kupić certyfikatu. Każe myśleć o danych w momencie, gdy rysujemy ekran. Na warsztacie startowym pytamy: po co to pole, kto je zobaczy, ile miesięcy żyje, czy da się je nie zbierać. Jeśli nikt nie umie obronić numeru PESEL w leadzie z Facebooka, pola nie ma w MVP. Jeśli recepcja musi widzieć imię i godzinę, a nie rozpoznanie, API nie zwraca rozpoznania do tej roli. To taniej niż później maskować kolumnę w dwudziestu raportach.
Domyślne ustawienia też są decyzją projektową. Nowy użytkownik nie ma zaznaczonego newslettera. Eksport CSV nie jest w menu każdego handlowca. Sesja wygasa. Hasło nie może być Firma2024. Kopie nie lądują na prywatnym Dysku Google księgowej. Privacy by default oznacza, że wygodne wszystko włączone jest świadomym wyjątkiem, nie presetem motywu. W Laravelu te presety zapisujemy w kodzie i w politykach, nie w PDF, którego nikt nie czyta przy kolejnej funkcji.
Wniosek o dostęp albo usunięcie nie może zależeć od tego, czy programista ma czas w kwietniu. Robimy ścieżkę w panelu albo procedurę z terminem: kto przyjmuje wniosek, jak weryfikujemy tożsamość (żeby nie skasować cudzego konta na podstawie maila z wolnego adresu), w jakim formacie oddajemy kopię. To jest art. 12 i 15 w praktyce — bez automatu na każdy mikro-CRM, ale z miejscem w systemie i terminem w kalendarzu, nie z wątkiem na Slacku, który ginie po urlopie administratora albo zmianie agencji. Termin i format odpowiedzi zapisujemy w dokumentacji przekazania, razem z Git.
Budujemy systemy dla branż, w których dane są szczególnie wrażliwe: medycyna, kancelarie, HR, ubezpieczenia. Logowanie i 2FA opisujemy osobno w uwierzytelnianiu Laravel, bo to najczęstszy wektor, którym ktoś obcy wchodzi w kartotekę. Jeśli potrzebujesz aplikacji zgodnej z RODO albo przeglądu istniejącego panelu, napisz do nas. Powiemy, co jest ryzykiem, a co tylko kosmetyką w regulaminie. Wycena po opisie zbiorów i ról, bez ceny katalogowej za pakiet RODO. Kod źródłowy i 6 miesięcy gwarancji — jak w każdym projekcie GESOFT.
Podstawy z art. 6 i 9 — nie jeden checkbox
Art. 6 RODO wymienia podstawy: zgoda, umowa, obowiązek prawny, żywotne interesy, zadanie publiczne, prawnie uzasadniony interes. Faktura i konto zamówienia to zwykle umowa i obowiązek rachunkowy — nie marketingowa zgoda, której klient „nie odhaczył”. Newsletter i profilowanie to zgoda albo (rzadziej) uzasadniony interes z testem równowagi i łatwym sprzeciwem. Łączenie „akceptuję regulamin i chcę maile” w jednym polu jest klasycznym błędem. W bazie trzymamy podstawę per cel, datę, wersję tekstu i źródło, nie flagę rodo=1.
Art. 9 (szczególne kategorie: zdrowie, biometria, związek zawodowy, seksualność) wymaga osobnej przesłanki i ciaśniejszej kontroli. Panel gabinetu, HR albo ubezpieczeń nie jest „CRM z dodatkowym polem”. Recepcja widzi termin, nie rozpoznanie. Eksport pełnej karty nie jest w menu każdej roli. DPIA (art. 35) rozważamy, gdy skala, nowa technologia albo dane szczególne podnoszą ryzyko — nie jako certyfikat do kupienia, tylko jako dokument administratora, do którego system dostarcza fakty: jakie zbiory, jakie odbiorcy, jakie retencje.
Cookies, e-Privacy i to, czego RODO nie załatwia samo
Baner cookies to nie RODO w całości. Identyfikatory w przeglądarce, tracking i marketingowe tagi spadają też pod przepisy e-Privacy / ustawę o świadczeniu usług drogą elektroniczną. Analityka bez identyfikacji osoby (zanonimizowane, lokalne, bez przekazywania do narzędzi reklamowych) da się uzasadnić inaczej niż piksel remarketingu. W aplikacjach panelowych często w ogóle nie stawiamy marketingowych cookies: sesja HttpOnly wystarcza do logowania. Nie sprzedajemy „zgodności” jako wtyczki banera na Laravelu, który i tak nie ma AdSense.
Transfer poza EOG (rozdział V): standardowe klauzule umowne, ocena kraju, czasem dodatkowe środki. Tani bucket w regionie poza UE „bo tańszy” nie przechodzi, jeśli w środku są kartoteki. Bramki płatności i SMS z siedzibą poza EOG muszą być nazwane w DPA i w informacji dla osoby. To checklista prawna + konfiguracja DNS/regionu, nie filozofia. Hosting paneli GESOFT — serwery w UE, HTTPS, dostęp admina rejestrowany.
DPIA, IOD i granica software house’u
Inspektor ochrony danych i rejestr czynności (art. 30) są po stronie administratora. My dajemy surowiec: słownik zbiorów, pola, retencje, odbiorców (kurier, KSeF, SMTP, SMS), logi kto eksportował. Nie podpisujemy się jako Twój IOD. Współpracujemy z kancelarią, jeśli ją masz. Umowa powierzenia (art. 28) jest obowiązkowa, gdy to my hostujemy albo mamy dostęp do produkcji — szablon DPA, nie stopka na fakturze. Podprocesorów nie ukrywamy.
72 godziny z art. 33 liczą się od stwierdzenia naruszenia, nie od „jak znajdziemy czas”. System ma umieć powiedzieć: które konto, jaki zakres, czy dane były zaszyfrowane, czy da się powiadomić osoby (art. 34). Bez logów i inwentarza te godziny zjadają się na zgadywaniu. Dlatego alert przy masowym eksporcie, nowym IP admina i serii resetów hasła projektujemy w panelach z danymi wrażliwymi od dnia jednego, razem z 2FA i kontrolą dostępu. Git i 6 miesięcy gwarancji — jak w każdym projekcie, nie jako pakiet RODO z cennika.
Najczęściej zadawane pytania
- Czy polityka prywatności w stopce wystarczy na RODO?
- Nie, jeśli aplikacja trzyma kartoteki, zamówienia albo dane medyczne. Potrzebne są zgody w bazie, role, prawo do usunięcia, retencja i bezpieczeństwo — nie tylko PDF. Art. 25 wymaga privacy by design, nie privacy by footer.
- Gdzie trzymacie dane?
- Na serwerach w UE, ruch HTTPS. Jeśli hosting jest po naszej stronie, podpisujemy umowę powierzenia (DPA, art. 28). Podprocesorów (płatności, SMS, poczta) nie ukrywamy.
- Czy da się dodać RODO do starego panelu?
- Część rzeczy tak (SSL, kopie, limity logowań). Model zgód, retencja i eksport na żądanie są drogie, gdy baza już urosła. Taniej zaprojektować to na starcie. Audyt pokaże, co da się załatać.
- Kogo dotyczy RODO w małej firmie?
- Każdego, kto przetwarza dane osób w UE — także JDG z listą klientów. Skala obowiązków zależy od rodzaju danych i ryzyka, nie od tego, czy mamy dział prawny. Dane zdrowotne i kadrowe podnoszą poprzeczkę.
- Czy muszę kasować faktury na żądanie klienta?
- Nie kosztem obowiązków podatkowych i rachunkowych. Faktury i dokumenty, które prawo każe trzymać, anonimizujemy w warstwie marketingowej, a w warstwie księgowej zostawiamy na wymagany okres. Ścieżkę ustalamy na analizie, nie ad hoc przy pierwszym wniosku.
- Czy newsletter i konto klienta to ta sama zgoda?
- Nie. Umowa (konto, zamówienie) to inna podstawa niż marketing. Checkbox łączony akceptuję regulamin i chcę maile jest klasycznym błędem. W panelu rozdzielamy to i zapisujemy wersję tekstu.
- Co z kopiami zapasowymi po usunięciu konta?
- Backup nie może być wiecznym drugim zbiorem. Ustalamy retencję kopii i to, że po wygaśnięciu odtwarzamy już bez skasowanego rekordu. Natychmiastowe wymazanie ze wszystkich taśm bywa nierealne — dlatego polityka retencji musi to nazywać wprost.
- Czy GESOFT zastępuje Inspektora Ochrony Danych?
- Nie. Dostarczamy system, który da się obronić: zgody, role, logi, DPA, eksport. Decyzje prawne, rejestr czynności i IOD zostają po stronie administratora. Współpracujemy z Twoim prawnikiem, jeśli go masz.
Powiązana usługa:
Aplikacje Laravel i Vue.js
Opisz projekt