Dane osobowe to wszelkie informacje o zidentyfikowanej lub możliwej do zidentyfikowania osobie fizycznej. W praktyce biznesowej kluczowe są dwa elementy: identyfikator (np. imię i nazwisko, PESEL, e‑mail) oraz możliwość identyfikacji pośrednio (np. poprzez połączenie kilku informacji z systemów).
Osoba jest „możliwa do zidentyfikowania”, jeśli mając rozsądnie dostępne środki (np. własne systemy, ogólnodostępne rejestry) można ją odróżnić od innych. Nie trzeba znać pełnego imienia i nazwiska – czasem wystarczy numer klienta plus e‑mail, albo numer rejestracyjny samochodu, który w bazie łączysz z konkretnym kierowcą.
RODO nie dotyczy osób prawnych (spółek, fundacji), ale w firmie rzadko masz do czynienia tylko z „czystymi” danymi spółki. Wystarczy, że w systemie CRM zarejestrowany jest „Jan Kowalski, specjalista ds. zakupów w XYZ sp. z o.o.” i już wchodzisz w reżim danych osobowych.
Przykłady danych osobowych w codziennej działalności
Lista poniżej nie jest zamknięta, ale dobrze pokazuje, jak szeroko działa definicja danych osobowych:
imię i nazwisko, adres e‑mail (także służbowy typu imie.nazwisko@firma.pl), numer telefonu;
adres zamieszkania, adres dostawy, adres rozliczeniowy osoby fizycznej prowadzącej działalność;
numery identyfikacyjne: PESEL, NIP osoby fizycznej, numer dowodu, numer paszportu, numer prawa jazdy;
nagrania z monitoringu wizyjnego, jeśli pozwalają rozpoznać osobę (w tym nagrania z wideokonferencji w systemach online);
numery klienta, identyfikatory w systemie CRM lub helpdesku, jeśli da się je powiązać z konkretną osobą;
adresy IP, identyfikatory ciasteczek (cookies) i identyfikatory urządzeń, jeśli w danym kontekście możesz powiązać je z użytkownikiem;
informacje o płatnościach: numery rachunków bankowych osób fizycznych, dane na przelewach;
dane lokalizacyjne, np. z GPS w samochodach służbowych przypisanych do konkretnego pracownika.
Warto zwrócić uwagę na e‑mail służbowy. Nawet adres typu imie.nazwisko@firma.pl, choć wydaje się „firmowy”, jest traktowany jako dana osobowa. Podobnie numer telefonu służbowego – jeśli jest przypisany do konkretnego pracownika, wchodzi w zakres RODO.
Dane zwykłe a dane wrażliwe – dlaczego to rozróżnienie ma znaczenie
RODO wyróżnia tzw. szczególne kategorie danych (potocznie: dane wrażliwe). Są to m.in. dane o zdrowiu, pochodzeniu rasowym lub etnicznym, przekonaniach religijnych, światopoglądzie, przynynależności do związków zawodowych, a także dane genetyczne, biometryczne i dotyczące życia seksualnego lub orientacji seksualnej.
W firmach najczęściej pojawiają się dane zdrowotne (np. zwolnienia lekarskie, orzeczenia o niepełnosprawności, informacje o ograniczeniach zdrowotnych przy wykonywaniu pracy) oraz dane biometryczne (np. odcisk palca w systemie wejścia do budynku). Dla takich danych obowiązuje ostrzejszy reżim:
ograniczony katalog podstaw prawnych przetwarzania (zwykła zgoda często nie wystarczy),
wyższe wymagania bezpieczeństwa (dostępy, szyfrowanie, ograniczenia zakresowe),
większa wrażliwość nadzorcza – naruszenia takich danych mają zwykle wyższy priorytet.
Większość danych biznesowych (imię, nazwisko, adres e‑mail, dane dotyczące zamówień) to dane zwykłe. Dobrą praktyką jest odseparowanie danych wrażliwych w systemach i procedurach – osobne uprawnienia, osobne zasady retencji, czasem nawet osobne systemy.
Dane osobowe a anonimizacja i pseudonimizacja
Granica między danymi osobowymi a danymi całkowicie zanonimizowanymi jest kluczowa z punktu widzenia RODO. Anonimizacja to taki proces przetworzenia danych, po którym nie da się już zidentyfikować osoby w żaden sposób, przy użyciu rozsądnie dostępnych środków. Dane całkowicie zanonimizowane wypadają z RODO.
Pseudonimizacja to tylko „schowanie” tożsamości za identyfikatorem (np. zamiast „Jan Kowalski” pojawia się „Użytkownik 1234”). Jeżeli organizacja nadal dysponuje kluczem pozwalającym połączyć pseudonim z konkretną osobą, to wciąż są to dane osobowe, choć ich ryzyko jest niższe.
Typowy przykład: eksport danych sprzedażowych do analityki w hurtowni danych. Jeśli odetniesz wszelkie identyfikatory i nie będziesz w stanie odtworzyć, który rekord dotyczył której osoby, dopiero wtedy można mówić o anonimizacji. Samo zastąpienie imienia numerem klienta niczego nie zmienia, jeśli numer klienta w innym systemie możesz odtworzyć.
Różne kategorie osób w firmie – jeden reżim RODO
RODO stosuje się do danych każdej osoby fizycznej, niezależnie od roli, jaką pełni wobec firmy. Z perspektywy administratora (firmy) pod reżim RODO wchodzą m.in. dane:
klientów – zarówno B2C (osób fizycznych), jak i osób kontaktowych po stronie B2B,
leadów sprzedażowych – osób, które wypełniły formularz, pobrały e‑booka, zostawiły wizytówkę,
pracowników i współpracowników (B2B, zlecenia, kontrakty menedżerskie),
kandydatów do pracy – zarówno z ogłoszeń, jak i pozyskanych bezpośrednio przez rekruterów,
Legalne podstawy przetwarzania – co realnie działa w biznesie
Podstawy przetwarzania z art. 6 RODO w skrócie
RODO wymaga, aby każde przetwarzanie danych miało konkretną podstawę prawną. Najczęściej spotykane w biznesie są:
art. 6 ust. 1 lit. b – wykonanie umowy: gdy dane są potrzebne do zawarcia lub wykonania umowy (zamówienie, świadczenie usługi, serwis gwarancyjny);
art. 6 ust. 1 lit. c – obowiązek prawny: gdy przepisy prawa nakazują przetwarzać dane (np. księgowość, prawo pracy, przepisy podatkowe);
art. 6 ust. 1 lit. f – uzasadniony interes administratora: gdy firma realizuje swoje prawnie uzasadnione interesy, o ile nie przeważają prawa i wolności osoby (np. dochodzenie roszczeń, bezpieczeństwo systemów, marketing bezpośredni do własnych klientów);
art. 6 ust. 1 lit. a – zgoda: gdy osoba w sposób dobrowolny, świadomy i jednoznaczny zgadza się na określone przetwarzanie (np. newsletter marketingowy);
art. 6 ust. 1 lit. e – zadanie realizowane w interesie publicznym – istotny głównie w jednostkach administracji publicznej;
art. 6 ust. 1 lit. d – żywotne interesy – sytuacje wyjątkowe, np. ratowanie życia lub zdrowia.
W firmie komercyjnej zdecydowana większość operacji będzie się opierać na kombinacji: umowa + obowiązek prawny + uzasadniony interes. Zgoda jest potrzebna rzadziej, niż się przyjęło, ale jeśli już jest stosowana, musi być dobrze „technicznie” zaprojektowana.
Dopasowanie podstawy prawnej do typu relacji
Przetwarzanie danych w relacji B2C (klient indywidualny) i B2B (przedstawiciel kontrahenta) opiera się na tych samych przepisach, ale akcenty są inne. Przykładowo:
sprzedaż usług B2C: wykonanie umowy (dane niezbędne do realizacji usługi, rozliczeń) + obowiązek prawny (faktury, dokumentacja) + uzasadniony interes (dochodzenie roszczeń, zabezpieczenie przed nadużyciami);
sprzedaż B2B: podobnie – umowa zawierana ze spółką, ale dane osób kontaktowych przetwarzasz najczęściej na podstawie uzasadnionego interesu (utrzymanie relacji, komunikacja biznesowa);
rekrutacja: dane kandydata wymagane przepisami (zakres z kodeksu pracy) – obowiązek prawny; szerszy zakres i przyszłe rekrutacje – zgoda lub uzasadniony interes, przy zachowaniu zasady minimalizacji;
marketing: komunikacja z własnymi klientami – często uzasadniony interes; newsletter i komunikacja do osób, które nie są klientami – zgoda + wymogi z innych ustaw (np. o świadczeniu usług drogą elektroniczną, Prawa telekomunikacyjnego).
Inna sytuacja: obsługa reklamacji i windykacja. Dane związane z reklamacjami możesz przetwarzać głównie na podstawie umowy i obowiązku prawnego (rękojmia, gwarancja), natomiast przy windykacji często pojawia się uzasadniony interes – dochodzenie roszczeń i obrona przed roszczeniami.
Typowe nadużycia przy stosowaniu zgody
Zgoda bywa traktowana jako „uniwersalne paliwo” do przetwarzania danych. To błąd. Zgoda musi być:
dobrowolna – brak zgody nie może uniemożliwiać wykonania umowy, jeśli dane nie są do niej niezbędne,
konkretna – przypisana do jasno określonego celu,
świadoma – osoba rozumie, na co się godzi i jakie są jej prawa,
jednoznaczna – wyrażona wyraźnym działaniem (np. zaznaczenie checkboxa, kliknięcie w link potwierdzający).
Błędy, które nadal pojawiają się nagminnie:
jeden checkbox „na wszystko” – marketing, profilowanie, udostępnianie partnerom, badania satysfakcji w jednym oświadczeniu; każdy cel wymaga osobnej zgody lub innej podstawy,
domyślnie zaznaczone zgody – to nie jest ważna zgoda; checkboxy muszą być puste,
zgoda zamiast umowy lub obowiązku prawnego – pobieranie zgody na przetwarzanie danych, które i tak musisz mieć, aby zrealizować umowę lub spełnić obowiązek ustawowy; to tylko myli użytkownika i utrudnia zarządzanie.
Zgoda jest przydatna głównie w kontekście marketingu dodatkowego, przechowywania CV „na przyszłość” oraz przetwarzania niektórych danych wrażliwych (choć tam katalog podstaw jest inny, z art. 9 RODO). W pozostałych obszarach zwykle wystarczy dobra analiza umowy, przepisów i uzasadnionych interesów.
Schemat decyzyjny: jak dobrać podstawę w praktyce
Przy projektowaniu procesu warto konsekwentnie przechodzić przez trzy pytania:
Czy bez tych danych można wykonać umowę? Jeśli nie – podstawa to zwykle wykonanie umowy. Przykład: adres e‑mail do przesłania dostępu do konta, adres dostawy przy sprzedaży fizycznego produktu.
Czy inny przepis prawa wymaga ode mnie tych danych? Jeśli tak – podstawa to obowiązek prawny. Przykład: dane na fakturze, dokumentacja kadrowa, przechowywanie dokumentów księgowych przez określony czas.
Czy mam uzasadniony interes, który uzasadnia przetwarzanie tych danych, przy akceptowalnym wpływie na prywatność osoby? Jeśli tak – rozważ art. 6 ust. 1 lit. f, ale przeprowadź test równowagi (co z prawami osoby, czy ma łatwą możliwość sprzeciwu, jaki jest zakres danych i okres przechowywania).
Dopiero gdy nie da się obronić przetwarzania danej kategorii na żadnej z powyższych podstaw, a mimo to chcesz ją mieć, rozważ stosowanie zgody. W wielu przypadkach wniosek będzie taki, że dana informacja w ogóle nie jest potrzebna i lepiej z niej zrezygnować.
Kiedy test równowagi przy uzasadnionym interesie jest konieczny
Uzasadniony interes jest wygodną, ale wymagającą podstawą. Potrzebny jest test równowagi – analiza, czy interes administratora nie narusza nadmiernie praw osoby, której dane dotyczą. W firmie warto mieć prosty szablon takiej analizy, zawierający m.in.:
opis celu i zakresu przetwarzania,
opis potencjalnego wpływu na osobę (ryzyka, niedogodności),
możliwość łatwego sprzeciwu (opt‑out), jeśli przepisy go przewidują.
Jakie dane klientów możesz zbierać i przetwarzać na co dzień
Zakres danych przy sprzedaży online i offline
Przy zwykłej sprzedaży (sklep internetowy, SaaS, usługi stacjonarne) trzon danych jest podobny. W praktyce „must have” i „nice to have” warto rozdzielić bardzo wyraźnie:
dane identyfikacyjne (imię, nazwisko) – potrzebne do personalizacji konta, umowy, obsługi reklamacji; przy sprzedaży anonimowej (np. dostęp do materiałów cyfrowych tylko na e‑mail) imię bywa zbędne,
dane kontaktowe (adres e‑mail, telefon) – e‑mail zwykle wystarcza do obsługi zamówienia online; telefon bywa uzasadniony przy dostawie kurierem lub usługach wymagających szybkiego kontaktu,
adres dostawy / korespondencyjny – tylko gdy istnieje wysyłka fizyczna lub wymóg formalny (np. korespondencja pisemna),
dane do faktury – imię i nazwisko lub nazwa firmy, adres, NIP (gdy kupuje przedsiębiorca i żąda faktury),
dane techniczne (logi serwera, identyfikatory sesji) – w uzasadnionym interesie: bezpieczeństwo, utrzymanie ciągłości działania, analiza nadużyć.
Jeśli formularz sprzedażowy zawiera pola typu „stan cywilny”, „data urodzenia”, „zawód”, przy zwykłej usłudze B2C – trzeba mieć solidne uzasadnienie. W większości branż te dane nie są niezbędne do umowy, więc pozostaje uzasadniony interes (profilowanie oferty) lub zgoda. Tu pojawia się pytanie, czy naprawdę są potrzebne.
Dane w kontach użytkownika i panelach klienta
Konto użytkownika kusi, żeby zbierać więcej informacji niż w jednorazowym zamówieniu. Sens mają głównie dane, które:
ułatwiają klientowi ponowne zakupy (historia zamówień, zapisane dane dostawy),
służą bezpieczeństwu (logi logowania, adres IP przy podejrzanych akcjach),
usprawniają support (przypisanie zgłoszeń do konta, status rozwiązywania problemów).
Nie ma powodu, żeby w każdym koncie wymagać danych, które nie są powiązane z oferowaną usługą. Jeśli moduł „profil klienta” zawiera pole na zdjęcie, biografię czy link do social mediów – ustaw to jako opcjonalne i przeanalizuj, czy istnieje rozsądna podstawa (zwykle zgoda, wyrażona poprzez uzupełnienie pola).
Każda z tych grup wymaga trochę innego podejścia do informacji, podstaw prawnych i retencji. Mechanizm jest jednak wspólny: jasno określony cel, adekwatny zakres danych, właściwa podstawa prawna i kontrolowany czas przechowywania. W razie potrzeby pogłębienia tematu podstaw prawnych i praktyki wdrożeń warto zerknąć na więcej o prawo, gdzie poszczególne reżimy przetwarzania są szerzej analizowane.
Lead magnety, webinary, newslettery
Przy typowej akcji marketingowej (e‑book, webinar, zapis na newsletter) granica potrzebnych danych jest dość jasna:
newsletter – zwykle wystarczy e‑mail; imię możesz chcieć do personalizacji komunikatów, ale jako dobrowolne pole,
webinar na żywo – e‑mail (link dostępu), czasem imię + nazwa firmy, jeśli wydarzenie jest stricte B2B; numer telefonu tylko, jeśli naprawdę planujesz kontakt telefoniczny i masz do tego właściwą podstawę,
e‑book – jedno pole na e‑mail i zgoda marketingowa (jeśli chcesz później wysyłać treści sprzedażowe) zwykle wystarczająco opisują relację.
Jeżeli przy pobieraniu materiału edukacyjnego pojawia się 10 pól, z czego 8 obowiązkowych (stanowisko, wielkość firmy, przychód, budżet roczny, numer telefonu), to z punktu widzenia RODO trzeba wprost odpowiedzieć na pytanie: jaka jest podstawa prawna dla tak szerokiego zestawu informacji i czy test równowagi to udźwignie. W wielu przypadkach lepiej zastosować krótką ankietę opcjonalną (uzasadniony interes + rozsądny minimalizm).
Analiza zachowań użytkowników i narzędzia analityczne
Narzędzia typu Google Analytics, Hotjar, systemy tagowania marketingowego generują sporo identyfikatorów i metadanych. Część z nich przy odpowiedniej konfiguracji da się „od-osobowić” (np. IP zanonimizowane, brak ID użytkownika przypisanego do osoby). Wtedy wchodzimy w obszar danych, które nie są danymi osobowymi w rozumieniu RODO.
Jeżeli jednak:
łączysz identyfikator analityczny z kontem użytkownika,
przypinasz ID z ciasteczek do adresu e‑mail,
budujesz szczegółowe profile zachowań przypisane do konkretnej osoby,
to w praktyce przetwarzasz dane osobowe. Podstawą będzie zwykle uzasadniony interes (analiza skuteczności serwisu) lub zgoda (bardziej agresywne profilowanie marketingowe). Dobrze zaprojektowany baner cookies i granularne ustawienia zgód to nie jest „ładny dodatek”, tylko kluczowy element legalności całego ekosystemu martech.
Źródło: Pexels | Autor: Miguel Á. Padriñán
Dane osobowe w relacjach B2B – co naprawdę podlega RODO
Osoba kontaktowa po stronie kontrahenta
Relacja „firma–firma” nie wyłącza RODO. Ustalenia, maile i telefony i tak przechodzą przez konkretne osoby. Typowy zestaw danych w B2B to:
imię i nazwisko osoby kontaktowej,
stanowisko / rola w organizacji,
służbowy adres e‑mail,
służbowy numer telefonu,
historia korespondencji i spotkań.
Te informacje są danymi osobowymi, bo pozwalają zidentyfikować konkretną osobę fizyczną, nawet jeśli adres e‑mail wygląda jak imie.nazwisko@duzaspolka.pl. Najczęściej podstawą przetwarzania jest uzasadniony interes administratora – umożliwienie komunikacji w związku z umową lub negocjacjami.
Systemy CRM, pipeline sprzedażowy i notatki handlowców
CRM to miejsce, w którym RODO „lubi się” wywracać na drobnych rzeczach. Oprócz standardowych pól, w bazach pojawiają się:
notatki typu „nie lubi telefonów rano”, „trudny w rozmowie” – to nadal dane osobowe, często o charakterze ocennym,
tagi segmentujące (np. „decyzyjny”, „influencer”, „promotor”),
informacje o prywatnych preferencjach (ulubiony sport, rodzina),
dane pozyskane z LinkedIn, konferencji, poleceń.
W przypadku takich informacji kluczowe są dwa elementy: podstawa prawna (zwykle uzasadniony interes – sprzedaż, utrzymanie relacji) oraz minimalizacja (czy rzeczywiście potrzebujesz tak szczegółowych notatek). Uwaga przy danych pozyskiwanych z serwisów społecznościowych: to, że ktoś coś upublicznił, nie oznacza dowolności przetwarzania. Kontekst oryginalnej publikacji ma znaczenie przy ocenie testu równowagi.
Prospecting i cold mailing w B2B
Pozyskiwanie kontaktów do nowych klientów B2B bez wcześniejszego związku biznesowego jest dopuszczalne, ale wymaga spójnej konstrukcji prawnej:
podstawa RODO – zazwyczaj uzasadniony interes (pozyskiwanie klientów biznesowych),
przepisy sektorowe – w Polsce dodatkowo ustawa o świadczeniu usług drogą elektroniczną i Prawo telekomunikacyjne (zgoda na marketing drogą elektroniczną lub telefoniczną),
jasna informacja przy pierwszym kontakcie (klauzula RODO), kto jest administratorem, jaki jest cel i jakie są prawa odbiorcy.
Technicznie można zbudować proces, w którym:
pozyskujesz służbowe dane kontaktowe z legalnych źródeł (strona www firmy, publiczny rejestr, LinkedIn w granicach regulaminu),
przeprowadzasz test równowagi dla uzasadnionego interesu (masz biznesowy cel, ograniczasz liczbę kontaktów, szanujesz sprzeciw),
w pierwszej wiadomości informujesz o źródle danych, celu i umożliwiasz łatwe wypisanie / sprzeciw.
W praktyce największym problemem nie jest sama legitymacja RODO, ale zbyt masowe i niedokładnie targetowane kampanie, które trudno obronić jako „proporcjonalne” wobec prywatności odbiorców.
Dane jednoosobowych działalności i wspólników
Jeżeli kontrahentem jest jednoosobowa działalność gospodarcza, wspólnik spółki cywilnej lub osobowej – dane identyfikujące tę firmę są równocześnie danymi osobowymi (np. „Jan Kowalski – Usługi Budowlane”). Nazwa, adres, NIP, numery rachunków bankowych – wchodzą pod RODO, bo identyfikują osobę.
Zakres i podstawy przetwarzania są podobne jak przy klasycznym kliencie B2C, tylko kontekst jest „firmowy”. To ważne przy segmentacji w systemach marketing automation – etykieta „B2B” nie wyłącza reżimu ochrony danych.
Dane pracowników i kandydatów – najczęstsze nadużycia w firmach
Zakres danych kandydata w rekrutacji
Przy rekrutacji zatrudnienia na podstawie kodeksu pracy minimalny zakres danych wynika wprost z przepisów. Standardowo obejmuje:
imię (imiona) i nazwisko,
datę urodzenia,
dane kontaktowe wskazane przez kandydata (najczęściej e‑mail, telefon),
informacje o wykształceniu, kwalifikacjach, przebiegu dotychczasowego zatrudnienia – jeśli są niezbędne do pracy na danym stanowisku.
Popularne „zestawy rekrutacyjne” zawierają jednak znacznie więcej: zdjęcie, stan cywilny, zainteresowania, linki do social mediów, a czasem nawet numer PESEL. W większości przypadków takie informacje nie są wymagane prawem ani nie są konieczne do oceny kompetencji. Jeśli system rekrutacyjny wymusza ich podanie, trudno mówić o dobrowolnej zgodzie.
„CV na przyszłość” i rekrutacje równoległe
Przechowywanie CV po zakończeniu konkretnej rekrutacji to klasyk. Aby robić to legalnie, trzeba:
wyraźnie rozdzielić cel „obecna rekrutacja” od celu „przyszłe rekrutacje”,
mieć odrębną zgodę na przyszłe procesy (lub dobrze uargumentowany uzasadniony interes przy rekrutacjach B2B, np. kontraktorzy),
określić rozsądny okres przechowywania (np. 6–24 miesięcy, zależnie od rynku i rotacji),
Tip: w systemach ATS (Applicant Tracking System) warto skonfigurować automatyczne alerty lub anonimizację po upływie wskazanego okresu, tak aby „martwe” bazy kandydatów nie rosły bez kontroli.
Dane pracowników – co wynika wprost z prawa
Pracodawca ma szeroki katalog obowiązków ustawowych, które generują dane osobowe. Chodzi m.in. o:
dokumentację pracowniczą (akta osobowe, ewidencja czasu pracy, urlopy),
dane do rozliczeń podatkowych i ZUS (PESEL, adres, dane członków rodziny przy świadczeniach),
badania medycyny pracy, szkolenia BHP,
informacje związane z uprawnieniami rodzicielskimi, niepełnosprawnością – jeśli wpływają na świadczenia i warunki pracy.
W tych obszarach podstawą jest głównie obowiązek prawny. Nie ma sensu ani podstaw prosić o „zgodę na przetwarzanie danych osobowych” – to myląca praktyka.
Monitoring, kontrola służbowej poczty i narzędzia pracy
Coraz więcej firm wdraża monitoring wideo, monitorowanie ruchu sieciowego, narzędzia EDR (Endpoint Detection & Response), systemy śledzące aktywność na komputerach. Wszystko to może prowadzić do intensywnego przetwarzania danych osobowych pracowników.
Jeśli stosujesz monitoring (kamer czy narzędzi IT), potrzebujesz przede wszystkim:
jasno określonego celu (bezpieczeństwo mienia, bezpieczeństwo informacji, kontrola wykorzystania narzędzi służbowych),
podstawy prawnej – najczęściej obowiązek prawny + uzasadniony interes,
wewnętrznych regulacji (np. regulamin pracy, polityka bezpieczeństwa IT) opisujących zakres, miejsca, czas przechowywania nagrań/logów,
transparentnej informacji dla pracowników – klauzula RODO + komunikaty przy wejściu do monitorowanej strefy,
rozsądnych retencji – monitoring wideo raczej tygodnie, a nie lata, o ile nie ma zdarzenia wymagającego zachowania nagrań.
Najczęstszy błąd: „monitoring wszystkiego wszędzie, bez ograniczeń, bo narzędzie to potrafi”. Z perspektywy RODO liczy się to, co faktycznie jest niezbędne do ochrony interesu pracodawcy, a nie pełne wykorzystanie funkcji zakupionego systemu.
Zdjęcia z imprez firmowych, intranet, „ścianki chwały”
Materiały wizerunkowe pracowników (zdjęcia, nagrania z eventów, wypowiedzi do case studies) to kolejny obszar, gdzie nadużywa się „domniemanej zgody”. Jeśli zdjęcie da się powiązać z konkretną osobą, to wizerunek jest daną osobową.
osobna zgoda na wykorzystanie wizerunku w komunikacji wewnętrznej (intranet, newsletter) i zewnętrznej (strona www, social media),
brak negatywnych konsekwencji przy odmowie – zgoda musi być realnie dobrowolna,
możliwość wycofania zgody z rozsądnym okresem na usunięcie materiałów z kanałów, na które masz wpływ (archiwalne posty w mediach społecznościowych bywają trudniejsze, ale nowe publikacje można wstrzymać).
Prywatne urządzenia w pracy (BYOD) i komunikatory
Model BYOD (Bring Your Own Device – prywatne urządzenia do celów służbowych) w praktyce oznacza mieszanie się danych osobowych z dwóch światów: prywatnego i firmowego. Na jednym smartfonie lądują:
służbowe kontakty (klienci, współpracownicy),
historie rozmów i wiadomości z komunikatorów (Teams, Slack, WhatsApp),
pliki z dokumentami, zrzuty ekranu, zdjęcia tablic z warsztatów.
Jeżeli firma dopuszcza BYOD, powinna uregulować to w sposób techniczny i organizacyjny, a nie tylko jednym zdaniem w regulaminie pracy. Praktyczne elementy takiej polityki to m.in.:
stosowanie kontenerów lub profilów służbowych (np. Android Enterprise, MDM na iOS),
oddzielne aplikacje do poczty i plików służbowych,
wyraźne zasady usuwania danych po zakończeniu współpracy (zdalne wipe profilu służbowego zamiast resetu całego telefonu),
zakaz przesyłania dokumentów z danymi osobowymi przez komunikatory prywatne, jeżeli nie są objęte kontrolą bezpieczeństwa.
Przy komunikatorach hybrydowych (np. WhatsApp, Messenger) problemem jest brak kontroli nad retencją i kopiami zapasowymi. Nawet jeśli masz politykę kasowania korespondencji w Outlooku po określonym czasie, to zrzuty ekranu konwersacji w komunikatorze mogą przetrwać latami w pamięci telefonu i chmurze prywatnej użytkownika. Z perspektywy RODO nadal odpowiadasz za te dane, jeśli służą do realizacji celów biznesowych firmy.
Dostęp do danych pracowników przez podmioty zewnętrzne
Coraz więcej procesów HR wychodzi na zewnątrz: outsourcing kadr i płac, zewnętrzne BHP, benefity (karty sportowe, opieka medyczna), platformy kafeteryjne. W każdej z tych relacji pojawia się pytanie, kto jest administratorem, a kto procesorem (podmiotem przetwarzającym).
Typowy błąd to zakładanie, że „dostawca benefitów jest procesorem”, podczas gdy w praktyce prowadzi własną bazę użytkowników, ma autonomię w określaniu celów (np. marketing do użytkowników), a więc działa jako odrębny administrator. W takiej konfiguracji:
firma przekazuje dane pracownika na podstawie określonej podstawy prawnej (zwykle obowiązek prawny lub wykonanie umowy o pracę – gdy benefit jest elementem wynagrodzenia),
dostawca działa jako niezależny administrator i sam odpowiada za spełnienie obowiązków informacyjnych wobec pracownika,
konieczne są przejrzyste postanowienia w umowie regulujące role, zakres danych, cele i obowiązki stron.
Jeżeli natomiast zewnętrzne biuro rachunkowe obsługuje wyłącznie Twoje procesy kadrowo‑płacowe, bez własnej agendy, jest klasycznym procesorem. Wtedy absolutnie kluczowa jest umowa powierzenia (art. 28 RODO) oraz sprawdzenie środków bezpieczeństwa (np. sposób wymiany plików z listami płac, szyfrowanie, kontrola dostępu).
Minimalizacja danych – jak „odchudzić” formularze, umowy i systemy
Formularze kontaktowe i leadowe
Formularze to najczęstsze miejsce, gdzie zasada minimalizacji (art. 5 ust. 1 lit. c RODO) jest łamana z rozpędu. Zestaw pytań rośnie w miarę potrzeb działów marketingu, sprzedaży, HR i product ownerów, aż w efekcie formularz wymaga:
pełnego imienia i nazwiska zamiast samego imienia,
telefonu, choć kontakt jest prowadzony e‑mailem,
szczegółów firmy (NIP, liczba pracowników, branża),
informacji „miękkich” – jak budżet, roczny przychód, liczba oddziałów.
Mechaniczna zasada jest prosta: każde pole trzeba przejść przez filtr „czy bez tego pola nadal mogę zrealizować cel?”. Jeżeli celem jest oddzwonienie na jedno zapytanie ofertowe, PESEL, data urodzenia czy adres zamieszkania są całkowicie zbędne.
Dobrą praktyką jest rozbicie zbieranych danych na warstwy:
Warstwa startowa – minimum do nawiązania kontaktu (np. imię, e‑mail, opcjonalnie firma).
Warstwa kwalifikacyjna – dane potrzebne handlowcowi do oceny potencjału, zbierane dopiero w rozmowie lub w kolejnym kroku (np. wielkość zespołu, zakres projektu).
Warstwa kontraktowa – dane potrzebne do zawarcia i wykonania umowy (pełne dane firmy, NIP, dane reprezentantów).
Takie podejście ułatwia obronienie proporcjonalności zakresu danych w razie kontroli, a przy okazji podnosi konwersję formularzy – mniej pól to zwykle więcej wysłanych zgłoszeń.
Umowy, regulaminy i załączniki
Wzory umów projektują często prawnicy lub działy zakupów według zasady „na każdy scenariusz”, co kończy się zbieraniem danych w nadmiarze. Klasyczne przykłady:
wymaganie PESEL i adresu zamieszkania przy umowach B2B, gdzie stroną jest spółka z KRS,
listy imienne wszystkich członków zespołu po stronie wykonawcy, choć wystarczyłby lider projektu,
dokładne daty urodzenia uczestników szkoleń, mimo że do certyfikatów potrzebne są tylko imię i nazwisko.
Przy przeglądzie wzorów umów warto zadać kilka precyzyjnych pytań:
czy dana informacja jest wymagana jakimkolwiek przepisem (np. podatkowym, rachunkowym, branżowym),
czy bez tej informacji umowa nie może zostać prawidłowo wykonana,
czy identyczny efekt da się osiągnąć, używając mniej szczegółowej danej (np. ID pracownika zamiast imienia i nazwiska w raportach wydajności).
Jeżeli okazuje się, że numer dokumentu tożsamości lub PESEL jest zbierany „na wszelki wypadek”, jest to sygnał do wycięcia lub przynajmniej ograniczenia takiego wymagania do specyficznych przypadków (np. przy weryfikacji tożsamości w branżach regulowanych).
Minimalizacja w systemach IT – perspektywa architektury danych
Minimalizacja to nie tylko formularze. Równie ważne jest to, jakie dane trafiają do poszczególnych systemów i integracji. Typowy scenariusz w rosnącej firmie:
CRM zbiera możliwie pełny profil klienta,
integracja przesyła te same dane do narzędzia mailingowego, systemu helpdesk, platformy e‑learningowej,
po kilku latach w pięciu różnych systemach leżą te same dane, w tym dane nieaktualne.
Z punktu widzenia RODO każdy system to osobny „magazyn ryzyka”. Im więcej zbędnych pól krąży po integracjach, tym trudniej panujesz nad retencją i realizacją praw osób (np. prawa do usunięcia lub sprostowania).
Praktyczna metoda to mapowanie atrybutów danych i świadome „obcinanie” integracji:
definiujesz schemat danych w systemie źródłowym (np. CRM) – jakie pola istnieją,
dla każdej integracji określasz minimalny podzbiór pól, który jest faktycznie potrzebny w systemie docelowym (np. do wysyłki newslettera wystarczy e‑mail, imię i tagi zgód marketingowych),
realizujesz synchronizację selektywną zamiast „pełnego eksportu wszystkiego”.
Tip: w dokumentacji integracji i w rejestrze czynności przetwarzania opłaca się zapisywać, jakie kategorie danych są przesyłane pomiędzy systemami. Ułatwia to zarówno audyt techniczny, jak i późniejsze odpowiedzi na wnioski osób, których dane dotyczą.
Retencja i automatyczne usuwanie danych
Minimalizacja dotyczy również czasu przechowywania. Dane „na zawsze” to prosta droga do problemów. W realnych projektach najwięcej pracy idzie nie w samo zdefiniowanie okresów retencji, ale w ich egzekwowanie w systemach.
Podstawowe kroki to:
podział danych na kategorie (np. dane sprzedażowe, marketingowe, serwis posprzedażowy, dane HR),
ustalenie okresów retencji dla każdej kategorii, uwzględniając obowiązki prawne (np. 5 lat podatkowo‑księgowe, 10 lat dla akt osobowych),
wdrożenie mechanizmów automatycznego usuwania lub anonimizacji po upływie okresu (np. joby w bazie danych, reguły w CRM/ATS),
logowanie operacji usunięcia, aby móc wykazać rozliczalność.
Anonimizacja bywa dobrą alternatywą, kiedy chcesz zachować dane statystyczne, ale nie potrzebujesz już identyfikowalnych osób. Ważne, aby była nieodwracalna w sensie technicznym (np. trwałe usunięcie identyfikatorów, hashowanie, które nie pozwala na reidentyfikację w praktyce).
Minimalizacja a analityka i machine learning
Działy produktowe i marketing często chcą „trzymać wszystko”, bo dane mogą się przydać do modeli predykcyjnych, personalizacji czy analizy kohortowej. Z RODO da się to pogodzić, jeśli zmieni się paradygmat z „zbierajmy wszystko” na „projektujmy dane pod konkretny use case”.
Przykład praktyczny: zamiast przechowywać pełną historię pojedynczych interakcji użytkownika w systemie billingowym w nieskończoność, można:
zachować agregaty (liczba transakcji w miesiącu, średnia wartość koszyka),
oddzielić dane identyfikacyjne od danych behawioralnych (pseudonimizacja),
określić maksymalny horyzont czasowy dla analiz (np. 24 miesiące historii, a starsze dane anonimizować).
Jeżeli powstają modele ML, które wpływają na decyzje wobec konkretnych osób (np. scoring leadów, ryzyko churnu, propozycje cen), trzeba dołożyć jeszcze wymogi z art. 22 RODO (zautomatyzowane podejmowanie decyzji) i przejrzystość zasad. Z perspektywy minimalizacji chodzi głównie o to, aby model nie był „karmiony” danymi, które są nadmiarowe wobec celu (np. dokładna lokalizacja GPS, kiedy wystarczyłby poziom miasta).
Przeglądy danych i „spring cleaning” w praktyce
Nawet najlepsze zasady minimalizacji z czasem się rozjeżdżają. Biznes się zmienia, systemy ewoluują, ludzie dorzucają nowe pola i raporty. Dlatego przydaje się cykliczny „spring cleaning” danych – niekoniecznie coroczny, ale na tyle regularny, by nie utonąć w bałaganie.
Efektywny przegląd obejmuje kilka kroków:
Inwentaryzacja – lista systemów, arkuszy, baz „shadow IT” (prywatne Excelle, Google Sheets z danymi klientów).
Ocena przydatności – które zbiory danych są aktywnie używane, a które są „zapasem historycznym”.
Decyzje – czy zbiór zostaje, jest migrowany, archiwizowany czy usuwany.
Uwaga: często najbardziej ryzykowne są małe, lokalne zbiory danych – foldery na pulpitach, eksporty CSV pobrane z CRM i wrzucone do wspólnych dysków, pliki z backupami na prywatnych nośnikach. To one wymykają się formalnym regułom retencji, a zawierają pełne zestawy danych osobowych.
Minimalizacja uprawnień zamiast „wszyscy mają wszystko”
RODO dotyczy nie tylko tego, jakie dane trzymasz, ale też kto ma do nich dostęp. W wielu firmach dostęp do systemów rośnie warstwowo – nowym osobom daje się „profil jak poprzednik”, bez głębszej refleksji, czy rzeczywiście potrzebują wglądu w całą bazę klientów lub pełne dane HR.
Zasada minimalizacji przekłada się tutaj na:
model uprawnień oparty na rolach (RBAC – Role Based Access Control),
separację danych wrażliwszych (np. dane zdrowotne, informacje o niepełnosprawności, wynagrodzenia) w osobnych modułach,
okresowe przeglądy uprawnień – czy dana osoba nadal potrzebuje dostępu do konkretnego systemu i zakresu danych.
Dobrym testem jest proste pytanie zadane menedżerom: „czy ten zespół jest w stanie wykonywać swoje obowiązki, jeśli zobaczy tylko X zamiast pełnego zestawu danych?”. Jeśli odpowiedź brzmi „tak”, znaczy, że dotychczasowy zakres dostępu był zbyt szeroki.
Najczęściej zadawane pytania (FAQ)
Jakie dane osobowe mogę legalnie przetwarzać w codziennej działalności firmy?
Możesz przetwarzać tylko takie dane, które są niezbędne do konkretnego celu i mają jasną podstawę prawną (np. umowa, obowiązek prawny, uzasadniony interes, zgoda). W praktyce będą to zwykle: imię i nazwisko, dane kontaktowe (e‑mail, telefon), adresy (zamieszkania, dostawy, rozliczeniowy), numery identyfikacyjne (PESEL, NIP osoby fizycznej), dane płatnicze i numer rachunku bankowego.
Do tego dochodzą dane wynikające z używanych narzędzi: identyfikatory klienta w CRM, dane z logów systemowych (adres IP, identyfikator urządzenia), a nawet nagrania z monitoringu czy wideokonferencji, jeśli umożliwiają rozpoznanie osoby. Każdą kategorię danych trzeba powiązać z konkretnym celem i podstawą z art. 6 RODO.
Czy służbowy e‑mail i telefon pracownika podlegają RODO?
Tak. Adres typu imie.nazwisko@firma.pl oraz służbowy numer telefonu są danymi osobowymi, jeśli pozwalają zidentyfikować konkretną osobę. To, że są „firmowe”, nie wyłącza ich spod RODO.
Tip: w politykach i rejestrach czynności przetwarzania warto osobno wykazać dane kontaktowe pracowników i przedstawicieli kontrahentów – zwykle przetwarzasz je na podstawie uzasadnionego interesu (komunikacja biznesowa, obsługa umów), a nie zgody.
Co jest różnicą między danymi zwykłymi a wrażliwymi w firmie?
Dane zwykłe to m.in. imię, nazwisko, dane kontaktowe, informacje o zamówieniach, historia współpracy. Dane wrażliwe (szczególne kategorie) to np. dane o zdrowiu, pochodzeniu rasowym lub etnicznym, przekonaniach religijnych, przynależności do związków zawodowych, a także dane biometryczne i dotyczące seksualności.
W firmie dane wrażliwe pojawiają się najczęściej przy kadrach i bezpieczeństwie (zwolnienia lekarskie, orzeczenia o niepełnosprawności, dane z czytników linii papilarnych). Dla tej kategorii wymagane są: ograniczony zestaw podstaw prawnych, wyższy poziom zabezpieczeń i precyzyjne ograniczenie dostępu (np. tylko dział HR, tylko administrator systemu kontroli dostępu).
Czy adres IP i cookies na stronie firmy to dane osobowe wg RODO?
Adres IP, identyfikatory cookies i identyfikatory urządzeń są danymi osobowymi, jeśli w konkretnym kontekście możesz powiązać je z konkretnym użytkownikiem. Przykład: jeśli system analityczny lub CRM pozwala „skleić” cookie z kontem zalogowanego klienta, to pracujesz na danych osobowych.
Jeżeli dane są zbierane w sposób, który nie pozwala w praktyce wrócić do konkretnej osoby (i nie masz innych danych, by to powiązać), można zbliżać się do anonimizacji. W większości typowych konfiguracji marketingowych (Google Analytics, piksele reklamowe, systemy marketing automation) mamy jednak do czynienia co najmniej z pseudonimizacją, więc RODO obowiązuje.
Na jakiej podstawie prawnej mogę prowadzić marketing do klientów?
Wobec własnych klientów (osób, które kupiły produkt/usługę) często można oprzeć marketing bezpośredni na uzasadnionym interesie administratora (art. 6 ust. 1 lit. f RODO), przy jednoczesnym respektowaniu przepisów szczególnych, np. zgody na e‑mail/SMS z ustawy o świadczeniu usług drogą elektroniczną i Prawa telekomunikacyjnego.
Wobec osób, które nie są klientami, klasycznym modelem jest zgoda (art. 6 ust. 1 lit. a RODO) udzielona np. w formularzu zapisu na newsletter. Zgoda musi być dobrowolna, konkretna i możliwa do wycofania jednym kliknięciem. Uwaga: checkbox „akceptuję regulamin” nie zastępuje odrębnej zgody marketingowej.
Jak odróżnić anonimizację od pseudonimizacji danych w firmie?
Anonimizacja oznacza taki proces przetworzenia, po którym nie da się już zidentyfikować osoby przy użyciu rozsądnie dostępnych środków. Jeżeli nie masz żadnego klucza, słownika ani zewnętrznego źródła, które pozwoli „odwrócić” proces, dane wypadają spod RODO.
Pseudonimizacja to zastąpienie bezpośrednich identyfikatorów (np. imienia, nazwiska) identyfikatorem technicznym, przy zachowaniu możliwości powrotu do konkretnej osoby – np. „Klient_1234”, gdy w innym systemie istnieje mapa: „Klient_1234 = Jan Kowalski”. Taki zbiór pozostaje zbiorem danych osobowych, tyle że o niższym ryzyku. Typowy przypadek: eksport danych sprzedaży z systemu transakcyjnego do hurtowni danych z zachowaniem numeru klienta.
Czy RODO dotyczy też danych kontaktowych osób z firm B2B?
Tak. RODO nie obejmuje osób prawnych (np. spółek), ale obejmuje osoby fizyczne działające w ich imieniu. Dane takie jak imię i nazwisko handlowca, e‑mail służbowy, telefon komórkowy przypisany do konkretnej osoby w firmie B2B są danymi osobowymi.
Najczęściej przetwarzasz je na podstawie uzasadnionego interesu administratora – utrzymanie relacji biznesowej, negocjacje i realizacja umowy, bieżąca komunikacja. Dobrą praktyką jest poinformowanie takich osób (np. w pierwszym mailu lub w stopce) o tym, kto jest administratorem, w jakim celu i w oparciu o jaki interes przetwarza ich dane oraz jak mogą zgłosić sprzeciw.
Najważniejsze punkty
Dane osobowe w firmie to nie tylko „oczywiste” imię i nazwisko, ale każda informacja pozwalająca zidentyfikować osobę bezpośrednio lub pośrednio (np. numer klienta połączony z e‑mailem, numer rejestracyjny auta spięty w systemie z konkretnym kierowcą).
Adres e‑mail i telefon służbowy, jeśli są przypisane do konkretnego pracownika (np. imie.nazwisko@firma.pl), są pełnoprawnymi danymi osobowymi i podlegają reżimowi RODO tak samo jak dane „prywatne”.
„Zwykłe” dane (imię, nazwisko, adres, dane zamówienia) są mniej wrażliwe niż szczególne kategorie danych (zdrowie, biometrii, poglądy, związki zawodowe), które wymagają mocniejszych podstaw prawnych, wyższego poziomu bezpieczeństwa i często osobnego traktowania w systemach.
Anonimizacja to nieodwracalne odcięcie możliwości identyfikacji osoby (RODO przestaje mieć zastosowanie), natomiast pseudonimizacja (np. „Użytkownik 1234” zamiast nazwiska) nadal oznacza dane osobowe, jeśli organizacja ma klucz do ich „odkodowania”.
RODO obejmuje dane wszystkich osób fizycznych, z którymi firma ma styczność: klientów B2C i kontaktowych B2B, leadów z formularzy, pracowników, podwykonawców, kandydatów do pracy oraz jednoosobowych działalności i wspólników spółek osobowych.
Ta sama informacja (np. adres IP, lokalizacja GPS, identyfikator urządzenia) staje się daną osobową w momencie, gdy w konkretnym kontekście da się ją powiązać z konkretną osobą – decyduje sposób użycia, a nie sam typ danych.
