Deweloper trzyma o kupujących wyjątkowo dużo danych osobowych: imię, PESEL, adres, dane kontaktowe, informacje o zdolności kredytowej i podpisane umowy. A często wszystko to leży w arkuszu na prywatnym dysku handlowca.
Bezpieczeństwo danych w CRM dla dewelopera działa na dwóch poziomach: prawnym (RODO — podstawa przetwarzania, minimalizacja, retencja, kontrola dostępu) i technicznym (szyfrowanie, uprawnienia, kopie zapasowe, ślad audytowy). Jedno i drugie ma ten sam cel: żeby dane kupującego nie wyciekły i żeby w razie kontroli dało się pokazać, kto, kiedy i na jakiej podstawie z nich korzystał.
Ten materiał ma charakter informacyjny i nie jest poradą prawną. Konkretny zakres obowiązków RODO w Twojej firmie warto potwierdzić z inspektorem ochrony danych (IOD) lub prawnikiem.
Z praktyki HauerPower
Budujemy dedykowane systemy sprzedaży dla deweloperów (m.in. dla Wola Village, Grupa URBA). Kontrolę dostępu projektujemy zwykle per rola: handlowiec pracuje na swoich leadach, a dane finansowe czy pełną bazę kupujących widzi tylko ten, kto musi. Powód jest bardzo praktyczny: największy wyciek u dewelopera zwykle przychodzi od środka. Dlatego u klientów pierwsze, co zamykamy, to zwykle nie szyfrowanie bazy, lecz swobodny eksport całej bazy do Excela z poziomu handlowca — bo tamtędy wychodzi najwięcej.
Każda warstwa domyka poprzednią: prawo mówi, co wolno; technika to egzekwuje; dostęp ogranicza, kto widzi; audyt pokazuje, kto co zrobił.
Jakie dane kupujących trzymasz
Zanim zabezpieczysz dane, warto zobaczyć, ile ich naprawdę jest. W procesie sprzedaży mieszkania deweloper gromadzi:
| Kategoria danych | Przykłady | Wrażliwość |
|---|---|---|
| Dane identyfikujące | imię, nazwisko, PESEL, seria dowodu | wysoka |
| Dane kontaktowe | telefon, e-mail, adres | średnia |
| Dane finansowe | zdolność kredytowa, źródło finansowania | wysoka |
| Dokumenty | umowy rezerwacyjne i deweloperskie | wysoka |
| Dane niedoszłych kupujących | leady, które nie kupiły | często zapominana |
Skala szybko robi się poważna: wyobraź sobie 200 lokali i sześciu handlowców — to kilkaset rekordów z imieniem, PESEL i danymi kontaktowymi krążących w mailach, arkuszach i na prywatnych dyskach. Ostatni wiersz tabeli jest przy tym najczęściej pomijany: dane osoby, która tylko pytała o mieszkanie, też podlegają RODO, a zwykle zalegają latami bez żadnej podstawy.
Co grozi przy wycieku
Ryzyko ma trzy wymiary:
- Kary administracyjne. RODO przewiduje wysokie kary za naruszenia; ich wysokość zależy od skali i charakteru naruszenia, ale sama procedura po incydencie jest kosztowna niezależnie od kary.
- Utrata zaufania. Zakup mieszkania to decyzja oparta na zaufaniu; informacja, że deweloper zgubił dane klientów, potrafi zaszkodzić bardziej niż niejedna kampania.
- Roszczenia osób. Poszkodowani mogą dochodzić odszkodowania, a organ może nałożyć obowiązki naprawcze i kontrole.
Warto zauważyć, że najczęstsze naruszenie ma bardzo prozaiczną postać: zgubiony laptop, plik na prywatnym dysku albo dostęp, którego ktoś nie powinien mieć.
Obowiązki RODO w systemie
Z perspektywy systemu sprzedaży cztery obowiązki są najważniejsze:
- Podstawa przetwarzania — każde dane trzeba przetwarzać na podstawie z RODO (np. wykonanie umowy, zgoda, uzasadniony interes); zbieranie „na wszelki wypadek" nie jest podstawą.
- Minimalizacja — zbierasz tylko to, co potrzebne do sprzedaży, a nie wszystko, co klient poda.
- Retencja — dane niedoszłych kupujących mają termin przydatności; trzymanie ich „na zawsze" jest naruszeniem, dlatego system powinien wspierać usuwanie i archiwizację.
- Umowa powierzenia — jeśli system prowadzi lub hostuje wykonawca, potrzebna jest umowa powierzenia przetwarzania (art. 28 RODO) oraz kontrola, gdzie fizycznie leżą dane.
Ogólny kontekst ochrony danych firmowych i ryzyk AI (np. wysyłanie danych do publicznych modeli) rozkładamy osobno w bezpieczeństwie danych firmowych a AI. Tutaj skupiamy się na tym, co specyficzne dla sprzedaży mieszkań: danych kupujących, umowach i rolach w zespole.
Zabezpieczenia techniczne
Warstwa prawna działa tylko wtedy, gdy stoi za nią technika. Minimum, którego oczekujemy od systemu sprzedaży dla dewelopera:
| Zabezpieczenie | Po co |
|---|---|
| Szyfrowanie danych | przechwycony plik czy dysk pozostaje bezużyteczny |
| Kontrola dostępu (role i uprawnienia) | każdy widzi tylko to, co musi |
| Ślad audytowy | wiadomo, kto i kiedy otworzył lub zmienił dane |
| Kopie zapasowe | awaria albo błąd nie kasuje bazy klientów |
| Wygaszanie dostępów | konto odchodzącego pracownika traci dostęp tego samego dnia (w arkuszu plik zostaje z nim) |
| Aktualizacje i łatanie | znane luki nie zostają otwarte na miesiące |
To jest właśnie różnica między danymi w arkuszu a danymi w systemie: arkusz nie ma żadnej z tych warstw. Kiedy Excel realnie przestaje wystarczać, rozkładamy w CRM vs Excel dla dewelopera.
Kontrola dostępu: kto widzi i zmienia co
To najbardziej niedoceniana część bezpieczeństwa u dewelopera, a zarazem najprostsza do wdrożenia. Chodzi o to, żeby dostęp do danych i prawo ich zmiany zależały od roli:
| Rola | Co widzi | Co może zmienić |
|---|---|---|
| Handlowiec | swoje leady i lokale | status swoich leadów |
| Kierownik sprzedaży | zespół i wszystkie leady | przydział, priorytety |
| Zarząd | raporty i pełny obraz | zwykle nic operacyjnie |
| Księgowość | dane do rozliczeń | dane finansowe, nie sprzedażowe |
Decyzja projektowa: cenę i status lokalu zmienia rola, nie każdy
Prawo zmiany ceny i dostępności lokalu projektujemy tak, by należało do wskazanych ról, a każdą zmianę rekomendujemy zapisywać w śladzie audytowym. Powód jest podwójny: to zabezpieczenie danych (widać, kto zmienił) i zabezpieczenie sprzedaży (nikt przypadkiem nie „poprawi" ceny widocznej dla klienta). Ta sama zasada stoi za tym, że asystent AI dostaje status lokalu tylko do odczytu.
Decyzja projektowa: retencję egzekwuje system, a nie procedura w Wordzie
Termin usunięcia danych leada, który nie kupił, rekomendujemy wpiąć jako funkcję systemu — przypomnienie plus łatwe usunięcie po zatwierdzeniu — a nie zostawiać jako zapis w polityce na dysku. Polityka retencji na papierze zwykle nie jest wykonywana; system pilnuje tego, o czym człowiek zapomina, a samo usunięcie zostawiamy do potwierdzenia przez człowieka.
Najkosztowniejszy wyciek u dewelopera to zwykle odchodzący handlowiec, który wynosi w kieszeni pełny eksport bazy klientów. Dlatego bezpieczeństwo zaczyna się od ról i śladu audytowego, nie od zapory.
— Mateusz Hauer, HauerPower
Czego lepiej nie robić
Bezpieczeństwo to też świadome „nie". Uczciwe zasady, które rekomendujemy:
- Nie zbieraj PESEL ani skanu dowodu na etapie leada — dopiero gdy jest ku temu podstawa (umowa). Minimalizacja to również zabezpieczenie.
- Nie dawaj zarządowi dostępu operacyjnego „bo prezes" — raporty tak, prawo edycji danych klientów nie.
- Nie automatyzuj kasowania danych bez człowieka — system proponuje usunięcie po terminie, decyzję zatwierdza osoba.
- Nie trzymaj danych „na wszelki wypadek" — im mniej danych przechowujesz bez celu, tym mniej masz do ochrony.
Dane są dobrze zabezpieczone, jeśli:
- dostęp jest przypisany do roli, a pełną bazę widzi tylko ten, kto musi,
- każda zmiana ceny i statusu zostaje w śladzie audytowym,
- retencję wymusza system automatycznie, po ustalonym terminie,
- z wykonawcą systemu jest podpisana umowa powierzenia,
- kopie zapasowe są regularnie testowane i odtwarzalne.
Najczęstsze błędy
- Dane kupujących w arkuszu na prywatnym dysku — bez kontroli dostępu, backupu i śladu, kto je otwierał.
- „Wszyscy widzą wszystko" — brak ról sprawia, że każdy handlowiec ma pełną bazę klientów, którą może wynieść.
- Brak umowy powierzenia — korzystanie z zewnętrznego narzędzia bez umowy i kontroli miejsca przetwarzania.
- Trzymanie danych „na zawsze" — leady sprzed lat bez podstawy i bez terminu usunięcia.
- Bezpieczeństwo „na później" — zostawione na koniec wdrożenia, czyli w praktyce nigdy.
Nie masz pewności, gdzie leżą dane Twoich kupujących?
Na bezpłatnej 30-minutowej konsultacji przejdziemy, jakie dane zbierasz w sprzedaży mieszkań i gdzie dziś są najsłabiej chronione — od arkuszy na prywatnych dyskach po dostępy, których nikt nie odbiera po odejściu handlowca.
Umów bezpłatną konsultację → Zobacz CRM dla deweloperaFAQ
Czy CRM dla dewelopera musi być zgodny z RODO?
Tak. Deweloper przetwarza dane osobowe kupujących (imię, PESEL, dane kontaktowe i finansowe), więc system, w którym te dane trzyma, podlega RODO. Oznacza to obowiązek podstawy przetwarzania, minimalizacji, retencji, kontroli dostępu i odpowiednich zabezpieczeń technicznych. Szczegółowy zakres warto potwierdzić z IOD lub prawnikiem.
Jak długo można trzymać dane niedoszłych kupujących?
Tylko tak długo, jak jest ku temu podstawa i cel. Dane osoby, która pytała o mieszkanie i nie kupiła, nie mogą być trzymane „na zawsze"; po ustaniu celu należy je usunąć lub zanonimizować. Konkretny termin zależy od podstawy przetwarzania, dlatego warto ustalić politykę retencji z prawnikiem i wesprzeć ją funkcją usuwania w systemie.
Kto w firmie deweloperskiej powinien mieć dostęp do danych klientów?
Tylko osoby, które muszą, i tylko do zakresu, który jest im potrzebny. Handlowiec pracuje na swoich leadach, kierownik widzi zespół, księgowość dane do rozliczeń, a zarząd raporty. Model „wszyscy widzą wszystko" to najczęstsza przyczyna wycieku od środka, dlatego dostęp warto oprzeć na rolach i uprawnieniach.
Czy dane w chmurze są bezpieczne dla dewelopera?
Mogą być, jeśli dostawca zapewnia odpowiednie zabezpieczenia, jest zawarta umowa powierzenia i wiadomo, gdzie fizycznie leżą dane (istotne przy przetwarzaniu poza EOG). Chmura sama w sobie nie jest ani bezpieczna, ani niebezpieczna — decyduje konfiguracja, umowy i kontrola dostępu.
Czy potrzebna jest umowa powierzenia z wykonawcą systemu?
Jeśli wykonawca prowadzi, hostuje lub ma dostęp do systemu z danymi kupujących, to zwykle tak — RODO wymaga umowy powierzenia przetwarzania (art. 28). Warto też ustalić, gdzie dane są przechowywane i kto po stronie wykonawcy ma do nich dostęp.
Czy wystarczy hasło na pliku Excel albo firmowy dysk z hasłem?
Nie na poziomie systemu. Hasło na pliku chroni przed przypadkowym otwarciem, ale nie daje kontroli dostępu per rola, śladu audytowego, kopii zapasowych ani wymuszania retencji. Taki plik nadal można skopiować, wynieść i trzymać latami, a po odejściu pracownika zostaje on na jego dysku. To zabezpieczenie pojedynczego pliku, nie danych całej sprzedaży.
Co grozi deweloperowi za wyciek danych kupujących?
RODO przewiduje wysokie kary administracyjne, których wysokość zależy od skali i charakteru naruszenia. Do tego dochodzą koszty obsługi incydentu, możliwe roszczenia osób i utrata zaufania na rynku. Dlatego bezpieczeństwo traktuje się jak fundament systemu sprzedaży.
Powiązane przewodniki
- CRM vs Excel dla dewelopera (arkusz nie ma tych warstw)
- Jak wdrożyć CRM u dewelopera
- CRM vs ERP dla dewelopera
- AI dla deweloperów (dane kupujących a AI)
- Bezpieczeństwo danych firmowych a AI (ogólny kontekst)
- CRM dla deweloperów
Podsumowanie
Bezpieczeństwo danych kupujących to nie techniczny dodatek, lecz warunek prowadzenia sprzedaży mieszkań — bo deweloper trzyma dane, których wyciek kosztuje i pieniądze, i zaufanie. Zadbaj o dwie warstwy naraz: prawną (podstawa, minimalizacja, retencja, umowa powierzenia) i techniczną (szyfrowanie, role, backup, ślad audytowy), a dostęp oprzyj na zasadzie „tylko to, co musisz widzieć". Jak wygląda dopasowany system w praktyce, pokazujemy w przewodniku o automatyzacji sprzedaży mieszkań. Zakres obowiązków RODO potwierdź z IOD lub prawnikiem — to nie porada prawna, lecz mapa, od czego zacząć.
