Minimalizacja danych w dzienniku audytowym — surowe identyfikatory sieciowe usunięte, pozostają wyłącznie zhashowane rekordy

Dlaczego ten wpis powstał

To jest wpis transparentny ze strony operatora, dotyczący zmiany w sposobie obsługi identyfikatorów sieciowych w naszym dzienniku audytowym. Zmiana nie wpływa na rozliczenia klientów, dostęp do konta ani żadne zachowanie produktu widoczne w panelu administracyjnym. Realizuje natomiast jedną z fundamentalnych zasad RODO — minimalizację danych z art. 5 ust. 1 lit. c — w sposób, który Inspektorzy Ochrony Danych z UE, kierownicy działów zgodności oraz radcowie prawni zwykle chcą zweryfikować przed zawarciem umowy z podmiotem przetwarzającym dane.

Co zmieniliśmy w zrozumiałym języku

Każda zmiana konta, którą rejestrujemy — utworzenie konta, rotacje kluczy, zmiany planu, modyfikacje członkostwa w zespołach, zdarzenia rozliczeniowe — jest zapisywana w dzienniku audytowym zgodności. Dziennik ten musi istnieć z uzasadnionych powodów prawnych (art. 30 RODO dotyczący prowadzenia rejestru czynności przetwarzania oraz polska Ustawa o rachunkowości wymagająca pięcioletniej retencji dla zdarzeń finansowych).

Do tej pory każdy wpis mógł zawierać identyfikator sieciowy obok zdarzenia. Od teraz przechowywana jest wyłącznie jednokierunkowa zhashowana forma tego identyfikatora. Forma surowa nie jest już nigdzie zachowywana.

Praktyczny skutek dla klientów:

• Mniej surowych danych osobowych pozostaje w dzienniku zgodności Twojego konta. To, co pozostaje, jest wystarczające, aby spełnić obowiązki audytowe i podatkowe, ale nie może być odwrócone w celu odzyskania oryginalnych danych sieciowych.
• Ciągłość wierszy jest zachowana. Audytorzy zgodności i organy podatkowe nadal mogą zobaczyć, że zdarzenie miało miejsce, kiedy oraz przez które konto — po prostu nie widzą już surowych szczegółów sieciowych.
• Starsze, historyczne wpisy. Wpisy historyczne sprzed wprowadzenia hashowania miały inny format. Wpisy te obecnie noszą wyraźnie oznaczony znacznik wskazujący, że pole sieciowe zostało dla danego wiersza wycofane. Znacznik zachowuje ciągłość wierszy w dzienniku audytowym, jednocześnie wyraźnie sygnalizując, że oryginalna wartość surowa nie jest już przechowywana.

Dlaczego ramy prawne są istotne

Zgodnie z art. 5 ust. 1 lit. c RODO — zasadą minimalizacji danych — dane osobowe muszą być "adekwatne, stosowne oraz ograniczone do tego, co niezbędne" dla celu przetwarzania. W przypadku dzienników audytowych niezbędną informacją jest zwykle co się stało oraz kto to zrobił, a nie surowe metadane sieciowe wokół zdarzenia. Zachowywanie formy surowej, gdy forma zhashowana służy temu samemu celowi audytowemu, jest dokładnie tym rodzajem ujawnienia, o które wyrafinowany kupujący pyta podczas procedury procurement.

Zgodnie z art. 30 RODO — rejestrami czynności przetwarzania — administrator musi prowadzić rejestr operacji przetwarzania. Nadal to robimy. Hashowanie identyfikatora sieciowego nie zmniejsza wartości audytowej rekordu; redukuje wyłącznie powierzchnię danych osobowych.

Zgodnie z polską Ustawą o rachunkowości art. 74 — zapisy finansowe muszą być przechowywane przez pięć lat od końca roku obrachunkowego. Zachowujemy ten wymóg: wiersze oznaczone jako zdarzenia finansowe są przechowywane przez pełny ustawowy okres. Nasza zmiana nie usuwa żadnego wiersza; minimalizuje wyłącznie pole identyfikatora sieciowego wewnątrz każdego wiersza.

Ta trójstronna zgodność (art. 5 ust. 1 lit. c minimalizacja + art. 30 prowadzenie rejestru + polska pięcioletnia retencja podatkowa) jest rodzajem szczegółu, który wywołuje późniejsze tarcia podczas audytów, gdy nie jest utrzymywany jednocześnie. Zdecydowaliśmy się utrzymać wszystkie trzy zasady jednocześnie, zamiast wybierać dwie z nich.

Dlaczego to publikujemy

Kupujący ze średniego rynku w UE z branż wydawniczej, e-commerce i SaaS oceniają swoich dostawców na podstawie coraz bardziej szczegółowej postawy prywatności. "Czy dostawca minimalizuje dane, które nie są ściśle niezbędne dla deklarowanego celu?" to jedno z powtarzających się pytań w kwestionariuszach due diligence dla dostawców. Powiedzenie "tak" to jedno; opisanie konkretnej zmiany, która uzasadnia tę odpowiedź, to coś zupełnie innego.

Publikujemy transparentne wpisy operatorskie, aby zespoły zgodności oceniające HumanKey mogły zweryfikować te deklaracje bezpośrednio wobec wersji usługi, którą zamierzają zakupić.

Czego ta zmiana nie zmienia

• Dokładność detekcji pozostaje nienaruszona. Wykrywanie botów zawsze działało na zhashowanych identyfikatorach dla celów analitycznych; ta zmiana dotyczy innego systemu (dziennika audytowego zgodności), nie potoku detekcji.
• Rozliczenia i dostęp do konta pozostają nienaruszone. Zmiany w dzienniku audytowym są wtórne wobec usługi operacyjnej.
• Odpowiedzialność prawna wobec osób, których dane dotyczą, na podstawie art. 15 RODO (prawo dostępu) pozostaje bez zmian. Zhashowany identyfikator pozostaje kanonicznym odniesieniem dla każdego wpisu z dziennika audytowego zwracanego w odpowiedzi na żądanie dostępu.

Odnośniki referencyjne

• Art. 5 ust. 1 lit. c RODO — Zasada minimalizacji danych
• Art. 30 RODO — Rejestr czynności przetwarzania
• Polska Ustawa o rachunkowości art. 74 — Pięcioletnia retencja zapisów finansowych
• Nasza Polityka Prywatności oraz DPIA opisują kategorie danych, które przetwarzamy, oraz okresy retencji obowiązujące dla poszczególnych planów

---

HumanKey to oparta na UE, natywnie zgodna z RODO platforma analityczna dla wydawców i serwisów e-commerce. Operatorskie wpisy transparentne obejmują wybory dotyczące zgodności i inżynierii, które kupujący B2B oceniają podczas procurement.