Data retention (retencja danych) to zasada określająca, jak długo organizacja trzyma dane, zanim je zarchiwizuje, zanonimizuje albo trwale skasuje. Polityka retencji przypisuje każdej kategorii danych (logi systemowe, dane osobowe, dokumenty finansowe, kopie zapasowe) konkretny okres przechowywania — wynikający z prawa, regulacji branżowych i potrzeb firmy — a po jego upływie dane są usuwane automatycznie.
W praktyce chodzi o pogodzenie dwóch przeciwnych celów: trzymać dane dość długo, by spełnić obowiązki dowodowe, audytowe i śledcze, ale nie dłużej, niż trzeba (zasada minimalizacji danych). Każdy zbiór, którego już nie potrzebujesz, to dodatkowe ryzyko — więcej do wykradzenia i więcej do ujawnienia przy wycieku.
Czym jest polityka retencji danych?
Polityka retencji danych (ang. data retention policy) to spisany zestaw reguł, który odpowiada na cztery pytania: jakie dane trzymamy, jak długo, gdzie i w jakiej formie oraz kto za nie odpowiada i je usuwa. Typowy dokument zawiera:
- Klasyfikację danych wg typu, wrażliwości i wartości dla firmy — z osobnym okresem retencji dla każdej kategorii.
- Okresy przechowywania oparte na podstawie prawnej lub regulacji (np. 7 lat dla dokumentów finansowych, 6 lat dla dokumentacji HIPAA).
- Sposoby usuwania — automatyczne kasowanie, nadpisywanie, anonimizacja albo bezpieczne niszczenie nośnika po upływie okresu.
- Role i odpowiedzialności — zwykle IT, dział prawny, compliance i właściciele procesów biznesowych.
- Zasady archiwizacji, kopii zapasowych i dostępu do danych przez cały czas ich przechowywania.
Dlaczego retencja danych jest ważna dla bezpieczeństwa?
Retencja to nie tylko zgodność z przepisami. Dla bezpieczeństwa pełni dwie ważne, częściowo sprzeczne role:
- Mniejsze ryzyko. Danych, których już nie trzymasz, nikt nie wykradnie ani nie zaszyfruje w ataku ransomware. Kasowanie zbędnych zbiorów ogranicza skutki naruszenia i zakres tego, co trzeba potem zgłosić.
- Materiał do wykrywania i śledztwa. Logi i dane o ruchu w sieci muszą żyć dość długo, by dało się wykryć i zbadać incydent. Atakujący potrafi siedzieć w sieci niewykryty tygodniami lub miesiącami (tzw. dwell time), więc logi krótsze niż ten czas nie nadają się już do analizy po fakcie.
To napięcie — kasować mało vs móc prześledzić atak — jest sednem retencji w cyberbezpieczeństwie. Dane osobowe użytkowników usuwa się szybko; logi bezpieczeństwa (logowania, dostęp administratorów, zdarzenia z EDR, przepływy NetFlow/IPFIX) trzyma się zwykle dłużej, powołując się na uzasadniony interes bezpieczeństwa.
Jak długo trzeba przechowywać dane? Wymogi regulacyjne
Nie ma jednego uniwersalnego okresu. Najczęściej cytowane wymogi:
- PCI DSS (wymóg 10.7 w v4.0): co najmniej 12 miesięcy historii dzienników audytu, z czego minimum 3 miesiące od ręki dostępne do analizy, bez odtwarzania z backupu.
- HIPAA (45 CFR 164.316): dokumentacja zabezpieczeń — w tym logi i analizy ryzyka — przez 6 lat od utworzenia lub ostatniego obowiązywania.
- RODO / GDPR (art. 5 ust. 1 lit. e): brak sztywnego okresu — dane osobowe wolno trzymać „nie dłużej, niż jest to niezbędne” do celu przetwarzania (zasada ograniczenia przechowywania). Logi bezpieczeństwa mogą żyć dłużej, jeśli uzasadnia to monitorowanie i reakcja na incydenty.
- SOX (Sarbanes-Oxley): 7 lat dla dokumentacji kontroli finansowej i powiązanych logów.
- ISO/IEC 27001: nie narzuca twardego okresu, ale wymaga zdefiniowanej i egzekwowanej polityki retencji logów (zwykle przyjmuje się ≥12 miesięcy).
- NIS2: dyrektywa unijna nie podaje jednej liczby, ale nakłada obowiązek logowania, wykrywania, obsługi i raportowania incydentów (wstępne zgłoszenie w 24 godziny) — co w praktyce wymusza retencję logów wystarczającą, by zdarzenie zbadać i udokumentować.
Gdy firma podlega kilku regulacjom naraz, nie pisze osobnych polityk — w danej kategorii danych stosuje najsurowszy wymóg jako wspólny mianownik.
Jak zaprojektować politykę retencji danych?
- Inwentaryzacja i klasyfikacja — ustal, jakie dane gromadzisz, gdzie leżą i jak są wrażliwe.
- Mapowanie wymogów — przypisz każdej kategorii podstawę prawną/regulacyjną i wynikający z niej minimalny okres.
- Ustalenie okresów — pogodź minima z przepisów z minimalizacją; przy logach bezpieczeństwa licz się z czasem potrzebnym na wykrycie i zbadanie ataku, nie tylko z compliance.
- Podział pamięci na poziomy — dane „gorące” (szybki dostęp do analizy w SIEM/NDR) i „ciepłe/zimne” (tańsze archiwum). PCI DSS wprost rozróżnia 3 miesiące „na gorąco” i 12 miesięcy łącznie.
- Automatyczne usuwanie — kasowanie wg reguł, z zapisaniem samej operacji usunięcia jako ślad w audycie.
- Ochrona w trakcie przechowywania — szyfrowanie, kontrola dostępu i niezmienność (WORM/append-only), która chroni logi przed manipulacją atakującego.
Retencja logów dla SOC, NDR i monitorowania sieci
Dla zespołów bezpieczeństwa retencja telemetrii to osobny temat. Logi i metadane przepływów sieciowych (NetFlow, sFlow, IPFIX) oraz zdarzenia z firewalli, DNS, proxy, EDR i systemów tożsamości to surowiec do wykrywania i śledztwa. Najważniejsze zasady:
- Niezmienność i integralność. Logi trzeba zapisywać tak, by nie dało się ich po cichu skasować — czyszczenie śladów to jeden z pierwszych ruchów napastnika. Pomaga centralizacja i magazyn typu append-only (dopisywanie bez nadpisywania).
- Koszt rośnie z czasem. Pełny zapis pakietów (full packet capture) trzyma się krótko (dni), metadane przepływów dłużej (miesiące), a wybrane logi audytowe latami — bo koszt szybko rośnie wraz z objętością i okresem.
- Dopasowanie do dwell time. Jeśli retencja jest krótsza niż czas, przez który atakujący był niewykryty, dochodzenie po fakcie jest niemożliwe — to częsta luka, gdy okres ustawiono wyłącznie pod minimalny wymóg compliance.
- Korelacja w czasie. Wykrycie powolnej eksfiltracji, łączności C2 (beaconing) czy nadużyć kont wymaga danych z miesięcy, nie dni.
Dowiedz się więcej
- Shadow IT — Shadow IT może utrudniać egzekwowanie polityk retencji danych i kontrolę ich przechowywania.
- Deduplikacja danych — Deduplikacja danych pomaga ograniczyć nadmiar kopii, co ułatwia zarządzanie retencją.
