Ład cyklu życia danych w ISO 27001 na 2026 rok

Maria, dyrektor ds. bezpieczeństwa informacji (CISO) w szybko rosnącym fintechu, miała piątkowe popołudnie, które zamieniło lukę zgodności w problem na poziomie zarządu.

Spółka właśnie weszła na nowe rynki UE. Przychody rosły, onboarding klientów przyspieszał, a nowe narzędzia SaaS dodawano co tydzień. Wtedy niemal jednocześnie przyszły trzy wiadomości.

Dział prawny ostrzegł, że organy ochrony danych nasilają egzekwowanie wymagań GDPR dotyczących ograniczenia przechowywania. Zespół ds. zgodności przypomniał jej, że obowiązki DORA w zakresie ryzyka ICT stały się bieżącą rzeczywistością operacyjną. Zarząd zapytał, czy ekspozycja organizacji na NIS2, w tym wymagania dotyczące dostawców i cyberhigieny, jest pod kontrolą.

Następnie klient zażądał usunięcia swojego konta oraz wszystkich powiązanych danych osobowych.

Prosty wniosek zamienił się w międzyfunkcyjną mobilizację. Dział prawny wskazał, że część zapisów może być potrzebna w sporze umownym. Finanse wskazały, że zapisy wymagane przepisami muszą zostać zachowane. Produkt potwierdził, że dane klienta znajdują się w produkcyjnej bazie danych, platformie analitycznej, zgłoszeniach wsparcia, pamięci obiektowej, logach Kubernetes, migawkach baz danych oraz narzędziu customer success dostawcy zewnętrznego. Zespół inżynierii chmury zapytał, które kopie zapasowe zawierają te dane. IOD zapytał, czy jakakolwiek kopia jest nadal przetwarzana poza UE. Maria poprosiła o dowody.

Ktoś w końcu wypowiedział zdanie, które ujawniło rzeczywisty problem:

„Nie mamy jednego miejsca, w którym widać cały ten cykl życia”.

To jest problem ładu cyklu życia danych w 2026 roku. Nie chodzi tylko o okres przechowywania danych. Chodzi o klasyfikację, własność, podstawę prawną, dostęp, lokalizację, replikację, okres przechowywania kopii zapasowych, wstrzymanie usuwania z przyczyn prawnych, offboarding chmury, usuwanie danych przez dostawców, przegląd archiwów, materiał dowodowy dotyczący incydentów i możliwą do obrony utylizację.

Dla MŚP, fintechów, dostawców usług zarządzanych, firm cloud-first i organizacji regulowanych ryzykiem nie jest już brak danych. Ryzyko polega na tym, że dane są wszędzie: zduplikowane, nieaktualne, z nadmiernymi uprawnieniami, niedostatecznie sklasyfikowane i niemożliwe do wykazania jako usunięte.

Dojrzały program ładu cyklu życia danych w ISO 27001 przekształca taki chaos w kontrolowany przepływ pracy.

Dlaczego ład cyklu życia danych zmienił się w 2026 roku

GDPR, NIS2 i DORA często traktuje się jako trzy odrębne listy kontrolne zgodności. To błędny model operacyjny. Są to różne regulacyjne ujęcia tego samego wymagania biznesowego: znać swoje dane, chronić je zgodnie z ryzykiem, przechowywać je z właściwego powodu i móc wykazać, co się z nimi stało.

Art. 5 GDPR wymaga, aby dane osobowe były przetwarzane zgodnie z prawem, rzetelnie i w sposób przejrzysty, zbierane w określonych celach, ograniczone do tego, co niezbędne, prawidłowe, przechowywane tylko tak długo, jak jest to potrzebne, oraz chronione przed nieuprawnionym lub niezgodnym z prawem przetwarzaniem, przypadkową utratą, zniszczeniem lub uszkodzeniem. Art. 5(2) dodaje zasadę rozliczalności, co oznacza, że administrator musi być w stanie wykazać zgodność. Zarządzanie okresami przechowywania w GDPR nie jest więc ćwiczeniem w arkuszu kalkulacyjnym. Wymaga dowodów operacyjnych.

NIS2 czyni cyberbezpieczeństwo zagadnieniem organu zarządzającego. Art. 20 określa oczekiwania w zakresie ładu wobec organów zarządzających, natomiast art. 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. Obejmują one analizę ryzyka, polityki bezpieczeństwa systemów informatycznych, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, ocenę skuteczności, cyberhigienę, szkolenia, kryptografię, kontrolę dostępu i zarządzanie aktywami. Nieznane lub przestarzałe dane nie są wyłącznie problemem prywatności. Są problemem powierzchni ataku.

DORA czyni zarządzanie ryzykiem ICT, odporność operacyjną i ryzyko stron trzecich ICT bezpośrednio egzekwowalnymi wobec podmiotów finansowych. Art. 5 i 6 przypisują odpowiedzialność organowi zarządzającemu i wymagają udokumentowanych ram zarządzania ryzykiem ICT. DORA oczekuje również, że podmioty finansowe będą chronić dostępność, autentyczność, integralność i poufność danych, utrzymywać zdolności obsługi incydentów, testować odporność oraz zarządzać zależnościami od stron trzecich ICT.

DORA zasadniczo działa jako sektorowy reżim dla nakładających się operacyjnych obowiązków cyberbezpieczeństwa podmiotów finansowych, podczas gdy NIS2 pozostaje istotna dla szerszego ekosystemu, w tym dostawców chmury, dostawców usług zarządzanych i wielu organizacji infrastruktury cyfrowej. Ma to znaczenie, ponieważ fintech może podlegać bezpośrednio DORA, a jego dostawca SaaS lub dostawca usług zarządzanych może znajdować się w zakresie NIS2.

ISO/IEC 27001:2022 jest systemem zarządzania, który może spiąć te obowiązki w całość. Punkty 4.1–4.4 wymagają, aby organizacja rozumiała swój kontekst, zainteresowane strony, wymagania prawne i umowne oraz zakres SZBI. Punkty 5.1–5.3 wymagają przywództwa, ról i odpowiedzialności. Punkty 6.1.2 i 6.1.3 wymagają oceny ryzyka bezpieczeństwa informacji, postępowania z ryzykiem, doboru zabezpieczeń, porównania z Załącznikiem A oraz zachowania udokumentowanych informacji.

Właśnie dlatego ISO 27001 nie jest „kolejną listą kontrolną”. Jest systemem operacyjnym ładu cyklu życia danych.

Model cyklu życia: siedem pytań, na które musi odpowiedzieć każdy właściciel danych

Praktyczny model ładu cyklu życia danych powinien odpowiadać na siedem pytań dla każdej istotnej kategorii danych:

1. Czym są te dane?
2. Dlaczego je przetwarzamy?
3. Kto jest ich właścicielem?
4. Jak bardzo są wrażliwe?
5. Gdzie są przechowywane i gdzie się replikują?
6. Jak długo muszą być przechowywane albo objęte wstrzymaniem usuwania?
7. Jak je chronimy, przeglądamy, usuwamy i jak to wykazujemy?

Podejście Clarysec łączy te pytania z zabezpieczeniami ISO 27001 i dowodami operacyjnymi. W Zenith Blueprint: 30-etapowej mapie drogowej audytora faza „Zabezpieczenia w działaniu” traktuje inwentarz aktywów i klasyfikację jako fundamenty operacyjne, a nie dokumentację tworzoną dla samej dokumentacji. Krok 22 wyjaśnia, że inwentarz powinien obejmować aktywa fizyczne, aktywa cyfrowe, aktywa logiczne, aktywa związane z usługami oraz osoby w kontekście odpowiedzialności, dostępu i ekspozycji.

Zenith Blueprint stwierdza:

„Każde aktywo powinno mieć zdefiniowanego właściciela — nie osobę, która z niego korzysta, lecz osobę odpowiedzialną za jego użycie, ochronę i cykl życia”.

To zdanie jest punktem zwrotnym. Ład cyklu życia danych zawodzi, gdy własność przypisuje się do „IT” albo „biznesu”. Działa wtedy, gdy imiennie wskazany, rozliczalny właściciel może zatwierdzić klasyfikację, okres przechowywania, dostęp, decyzje o wstrzymaniu usuwania z przyczyn prawnych, przegląd archiwów i dowody usunięcia.

Clarysec Polityka zarządzania aktywami — MŚP wzmacnia tę samą dyscyplinę:

„Własność, cel, uprawnienia dostępu i terminy odnowienia muszą być udokumentowane”.

Wymaganie to znajduje się w Polityce zarządzania aktywami — MŚP, w sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.6.2. Bez własności i celu okres przechowywania staje się zgadywaniem, a usuwanie danych — ryzykowne.

Klasyfikacja jest pierwszym zabezpieczeniem okresu przechowywania

Wiele organizacji próbuje budować harmonogramy retencji, zanim ma wiarygodną klasyfikację. To zwykle się nie udaje.

Jeżeli eksport z systemu obsługi klienta, dokument HR, zapis transakcyjny albo log aplikacyjny nie jest sklasyfikowany, organizacja nie może konsekwentnie zdecydować, kto powinien mieć do niego dostęp, gdzie może być przechowywany, czy może zostać użyty w testach, jak silnie musi być szyfrowany, czy wymaga ochrony w ramach wstrzymania usuwania z przyczyn prawnych ani jak powinien zostać usunięty.

Clarysec Polityka klasyfikacji i oznaczania informacji — MŚP mówi wprost:

„Wszystkie dokumenty, pliki i systemy muszą zostać sklasyfikowane niezwłocznie po ich utworzeniu lub otrzymaniu”.

Wymaganie to znajduje się w Polityce klasyfikacji i oznaczania informacji — MŚP, w sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.1.1.

Korporacyjna Polityka klasyfikacji i oznaczania informacji łączy klasyfikację z pełnym łańcuchem postępowania:

„Wszelkie postępowanie z informacjami, ich przesyłanie, dostęp, przechowywanie i utylizacja muszą być zgodne z poziomem ich klasyfikacji. Co najmniej:”.

Wymaganie to znajduje się w Polityce klasyfikacji i oznaczania informacji, w sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.3.1.

Zenith Blueprint dodaje wskazówki wdrożeniowe dla zabezpieczenia ISO/IEC 27002:2022 5.12, Klasyfikacja informacji. Schemat klasyfikacji powinien definiować poziomy takie jak publiczne, wewnętrzne, poufne i zastrzeżone, obejmować kryteria oparte na szkodzie wynikającej z nieuprawnionego dostępu, utraty lub modyfikacji, mieć zastosowanie do wszystkich form informacji i pozostawać niezależny od formatu przechowywania lub lokalizacji.

Mówiąc prosto: klasyfikacja podąża za treścią, a nie za miejscem przechowywania.

Zbiór danych zastrzeżonych nie staje się mniej ryzykowny tylko dlatego, że został przeniesiony z bazy danych do narzędzia analitycznego SaaS. Zapis objęty wstrzymaniem usuwania z przyczyn prawnych nie traci swojego statusu dlatego, że został wyeksportowany do CSV. Dane osobowe nie przestają podlegać regulacjom dlatego, że pojawiają się w komunikacie logu.

Klasyfikacja powinna stać się metadanymi w rejestrze aktywów, rejestrze retencji, mapie danych, przeglądzie uprawnień dostępu, liście kontrolnej onboardingu chmury i zapisie utylizacji.

Szkielet zabezpieczeń ISO 27001 dla ładu cyklu życia

Najskuteczniejsze programy cyklu życia danych mają szkielet zabezpieczeń. Łączy on zabezpieczenia ISO/IEC 27002:2022 z dowodami operacyjnymi.

Clarysec Zenith Controls: przewodnik po mapowaniu zgodności zapewnia przewodnik po mapowaniu zgodności dla tych działań. Dla ładu cyklu życia danych centralne znaczenie mają trzy zabezpieczenia: 5.33 Ochrona zapisów, 5.34 Prywatność i ochrona PII oraz 8.10 Usuwanie informacji.

W Zenith Controls zabezpieczenie ISO/IEC 27002:2022 5.33, Ochrona zapisów, opisano przez atrybuty zabezpieczenia zapobiegawczego wspierającego poufność, integralność i dostępność, z operacyjnymi zdolnościami w obszarach prawa i zgodności, zarządzania aktywami oraz ochrony informacji. Łączy się ono z kopiami zapasowymi, klasyfikacją, bezpieczną utylizacją sprzętu, wymaganiami prawnymi i regulacyjnymi, zgodnością z politykami, kontrolą dostępu i reagowaniem na incydenty.

Zabezpieczenie 5.34, Prywatność i ochrona PII, wspiera poufność, integralność i dostępność. Zenith Controls wiąże je z inwentarzem aktywów, maskowaniem danych, bezpieczeństwem chmury, klasyfikacją, transferem informacji, kontrolą dostępu, zarządzaniem tożsamością oraz przeglądem bezpieczeństwa projektów i zmian.

Zabezpieczenie 8.10, Usuwanie informacji, ma charakter zapobiegawczy i koncentruje się na poufności. Zenith Controls łączy je z oznaczaniem, transferem informacji, własnością intelektualną, dostępem uprzywilejowanym, maskowaniem danych, zapobieganiem wyciekom danych, ochroną zapisów, zarządzaniem konfiguracją oraz zgodnością z politykami i normami.

Razem te zabezpieczenia tworzą łańcuch cyklu życia.

Ta tabela nie jest przeznaczona wyłącznie dla audytorów. To model operacyjny dla CISO, IOD, menedżerów ds. zgodności i właścicieli biznesowych, którzy potrzebują jednego języka ładu dla prywatności, cyberbezpieczeństwa i odporności.

Zbuduj rejestr retencji przed procesem usuwania

Proces usuwania bez rejestru retencji jest niebezpieczny. Może usunąć zapisy, które muszą zostać zachowane, pominąć dane, które powinny zostać skasowane, albo nie odróżnić usunięcia operacyjnego od wstrzymania usuwania z przyczyn prawnych.

Clarysec Polityka retencji danych i bezpiecznej utylizacji — MŚP ustanawia punkt odniesienia:

„Rejestr retencji jest ustanawiany i utrzymywany oraz zawiera kluczowe kategorie zapisów, wymagania prawne i przypisane okresy przechowywania”.

Wymaganie to znajduje się w Polityce retencji danych i bezpiecznej utylizacji — MŚP, w sekcji „Wymagania dotyczące ładu”, klauzula 5.1.1.

Dla programów korporacyjnych Clarysec Polityka retencji i utylizacji danych definiuje cel:

„Ustanowienie i egzekwowanie spójnych harmonogramów retencji opartych na klasyfikacji informacji, typie aktywów, obowiązujących przepisach i ekspozycji na ryzyko”.

Wymaganie to znajduje się w Polityce retencji i utylizacji danych, w sekcji „Cele”, klauzula 3.3.

Użyteczny rejestr retencji powinien łączyć wymagania prawne, operacyjne, bezpieczeństwa i chmury.

Rejestr retencji małego fintechu może obejmować:

Kluczowe jest to, że okres przechowywania musi być oparty na ryzyku i poparty dowodami. Ograniczenie przechowywania w GDPR wymaga, aby dane osobowe nie były przechowywane dłużej, niż jest to konieczne, ale dopuszcza również przechowywanie, gdy istnieje obowiązek prawny lub uzasadniona potrzeba. NIS2 oczekuje zarządzania aktywami, kontroli dostępu i cyberhigieny. DORA oczekuje udokumentowanego zarządzania ryzykiem ICT i dyscypliny ciągłości działania. Rejestr retencji jest miejscem, w którym te obowiązki stają się decyzjami.

Wstrzymanie usuwania z przyczyn prawnych musi być zaprojektowane procesowo, a nie wysyłane e-mailem

Dojrzały program cyklu życia musi usuwać dane, gdy nie są już potrzebne, ale nie może usuwać zapisów objętych wstrzymaniem usuwania z przyczyn prawnych, dochodzeniem lub obowiązkiem zachowania na potrzeby audytu.

Polityka retencji danych i bezpiecznej utylizacji — MŚP jest jednoznaczna:

„Żaden zapis objęty zabezpieczeniem prawnym i wstrzymaniem usuwania nie może zostać zniszczony ani zmieniony, nawet jeśli jego okres przechowywania wygasł”.

Wymaganie to znajduje się w Polityce retencji danych i bezpiecznej utylizacji — MŚP, w sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.3.4.

Korporacyjna Polityka retencji i utylizacji danych stosuje tę samą zasadę ładu:

„Jeżeli wydano zabezpieczenie prawne i wstrzymanie usuwania (np. w związku z toczącym się postępowaniem sądowym, dochodzeniem lub audytem), dane, które w innym przypadku podlegałyby zniszczeniu, muszą zostać zachowane poza standardowym okresem przechowywania”.

Wymaganie to znajduje się w Polityce retencji i utylizacji danych, w sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.4.1.

Wstrzymanie usuwania z przyczyn prawnych nie powinno być e-mailem, który może, ale nie musi dotrzeć do administratorów systemów. Powinno być statusem w rejestrze retencji, powiązanym z systemami, kategoriami zapisów, opiekunami danych i automatyzacją usuwania.

Możliwy do obrony przepływ pracy wstrzymania usuwania z przyczyn prawnych obejmuje:

• Wyzwalacz, taki jak spór sądowy, zapytanie organu regulacyjnego, incydent bezpieczeństwa, audyt lub dochodzenie wewnętrzne
• Właściciela wstrzymania, zwykle dział prawny lub zgodności
• Objęte kategorie zapisów, systemy i opiekunów danych
• Instrukcje wstrzymania zadań usuwania, wygaśnięcia kopii zapasowych i czyszczenia archiwów
• Ograniczenia dostępu w celu zachowania integralności
• Okresowy przegląd wstrzymania
• Zatwierdzenie zwolnienia i udokumentowany powrót do standardowego okresu przechowywania
• Dowody tego, co zostało zachowane, przez kogo i kiedy

Ma to szczególne znaczenie podczas reagowania na incydenty. Logi, obrazy, eksporty i komunikacja mogą wymagać zachowania nawet wtedy, gdy standardowy okres przechowywania wygasł. Usuwanie musi być kontrolowane na tyle, aby można je było zatrzymać, uzasadnić i wznowić.

Usuwanie danych w chmurze i SaaS to miejsce, w którym ład cyklu życia najczęściej się załamuje

W 2026 roku większość organizacji nie traci kontroli nad cyklem życia w głównej bazie danych. Traci ją w zasobnikach pamięci masowej w chmurze obliczeniowej, eksportach SaaS, platformach wsparcia, załącznikach CRM, przestrzeniach współpracy, logach API, hurtowniach danych, migawkach i skarbcach kopii zapasowych.

Zenith Blueprint, faza „Zabezpieczenia w działaniu”, krok 23, obejmujący zabezpieczenie ISO/IEC 27002:2022 5.23, Bezpieczeństwo informacji przy korzystaniu z usług w chmurze, ostrzega, że dostawcy chmury zabezpieczają infrastrukturę, ale klient pozostaje rozliczalny za dane, konfiguracje, polityki dostępu i gotowość do reagowania na incydenty. Błędnie skonfigurowane zasobniki, publiczne pulpity i nadmierne uprawnienia cloud IAM są niepowodzeniami ładu, a nie niepowodzeniami dostawcy.

Dokument wskazuje również, że korzystanie z chmury musi być traktowane jako część SZBI. Organizacje muszą klasyfikować usługi w chmurze obliczeniowej, rozumieć dane w nich przetwarzane lub przechowywane, oceniać profil bezpieczeństwa dostawcy, ustanawiać klauzule umowne oraz zarządzać zmianami lub rozszerzaniem zakresu.

Clarysec Polityka korzystania z chmury obliczeniowej — MŚP przekłada to na wymagania offboardingu:

„Potwierdzenie procedur bezpiecznego usuwania przed zamknięciem konta”.

Wymaganie to znajduje się w Polityce korzystania z chmury obliczeniowej — MŚP, w sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.3.5.

Korporacyjna Polityka korzystania z chmury obliczeniowej wymaga nadzoru nad:

„Własnością danych oraz ich zwrotem lub usunięciem po zakończeniu współpracy”.

Wymaganie to znajduje się w Polityce korzystania z chmury obliczeniowej, w sekcji „Wymagania dotyczące ładu”, klauzula 5.4.1.

Dla podmiotów finansowych regulowanych DORA nie jest to opcjonalna higiena. Art. 28 DORA wymaga zarządzania ryzykiem stron trzecich ICT, rejestru uzgodnień umownych ICT, due diligence przed zawarciem umowy, uwzględnienia ryzyka koncentracji, prawa audytu i dostępu, praw wypowiedzenia oraz strategii wyjścia dla usług ICT wspierających krytyczne lub istotne funkcje. Art. 30 wymaga postanowień umownych obejmujących opisy usług, lokalizacje przetwarzania i przechowywania, zabezpieczenia dostępności, autentyczności, integralności i poufności, dostęp do danych, odzyskiwanie, zwrot danych, wsparcie przy incydentach i wsparcie przejścia.

Dla podmiotów NIS2 decyzje dotyczące dostawców muszą uwzględniać cyberbezpieczeństwo łańcucha dostaw oraz podatności i odporność produktów i usług. Ład cyklu życia danych musi więc obejmować dostawców, a nie kończyć się na zatwierdzeniu zakupów.

Tygodniowy sprint do utworzenia pakietu kontroli cyklu życia

Nie zaczynaj od próby zmapowania każdego systemu w firmie. Zacznij od jednego przepływu danych wysokiego ryzyka i utwórz powtarzalny pakiet kontroli.

Dzień 1: Wybierz jeden przepływ danych wysokiego ryzyka

Wybierz istotny przepływ danych, taki jak onboarding klienta, zakończenie współpracy pracownika, obsługa sporu płatniczego, zarządzanie zgłoszeniami wsparcia lub rejestrowanie zdarzeń bezpieczeństwa.

Dla fintechu onboarding klienta jest dobrym kandydatem, ponieważ może obejmować dokumenty tożsamości, PII, zapisy transakcyjne, sygnały fraudowe, zewnętrznych dostawców weryfikacji, przechowywanie w chmurze, dostęp wsparcia i regulacyjne okresy przechowywania.

Dzień 2: Zbuduj miniinwentarz aktywów i danych

Użyj Zenith Blueprint, faza „Zabezpieczenia w działaniu”, krok 22, zabezpieczenie ISO/IEC 27002:2022 5.9, aby ująć aktywa fizyczne, cyfrowe, logiczne, związane z usługami oraz oparte na odpowiedzialnościach.

Udokumentuj zebrane kategorie danych, systemy rekordów, platformy SaaS otrzymujące kopie, interfejsy API, integracje, role użytkowników, role uprzywilejowane, lokalizacje kopii zapasowych, lokalizacje archiwów, właściciela danych, właściciela systemu, klasyfikację, flagi PII i zależności od dostawców.

Celem nie jest perfekcja. Celem jest ujawnienie ukrytych punktów replikacji.

Dzień 3: Zastosuj logikę klasyfikacji i dostępu

Zastosuj Politykę klasyfikacji i oznaczania informacji i sklasyfikuj każdą kategorię danych. Następnie sprawdź, czy uprawnienia dostępu odzwierciedlają klasyfikację.

Zastrzeżone dokumenty tożsamości klientów nie powinny być szeroko dostępne przez narzędzia wsparcia. Logi bezpieczeństwa zawierające identyfikatory nie powinny być swobodnie eksportowane do niezarządzanych arkuszy kalkulacyjnych. Dostęp powinien być powiązany z rolą, celem, zatwierdzeniem i dowodami przeglądu.

Dzień 4: Utwórz wpisy dotyczące retencji i wstrzymania usuwania z przyczyn prawnych

Użyj Polityki retencji i utylizacji danych oraz Polityki retencji danych i bezpiecznej utylizacji — MŚP, aby utworzyć wpisy retencyjne dla każdej kategorii zapisów. Uwzględnij podstawę prawną, cel biznesowy, wymóg prawny, okres przechowywania, metodę usuwania i status wstrzymania usuwania z przyczyn prawnych.

Jeżeli istnieje aktywny spór, incydent lub dochodzenie, oznacz wstrzymanie usuwania i zapisz osobę zatwierdzającą.

Dzień 5: Zweryfikuj usuwanie danych w chmurze i u dostawców

Użyj Polityki korzystania z chmury obliczeniowej oraz Polityki korzystania z chmury obliczeniowej — MŚP, aby sprawdzić każdego dostawcę chmury lub SaaS w danym przepływie.

Potwierdź warunki własności danych, zwrotu lub usunięcia po zakończeniu współpracy, terminy usuwania, zachowanie usuwania kopii zapasowych, implikacje dotyczące podwykonawców przetwarzania, dowody usunięcia oraz obowiązki wsparcia przy incydentach.

Dla środowisk DORA zaktualizuj rejestr stron trzecich ICT i plan wyjścia. Dla środowisk NIS2 udokumentuj kwestie ryzyka dostawców oraz zależności cyberhigieny.

Dzień 6: Zdefiniuj dowody i monitorowanie

Dowody nie powinny powstawać dopiero po żądaniu audytowym. Zdefiniuj je podczas projektowania procesu.

Polityka retencji i utylizacji danych wymaga, aby utylizacja była:

„Zarejestrowana w Rejestrze utylizacji, w tym identyfikator aktywa, klasyfikacja, metoda i operator”.

Wymaganie to znajduje się w Polityce retencji i utylizacji danych, w sekcji „Wymagania dotyczące wdrożenia polityki”, klauzula 6.5.3.2.

Silny pakiet dowodowy obejmuje wpisy rejestru retencji, wyniki przeglądów dostępu, zgłoszenia usunięcia, logi rejestru utylizacji, potwierdzenia usunięcia danych w chmurze, zatwierdzenia wstrzymania usuwania z przyczyn prawnych, ustawienia retencji kopii zapasowych, klauzule umów z dostawcami i zapisy przeglądów archiwów.

Dzień 7: Zaktualizuj ryzyka i Deklarację stosowania

Zaktualizuj rejestr ryzyk ISO 27001 i Deklarację stosowania. Jeżeli przegląd cyklu życia ujawnił niezarządzane eksporty SaaS, bezterminowe przechowywanie kopii zapasowych, nadmierny dostęp, niejasne warunki usuwania albo brak własności, są to ryzyka wymagające postępowania.

Ten tygodniowy sprint tworzy powtarzalny pakiet kontroli cyklu życia. Powtórz go dla kolejnego przepływu danych, a następnie dla następnego.

Mapowanie zgodności: jeden program cyklu życia, wiele obowiązków

Wartość ładu cyklu życia danych w ISO 27001 polega na tym, że te same dowody mogą wspierać oczekiwania dotyczące prywatności, cyberhigieny, ryzyka ICT i audytu.

NIST CSF 2.0 jest użyteczny w komunikacji z kierownictwem, ponieważ jego funkcja GOVERN oczekuje, że obowiązki prawne, regulacyjne, umowne i dotyczące prywatności będą rozumiane i zarządzane, apetyt na ryzyko zostanie ustanowiony, rozliczalność kierownictwa będzie jasna, polityki będą egzekwowane, a wyniki przeglądane. Wyniki w obszarze zarządzania aktywami wymagają inwentarzy i zarządzania cyklem życia sprzętu, oprogramowania, systemów, usług i danych.

COBIT 2019 dodaje język ładu dla zarządów i komitetów audytu. Zenith Controls mapuje Ochronę zapisów na procesy COBIT, takie jak zarządzanie kopiami zapasowymi i odtwarzaniem, zarządzanie bezpieczeństwem informacji w spoczynku oraz zarządzanie zapisami. Mapuje Prywatność i ochronę PII na prywatność, ochronę informacji i ład programu prywatności. Mapuje Usuwanie informacji na cele ryzyka i operacji, wzmacniając usuwanie danych jako proces objęty ładem, a nie doraźne zadanie porządkowe.

Co audytorzy faktycznie będą testować

Program ładu cyklu życia jest wiarygodny tylko wtedy, gdy przejdzie testy audytowe.

Audytor ISO/IEC 27001:2022 zacznie od zakresu, wymagań zainteresowanych stron, ryzyk, Deklaracji stosowania, udokumentowanych informacji i dowodów operacyjnej kontroli. W przypadku ładu cyklu życia należy spodziewać się próbkowania. Audytor może wybrać umowę, zapis HR, zestaw logów lub zapis finansowy i prześledzić go przez utworzenie, przechowywanie, kopię zapasową, dostęp i utylizację.

Korzystając z perspektywy audytowej w Zenith Controls dla Ochrony zapisów, audytorzy sprawdzają, czy zapisy w zakresie są zidentyfikowane, czy istnieją harmonogramy retencji, jak zapisy są przechowywane, jak kontrolowany jest dostęp i jak chroniona jest integralność.

Dla Usuwania informacji Zenith Controls wyjaśnia, że audytorzy przeglądają polityki retencji i usuwania, metody usuwania, odpowiedzialności, logi usuwania, ślady audytowe, certyfikaty zniszczenia nośników i dowody z narzędzi sanityzacji. Badają również, czy kopie zapasowe i archiwa są objęte procesem.

Audytor prywatności lub PII przejrzy polityki prywatności, inwentarze danych, DPIA lub PIA, dzienniki szkoleń oraz środki techniczne, takie jak szyfrowanie danych w spoczynku i danych w tranzycie. Może wybrać próbkę żądania osoby, której dane dotyczą, potwierdzić, gdzie znajdują się właściwe dane, zweryfikować, czy zastosowano usunięcie lub ograniczenie, oraz sprawdzić, czy wyjątki takie jak wstrzymanie usuwania z przyczyn prawnych są uzasadnione.

Asesor zorientowany na NIST może zbadać dostosowanie do wyników NIST CSF i technicznych zabezpieczeń, takich jak NIST SP 800-53 AU-11 Audit Record Retention, a także praktyki sanityzacji nośników inspirowane NIST SP 800-88. Może przetestować odtwarzanie kopii zapasowych, skontrolować reguły retencji logów, zweryfikować szyfrowanie i sprawdzić, czy niepotrzebne PII jest minimalizowane.

Audytor COBIT lub ISACA skupi się na procesach ładu i jakości dowodów. Zapyta, kto jest właścicielem zapisów, czy kontrole procesów biznesowych zachowują integralność, czy monitorowanie zgodności wykrywa nadmierne przechowywanie oraz czy operacje obejmują zadania bezpiecznego usuwania.

Typowe wzorce niepowodzeń w ładzie cyklu życia

Clarysec często obserwuje te same wzorce w MŚP i organizacjach regulowanych.

Pierwszy to klasyfikacja bez egzekwowania. Dane są oznaczone jako poufne, ale prawa dostępu, udostępnianie w SaaS, eksporty i metody usuwania się nie zmieniają.

Drugi to retencja bez replik. Harmonogram obejmuje system główny, ale nie logi, kopie zapasowe, hurtownie danych, eksporty wsparcia, arkusze kalkulacyjne ani platformy stron trzecich.

Trzeci to offboarding chmury bez dowodów. Umowa mówi, że dane zostaną usunięte, ale nikt nie zna metody usuwania, osi czasu, zachowania kopii zapasowych ani formatu dowodów.

Czwarty to wstrzymanie usuwania z przyczyn prawnych przez e-mail. Dział prawny wysyła instrukcje, ale zadania usuwania działają dalej, ponieważ żaden system operacyjny nie wykorzystuje statusu wstrzymania.

Piąty to dowody audytowe tworzone po fakcie. Zespoły ręcznie odtwarzają dowody usunięcia i retencji, tworząc niespójności i możliwe do uniknięcia wątpliwości.

Szósty to „wskrzeszenie” danych z kopii zapasowej. Dane usunięte ze środowiska produkcyjnego pojawiają się ponownie podczas odtwarzania lub testowania, ponieważ okres przechowywania kopii zapasowych i logika czyszczenia nigdy nie zostały dostosowane do polityki retencji danych.

Każdemu z tych niepowodzeń można zapobiec, gdy klasyfikacja, inwentarz, retencja, ład chmury, usuwanie i dowody są projektowane jako jeden cykl życia.

Model operacyjny ładu cyklu życia danych Clarysec

Model Clarysec jest prosty: ustanowić szkielet kontroli cyklu życia, a następnie przypiąć do niego obowiązki regulacyjne i dowody.

Szkielet kontroli obejmuje:

• Inwentarz aktywów i danych
• Własność i cel
• Klasyfikację i oznaczanie
• Podstawę prawną i cel przetwarzania
• Rejestr retencji
• Wstrzymanie usuwania z przyczyn prawnych
• Klauzule cyklu życia dla chmury i dostawców
• Kontrolę dostępu i nadzór nad dostępem uprzywilejowanym
• Reguły kopii zapasowych i archiwów
• Bezpieczne usuwanie i rejestr utylizacji
• Rejestrowanie, monitorowanie i materiał dowodowy dotyczący incydentów
• Okresowy przegląd i aktualizacje postępowania z ryzykiem

Zenith Blueprint zapewnia mapę drogową wdrożenia przez kroki „Zabezpieczenia w działaniu” dla inwentarza, klasyfikacji, ładu chmury i usuwania informacji. Zenith Controls zapewnia przewodnik po mapowaniu zgodności pokazujący, jak zabezpieczenia ISO/IEC 27002:2022 łączą się z GDPR, NIS2, DORA, NIST, COBIT, ISO/IEC 27701, ISO/IEC 27018, ISO/IEC 27017, ISO/IEC 27040, ISO 15489 i ISO 22301. Polityki Clarysec dostarczają klauzule operacyjne, które zespoły mogą wdrożyć natychmiast.

Ład cyklu życia nie może funkcjonować wyłącznie w prywatności, bezpieczeństwie lub IT. Musi być współdzielonym systemem zarządzania.

Jeżeli Twoja organizacja nie potrafi odpowiedzieć, gdzie znajdują się dane regulowane, kto jest ich właścicielem, jak długo są przechowywane, co zapobiega usunięciu podczas wstrzymania usuwania z przyczyn prawnych, jak usuwane są dane SaaS i jakie dowody potwierdzają utylizację, teraz jest czas, aby to naprawić.

Zacznij od jednego przepływu danych wysokiego ryzyka. Użyj Zenith Blueprint: 30-etapowej mapy drogowej audytora, aby zbudować fundament inwentarza i klasyfikacji. Użyj Zenith Controls: przewodnika po mapowaniu zgodności, aby zmapować Ochronę zapisów, Prywatność i ochronę PII oraz Usuwanie informacji względem GDPR, NIS2, DORA, NIST i COBIT. Następnie wdroż właściwe polityki Clarysec, w tym Politykę klasyfikacji i oznaczania informacji, Politykę retencji i utylizacji danych, Politykę korzystania z chmury obliczeniowej oraz ich odpowiedniki dla MŚP, jeśli są właściwe.

Praktyczny cel nie polega na ślepym przechowywaniu mniejszej ilości danych. Polega na przechowywaniu właściwych danych, z właściwego powodu, pod właściwymi zabezpieczeniami, przez właściwy czas, z dowodami, które wytrzymają ocenę klientów, regulatorów, audytorów i zarządu.

Pobierz zestawy polityk Clarysec, zmapuj swoje zabezpieczenia z Zenith Controls albo użyj Zenith Blueprint, aby przeprowadzić pierwszy sprint kontroli cyklu życia, zanim następny wniosek o usunięcie stanie się ustaleniem z audytu.