DSAR, usuwanie danych i dowody ISO 27001 w 2026 roku

Wiadomość trafiła do skrzynki Sarah o 9:03.

Nie był to pierwszy Data Subject Access Request, jaki otrzymała jej szybko rosnąca spółka SaaS. Był to jednak pierwszy wniosek, który wyglądał jak publiczny audyt.

Nadawcą był były pracownik, obecnie aktywista zajmujący się prywatnością. Wniosek przywoływał konkretne artykuły GDPR i żądał wszystkich danych osobowych, natychmiastowego ograniczenia przetwarzania, listy każdej usługi zewnętrznej przechowującej jego dane oraz weryfikowalnego dowodu usunięcia danych z systemów produkcyjnych i kopii zapasowych. Do wiadomości dodano dziennikarza.

W ciągu kilku minut ujawniły się luki. Dział inżynierii ostrzegł, że „faktyczne usunięcie” z wielodzierżawnej bazy danych mogłoby wpłynąć na innych klientów. Marketing próbował uporządkować dane użytkownika na platformach analitycznych. Dział prawny znalazł nierozstrzygniętą sprawę pracowniczą. Zespół bezpieczeństwa obawiał się, że logi mogą ujawnić logikę detekcji albo dane innej osoby. Wsparcie miało zapisy pod dwoma adresami e-mail. Finanse miały faktury pod trzecim adresem.

Termin już biegł.

Taki scenariusz nie jest już niczym wyjątkowym. Prawa osób, których dane dotyczą, w 2026 roku nie są problemem skrzynki ds. prywatności. Są kontrolowanym procesem biznesowym, który zależy od inwentarzy aktywów, decyzji dotyczących podstaw prawnych, weryfikacji tożsamości, kontroli dostępu, zasad retencji, blokad prawnych, koordynacji z dostawcami, bezpiecznego ujawniania, dowodów usunięcia i gotowego do audytu rejestrowania zdarzeń.

GDPR określa, jakie prawa mają osoby fizyczne. ISO/IEC 27001:2022 daje zespołom bezpieczeństwa i zgodności dyscyplinę systemu zarządzania potrzebną do wykazania, że prawa te są obsługiwane spójnie, bezpiecznie i powtarzalnie.

Dla CISO, menedżerów zgodności, liderów prywatności i właścicieli biznesowych celem nie jest tworzenie większej liczby dokumentów. Celem jest zbudowanie jednego niezawodnego procesu DSAR, usuwania danych i ograniczania przetwarzania, który generuje dowody wymagane przez GDPR, audyty ISO/IEC 27001:2022 oraz szersze oczekiwania w zakresie zapewnienia zgodności wynikające z NIS2, DORA, NIST CSF 2.0 i COBIT 2019.

Dlaczego doraźna obsługa DSAR zawodzi pod presją

Większość niepowodzeń DSAR nie wynika ze złych intencji. Wynika z fragmentacji.

Organizacja może mieć informację o prywatności, skrzynkę IOD i klauzulę GDPR w umowach z dostawcami, a mimo to mieć trudność z odpowiedzią na podstawowe pytania operacyjne:

• Kto weryfikuje tożsamość wnioskodawcy?
• Który podmiot prawny jest administratorem albo podmiotem przetwarzającym?
• Które systemy należy przeszukać?
• Kto jest właścicielem każdego systemu?
• Które dane mieszczą się w zakresie wniosku?
• Które dane należy zanonimizować lub zamaskować przed ujawnieniem?
• Których danych nie można usunąć ze względu na podatki, audyt, spór sądowy, zapobieganie oszustwom lub obowiązek prawny?
• Jak technicznie egzekwuje się ograniczenie przetwarzania?
• Którzy dostawcy muszą wspierać wyszukiwanie, eksport, usuwanie lub ograniczenie przetwarzania?
• Jakie dowody potwierdzają, że wniosek obsłużono terminowo?
• Co się dzieje, jeśli DSAR ujawnia naruszenie ochrony danych osobowych?

GDPR Article 5 wymaga, aby dane osobowe były przetwarzane zgodnie z prawem, rzetelnie i przejrzyście, zbierane w określonych celach, ograniczone do tego, co niezbędne, prawidłowe, przechowywane nie dłużej niż to konieczne oraz chronione odpowiednimi środkami technicznymi i organizacyjnymi. GDPR Article 5(2) wprost ustanawia rozliczalność: administrator musi być w stanie wykazać zgodność. GDPR Article 4 definiuje przetwarzanie szeroko, obejmując nim m.in. zbieranie, przechowywanie, wykorzystywanie, ujawnianie, ograniczanie, usuwanie i niszczenie.

Oznacza to, że sam proces DSAR jest czynnością przetwarzania. Musi być kontrolowany.

GDPR Article 3 ma również znaczenie dla chmury, SaaS, fintechu i biznesów cyfrowych spoza UE. Jeżeli oferujesz towary lub usługi osobom w Unii, monitorujesz ich zachowanie albo przetwarzasz dane osobowe w kontekście jednostki organizacyjnej w UE, GDPR może mieć zastosowanie nawet wtedy, gdy operacje są realizowane w outsourcingu, a infrastruktura jest globalna.

ISO/IEC 27001:2022 porządkuje tę rzeczywistość. Klauzule 4.1 do 4.4 wymagają, aby organizacja rozumiała swój kontekst, zainteresowane strony, wymagania, zakres SZBI i wzajemnie oddziałujące procesy. Osoba, której dane dotyczą, jest zainteresowaną stroną. Prawa wynikające z GDPR są wymaganiami. Aplikacje SaaS, dostawcy tożsamości, platformy analityczne, narzędzia wsparcia, hurtownie danych i kopie zapasowe w chmurze są wzajemnie oddziałującymi procesami. Proces DSAR należy do SZBI, a nie obok niego.

Trzy prawa osób, których dane dotyczą, wywierające największą presję

Dostęp, usunięcie danych i ograniczenie przetwarzania ujawniają największą lukę między obietnicą prawną a zdolnością operacyjną.

GDPR Article 6 jest centralny dla tej logiki decyzyjnej. Nie można przetwarzać, przechowywać, ujawniać ani odmówić usunięcia danych bez zrozumienia podstawy prawnej. GDPR Article 9 podnosi wymagania dla szczególnych kategorii danych osobowych, takich jak dane dotyczące zdrowia, dane biometryczne używane do jednoznacznej identyfikacji albo dane ujawniające wrażliwe cechy. W środowisku SaaS w 2026 roku może to wpływać na onboarding, weryfikację tożsamości, monitorowanie oszustw, załączniki w obsłudze klienta i rejestry pracowników.

Firmowa Polityka ochrony danych i prywatności [P17] Clarysec ujmuje ten obowiązek wprost. W klauzuli celów 3.6 wymaga od organizacji, aby:

Respektowała prawa osób, których dane dotyczą, w tym dostęp, sprostowanie, usunięcie, ograniczenie przetwarzania, przenoszenie, sprzeciw oraz ochronę przed zautomatyzowanym podejmowaniem decyzji.

Cel ten staje się możliwy do prześledzenia audytowo dopiero wtedy, gdy jest powiązany z właścicielami, rejestrami, procesami, zabezpieczeniami i dowodami.

Zacznij tam, gdzie zaczynają audytorzy: zakres, interesariusze i własność

W Zenith Blueprint: 30-etapowej mapie drogowej audytora [ZB], w fazie podstaw i przywództwa SZBI, krok 2 koncentruje się na potrzebach interesariuszy i zakresie SZBI. Dla GDPR Blueprint wskazuje oczekiwania regulatorów jako:

Regulatorzy UE
(GDPR)

Zgodne z prawem przetwarzanie danych
osobowych, zgłaszanie naruszeń w ciągu 72 godzin,
prawa osób, których dane dotyczą

Wyznaczenie inspektora ochrony danych, ustanowienie
procesu reagowania na naruszenia, procedury
obsługi wniosków dotyczących danych.

To właściwy punkt wyjścia. Przed automatyzacją zgłoszeń albo konfiguracją portali należy zdefiniować zakres przetwarzania związanego z prawami osób, których dane dotyczą:

1. Które podmioty prawne działają jako administrator, współadministrator albo podmiot przetwarzający?
2. Które produkty, usługi i terytoria są objęte zakresem?
3. Jakie kategorie osób, których dane dotyczą, występują, np. klienci, pracownicy, użytkownicy próbni, potencjalni klienci, dostawcy, odwiedzający stronę internetową albo użytkownicy aplikacji?
4. Które systemy, repozytoria i dostawcy przechowują dane osobowe?
5. Które role zatwierdzają ujawnienie, odmowę, usunięcie, ograniczenie przetwarzania albo eskalację?
6. Jakie metryki są raportowane kierownictwu?

Klauzule ISO/IEC 27001:2022 5.1 do 5.3 wymagają przywództwa, dostosowania polityk, zasobów i przypisanych odpowiedzialności. Jest to bezpośrednio zgodne z rozliczalnością GDPR.

Polityka ochrony danych i prywatności [P17], klauzula 6.4.1 wymagań wdrożeniowych polityki, stanowi:

Inspektor ochrony danych (IOD) musi utrzymywać udokumentowane procesy przyjmowania, walidacji, śledzenia i obsługi wniosków osób, których dane dotyczą (DSR).

Dla MŚP Polityka ochrony danych i prywatności - MŚP [P17S] Clarysec stosuje własność dopasowaną do skali. Klauzula 5.2.1 wymagań dotyczących ładu zarządczego stanowi:

Koordynator ds. prywatności musi prowadzić rejestr wszystkich czynności przetwarzania danych osobowych, obejmujący kategorie danych, cel, podstawę prawną oraz okresy retencji.

Ten rejestr przetwarzania jest operacyjnym rdzeniem gotowości do DSAR. Jeżeli jest niekompletny, zespół DSAR szuka według pamięci, wiadomości ze Slacka i wiedzy nieformalnej. Jeżeli jest dokładny, zespół szuka według czynności przetwarzania, kategorii danych, właściciela systemu, dostawcy i zasady retencji.

Proces DSAR Clarysec: od przyjęcia do zamknięcia

Gotowy do audytu proces DSAR powinien być na tyle prosty, aby działał pod presją, i na tyle kontrolowany, aby wytrzymał kontrolę regulatora, przegląd zapewnienia dla klienta albo audyt ISO/IEC 27001:2022.

1. Przyjęcie i potwierdzenie

Wnioski powinny trafiać do kontrolowanego kanału, takiego jak skrzynka ds. prywatności, portal, formularz wsparcia albo kolejka przyjęcia spraw prawnych. Personel musi rozpoznawać wnioski sformułowane potocznym językiem. Osoba nie musi napisać „DSAR”, aby wykonać swoje prawo. „Jakie dane macie na mój temat?” albo „usuńcie mój profil” może wystarczyć do uruchomienia procesu.

Polityka ochrony danych i prywatności - MŚP [P17S], klauzula 6.5.2 wymagań wdrożeniowych polityki, określa jasny poziom obsługi:

Koordynator ds. prywatności musi potwierdzać otrzymanie wniosków w ciągu 3 dni roboczych i odpowiadać w ciągu 30 dni.

Potwierdzenie powinno obejmować numer referencyjny wniosku, doprecyzowanie zakresu, jeżeli jest potrzebne, instrukcje weryfikacji tożsamości i oczekiwany termin odpowiedzi.

2. Weryfikacja tożsamości i sprawdzenie umocowania

DSAR może stać się naruszeniem ochrony danych osobowych, jeżeli informacje zostaną wysłane do niewłaściwej osoby. Weryfikacja powinna być proporcjonalna i nie powinna gromadzić nadmiernych nowych danych osobowych. Tam, gdzie to możliwe, należy korzystać z uwierzytelnionych portali. W przypadku byłych użytkowników należy walidować dane względem znanych danych konta. W przypadku pracowników należy koordynować działania z HR. W przypadku pełnomocników należy wymagać dowodu umocowania.

Należy zachować dowody metody weryfikacji, daty zakończenia, osoby zatwierdzającej, wszelkich dodatkowych żądanych informacji oraz decyzji w przypadku niepowodzenia weryfikacji.

3. Klasyfikacja wniosku

Jedna wiadomość może zawierać kilka praw. Każde z nich należy sklasyfikować oddzielnie, ponieważ dostęp, usunięcie danych, ograniczenie przetwarzania, sprzeciw i przenoszenie wymagają odmiennej logiki decyzyjnej i dowodów. Należy również oznaczyć potencjalne skargi, sprawy pracownicze, dane dzieci, szczególne kategorie danych oraz potencjalne naruszenia ochrony danych osobowych.

4. Przeszukuj inwentarz, a nie tylko oczywiste systemy

W tym miejscu ISO/IEC 27001:2022 staje się praktyczne. Zenith Blueprint [ZB], faza zabezpieczeń w działaniu, krok 22, ostrzega, że zakres inwentarza jest szerszy, niż zakłada wiele organizacji:

Zakres tego inwentarza jest szerszy, niż większość zakłada. Powinien obejmować:

✓ Aktywa fizyczne: laptopy, serwery, telefony, taśmy kopii zapasowych, nośniki wymienne, wydrukowane
rejestry.
✓ Aktywa cyfrowe: dokumenty, zbiory danych, repozytoria, wiadomości e-mail, kod źródłowy, pliki przechowywane
w chmurze.
✓ Aktywa logiczne: konta użytkowników, poświadczenia, klucze, licencje oprogramowania, interfejsy API.
✓ Aktywa związane z usługami: platformy SaaS, zarządzane usługi bezpieczeństwa, outsourcingowe
przechowywanie.
✓ Ludzie jako aktywa: nie w sensie uprzedmiotowienia, lecz w zakresie przypisanych odpowiedzialności,
dostępu i ekspozycji na informacje wynikającej z roli.

Krok 22 wyjaśnia również własność:

Każde aktywo powinno mieć zdefiniowanego właściciela, nie osobę, która go używa, lecz osobę rozliczalną za
jego użycie, ochronę i cykl życia. Własność jest kluczowa dla dostosowania zabezpieczeń: kto klasyfikuje
aktywo (5.10), kto decyduje o poziomie jego dostępu (8.3), kto obsługuje jego usunięcie (8.10), kto zapewnia
jego zwrot (5.9 subtelnie nakłada się na procedury zwrotu aktywów).

W Zenith Controls: przewodniku po zgodności międzyramowej [ZC] zabezpieczenie ISO/IEC 27002:2022 5.9, Inwentarz informacji i innych powiązanych aktywów, jest traktowane jako zabezpieczenie prewencyjne wspierające poufność, integralność i dostępność. Jego koncepcją cyberbezpieczeństwa jest Identify, zdolnością operacyjną jest Asset Management, a domeny bezpieczeństwa obejmują Governance, Ecosystem i Protection.

Dla DSAR oznacza to, że inwentarz nie jest arkuszem IT. Jest mapą, która wskazuje zespołom prywatności, prawnym i bezpieczeństwa, gdzie mogą istnieć dane osobowe.

5. Przegląd, maskowanie danych i zatwierdzenie ujawnienia

Odpowiedź na DSAR nie powinna być surowym eksportem. Przegląd musi chronić dane osobowe innych osób, poufne informacje biznesowe, tajemnicę zawodową prawnika, dane wrażliwe z perspektywy bezpieczeństwa, sygnały oszustw oraz dane poza zakresem wniosku.

Zatwierdzenie powinno być oparte na ryzyku. Rutynowe odpowiedzi na wnioski o dostęp mogą być zatwierdzane przez Koordynatora ds. prywatności albo IOD. Wnioski dotyczące pracowników, sporów sądowych, szczególnych kategorii danych, dzieci, oszustw, logów bezpieczeństwa albo dużych eksportów powinny angażować dział prawny, HR albo kierownictwo bezpieczeństwa.

6. Bezpieczne przekazanie

Nie należy załączać dużych niezaszyfrowanych plików do wiadomości e-mail. Należy używać uwierzytelnionych portali, zaszyfrowanych plików z oddzielnym przekazaniem hasła albo bezpiecznych linków transferowych z datą wygaśnięcia i rejestrowaniem dostępu. Należy odnotować metodę przekazania, datę, konto odbiorcy, datę wygaśnięcia oraz potwierdzenie, jeśli jest dostępne.

7. Zamknięcie z dowodami

Polityka ochrony danych i prywatności [P17], klauzula 6.4.3, jest jednoznaczna:

Wszystkie podjęte działania muszą być rejestrowane na potrzeby audytu, w tym decyzje o odmowie realizacji wniosków.

Polityka ochrony danych i prywatności - MŚP [P17S], klauzula 6.5.4, stanowi:

Wszystkie odpowiedzi na wnioski osób, których dane dotyczą, muszą być rejestrowane w bezpiecznym rejestrze, z dostępem ograniczonym do Koordynatora ds. prywatności i dyrektora generalnego.

DSAR nie jest zakończony w chwili wysłania wiadomości e-mail. Jest zakończony, gdy rejestr pokazuje wniosek, sprawdzenie tożsamości, decyzje, przeszukane systemy, odpowiedź, wyjątki, zatwierdzenia, przekazanie i zamknięcie.

Usunięcie danych to kontrolowane zniszczenie, a nie przycisk „usuń”

Wnioski o usunięcie danych pokazują, czy prywatność została wbudowana w systemy, czy dodana po uruchomieniu.

Firmowa Polityka retencji i utylizacji danych [P14] Clarysec, klauzula 4.3.3 ról i odpowiedzialności, przypisuje odpowiedzialność roli, która:

Odpowiada na wnioski o usunięcie danych i zapewnia terminowe, weryfikowalne usunięcie danych osobowych tam, gdzie jest to wymagane.

Zwrot „tam, gdzie jest to wymagane” ma kluczowe znaczenie. Usunięcie danych w GDPR nie jest bezwzględne. Organizacje mogą być zobowiązane do zachowania danych ze względu na obowiązki prawne, audyt, podatki, obowiązki regulacyjne, zapobieganie oszustwom, bezpieczeństwo, spory sądowe albo ustalenie, dochodzenie lub obronę roszczeń. Proces musi obejmować decyzję dotyczącą zgodnego z prawem przechowywania oraz wyjątku.

Zenith Blueprint [ZB], faza zabezpieczeń w działaniu, krok 19, wyjaśnia zabezpieczenie ISO/IEC 27002:2022 8.10, Usuwanie informacji, w kategoriach operacyjnych:

To zabezpieczenie zapewnia, że dane nie są przechowywane dłużej niż to konieczne, a gdy nie są już
potrzebne, muszą zostać bezpiecznie i niezawodnie usunięte. Wiele organizacji z czasem gromadzi duże
wolumeny danych, ale bez jasnego procesu usuwania dane te mogą pozostawać bezczynne i
niezabezpieczone, po cichu zwiększając ryzyko ujawnienia, naruszenia albo naruszenia regulacyjnego.

Ostrzega również:

Nie zapominaj o kopiach zapasowych i systemach archiwalnych; często przechowują one dane historyczne długo po utracie ich
wartości operacyjnej. Polityki usuwania muszą obejmować:

✓ ustawienia retencji kopii zapasowych,
✓ cykle życia migawek,
✓ archiwalne repozytoria poczty e-mail lub dokumentów.

I kończy dowodami:

Sam proces usuwania musi być rejestrowany, a w przypadku danych wysokiego ryzyka lub danych regulowanych
przeglądany albo zatwierdzany. Zapewnia to identyfikowalność i chroni przed przypadkowym lub
nieuprawnionym zniszczeniem wartościowych zapisów.

W Zenith Controls [ZC] zabezpieczenie ISO/IEC 27002:2022 8.10, Usuwanie informacji, jest mapowane jako zabezpieczenie prewencyjne ukierunkowane na poufność, zgodne z koncepcją cyberbezpieczeństwa Protect i powiązane ze zdolnościami operacyjnymi Information protection oraz Legal and compliance.

W złożonych architekturach chmurowych usuwanie kryptograficzne może być właściwe, jeśli zostało poprawnie zaprojektowane. Jeżeli dane osobowe są szyfrowane kluczem specyficznym dla osoby albo dzierżawcy, zniszczenie klucza może trwale uniemożliwić dostęp do danych, również wtedy, gdy zaszyfrowane pozostałości pozostają w kopiach zapasowych do czasu zaplanowanej rotacji. Musi to być starannie zaprojektowane, udokumentowane, przetestowane i zatwierdzone. Nie jest to obejście dla słabej architektury usuwania.

Gotowość aplikacji jest zatem niezbędna. Polityka wymagań bezpieczeństwa aplikacji - MŚP [P09S] Clarysec, klauzula 6.5.1.3, wymaga, aby aplikacje:

umożliwiały bezpieczny eksport i usuwanie danych osobowych, gdy jest to wymagane prawem (np. GDPR Article 17 – prawo do usunięcia danych).

Jeżeli zespoły produktowe nie zbudują funkcji eksportu i usuwania, zespoły ds. prywatności są zmuszone do stosowania skryptów bazodanowych, zgłoszeń do dostawców i niespójnej pracy ręcznej.

Blokada prawna i wstrzymanie usuwania

Dojrzały proces usuwania danych musi obejmować ścieżkę „nie usuwać”. Nie jest to wymówka do ignorowania usunięcia danych. Jest to kontrolowany wyjątek.

Polityka Clarysec dla MŚP Polityka retencji danych i bezpiecznej utylizacji - MŚP [P14S], klauzula 5.4 wymagań dotyczących ładu zarządczego, stanowi:

Dane objęte blokadą prawną i wstrzymaniem usuwania (np. w przypadku sporu sądowego, audytu lub dochodzenia) muszą być wyraźnie oznaczone w systemie i chronione przed usunięciem, nawet jeśli zaplanowany okres retencji upłynął.

Polityka retencji i utylizacji danych [P14], klauzula 6.4.1, odzwierciedla tę samą zasadę:

Jeżeli wydano blokadę prawną i wstrzymanie usuwania (np. w związku z trwającym sporem sądowym, dochodzeniem lub audytem), dane, które w innym przypadku podlegałyby zniszczeniu, muszą być zachowane poza ich normalny okres retencji.

Audytorzy chcą widzieć obie strony: dowody terminowego usunięcia i dowody uzasadnionego zachowania danych.

Ograniczenie przetwarzania: niedoceniane prawo

Wnioski o ograniczenie przetwarzania nie zawsze wymagają usunięcia danych. Wymagają ograniczenia aktywnego przetwarzania przy jednoczesnym zachowaniu danych w kontrolowanych warunkach.

Typowe przykłady obejmują:

• Klient kwestionuje prawidłowość danych i prosi o zaprzestanie ich używania do czasu weryfikacji.
• Były pracownik sprzeciwia się przetwarzaniu, ale zapis jest potrzebny do roszczeń prawnych.
• Użytkownik żąda usunięcia danych, ale minimalne dane muszą zostać zachowane w celu utrzymania listy wykluczeń.
• Dochodzenie w sprawie oszustwa wymaga zachowania danych, ale nie ich normalnego użycia operacyjnego.

Praktyczny proces ograniczenia przetwarzania powinien obejmować decyzję prawną, flagę systemową, zmianę kontroli dostępu, wykluczenie z marketingu, wyłączenie z analityki, instrukcję dla dostawcy, okresowy przegląd i dowody wyjątków.

W Zenith Controls [ZC] zabezpieczenie ISO/IEC 27002:2022 5.34, Prywatność i ochrona PII, jest traktowane jako zabezpieczenie prewencyjne wspierające poufność, integralność i dostępność. Mapuje się do Identify i Protect, z operacyjnymi zdolnościami Information Protection oraz Legal and Compliance.

Zenith Blueprint [ZB], faza zabezpieczeń w działaniu, krok 23, podsumowuje test audytowy:

Potwierdź, że organizacja wdrożyła środki prywatności (5.34) zgodne z
mającymi zastosowanie wymaganiami prawnymi. Zweryfikuj klasyfikację PII, właściwe kontrole dostępu, bezpieczne
praktyki postępowania oraz szkolenie uświadamiające. Sprawdź, czy wnioski o dostęp osoby, której dane dotyczą,
usuwanie danych albo logi przetwarzania są wspierane operacyjnie, a nie tylko przez politykę.

Kluczowe sformułowanie brzmi: „wspierane operacyjnie, a nie tylko przez politykę”.

Mapowanie procesów DSAR na dowody ISO/IEC 27001:2022

ISO/IEC 27001:2022 nie zastępuje GDPR. Porządkuje dowody.

Klauzule 6.1.1 do 6.1.3 wymagają oceny ryzyka, postępowania z ryzykiem, kryteriów akceptacji ryzyka, właścicieli ryzyka, doboru zabezpieczeń, Deklaracji stosowania i planu postępowania z ryzykiem. Ryzyka DSAR obejmują nieuprawnione ujawnienie, przekroczenie terminów, niepełne usunięcie danych, bezprawne przechowywanie, nadmierną weryfikację tożsamości, brak współpracy dostawcy i brak możliwości ograniczenia przetwarzania.

Klauzula 8.1 wymaga od organizacji planowania, wdrażania i kontrolowania procesów SZBI, zachowania udokumentowanych dowodów, kontrolowania zmian oraz zapewnienia, że zewnętrznie dostarczane procesy, produkty i usługi istotne dla SZBI są kontrolowane. Pasuje to do operacji DSAR, ponieważ wnioski przechodzą przez funkcje wewnętrzne i zewnętrzne podmioty przetwarzające.

Silny pakiet dowodowy obejmuje procedurę DSR, rejestr DSR, rejestr czynności przetwarzania, inwentarz aktywów, harmonogram retencji danych, rejestr blokad prawnych, procedurę weryfikacji tożsamości, wytyczne maskowania danych, bezpieczną metodę ujawniania, procedurę usuwania, procedurę ograniczania przetwarzania, podręcznik postępowania dla dostawców, rejestr wyjątków, zapisy szkoleń, wyniki audytu wewnętrznego i raportowanie z przeglądu zarządzania.

Praktyczny proces dla dostępu, usuwania danych i ograniczenia przetwarzania

Ten proces przekształca kryzys Sarah w proces możliwy do audytu. Każdy etap ma właściciela, podstawę kontrolną i dowody.

Wartość zgodności międzyramowej poza GDPR

Proces DSAR jest zakorzeniony w GDPR, ale te same zabezpieczenia wspierają szersze frameworki.

NIS2 Article 20 czyni cyberbezpieczeństwo odpowiedzialnością zarządzających dla podmiotów kluczowych i ważnych. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych, w tym analizy ryzyka, obsługi incydentów, ciągłości działania, bezpieczeństwa łańcucha dostaw, oceny skuteczności, cyberhigieny, szkoleń, kontroli dostępu, zarządzania aktywami, uwierzytelniania i bezpiecznej komunikacji. DSAR opiera się na wielu z tych samych zdolności.

DORA ma zastosowanie od 17 stycznia 2025 r. do wielu podmiotów finansowych i ustanawia jednolite wymagania dotyczące zarządzania ryzykiem ICT, zgłaszania incydentów, testowania odporności i ryzyka związanego z zewnętrznymi dostawcami usług ICT. Articles 5 i 6 wymagają ładu zarządczego i udokumentowanego zarządzania ryzykiem ICT. Articles 17 do 20 dotyczą wykrywania, klasyfikacji, eskalacji, komunikacji i zamykania incydentów. Articles 24 do 30 dotyczą testowania odporności, ryzyka zewnętrznych dostawców usług ICT, rejestrów usług, praw do audytu, lokalizacji danych, wsparcia w obsłudze incydentów i strategii wyjścia. Fintech obsługujący DSAR przez platformy chmurowe powinien dostosować obsługę wniosków dotyczących prywatności do swojego rejestru usług ICT.

NIST CSF 2.0 pomaga przełożyć tę samą pracę na wyniki cyberbezpieczeństwa. GOVERN obejmuje wymagania prawne, regulacyjne i umowne, strategię ryzyka, role, politykę i nadzór. IDENTIFY i PROTECT silnie wiążą się z widocznością aktywów, klasyfikacją danych, kontrolą dostępu, usuwaniem, nadzorem nad dostawcami i ochroną prywatności.

COBIT 2019 zadaje pytania dotyczące ładu zarządczego. Kto jest właścicielem procesu? Jakie cele zdefiniowano? Jak mierzy się wyniki? Jak zatwierdza się wyjątki? Jak uzyskuje się zapewnienie? Dowody DSAR mogą wspierać cele takie jak APO13 Managed Security, APO14 Managed Data i DSS06 Managed Business Process Controls.

Perspektywa audytora

Nie twórz oddzielnych dowodów dla każdego frameworku. Stwórz jeden niezawodny proces DSAR i dobrze go zmapuj.

Metryki DSAR, które powinno widzieć kierownictwo

Kierownictwo nie może nadzorować tego, czego nie widzi. Użyteczne metryki obejmują wolumen wniosków według rodzaju prawa, średni czas potwierdzenia, średni czas zamknięcia, terminowość, wskaźniki doprecyzowania tożsamości, wyjątki od usuwania, przypadki blokady prawnej, czasy odpowiedzi dostawców, częściowe odmowy, incydenty zidentyfikowane podczas obsługi oraz otwarte działania naprawcze.

Te metryki pokazują, czy prawa osób, których dane dotyczą, są operacyjnie zdrowe, czy zależą od działań heroicznych.

Typowe luki w gotowości do DSAR

Clarysec często obserwuje te same słabości w SaaS, fintechu, usługach profesjonalnych i MŚP działających przede wszystkim w chmurze:

• Brak właściciela dla każdego systemu zawierającego dane osobowe
• Rejestr przetwarzania niedostosowany do rzeczywistego użycia SaaS
• Platformy marketingowe, analityczne i hurtownie danych wyłączone z wyszukiwań
• Brak udokumentowanego standardu weryfikacji tożsamości
• Brak przeglądu maskowania danych przed ujawnieniem
• Usunięcie w produkcji wykonane bez uwzględnienia kopii zapasowych
• Brak sprawdzenia blokady prawnej przed usunięciem
• Ograniczenie obsługiwane ręcznie bez flagi systemowej
• Umowy z dostawcami bez warunków wsparcia DSAR
• Odmowy i częściowe odmowy nieudokumentowane
• Brak próbkowania zakończonych DSAR w audycie wewnętrznym
• Personel pierwszej linii nieprzeszkolony w rozpoznawaniu wniosków

Twoja lista kontrolna gotowości do DSAR na 2026 rok

Użyj jej jako testu dojrzałości:

• Czy mamy udokumentowany proces przyjmowania, walidacji, śledzenia i obsługi DSR?
• Czy potwierdzamy otrzymanie wniosków w ramach zdefiniowanego wewnętrznego SLA?
• Czy prowadzimy bezpieczny rejestr DSR z ograniczonym dostępem?
• Czy mamy aktualny rejestr czynności przetwarzania z kategoriami, celami, podstawami prawnymi i okresami retencji?
• Czy znamy każdy system, platformę SaaS, repozytorium i dostawcę, który może przechowywać dane osobowe?
• Czy każde istotne aktywo ma rozliczalnego właściciela?
• Czy możemy bezpiecznie eksportować dane osobowe?
• Czy możemy bezpiecznie usuwać dane osobowe tam, gdzie jest to wymagane prawem?
• Czy możemy technicznie albo proceduralnie ograniczyć przetwarzanie?
• Czy sprawdzamy blokadę prawną przed usunięciem?
• Czy dokumentujemy decyzje o odmowie, częściowej odmowie i wyjątkach?
• Czy umowy z dostawcami wspierają obsługę DSAR?
• Czy testujemy proces poprzez audyt wewnętrzny albo ćwiczenia typu tabletop?
• Czy raportujemy wyniki DSAR kierownictwu?
• Czy mapujemy zabezpieczenia DSAR na postępowanie z ryzykiem ISO/IEC 27001:2022 i Deklarację stosowania?

Jeżeli kilka odpowiedzi brzmi „niekonsekwentnie”, kolejny wniosek może ujawnić lukę.

Przekształć prawa osób, których dane dotyczą, w gotowe do audytu dowody

Prawa osób, których dane dotyczą, w 2026 roku wymagają więcej niż dobrych intencji i skrzynki ds. prywatności. Wymagają procesu, który potrafi znaleźć dane, zweryfikować tożsamość, podejmować decyzje zgodne z prawem, koordynować dostawców, chronić ujawnianie, realizować usunięcie, egzekwować ograniczenie przetwarzania i zachować dowody.

Clarysec pomaga organizacjom zbudować ten proces bez tworzenia równoległej biurokracji zgodności. Zacznij od Zenith Blueprint, aby umieścić prawa osób, których dane dotyczą, we właściwej fazie i krokach SZBI. Użyj polityk Clarysec: Polityka ochrony danych i prywatności, Polityka ochrony danych i prywatności - MŚP, Polityka retencji i utylizacji danych, Polityka retencji danych i bezpiecznej utylizacji - MŚP oraz Polityka wymagań bezpieczeństwa aplikacji - MŚP, aby zdefiniować własność i zasady operacyjne.

Następnie użyj Zenith Controls, aby zmapować zabezpieczenia ISO/IEC 27002:2022 5.9, 5.34 i 8.10 na dowody zgodności międzyramowej dla zapewnienia zgodności z GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 i COBIT 2019.

Jeżeli chcesz wiedzieć, czy Twoje procesy DSAR, usuwania danych i ograniczania przetwarzania przetrwałyby jutro audyt, Clarysec może pomóc przetestować proces, zamknąć luki i zbudować pakiet dowodowy, zanim nadejdzie kolejny wniosek. Pobierz właściwe szablony polityk Clarysec albo umów ocenę gotowości do DSAR, aby przejść od reaktywnej obsługi do kontrolowanych, gotowych do audytu operacji prywatności.