Co zrobić z danymi po rezygnacji z oprogramowania: usunięcie czy archiwizacja

Od czego zacząć: rezygnacja z oprogramowania nie równa się usunięciu danych

Rezygnacja z licencji i los danych to dwie różne decyzje. Umowa licencyjna określa, co dzieje się przy wypowiedzeniu lub wygaśnięciu licencji — klauzule o wypowiedzeniu i wygaśnięciu występują nawet w licencjach wieczystych, np. w umowie licencyjnej Web of Knowledge. Zaprzestanie opłat lub odcięcie dostępu do interfejsu nie usuwa rekordów z bazy, załączników z serwera ani kopii zapasowych.

Dane istnieją w bazie i poza aplikacją. Dokumentacja Comarch PPK wskazuje, że aplikacja współpracująca z Comarch ERP HR pobiera dane z bazy systemu ERP, a informacje o uczestnictwie, wysokościach składek i rezygnacji z PPK są odnotowywane na formularzu danych kadrowych pracownika, z uzupełnianą historią zmian. Po wyłączeniu modułu lub całego systemu rekordy mogą więc nadal istnieć, ale bez narzędzia do ich odczytania.

Dostęp zwykle kończy się wcześniej niż życie danych. Po wygaśnięciu licencji SOLIDWORKS użytkownicy tracą dostęp do nowych wersji i poprawek, co grozi problemami z kompatybilnością plików. Decyzję o eksporcie, archiwizacji albo usunięciu trzeba podjąć przed wygaśnięciem licencji, nie po fakcie.

Modele licencyjne różnią się możliwością zachowania ciągłości: w Kaspersky Small Office Security nie można dodać kodu zapasowego, gdy korzystasz z subskrypcji lub licencji testowej, ani wtedy, gdy bieżąca licencja już utraciła ważność. Przed rezygnacją sprawdź w dokumentacji dostawcy, czy i jak długo po wygaśnięciu zachowasz dostęp do odczytu i eksportu.

Inwentaryzacja danych: co tak naprawdę zostaje po oprogramowaniu

Punktem wyjścia jest lista zbiorów, nie modułów. Spisz kategorie: dane osobowe pracowników i kandydatów, dane finansowo-księgowe, magazynowe, produkcyjne, projekty i rysunki, historię zmian, załączniki, słowniki i konfiguracje. Waga tych danych bywa krytyczna — systemy ERP przechowują informacje istotne dla działania całej organizacji, a ich utrata może oznaczać śmierć firmy.

Historia zmian i dane pochodne to osobna kategoria. Zbiór aktualizowany po rezygnacji z jednego narzędzia nie może być zamrożony bezmyślnie — trzeba ustalić, kto i w jakim systemie będzie go dalej prowadził.

Dane techniczne są silnie związane z wersją narzędzia. Pliki CAD, biblioteki, szablony i konfiguracje współpracują z konkretną wersją oprogramowania; inwentaryzacja powinna więc objąć także format zapisu, wersję plików i powiązania między nimi (złożenia, odwołania do bibliotek).

Inwentaryzacja nie może kończyć się na systemie produkcyjnym. Te same dane często istnieją w kopiach zapasowych, na dyskach użytkowników, w skrzynkach e-mail, w eksportach i w integracjach z podmiotami trzecimi. Wielowarstwowa architektura ERP — dane oddzielone od logiki aplikacji, logika od interfejsu — pokazuje, że do odczytania danych potrzebna jest warstwa danych, a nie sama aplikacja; w wykazie wskaż więc, gdzie fizycznie leży baza, kto ma do niej dostęp i jaka jest polityka kopii bezpieczeństwa.

Efekt inwentaryzacji to tabela: nazwa zbioru, cel przetwarzania, podstawa przechowywania, właściciel, format, miejsce przechowywania, czy dane nadal są aktualizowane oraz proponowana decyzja (usunięcie, archiwizacja, migracja). Bez takiej tabeli każda dalsza decyzja jest zgadywaniem.

Usunięcie czy archiwizacja? Kryteria, które warto przejść punkt po punkcie

Pierwsze kryterium to cel przetwarzania. Jeśli cel wygasł wraz z odejściem oprogramowania, domyślną decyzją jest usunięcie.

Drugie kryterium to rzeczywisty obowiązek przechowywania. Sprawdź, czy przepisy nakazują zachowanie danego rodzaju dokumentacji, zamiast zakładać, że „wszystko trzeba trzymać”. Okresy przechowywania wynikają z rodzaju dokumentacji i daty, więc ta sama kategoria w dwóch firmach może mieć różny horyzont — decyzję trzeba uzasadnić dla własnego zbioru.

Trzecie kryterium to potrzeba dowodowa i operacyjna. Dane mogą być potrzebne do wykazania wykonania umowy, dochodzenia roszczeń, obsługi reklamacji, serwisu urządzeń lub odtworzenia historii produkcji. Zapytaj: czy po usunięciu systemu znajdziemy konkretny dokument w rozsądnym czasie i przedstawimy go w czytelnej formie?

Czwarte kryterium to koszt i ryzyko. Archiwizacja generuje koszt przechowywania, zabezpieczenia i utrzymania czytelności formatu, a migracja do nowego systemu — koszt wdrożenia; z drugiej strony utrata dostępu do danych operacyjnych oznacza konieczność odtworzenia ich z dokumentów papierowych lub od kontrahentów. Ryzyko trzeba zestawić z kosztem, a nie rozstrzygać hasłem „lepiej zachować”.

Wynikiem przejścia przez te kryteria jest jedna z trzech decyzji dla każdego zbioru: usunąć, zarchiwizować na określony czas, zmigrować do systemu, który będzie dalej używany. Zbiory, dla których żadne kryterium nie wskazuje na potrzebę zachowania, powinny trafić do usunięcia — inaczej archiwum zamienia się w składowisko.

Archiwizacja, która nie zamienia się w składowisko danych

Archiwizacja zgodna z RODO to nie „przeniesienie plików”, lecz planowanie, organizacja, zabezpieczenie i monitorowanie danych osobowych w każdej formie. Rozporządzenie nakłada obowiązek zapewnienia poufności, integralności i dostępności przetwarzanych informacji, a dane muszą być zabezpieczone przed dostępem osób nieuprawnionych, utratą, zniszczeniem i nieautoryzowanym ujawnieniem.

Warunkiem sensownego archiwum jest uporządkowanie. Dane muszą być przechowywane tak, by łatwo je odnaleźć, zaktualizować lub usunąć. W praktyce oznacza to indeks zbiorów, identyfikatory rekordów, powiązanie z systemem źródłowym oraz dołączenie słowników i opisów pól — bez nich eksport z bazy nieczytelny dla człowieka traci wartość dowodową i operacyjną.

Dostęp do archiwum powinien podlegać tym samym zasadom co dostęp do ERP: każdy użytkownik korzysta wyłącznie z funkcji i danych niezbędnych do pracy, dostęp jest przydzielany po identyfikacji, uwierzytelnieniu i dwustopniowej autoryzacji, a polityka haseł wymusza regularne zmiany i silne kombinacje. Dodatkowo potrzebna jest polityka wykonywania kopii bezpieczeństwa i plan przywrócenia działania — archiwum bez możliwości odtworzenia po awarii nie spełnia wymogu dostępności.

Każdy zbiór w archiwum powinien mieć trzy przypisane elementy: okres przechowywania, osobę odpowiedzialną oraz sposób usunięcia po upływie tego okresu. Minimalizacja danych nakazuje ograniczenie ilości przechowywanych informacji do niezbędnego minimum, więc archiwum nie może rosnąć bez kontroli — ustal, kto je przegląda i kiedy usuwa pozycje, których cel przetwarzania wygasł.

Techniczne zabezpieczenie archiwum to szyfrowanie, kontrola dostępu i rozdzielenie od środowiska produkcyjnego. Archiwum powinno być odrębnym, najlepiej tylko do odczytu, zbiorem z rejestrem dostępu; dane operacyjne, które nadal mają być używane, powinny trafić do systemu docelowego, a nie do tego samego katalogu co kopie historyczne.

Bezpieczne usunięcie danych, gdy nie ma podstaw do dalszego przechowywania

Usunięcie danych z systemu to dopiero pierwszy krok. Zakres obejmuje bazę produkcyjną, środowiska testowe, kopie zapasowe, eksporty i pliki robocze, dyski użytkowników, nośniki przenośne, skrzynki e-mail oraz zasoby w chmurze, do których dane trafiały przez integracje. Jeśli pominiesz którykolwiek nośnik, dane nadal będą przetwarzane bez podstawy.

Kopie zapasowe rządzą się własnym cyklem. Ustal, kiedy usunięte rekordy znikną z kolejnych generacji kopii i czy w okresie przejściowym istnieje ryzyko przypadkowego odtworzenia ich do systemu produkcyjnego. Bez tej analizy „usunięcie” bywa tylko ukryciem danych w migawce sprzed miesiąca.

Usuwanie powinno być czynnością uprawnioną i udokumentowaną: wykonywaną przez wyznaczone osoby, na podstawie zatwierdzonej decyzji, z zapisem, co i kiedy usunięto. Zasada ograniczania uprawnień znana z ERP działa tu podwójnie — minimalizuje ryzyko pomyłkowego skasowania danych przeznaczonych do archiwizacji i utrudnia użycie funkcji usuwania do zatarcia śladów.

Nośniki i urządzenia wymagają odrębnego postępowania także przy wycofywaniu sprzętu z eksploatacji — przed przekazaniem nośnika do serwisu, sprzedaży lub utylizacji. Żądaj od wykonawcy potwierdzenia zniszczenia nośnika i obejmij tym trybem dyski przenośne oraz służbowe telefony, których zgubienie jest jednym z typowych zdarzeń prowadzących do wycieku.

Osobno potraktuj urządzenia pracujące zdalnie. Jeśli dane były kopiowane na komputer domowy lub prywatny dysk, usunięcie w systemie centralnym nic nie daje — potrzebny jest wykaz takich miejsc i czynność zdalnego czyszczenia albo fizycznego zwrotu sprzętu.

Dane osobowe po rezygnacji z oprogramowania: kiedy archiwizować, a kiedy usuwać

Nie ma jednego uniwersalnego okresu przechowywania danych osobowych. RODO nie określa konkretnego okresu, a w Polsce okres przechowywania akt osobowych pracowników zależy od daty — nie da się przenieść jednej liczby na wszystkie zbiory; trzeba ustalić własną retencję dla poszczególnych kategorii dokumentacji.

Retencję wyznacza się w dwóch krokach. Najpierw ustal cel przetwarzania zbioru (kadry i płace, rekrutacja, PPK, obsługa klientów, marketing), a następnie sprawdź, czy istnieje przepis nakazujący przechowywanie dokumentacji danego rodzaju. Dopiero z połączenia tych elementów wynika okres dla konkretnego zbioru — inny dla dokumentacji pracowniczej, inny dla danych kontaktowych z kampanii handlowej.

Dane dotyczące świadczeń i rozliczeń bywają aktualizowane po zakończeniu współpracy, co komplikuje usunięcie. Taki zbiór musi pozostać edytowalny tak długo, jak długo trwa proces, dlatego należy go zmigrować, a nie tylko zarchiwizować w formie niezmiennej.

Jeżeli po zamknięciu systemu nie potrafimy wskazać celu dla danego zbioru ani podstawy jego przechowywania, właściwą decyzją jest usunięcie — a nie „zarchiwizowanie na wszelki wypadek”.

Odrębną kwestią jest zdolność realizacji uprawnień osób, których dane dotyczą — trzeba ją uwzględnić przy projektowaniu archiwum.

Zamknięte formaty i wygasająca licencja: eksport przed utratą dostępu

Gdy licencja wygasa, dostęp do narzędzia może się skończyć wcześniej niż same pliki. Dlatego eksport i weryfikację czytelności trzeba zaplanować przed zakończeniem licencji.

Zakres tego, co wolno zrobić po zakończeniu licencji, określa umowa. Przed rezygnacją ustal, czy dostawca zapewnia okres przejściowy, dostęp do odczytu lub eksport i na jakich warunkach.

Eksport powinien objąć nie tylko rekordy, ale i kontekst potrzebny do ich zrozumienia: słowniki, opisy pól, powiązania między tabelami, załączniki i pliki binarne, historię zmian oraz informację o wersji systemu źródłowego. Testem jakości eksportu jest próba otwarcia i odczytania danych na innym komputerze, bez oryginalnego oprogramowania i bez aktywnej licencji — jeśli to się nie udaje, archiwum nie istnieje.

Alternatywą dla czystej archiwizacji jest migracja danych do systemu, który będzie dalej używany. W przykładzie rodziny Comarch ERP wskazuje się, że przy odpowiednim wyborze systemu rozbudowa funkcji lub migracja danych do wyższego systemu jest możliwa — dla danych operacyjnych, które mają być nadal przetwarzane, jest to lepsze rozwiązanie niż zamrożony eksport.

Praktyczny plan działania krok po kroku

Krok 1: inwentaryzacja. Spisz zbiory danych, ich właścicieli, cel przetwarzania, format, miejsce przechowywania oraz informację, czy dane są nadal aktualizowane. Uwzględnij kopie zapasowe, eksporty, urządzenia użytkowników i integracje z podmiotami trzecimi. Krok 2: przegląd umowy i dokumentacji licencyjnej. Ustal, co dzieje się z danymi po wypowiedzeniu lub wygaśnięciu licencji, czy dostawca oferuje eksport lub dostęp do odczytu i do kiedy.

Krok 3: decyzja o retencji dla każdego zbioru — usunięcie, archiwizacja na oznaczony okres albo migracja. Uzasadnij ją celem przetwarzania i obowiązkiem przechowywania; dla danych osobowych ustal okresy wynikające z rodzaju dokumentacji i daty. Krok 4: eksport. Wykonaj eksport wraz ze słownikami i załącznikami.

Krok 5: archiwizacja. Umieść wyłącznie potrzebne dane w uporządkowanym, zaszyfrowanym zbiorze z kontrolą dostępu przypominającą politykę uprawnień z ERP, z polityką kopii bezpieczeństwa i planem przywrócenia działania. Przypisz każdemu zbiorowi okres przechowywania i osobę odpowiedzialną. Krok 6: usunięcie pozostałych danych — z systemu produkcyjnego, środowisk testowych, kopii zapasowych, urządzeń i nośników, z udokumentowaniem, co i kiedy usunięto oraz kiedy dane znikną z kolejnych generacji kopii.

Krok 7: udokumentowanie całości. Opisz, jakie dane zachowano, w jakim formacie, kto ma do nich dostęp, do kiedy wolno je przechowywać i jak zostaną usunięte po upływie tego okresu. Krok 8: przegląd. Ustal termin kolejnej weryfikacji archiwum i wpisz ją do procesu zarządzania dokumentacją tak, aby zbiory, których cel wygasł, były usuwane, a nie odkładane na następne lata.

Podsumowanie: decyzja zależy od danych, nie od samego oprogramowania

Rezygnacja z oprogramowania nie jest równoznaczna z usunięciem danych ani z obowiązkiem ich zachowania. Decyzję dla każdego zbioru trzeba oprzeć na inwentaryzacji, celu przetwarzania, obowiązku przechowywania oraz potrzebie dowodowej i operacyjnej.

Bezpieczne podejście to archiwizacja wyłącznie danych niezbędnych, z określonym okresem i kontrolowanym dostępem, oraz usunięcie reszty wraz z kopiami zapasowymi i nośnikami. Eksport i jego czytelność należy sprawdzić przed utratą dostępu do licencji.