Według raportu IBM Cost of a Data Breach Report 2025 średni koszt naruszenia wynosi 4.44 mln dolarów. Naruszenia danych osobowych pociągają za sobą najwyższe kary regulacyjne na mocy RODO i HIPAA, nie dlatego, że ich naprawa jest technicznie droższa, ale dlatego, że organy regulacyjne traktują je inaczej. Kary wynikające z RODO mogą sięgać czterech procent globalnych rocznych przychodów. Kary cywilne wynikające z HIPAA sięgają 1.9 mln dolarów rocznie za każdą kategorię naruszenia. Narażenie organizacji na ryzyko wynikające z pojedynczego naruszenia systemu, którego inwentaryzacja danych osobowych była niekompletna, ponieważ program wykrywania, który powinien był je wykryć, obejmował tylko nowoczesny stos i zatrzymywał się na granicy komputera mainframe, nie jest problemem inżynierii danych. Jest to ryzyko regulacyjne i finansowe, które znajduje się w programie zarządu.
Większość organizacji nie jest w stanie na żądanie utworzyć kompletnego spisu danych osobowych (PII). Standardowe narzędzia do wykrywania danych osobowych (PII), takie jak Varonis, IBM Guardium, BigID, Microsoft Purview i Strac, doskonale sprawdzają się w skanowaniu ustrukturyzowanych baz danych, pamięci masowej w chmurze, platform SaaS i udziałów plików. Łączą się z tym, z czym mogą się połączyć. Tego, z czym nie mogą się połączyć, nie mogą skanować. Pliki VSAM w systemie z/OS nie posiadają złączy JDBC. Programy COBOL, które przechowują dane klientów w pamięci masowej (WORKING-STORAGE) podczas przetwarzania wsadowego, nie udostępniają danych za pośrednictwem interfejsów API. Definicje zbiorów danych JCL nie są rejestrowane w katalogu danych. Warstwa mainframe, która przetwarza 95% transakcji ATM i obsługuje szacowany na 3 biliony dolarów dzienny handel, jest największą, najbardziej zagęszczoną pod względem PII i najbardziej systematycznie niedoskanowaną warstwą w korporacyjnych zasobach danych. Nie można chronić tego, czego nie można znaleźć, a większość organizacji nie znalazła jeszcze wszystkiego.
Dane osobowe, do których Twój katalog nie może dotrzeć
SMART TS XL śledzi dane osobowe od źródła VSAM poprzez programy COBOL do każdego podrzędnego zestawu danych, który je dziedziczy.
DOWIEDZ SIĘ WIĘCEJ…Dlaczego warstwa legacy jest najtrudniejszą częścią odkrywania informacji osobowych
Standardowe wyzwanie w zakresie wykrywania danych osobowych (PII), czyli wyszukiwanie nazwisk, adresów, numerów ubezpieczenia społecznego i danych kart płatniczych rozproszonych w setkach baz danych i udziałów plików, jest trudne, ale możliwe do rozwiązania dzięki nowoczesnym narzędziom. Metody dopasowywania wzorców, które stanowią podstawę większości narzędzi do wykrywania danych osobowych (PII), dobrze sprawdzają się w przypadku danych ustrukturyzowanych z dostępnymi łącznikami: skanowanie kolumn, stosowanie wzorców wyrażeń regularnych, oznaczanie pól pasujących do sygnatur PII, klasyfikowanie i inwentaryzacja.
Warstwa legacy wprowadza cztery właściwości, które łamią podejście dopasowywania wzorców:
Skrócone nazwy pól bez sygnału semantycznego. Nazwy pól w języku COBOL są w nowoczesnych dialektach ograniczone do 30 znaków, a w starszym kodzie były powszechnie zapisywane w skróconej, 8-znakowej formie: CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DTSkaner dopasowujący wzorce, który identyfikuje social_security_number or customer_name jako wskaźniki polowe PII nie mają podstaw do klasyfikacji SSN-NO or CUST-NM bez zrozumienia konwencji nazewnictwa języka COBOL. Konwencja skrótów sama w sobie stanowi problem metadanych. Pole zawiera dane osobowe, ale jego nazwa nie sygnalizuje tego jednoznacznie skanerowi zaprojektowanemu zgodnie z nowoczesnymi konwencjami nazewnictwa.
PII osadzone w strukturach kompozytowych. Rekordy COBOL często pakują wiele elementów danych do jednego pola lub używają REDEFINES do nakładania różnych interpretacji na te same bajty. Pole rekordu klienta CUST-FULL-DATA zdefiniowana jako PIC X(100) może zawierać imię, adres i numer telefonu połączone w jeden ciąg z podpolami o stałej pozycji, strukturę, która jest widoczna jako pojedyncze nieprzezroczyste pole tekstowe dla dowolnego skanera odczytującego wyłącznie definicję pola, bez zrozumienia logiki programu, która je wypełnia i odczytuje.
Dane osobowe przesyłane przez WORKING-STORAGE. Programy wsadowe w języku COBOL często odczytują dane osobowe z plików VSAM, przetwarzają je w zmiennych WORKING-STORAGE i zapisują dane wyjściowe do zestawów danych. Dane osobowe znajdują się w WORKING-STORAGE podczas wykonywania programu, w pamięci, a nie w trwałym magazynie danych, a następnie znikają po zakończeniu działania programu. Skanowanie w pamięci trwałej w celu odkrycia danych znajduje źródło VSAM i wyjściowy zestaw danych, ale nie pośrednik przetwarzania, w którym dane są agregowane, transformowane i potencjalnie rejestrowane.
Dane osobowe przekraczające granicę IT/OT za pośrednictwem interfejsów plików płaskich. Dane klientów wyodrębnione z plików VSAM komputerów mainframe często trafiają do systemów niższego rzędu za pośrednictwem interfejsów plików płaskich, ekstraktów CSV, plików rekordów o stałej długości, plików w formacie pozycyjnym, które nie zawierają metadanych kolumn. Plik płaski zawiera dane osobowe w określonych pozycjach bajtów, ale skaner odbierający plik nie ma schematu mapowania pozycji na znaczenia pól, chyba że analizowany jest również wpis w pliku FD języka COBOL, który definiuje układ rekordu.
Wyzwanie dotyczące inwentaryzacji PII w podzielonym majątku
Przedsiębiorstwo posiadające zarówno starsze systemy mainframe, jak i nowoczesne platformy chmurowe, stoi przed wyzwaniem inwentaryzacji danych osobowych (PII), które obejmuje dwa zasadniczo różne podejścia do wyszukiwania. Warstwa nowoczesna jest dostępna dla standardowych narzędzi. Warstwa tradycyjna wymaga innej metody. Wymóg zgodności, prawo do usunięcia danych wynikające z RODO, minimalny wymagany standard HIPAA, zakres danych posiadacza karty PCI-DSS oraz inwentaryzacja danych konsumentów zgodnie z CCPA, mają zastosowanie do obu warstw w równym stopniu. Wniosek o dostęp do danych osobowych osoby, której dane dotyczą, zgodnie z RODO, wymaga inwentaryzacji wszystkich danych osobowych przechowywanych na temat konkretnej osoby we wszystkich systemach, a nie tylko tych, które łączą się z katalogiem danych.
Inwentarz majątku osobistego w podziale majątku składa się z trzech elementów, które muszą ze sobą współdziałać:
Nowoczesny inwentarz danych , bazy danych w chmurze, platformy SaaS, magazyny danych, logi API i udziały plików są obsługiwane za pomocą standardowych narzędzi do wykrywania danych osobowych (PII). Narzędzia z tej kategorii skanują w poszukiwaniu wzorców danych osobowych (PII), klasyfikują je zgodnie z przepisami i integrują się z platformami katalogów danych, tworząc ustrukturyzowane inwentaryzacje. IBM Guardium obejmuje ustrukturyzowane bazy danych i bazy danych mainframe (DB2) z klasyfikacją opartą na regułach. Microsoft Purview obejmuje usługi chmurowe Microsoft. BigID i Varonis obejmują szersze ekosystemy, w tym dane nieustrukturyzowane.
Starsze inwentaryzacje danych , pliki VSAM, schematy DB2 komputerów mainframe, program COBOL WORKING-STORAGE, definicje zestawów danych JCL wymagają analizy kodu źródłowego w celu zidentyfikowania miejsca, w którym definiowane, przechowywane i przetwarzane są dane osobowe (PII). Analiza ta odczytuje programy COBOL, aby zrozumieć, jakie dane przetwarzają, a nie tylko do jakich baz danych zapisują.
Inwentaryzacja przepływów danych między granicami , czyli ścieżki, którymi dane osobowe (PII) przemieszczają się ze starszych systemów na nowoczesne platformy, często za pośrednictwem interfejsów plików płaskich, które nie zawierają schematu, wymaga śledzenia pochodzenia danych od źródła COBOL, poprzez strumienie zadań JCL, do punktów końcowych, w których dane docierają do systemów z możliwością połączenia. Plik płaski, który co noc opuszcza komputer mainframe, nie jest oznaczany tagiem PII, dopóki schemat definiujący układ jego rekordów nie zostanie połączony z definicjami kolumn w docelowym zestawie danych.
Organizacje, które tworzą kompletne inwentaryzacje danych osobowych, to te, które uwzględniły wszystkie trzy komponenty. Organizacje, które nie przeszły audytów RODO lub przeglądów HIPAA, często uwzględniły pierwszy komponent, zakładając, że pozostałe zostały uwzględnione.
Wzorce PII specyficzne dla języka COBOL i jak je znaleźć
Wzorzec 1: Bezpośrednie dane osobowe w wpisach FD i kopiach
Najprostszy wzorzec PII w COBOL: pole we wpisie FD lub elemencie COPY, którego nazwa, typ lub kontekst jednoznacznie wskazują na PII. Nawet przy skróconych konwencjach nazewnictwa, pewne wzorce są stale obecne:
kobol
01 CUSTOMER-RECORD.
05 CUST-ID PIC 9(10).
05 CUST-LAST-NM PIC X(30). *> Last name -- PII
05 CUST-FIRST-NM PIC X(20). *> First name -- PII
05 CUST-DOB PIC 9(8). *> Date of birth -- PII
05 CUST-SSN PIC 9(9). *> Social Security -- PII (HIGH SENSITIVITY)
05 CUST-ADDR-1 PIC X(40). *> Address line 1 -- PII
05 CUST-ADDR-2 PIC X(40). *> Address line 2 -- PII
05 CUST-CITY PIC X(25). *> City -- PII
05 CUST-STATE PIC X(2).
05 CUST-ZIP PIC 9(5). *> ZIP code -- potentially PII
05 CUST-PHONE PIC 9(10). *> Phone number -- PII
05 CUST-EMAIL PIC X(60). *> Email -- PII
Analiza statyczna identyfikuje pola kandydatów PII poprzez połączenie dopasowania wzorców nazw (pola zawierające NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT) i analiza typu (pola PIC X o odpowiedniej długości dla danych osobowych, pola PIC 9 o odpowiedniej długości dla numeru ubezpieczenia społecznego lub numeru telefonu). Wynikiem jest inwentaryzacja pól PII, która wymaga weryfikacji przez człowieka w przypadku niejednoznaczności.
Wzorzec 2: PII w strukturach REDEFINES
REDEFINES tworzy wiele interpretacji tego samego fizycznego magazynu. Pole zdefiniowane jako ogólny magazyn danych w definicji bazowej może zawierać dane osobowe w jednym ze swoich wariantów REDEFINES:
kobol
05 ACCT-DETAIL PIC X(120).
05 ACCT-PERSONAL REDEFINES ACCT-DETAIL.
10 ACCT-HOLDER-NM PIC X(40). *> PII in REDEFINES variant
10 ACCT-HOLDER-DOB PIC 9(8). *> PII in REDEFINES variant
10 ACCT-TAX-ID PIC 9(11). *> PII (EIN or SSN) in REDEFINES
10 FILLER PIC X(57).
05 ACCT-BUSINESS REDEFINES ACCT-DETAIL.
10 ACCT-BUS-NAME PIC X(60). *> Business name -- not personal PII
10 ACCT-REG-NO PIC X(20).
10 FILLER PIC X(40).
Zakres informacji osobowych ACCT-DETAIL Nie można tego określić wyłącznie na podstawie definicji pola bazowego. Wymaga analizy struktury REDEFINES, aby określić, który wariant zawiera dane osobowe i które programy uzyskują dostęp do wariantu osobistego, a które do biznesowego. Skaner, który profiluje tylko kolumnę ACCT_DETAIL w bazie danych docelowej nie ma możliwości zidentyfikowania zawartości PII na podstawie definicji kolumny, PII znajdują się w strukturze źródłowej COBOL.
Wzór 3: PII zmontowane w trybie WORKING-STORAGE
Programy, które gromadzą dane osobowe z wielu źródeł w WORKING-STORAGE przed zapisaniem ich na wyjściu, mogą narazić się na ujawnienie danych osobowych, które nie pojawiają się w żadnej trwałej definicji pliku:
kobol
WORKING-STORAGE SECTION.
01 WS-REPORT-LINE.
05 WS-CUST-NAME PIC X(50).
05 FILLER PIC X(2) VALUE SPACES.
05 WS-CUST-SSN PIC X(11). *> Formatted SSN: XXX-XX-XXXX
05 FILLER PIC X(2) VALUE SPACES.
05 WS-CUST-BALANCE PIC ZZZ,ZZZ,ZZZ.99.
PROCEDURE DIVISION.
MOVE CUST-LAST-NM TO WS-CUST-NAME
STRING CUST-SSN(1:3) '-' CUST-SSN(4:2) '-' CUST-SSN(6:4)
DELIMITED SIZE INTO WS-CUST-SSN
WRITE REPORT-RECORD FROM WS-REPORT-LINE.
Ten program tworzy sformatowany numer PSI w WORKING-STORAGE i zapisuje go do pliku raportu. Dane osobowe znajdują się w dwóch miejscach: w źródłowym pliku VSAM (objętym klasyfikacją PII pliku) oraz w pliku wyjściowym raportu, który może nie zostać sklasyfikowany jako zawierający dane osobowe, chyba że program COBOL, który go zapisuje, zostanie przeanalizowany. WRITE REPORT-RECORD FROM WS-REPORT-LINE Oświadczenie to zdarzenie pochodzenia danych, które łączy numer ubezpieczenia społecznego klienta z plikiem raportu, widoczne tylko w DZIALE PROCEDUR.
Wzorzec 4: Dane osobowe w definicjach zestawów danych JCL
JCL definiuje zestawy danych, które programy odczytują i zapisują. Instrukcja JCL DD, która odwołuje się do zestawu danych zawierającego dane osobowe, jest częścią przepływu danych osobowych, mimo że sama nie zawiera żadnych danych:
jkl
//CUSTPROC JOB (ACCT-001),'CUSTOMER PROCESSING'
//STEP01 EXEC PGM=CUSTUPDT
//CUSTMSTR DD DSN=PROD.CUSTOMER.MASTER.FILE,DISP=SHR
//CUSTOUT DD DSN=BATCH.CUSTOMER.EXTRACT.FILE,
// DISP=(NEW,CATLG),
// SPACE=(CYL,(10,5))
//CUSTLOG DD SYSOUT=*Zbiór danych PROD.CUSTOMER.MASTER.FILE znajduje się w inwentarzu PII, ponieważ program COBOL CUSTUPDT odczytuje z niego dane i zawiera rekordy klientów. Zestaw danych BATCH.CUSTOMER.EXTRACT.FILE wymaga klasyfikacji PII, ponieważ CUSTUPDT zapisuje w nim dane klientów. JCL to rekord pochodzenia danych, który łączy źródłowy zbiór danych z wyjściowym zbiorem danych za pośrednictwem programu. Połączenie to jest widoczne tylko po przeanalizowaniu JCL wraz z programem, który JCL wywołuje.
Mapowanie przepisów: czego wymagają poszczególne ramy i gdzie pasują starsze dane
Różne przepisy nakładają różne wymagania na zakres ujawniania informacji osobowych:
RODO (dane osobowe UE i EOG) nakłada na organizacje obowiązek prowadzenia Rejestru Działalności Przetwarzania (RoPA), dokumentującego wszelkie operacje przetwarzania danych osobowych mieszkańców UE, miejsce ich przechowywania, cel, podstawę prawną i okres przechowywania. Zgodny z RODO Rejestr RoPA dla organizacji przetwarzającej dane klientów z UE na komputerze mainframe wymaga, aby pliki VSAM komputera mainframe, programy COBOL i strumienie zadań JCL, które przetwarzają te dane, znajdowały się w RoPA. Prawo do usunięcia danych wymaga możliwości zidentyfikowania i usunięcia wszystkich danych dotyczących konkretnej osoby, co z kolei wymaga znajomości wszystkich lokalizacji, w których znajdują się dane tej osoby, w tym zestawów danych komputera mainframe, które były produkowane przez trzydzieści lat.
HIPAA (US Protected Health Information) wymaga od podmiotów objętych przepisami i partnerów biznesowych ochrony PHI, niezależnie od ich obecności. Organizacja przetwarzająca informacje medyczne w systemie mainframe COBOL, dokumentację medyczną pacjentów, dane dotyczące roszczeń i rejestry autoryzacji, musi uwzględnić ten system w swojej ocenie ryzyka i zakresie powiadamiania o naruszeniach HIPAA. Zmiany w przepisach bezpieczeństwa HIPAA z 2025 roku zwiększyły nacisk na egzekwowanie przepisów dotyczących zabezpieczeń starszych systemów, co sprawiło, że inwentaryzacja PHI w starszych systemach stała się priorytetem w porównaniu z poprzednimi cyklami egzekwowania.
Norma PCI-DSS v4.0 (dane posiadaczy kart) wymaga zdefiniowanego środowiska danych posiadaczy kart (CDE), obejmującego wszystkie systemy przechowujące, przetwarzające lub przesyłające dane posiadaczy kart. Organizacja przetwarzająca transakcje kartami płatniczymi za pośrednictwem programu COBOL działającego na komputerze mainframe, który opisuje architekturę przetwarzania transakcji większości dużych banków i sprzedawców detalicznych, posiada system mainframe w swoim środowisku CDE. Wymóg PCI-DSS dotyczący skanowania systemów objętych zakresem w poszukiwaniu danych posiadaczy kart ma zastosowanie do komponentów środowiska CDE komputera mainframe.
Ustawa DORA (UE o cyfrowej odporności operacyjnej) dla usług finansowych wymaga zarządzania ryzykiem ICT obejmującego wszystkie systemy zaangażowane w funkcje krytyczne, ze szczególnym uwzględnieniem ryzyka związanego z systemami zewnętrznymi i systemami starszymi. Systemy mainframe COBOL instytucji finansowej, które przetwarzają transakcje i przechowują dane klientów, są objęte ramami ryzyka ICT określonymi w DORA, w tym wymogiem utrzymywania aktualnego spisu wszystkich zasobów ICT obsługujących funkcje krytyczne.
Wspólny mianownik: regulacyjne wymogi dotyczące inwentaryzacji danych osobowych nie obejmują wyjątku „wykluczenia starszych systemów”. Dane, które najtrudniej znaleźć, to jednocześnie dane, o które organy regulacyjne będą pytać, gdy coś pójdzie nie tak.
Przepływ pracy: odkrywanie-maskowanie-zarządzanie
Ujawnienie informacji osobowych to pierwszy krok w trzyetapowym procesie zapewniania zgodności:
Usługa Discovery identyfikuje miejsca występowania informacji osobowych we wszystkich bazach danych, zarówno starszych, jak i nowoczesnych. Wynikiem jest ustrukturyzowany spis: każdy magazyn danych, każdy zestaw danych, każde pole sklasyfikowane jako zawierające określone kategorie informacji osobowych, wraz z ramami regulacyjnymi mającymi zastosowanie do każdego znaleziska.
Maskowanie chroni dane osobowe w środowiskach nieprodukcyjnych, w tym w środowiskach programistycznych, testowych i analitycznych, gdzie nie są wymagane pełne dane produkcyjne, ale struktura i wolumen danych są wymagane. RODO nakazuje ochronę danych osobowych za pomocą technik takich jak anonimizacja i pseudonimizacja w środowiskach nieprodukcyjnych. Program do wykrywania, który identyfikuje dane osobowe w plikach VSAM komputerów mainframe, umożliwia maskowanie, które zastępuje rzeczywiste dane klientów syntetycznymi odpowiednikami w środowiskach testowych, ale tylko wtedy, gdy pola danych osobowych zostały poprawnie zidentyfikowane we wpisach COBOL FD i kopiach definiujących układ rekordów.
Zarządzanie utrzymuje inwentaryzację danych osobowych (PII) w czasie, śledząc dodawanie nowych systemów zawierających dane osobowe (PII), migrację lub wycofanie istniejących danych PII oraz zmiany w zakresie inwentaryzacji danych wprowadzane przez przepisy. W przypadku starszych systemów zarządzanie wymaga nie tylko okresowego ponownego skanowania baz danych, ale także monitorowania zmian w kodzie, które powodują nowe zagrożenia dla danych osobowych (PII), modyfikacji programu COBOL w celu zapisania nowego pola do pliku wyjściowego, modyfikacji zadania JCL w celu uwzględnienia nowego zestawu danych oraz zmiany w kopii zapasowej, która dodaje pole PII do istniejącego układu rekordów.
Badanie State of Enterprise Data Compliance z 2026 roku wykazało, że tylko 2% organizacji uważa swoje środowiska AI za w pełni zgodne z wymogami, co odnosi się również do środowisk starszych: zgodność słabnie na granicy między tym, co obejmują standardowe narzędzia, a tym, czego nie obejmują. W większości organizacji granica ta przebiega dokładnie wzdłuż obwodu systemów starszych.
W jaki sposób SMART TS XL Obsługuje wykrywanie danych osobowych w starszych środowiskach
SMART TS XLRolą narzędzia w odkrywaniu informacji osobowych jest analiza kodu źródłowego, krok poprzedzający uruchomienie standardowych narzędzi do odkrywania informacji osobowych w starszych środowiskach oraz krok generujący metadane niezbędne tym narzędziom do prawidłowej klasyfikacji starszych magazynów danych.
Funkcja statycznej analizy kodu analizuje każdy wpis w kodzie COBOL FD, element COPY, klauzulę SELECT i DIVISION PROCEDURE, aby zidentyfikować pola kandydatów PII poprzez analizę wzorców nazw, analizę typów i analizę kontekstu. Wynikiem jest inwentaryzacja pól kandydatów PII na poziomie pola, czyli każde pole, którego nazwa, typ, długość lub kontekst użycia sugeruje, że zawiera dane osobowe, uporządkowane według programu, zestawu danych i pola, wraz z technicznymi metadanymi COBOL (typ, długość, precyzja), wymaganymi przez narzędzia do maskowania i klasyfikacji.
Mapowanie zależności aplikacji tworzy mapę przepływu danych PII: każdy program odczytujący dane z pliku VSAM zawierającego dane PII, każdy program zapisujący dane do podrzędnego zbioru danych, który dziedziczy dane PII ze źródła, każdy krok zadania JCL, który tworzy lub wykorzystuje zbiory danych zawierające dane PII. Ta mapa pochodzenia to inwentaryzacja przepływu danych między granicami, czyli zapis sposobu, w jaki dane PII przemieszczają się od komputera mainframe przez programy transformacyjne i strumienie zadań JCL, które ostatecznie dostarczają je do nowoczesnych systemów.
Funkcja rozszerzenia JCL śledzi pełny kontekst operacyjny każdego zestawu danych zawierającego dane osobowe: które zadania JCL się do niego odwołują, w jakiej kolejności, z jakimi kodami dyspozycji oraz jakie dalsze zestawy danych zadanie tworzy na jego podstawie. W przypadku wniosków o prawo do usunięcia danych zgodnie z RODO, ta mapa operacyjna identyfikuje każde miejsce, w którym dane konkretnego klienta mogły zostać zapisane w wyniku przetwarzania jego rekordu źródłowego, w tym pośrednie pliki robocze, sortowane zestawy danych roboczych i pliki raportów utworzone podczas przetwarzania wsadowego.
Funkcja wyszukiwania w przedsiębiorstwie umożliwia wyszukiwanie w spisie danych osobowych (PII) w celu obsługi żądań dostępu osób, których dane dotyczą, oraz audytów regulacyjnych: znajdź każdy program uzyskujący dostęp do określonego pola, każdy zbiór danych zawierający rekordy z określoną wartością klucza, każde zadanie JCL przetwarzające określony zbiór danych. Ta funkcja wyszukiwania przekształca spis danych osobowych (PII) ze statycznego dokumentu w interfejs zapytań na żywo – narzędzie, które odpowiada na pytanie „gdzie znajdują się dane tej osoby” w ciągu kilku godzin, a nie tygodni.
Dla organizacji prowadzących modernizacja dziedziczna programy SMART TS XLAnaliza danych osobowych (PII) jest warunkiem wstępnym zgodności: zakres zgodności z PCI-DSS, HIPAA i RODO obejmuje dane wrażliwe od momentu opuszczenia przez nie pierwotnego środowiska. Dane osobowe (PII) przesyłane wraz z migrowanymi danymi muszą zostać zinwentaryzowane przed migracją, zabezpieczone w trakcie migracji i ponownie zweryfikowane po migracji. Nie migrujesz tylko kodu. Migrujesz ryzyko.
Granica zgodności obejmuje wszystko, co zawiera dane osobowe
Ramy regulacyjne dotyczące ochrony danych osobowych, takie jak RODO, HIPAA, PCI-DSS, CCPA, DORA, zostały opracowane z myślą o uniwersalnym zakresie. Mają one zastosowanie do danych osobowych, niezależnie od wieku systemu, w którym są przechowywane, niezależnie od tego, czy system ten posiada nowoczesny łącznik, oraz niezależnie od tego, czy katalog danych organizacji ma do nich wgląd.
Luka w ujawnianiu danych osobowych w starszych środowiskach nie jest ograniczeniem technicznym, które organy regulacyjne uznają za usprawiedliwienie. Jest to luka w zgodności, którą organy ścigania traktują jako brak wdrożenia odpowiednich zabezpieczeń – tego samego standardu, który obowiązuje w nowoczesnych systemach, a który jest stosowany do systemów wymagających innych metod ujawniania danych do prawidłowego przeprowadzenia audytu.
Aby wypełnić tę lukę, należy uznać, że warstwa mainframe w systemie danych przedsiębiorstwa przechowuje znaczne ilości danych osobowych (PII), że standardowe narzędzia do wyszukiwania nie mogą do niej dotrzeć za pomocą standardowych metod połączeń oraz że analiza kodu źródłowego programów COBOL i strumieni zadań JCL zarządzających tymi danymi to podejście, które pozwala na uzyskanie kompletnego inwentarza. Pełne wyszukiwanie, zarówno w warstwie tradycyjnej, jak i nowoczesnej, nie jest celem technicznym. Stanowi ono punkt odniesienia, względem którego oceniane są programy zgodności.
