Jak przechowywać logi zmian NAP bez zbędnych danych osobowych

Log zmian NAP nie powinien być kopią formularza, panelu administracyjnego ani odpowiedzi z zewnętrznego katalogu. Jego zadanie jest prostsze: umożliwić ustalenie co zmieniono, kiedy, w jakim źródle i z jakim skutkiem. Wszystko ponad ten zakres trzeba umieć uzasadnić.

Problem pojawia się szczególnie przy obsłudze jednoosobowych działalności gospodarczych. Nazwa firmy, adres siedziby lub numer telefonu bywają publicznie dostępne, ale nadal mogą stanowić dane osobowe, jeżeli pozwalają zidentyfikować konkretną osobę. Publiczność danych nie oznacza, że można je bezterminowo kopiować do logów, przechowywać w wielu wersjach i udostępniać każdemu administratorowi systemu.

Dobrze zaprojektowany rejestr zmian powinien więc zachować historię potrzebną do kontroli jakości, rozwiązywania sporów i cofania błędnych aktualizacji, ale nie może zamieniać się w archiwum dawnych adresów domowych, prywatnych numerów telefonu i nazwisk pracowników.

Co faktycznie powinno znaleźć się w logu zmian NAP

NAP oznacza zestaw podstawowych danych identyfikujących lokalizację firmy: nazwę, adres i numer telefonu. W praktyce do tej grupy często dołącza się również adres strony internetowej, identyfikator wizytówki, kategorię działalności oraz współrzędne geograficzne. Nie wszystkie te informacje trzeba jednak zapisywać w historii w identycznej postaci.

Minimalny, użyteczny wpis w logu powinien zawierać:

• identyfikator rekordu lub placówki,
• nazwę zmienionego pola, na przykład phone, street albo business_name,
• datę i godzinę zmiany,
• źródło operacji, na przykład panel klienta, import CSV, API lub ręczna korekta,
• identyfikator konta wykonującego zmianę,
• status operacji: przyjęta, odrzucona, oczekująca albo cofnięta,
• kod przyczyny, na przykład CLIENT_REQUEST, DUPLICATE_FIX lub SOURCE_CONFLICT,
• identyfikator zadania publikacyjnego albo synchronizacji.

Taki zakres zazwyczaj wystarcza do odpowiedzi na najważniejsze pytania operacyjne. Wiadomo, kto lub jaki proces uruchomił zmianę, którego pola dotyczyła i czy została poprawnie przesłana do katalogu.

Najwięcej zbędnych danych trafia do dwóch pól: wartość przed zmianą oraz wartość po zmianie. Zapisanie pełnego numeru telefonu lub pełnego adresu bywa wygodne, ale nie zawsze jest konieczne. Jeżeli celem logu jest wyłącznie potwierdzenie, że zmiana nastąpiła, można przechowywać:

• rodzaj zmiany: PHONE_CHANGED,
• skróconą wartość: *** *** 418,
• hash wartości przed i po zmianie,
• identyfikator aktualnej wersji rekordu,
• informację, że zmieniono miejscowość, kod pocztowy albo numer lokalu, bez kopiowania całego adresu.

Hash pozwala potwierdzić, czy dwie wartości były identyczne, ale sam nie umożliwia wygodnego odtworzenia poprzednich danych. To zaleta, gdy historia ma służyć do wykrywania powtórzeń, i wada, gdy operator musi cofnąć zmianę. Dlatego nie należy automatycznie hashować wszystkiego. Najpierw trzeba ustalić, czy system ma jedynie rejestrować zdarzenia, czy również obsługiwać przywracanie wcześniejszych wersji.

Pełne wartości mają uzasadnienie głównie wtedy, gdy:

• zmiany mogą być cofane automatycznie,
• firma rozpatruje reklamacje dotyczące błędnych publikacji,
• trzeba wykazać treść danych przekazanych konkretnemu katalogowi,
• aktualizacje są zatwierdzane wieloetapowo,
• jedno źródło cyklicznie nadpisuje dane z innego źródła.

Nawet wtedy nie trzeba zapisywać całych obiektów JSON. Częstym błędem jest umieszczanie w logu kompletnego żądania API, które poza NAP zawiera adres e-mail właściciela, nazwisko osoby kontaktowej, token autoryzacyjny, komentarz operatora i dane techniczne sesji. Do analizy zmiany telefonu nie potrzeba sześciu dodatkowych identyfikatorów osoby.

Tokeny, hasła, klucze API, nagłówki autoryzacyjne i pliki cookie nie powinny trafiać do logów w żadnej postaci. Maskowanie takich danych dopiero podczas wyświetlania panelu jest za późne. Należy je odrzucić przed zapisaniem zdarzenia.

Jak ustalić retencję i dostęp bez tworzenia wiecznego archiwum

RODO nie wskazuje jednego ustawowego terminu przechowywania logów zmian NAP. Okres trzeba powiązać z rzeczywistym celem. Zapis „przechowujemy tak długo, jak jest to potrzebne” jest niewystarczający, jeżeli nie prowadzi do automatycznego usuwania albo okresowego przeglądu.

W typowym systemie zarządzania lokalizacjami rozsądny model może wyglądać następująco:

• 30–90 dni dla szczegółowych logów technicznych importu, odpowiedzi API i błędów synchronizacji;
• 6–12 miesięcy dla historii operacyjnej potrzebnej do reklamacji, kontroli jakości i wyjaśniania konfliktów między źródłami;
• 24–36 miesięcy wyłącznie dla ograniczonego rejestru audytowego, gdy przemawia za tym cykl umów, postępowań reklamacyjnych lub roszczeń;
• dłuższy okres tylko po wskazaniu konkretnej podstawy, celu oraz zakresu danych, które rzeczywiście muszą pozostać.

To widełki projektowe, a nie terminy wynikające automatycznie z przepisów. Firma obsługująca sezonową sieć punktów może potrzebować krótszej historii niż operator platformy, na której aktualizacje przechodzą przez kilka systemów i są podstawą rozliczeń z klientem.

Najpraktyczniejsze rozwiązanie to podział danych na warstwy. Przez pierwsze 30 lub 90 dni system przechowuje pełniejszy materiał diagnostyczny. Po tym czasie usuwa treść żądań i odpowiedzi, pozostawiając jedynie uproszczony wpis audytowy. Po upływie kolejnego okresu kasuje albo anonimizuje także ten wpis.

Przykład:

2026-07-14 10:42 | location_id: 1847 | field: phone | actor_id: 62 | source: panel | result: accepted

Taki rekord zwykle wystarcza dłużej niż log zawierający pełny numer, adres IP, adres e-mail operatora, nazwę przeglądarki i treść komentarza klienta.

Dostęp do historii również powinien być podzielony. Pracownik pierwszej linii może potrzebować informacji, że numer został zmieniony i opublikowany. Nie musi widzieć poprzedniego numeru ani dokładnego adresu IP użytkownika. Pełniejszy wgląd można pozostawić administratorowi bezpieczeństwa lub osobie rozpatrującej konkretną reklamację.

W praktyce sprawdza się model trzech poziomów:

• podgląd podstawowy — data, pole, status i źródło zmiany;
• podgląd operacyjny — zamaskowana wartość oraz identyfikator wykonawcy;
• podgląd audytowy — pełniejsza historia dostępna po nadaniu odpowiedniej roli lub zarejestrowaniu sprawy.

Uprawnienia trzeba przyznawać według roli, nie według wygody. Konto „administrator”, używane przez kilkanaście osób, praktycznie uniemożliwia ustalenie, kto przeglądał albo eksportował historię. Każdy pracownik powinien działać na własnym koncie, a dostęp do logów zawierających dane osobowe również powinien być rejestrowany.

Szczególnie irytujący błąd projektowy polega na tym, że system usuwa rekord z głównej bazy, ale pozostawia go bezterminowo w kopiach zapasowych, indeksie wyszukiwarki, hurtowni danych i narzędziu do analizy błędów. Retencja musi obejmować cały przepływ. Jeżeli dane trafiają do Elasticsearch, Sentry, Datadog, BigQuery albo plików przechowywanych w Amazon S3, harmonogram usuwania powinien działać również tam.

Nie zawsze da się skasować pojedynczy wpis z niezmiennej kopii zapasowej bez naruszenia integralności backupu. W takim przypadku trzeba określić czas życia całej kopii, ograniczyć dostęp oraz zagwarantować, że po odtworzeniu system ponownie wykona procedury usuwania. Backup nie powinien być bocznym archiwum używanym do zwykłego wyszukiwania dawnych danych.

Jak zaprojektować log, który pomaga w audycie, ale nie ujawnia za dużo

Najbezpieczniejszy wzorzec to log zdarzeniowy, a nie log pełnych rekordów. Zamiast zapisywać kompletną wizytówkę przy każdej aktualizacji, system odnotowuje zmianę konkretnego pola i wskazuje wersję danych przechowywaną w kontrolowanym repozytorium.

Przykładowa struktura wpisu może zawierać:

event_id: 01J2X8FQW7
location_id: 1847
event_type: NAP_FIELD_UPDATED
field: phone
actor_type: user
actor_id: 62
source: client_panel
old_value_fingerprint: 8c71...
new_value_fingerprint: 1f04...
created_at: 2026-07-14T10:42:18+02:00
result: accepted

Pole actor_id jest lepsze niż wpisywanie imienia, nazwiska i adresu e-mail pracownika do każdego zdarzenia. Dane konta można pobrać z odrębnej tabeli, do której dostęp jest ograniczony. Po odejściu pracownika identyfikator nadal pozwala zachować spójność audytu, ale nie powiela jego danych osobowych w tysiącach rekordów.

Podobnie należy traktować adres IP. Może być przydatny przy wykrywaniu przejęcia konta albo nietypowych operacji, lecz nie musi występować w każdym logu biznesowym. Najlepiej przechowywać go w osobnym rejestrze bezpieczeństwa, z krótszą retencją i węższym dostępem. Łączenie historii zmian wizytówki z pełną historią logowań upraszcza pracę programistyczną, ale zwiększa zakres danych dostępnych podczas jednego wycieku.

Komentarze tekstowe wymagają jeszcze większej dyscypliny. Pole „uwagi” szybko wypełnia się wpisami w rodzaju: „telefon podała pani Anna Kowalska, właścicielka, prywatny numer 501…”. Takich informacji nie da się skutecznie ograniczać prostą walidacją. Lepsze są zamknięte kody przyczyn oraz osobny, opcjonalny komentarz z limitem znaków i ostrzeżeniem, aby nie wpisywać danych osobowych.

Przy projektowaniu formularza warto zastosować cztery zabezpieczenia:

• lista gotowych powodów zmiany zamiast obowiązkowego komentarza,
• automatyczne wykrywanie numerów PESEL, adresów e-mail i długich ciągów cyfr,
• maskowanie numerów telefonu oraz adresów w podglądzie,
• blokowanie eksportu pełnych logów dla zwykłych kont operacyjnych.

Automatyczne wykrywanie danych nie gwarantuje pełnej skuteczności. Filtr może nie rozpoznać numeru zapisanego słownie, adresu z literówką albo informacji umieszczonej na zrzucie ekranu. Powinien ograniczać typowe błędy, a nie zastępować reguły dostępu i szkolenie osób obsługujących system.

Trzeba też rozdzielić anonimizację od pseudonimizacji. Zamiana nazwiska pracownika na identyfikator konta jest pseudonimizacją, ponieważ administrator nadal może ustalić, kto wykonał zmianę. Dane pozostają objęte przepisami o ochronie danych. Dopiero trwałe usunięcie możliwości identyfikacji, także przez połączenie wpisu z innymi tabelami, może prowadzić do anonimizacji.

W przypadku nazw firm granica bywa nieoczywista. „ABC Serwis sp. z o.o.” dotyczy osoby prawnej, ale „Jan Kowalski Usługi Hydrauliczne” bezpośrednio identyfikuje przedsiębiorcę. Podobnie adres lokalu handlowego zwykle stwarza mniejsze ryzyko niż adres jednoosobowej działalności zarejestrowanej w mieszkaniu. System nie musi tworzyć osobnej architektury dla każdej formy prawnej, ale powinien przyjmować ostrzejszy wariant ochrony, gdy nie potrafi wiarygodnie rozróżnić tych przypadków.

Dodatkowe informacje na: wizytówki NAP – aiqo.pl.

FAQ

Czy publiczny numer telefonu firmy można bez ograniczeń przechowywać w logach?
Nie. Publiczne udostępnienie numeru nie znosi zasady minimalizacji ani ograniczenia przechowywania. Trzeba określić, po co pełny numer znajduje się w historii i kiedy zostanie usunięty albo zamaskowany.

Czy każdy log zmian NAP zawiera dane osobowe?
Nie każdy, ale wiele logów umożliwia identyfikację przedsiębiorcy, pracownika lub użytkownika konta. Dotyczy to zwłaszcza nazw jednoosobowych działalności, adresów domowych, numerów telefonu, adresów IP oraz identyfikatorów możliwych do połączenia z kontem.

Czy wystarczy usunąć imię i nazwisko operatora?
Nie, jeżeli pozostawiony identyfikator konta pozwala ustalić jego tożsamość. Jest to pseudonimizacja, która zmniejsza ryzyko, ale nie powoduje automatycznie, że dane przestają być osobowe.

Jak długo przechowywać historię zmian?
Termin powinien wynikać z celu. Szczegółowe dane diagnostyczne często można usuwać po 30–90 dniach, a uproszczoną historię operacyjną pozostawić przez 6–12 miesięcy. Dłuższa retencja wymaga konkretnego uzasadnienia, a nie samego argumentu, że dane mogą kiedyś się przydać.

Czy można przechowywać pełną wartość przed zmianą?
Tak, gdy jest potrzebna do cofnięcia operacji, obsługi reklamacji albo wykazania treści przekazanej zewnętrznemu katalogowi. Jeżeli system ma tylko potwierdzić fakt zmiany, wystarczy maska, hash albo identyfikator wersji.

Czy logi trzeba szyfrować?
Szyfrowanie jest uzasadnione szczególnie wtedy, gdy historia zawiera pełne adresy, numery telefonu, adresy IP lub dane użytkowników. Nie zastępuje jednak ograniczenia dostępu, krótkiej retencji i kontroli eksportów.

Czy administrator może przechowywać logi bezterminowo w celu bezpieczeństwa?
Nie powinien przyjmować takiej reguły automatycznie. Cel bezpieczeństwa nie uzasadnia przechowywania każdego rodzaju danych przez nieograniczony czas. Trzeba rozdzielić logi bezpieczeństwa od historii biznesowej i ustalić dla nich osobne okresy retencji.

Co zrobić z logami znajdującymi się w kopiach zapasowych?
Należy określić czas życia backupów, ograniczyć dostęp i uwzględnić ponowne usunięcie danych po odtworzeniu systemu. Kopie zapasowe nie mogą służyć jako łatwo dostępne archiwum dawnych danych.

Pierwszy krok powinien być jednoznaczny: sprawdź, czy obecny system zapisuje pełne żądania API, odpowiedzi serwerów albo całe rekordy wizytówek przy każdej zmianie. Jeżeli tak, usuń ten mechanizm w pierwszej kolejności i zastąp go listą dozwolonych pól logu. To właśnie niekontrolowane kopiowanie całych obiektów, a nie pojedynczy brak maskowania, najczęściej powoduje największy i najmniej uzasadniony nadmiar danych.