KOMPAS FORSAFE 2026/46

Podstawa prawna naruszenia

Art. 5, art. 6, art. 13, art. 25, art. 28, art. 32, art. 35 RODO.

Nieprzestrzeganie ogólnych zasad przetwarzania danych.

Przyczyna naruszenia

Naruszenie wynikało z wdrożenia systemu antyfraudowego umożliwiającego pozyskiwanie informacji o aplikacjach zainstalowanych i uruchomionych na urządzeniach użytkowników bez wykazania, że tak szeroki zakres danych był rzeczywiście niezbędny do zapewnienia bezpieczeństwa transakcji. Administrator błędnie uznał, że obowiązki wynikające z regulacji dotyczących usług płatniczych stanowią wystarczającą podstawę prawną dla takiego przetwarzania, nie przeprowadzając jednocześnie odpowiedniej oceny skutków dla ochrony danych oraz analizy mniej ingerujących rozwiązań.

Opis wydarzeń

Wpłynięcie licznych skarg użytkowników aplikacji mobilnych: Sprawa rozpoczęła się wiosną 2024 roku, kiedy do włoskiego organu nadzorczego zaczęły napływać skargi i zgłoszenia od użytkowników aplikacji BancoPosta oraz PostePay działających na systemie Android. Klienci wskazywali, że po aktualizacji aplikacji otrzymywali komunikaty wymagające przyznania aplikacji dostępu do danych użytkowania urządzenia. Jednocześnie informowano ich, że brak zgody doprowadzi do ograniczenia funkcjonalności aplikacji i zablokowania możliwości korzystania z usług po wykonaniu określonej liczby logowań.
Wdrożenie nowego rozwiązania antyfraudowego ThreatMetrix: Poste Italiane oraz PostePay wdrożyły komponent ThreatMetrix stanowiący element platformy antyfraudowej. Mechanizm miał służyć identyfikacji zagrożeń związanych z oprogramowaniem złośliwym oraz oceną wiarygodności urządzenia wykorzystywanego do realizacji operacji finansowych. Rozwiązanie analizowało szereg informacji technicznych dotyczących urządzenia oraz (w określonej konfiguracji) pozyskiwało informacje o aplikacjach zainstalowanych lub uruchomionych na urządzeniu użytkownika.
Uzależnienie korzystania z aplikacji od przyznania dostępu do danych użytkowania urządzenia: Klienci byli proszeni o aktywowanie specjalnego uprawnienia systemowego Android pozwalającego na dostęp do danych użycia urządzenia. Organizacja argumentowała, że było to technicznie niezbędne do działania mechanizmów wykrywania złośliwego oprogramowania. Włoski organ nadzorczy uznał jednak, że praktyczne uzależnienie korzystania z aplikacji od aktywacji tego uprawnienia powodowało sytuację, w której użytkownik nie miał realnej swobody wyboru.
Pozyskiwanie danych dotyczących aplikacji zainstalowanych na urządzeniu: Mechanizm ThreatMetrix analizował aplikacje znajdujące się na urządzeniu użytkownika oraz aplikacje aktualnie uruchomione. Administrator twierdził, że przetwarzane są jedynie skróty kryptograficzne identyfikujące aplikacje, a nie ich nazwy. Włoski organ nadzorczy wykazał jednak, że takie skróty mogą zostać powiązane z konkretnymi aplikacjami oraz pozwalają na ustalenie rodzaju wykorzystywanego oprogramowania.
Możliwość ujawniania szczególnie wrażliwych informacji o użytkownikach: W toku postępowania podkreślono, że lista aplikacji zainstalowanych na smartfonie może pośrednio ujawniać szeroki zakres informacji o osobie fizycznej. Może wskazywać stan zdrowia, zainteresowania, poglądy polityczne, przekonania religijne, orientację życiową, sytuację finansową czy korzystanie z określonych usług medycznych. Tym samym pozyskiwanie takich danych stanowi znaczącą ingerencję w prywatność użytkownika.
Przeprowadzenie kontroli i analiz technicznych przez organ nadzorczy: W ramach postępowania włoski organ nadzorczy przeprowadził szczegółowe działania wyjaśniające oraz kontrolne. Zweryfikowano sposób działania aplikacji, przepływy danych oraz konfigurację wykorzystywanych narzędzi. Sprawdzenie wykazało, że rozwiązanie było bardziej inwazyjne niż wynikało to z przekazywanych użytkownikom informacji oraz że dostępne były mniej ingerujące alternatywy.
Brak wykazania konieczności stosowania najbardziej inwazyjnej konfiguracji systemu: W trakcie postępowania administrator utrzymywał, że rozwiązanie było konieczne do realizacji wymogów PSD2 i ochrony klientów przed oszustwami. Organ przypomniał jednak, że regulacje sektorowe nie wskazują wprost obowiązku pozyskiwania informacji o aplikacjach zainstalowanych na urządzeniu. W ocenie włoskiego organu nadzorczego organizacja powinna była wykazać, że nie istnieją inne skuteczne i mniej ingerujące środki ochrony. Takiego wykazania nie przedstawiono.
Stwierdzenie braku odpowiedniej podstawy prawnej przetwarzania: Po przeanalizowaniu argumentacji administratora włoski organ nadzorczy uznał, że powołanie się na obowiązek prawny nie było zasadne. Przepisy PSD2 nakładają obowiązek zapewnienia bezpieczeństwa transakcji, lecz nie określają konkretnych operacji przetwarzania danych realizowanych przez ThreatMetrix. Tym samym administrator nie posiadał adekwatnej podstawy prawnej dla analizowanych operacji.
Brak przeprowadzenia odrębnej oceny skutków dla ochrony danych: Włoski organ nadzorczy stwierdził, że wcześniejsze analizy ryzyka oraz dokumenty dotyczące platformy antyfraudowej nie obejmowały nowych kategorii danych oraz nowego poziomu ingerencji wynikającego z monitorowania aplikacji użytkowników. W efekcie organizacja nie zidentyfikowała wszystkich zagrożeń oraz nie przeprowadziła prawidłowej analizy proporcjonalności przetwarzania.
Niepełna realizacja obowiązków informacyjnych: Przeanalizowane klauzule informacyjne nie wskazywały jasno, że aplikacje pozyskują informacje o innych aplikacjach znajdujących się na urządzeniu użytkownika. Brakowało również szczegółowego opisu celu, zakresu i sposobu przetwarzania danych związanych z działaniem mechanizmów ThreatMetrix. Użytkownicy nie mogli więc w pełni przewidzieć rzeczywistego zakresu operacji prowadzonych na ich danych.
Nieprawidłowości w relacjach z podmiotami przetwarzającymi: Kontrola wykazała również uchybienia dotyczące umów powierzenia przetwarzania. Włoski organ nadzorczy zwrócił uwagę na niepełne określenie ról uczestników procesu oraz niedostateczne udokumentowanie wykorzystania podwykonawców. Nie zapewniono pełnej przejrzystości łańcucha przetwarzania danych.
Naruszenie zasady ograniczenia przechowywania danych: W toku postępowania ustalono, że dane wykorzystywane przez rozwiązanie ThreatMetrix przechowywane były przez 28 miesięcy, mimo że wcześniej wskazywano krótszy okres retencji. Administrator argumentował, że dodatkowy okres był potrzebny do analiz statystycznych. Włoski organ nadzorczy uznał jednak, że nie przedstawiono wystarczającego uzasadnienia dla takiego wydłużenia przechowywania danych.
Ocena końcowa organu nadzorczego: Włoski organ nadzorczy uznał, że doszło do szeregu naruszeń RODO i przepisów ePrivacy obejmujących m.in. brak prawidłowej podstawy prawnej, naruszenie wymogu przejrzystości, niewłaściwe stosowanie zasad privacy by design, brak odpowiedniej oceny skutków dla ochrony danych, nieprawidłowości w obszarze powierzenia przetwarzania oraz naruszenie zasad ograniczenia przechowywania danych. W rezultacie nakazano zaprzestanie przetwarzania danych dotyczących aplikacji zainstalowanych i uruchomionych na urządzeniach użytkowników oraz zobowiązano spółki do dostosowania procesów do wymagań prawa ochrony danych. Na administratora nałożono również karę w wysokości 5 877 000 EUR.

Źródło

Pełna treść decyzji organu nadzorczego

Aby uniknąć podobnych naruszeń, zalecamy:

Przeprowadzanie szczegółowej oceny konieczności przetwarzania danych przed wdrożeniem nowych technologii: Administratorzy powinni każdorazowo analizować, czy konkretna kategoria danych jest rzeczywiście niezbędna do realizacji celu przetwarzania. Sam fakt, że dane mogą zwiększyć skuteczność działania systemu bezpieczeństwa, nie oznacza automatycznie, że ich pozyskiwanie jest zgodne z zasadą minimalizacji. W szczególności należy dokumentować analizę alternatywnych rozwiązań technicznych i organizacyjnych.
Prawidłowe ustalanie podstaw prawnych przetwarzania: Przed wdrożeniem mechanizmów antyfraudowych należy precyzyjnie określić właściwą podstawę prawną przetwarzania danych. Niedopuszczalne jest automatyczne uznawanie, że każdy środek bezpieczeństwa jest objęty obowiązkiem prawnym wynikającym z regulacji sektorowych. Jeżeli administrator korzysta z prawnie uzasadnionego interesu, powinien przeprowadzić pełny test równowagi interesów i odpowiednio go udokumentować.
Uwzględnianie zasad privacy by design i privacy by default od początku projektu: Systemy bezpieczeństwa powinny być projektowane w taki sposób, aby standardowo wykorzystywały możliwie najmniejszy zakres danych osobowych. Każde rozszerzenie funkcjonalności powinno być poprzedzone oceną wpływu na prywatność użytkowników oraz analizą możliwości osiągnięcia tego samego celu przy wykorzystaniu mniej ingerujących mechanizmów.
Realizacja kompleksowych ocen skutków dla ochrony danych: W przypadku wdrażania nowych technologii monitorujących zachowania użytkowników lub pozyskujących dane z urządzeń końcowych konieczne jest przeprowadzenie szczegółowej oceny skutków dla ochrony danych. DPIA powinna obejmować konkretne funkcjonalności, rzeczywiste przepływy danych, ryzyka dla praw osób fizycznych oraz planowane środki ograniczające zagrożenia.
Zapewnienie pełnej transparentności wobec użytkowników: Klauzule informacyjne powinny jasno wskazywać, jakie dane są pobierane z urządzenia, w jakim celu są wykorzystywane, komu są udostępniane i jak długo będą przechowywane. Informacje przekazywane użytkownikowi powinny być zrozumiałe, precyzyjne i kompletne, a nie ograniczać się do ogólnych stwierdzeń dotyczących bezpieczeństwa lub przeciwdziałania nadużyciom.
Ograniczanie wykorzystania danych pochodzących z urządzeń końcowych: Dane dotyczące aplikacji zainstalowanych na urządzeniach, historii korzystania z urządzenia czy innych elementów środowiska użytkownika powinny być traktowane jako szczególnie wrażliwe z punktu widzenia prywatności. Ich wykorzystanie powinno następować wyłącznie w sytuacjach rzeczywistej konieczności oraz po dokładnym udokumentowaniu takiej potrzeby.
Weryfikacja dostawców i podmiotów przetwarzających przed rozpoczęciem współpracy: Administratorzy powinni przeprowadzać formalną ocenę dostawców technologicznych pod kątem zgodności z RODO, stosowanych zabezpieczeń oraz zakresu danych przetwarzanych przez podwykonawców. W umowach należy szczegółowo opisywać czynności przetwarzania, wykorzystywane technologie i role wszystkich uczestników procesu.
Stosowanie środków bezpieczeństwa o najmniejszej ingerencji w prywatność: Przed wdrożeniem rozwiązań wymagających dostępu do szerokiego zakresu danych użytkownika należy rozważyć wykorzystanie mechanizmów alternatywnych, takich jak rozszerzone uwierzytelnianie wieloskładnikowe, analiza anomalii transakcyjnych, kontrola ryzyka zachowań użytkownika czy monitorowanie nietypowych operacji finansowych.
Wdrożenie rygorystycznej polityki retencji danych: Organizacje powinny dokumentować i uzasadniać każdy okres przechowywania danych. Czas retencji powinien być ściśle powiązany z konkretnym celem przetwarzania, a wszelkie wydłużenia wymagają przeprowadzenia odrębnej analizy proporcjonalności oraz aktualizacji dokumentacji i informacji dla użytkowników.
Regularne przeglądy zgodności technologii bezpieczeństwa z RODO: Rozwiązania antyfraudowe i cyberbezpieczeństwa powinny być okresowo poddawane audytom prawnym, technicznym i organizacyjnym. Pozwala to identyfikować sytuacje, w których rozwój technologii prowadzi do zwiększenia zakresu przetwarzania danych osobowych ponad poziom pierwotnie oceniony w dokumentacji zgodności.