Laut dem IBM-Bericht „Cost of a Data Breach Report 2025“ belaufen sich die durchschnittlichen Kosten einer Datenschutzverletzung auf 4.44 Millionen US-Dollar. Datenschutzverletzungen mit personenbezogenen Daten ziehen die höchsten Strafen gemäß DSGVO und HIPAA nach sich, nicht weil die Behebung solcher Verstöße technisch aufwendiger wäre, sondern weil die Aufsichtsbehörden sie unterschiedlich behandeln. DSGVO-Strafen können bis zu vier Prozent des weltweiten Jahresumsatzes erreichen. Zivilrechtliche Strafen nach HIPAA betragen 1.9 Millionen US-Dollar pro Verstoßkategorie und Jahr. Das Risiko für ein Unternehmen, das durch eine einzelne Datenschutzverletzung in einem System entsteht, dessen PII-Inventar unvollständig war – weil das zuständige Erkennungsprogramm nur die moderne Systemarchitektur abdeckte und an der Mainframe-Schnittstelle abbrach –, ist kein Problem der Datentechnik. Es handelt sich um ein regulatorisches und finanzielles Risiko, das auf der Tagesordnung des Vorstands steht.
Die meisten Organisationen können nicht auf Anfrage ein vollständiges PII-Inventar erstellen. Die gängigen PII-Erkennungstools wie Varonis, IBM Guardium, BigID, Microsoft Purview und Strac eignen sich hervorragend zum Scannen strukturierter Datenbanken, Cloud-Speicher, SaaS-Plattformen und Dateifreigaben. Sie stellen Verbindungen zu dem her, worauf sie zugreifen können. Was sie nicht erreichen können, können sie nicht scannen. VSAM-Dateien unter z/OS verfügen nicht über JDBC-Konnektoren. COBOL-Programme, die Kundendaten während der Stapelverarbeitung im Arbeitsspeicher halten, stellen Daten nicht über APIs bereit. JCL-Dataset-Definitionen werden nicht in einem Datenkatalog registriert. Die Mainframe-Schicht, die 95 Prozent der Geldautomatentransaktionen verarbeitet und ein geschätztes tägliches Handelsvolumen von 3 Billionen US-Dollar abwickelt, ist die größte, PII-reichste und systematisch am wenigsten gescannte Schicht in Unternehmensdatenbeständen. Man kann nicht schützen, was man nicht findet, und die meisten Organisationen haben noch nicht alle Daten gefunden.
Die personenbezogenen Daten, die Ihr Katalog nicht erfassen kann
SMART TS XL Verfolgt personenbezogene Daten (PII) von der VSAM-Quelle über COBOL-Programme bis zu jedem nachgelagerten Datensatz, der diese Daten erbt.
MEHR ERFAHREN…Warum die Legacy-Schicht der schwierigste Teil der PII-Ermittlung ist
Die standardmäßige Herausforderung bei der Ermittlung personenbezogener Daten (PII), also das Auffinden von Namen, Adressen, Sozialversicherungsnummern und Zahlungskartendaten, die über Hunderte von Datenbanken und Dateifreigaben verstreut sind, ist zwar schwierig, aber mit modernen Werkzeugen lösbar. Die Mustererkennungsverfahren, die den meisten PII-Ermittlungswerkzeugen zugrunde liegen, funktionieren gut mit strukturierten Daten, die über zugängliche Schnittstellen verfügen: Spalten werden durchsucht, reguläre Ausdrücke angewendet, Felder, die mit PII-Signaturen übereinstimmen, markiert, klassifiziert und inventarisiert.
Die Legacy-Schicht führt vier Eigenschaften ein, die den Ansatz der Mustererkennung unterbrechen:
Abgekürzte Feldnamen ohne semantisches Signal. In modernen COBOL-Dialekten sind Feldnamen auf 30 Zeichen begrenzt und wurden in älteren Codes üblicherweise in 8-stelliger Kurzform geschrieben: CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DTEin Mustererkennungsscanner, der identifiziert social_security_number or customer_name da PII-Feldindikatoren keine Grundlage für eine Klassifizierung haben SSN-NO or CUST-NM ohne Kenntnisse der COBOL-Namenskonventionen. Die Abkürzungskonvention selbst ist ein Metadatenproblem; das Feld enthält personenbezogene Daten, aber sein Name signalisiert dies einem Scanner, der für moderne Namenskonventionen ausgelegt ist, nicht eindeutig.
PII eingebettet in Verbundstrukturen. COBOL-Datensätze packen häufig mehrere Datenelemente in ein einzelnes Feld oder verwenden REDEFINES, um unterschiedliche Interpretationen auf dieselben Bytes anzuwenden. Ein Kundendatensatzfeld CUST-FULL-DATA definiert als PIC X(100) kann Name, Adresse und Telefonnummer enthalten, die zu einer einzigen Zeichenkette mit Unterfeldern an festen Positionen verkettet sind. Diese Struktur erscheint jedem Scanner, der nur die Felddefinition liest, ohne die Programmlogik zu verstehen, die sie befüllt und liest, als ein einziges undurchsichtiges Textfeld.
Personenbezogene Daten (PII) im Arbeitsspeicher: COBOL-Batchprogramme lesen häufig PII aus VSAM-Dateien, verarbeiten sie in Arbeitsspeichervariablen und schreiben die Ausgaben in Datensätze. Die PII befinden sich während der Ausführung im Arbeitsspeicher, nicht in einem persistenten Datenspeicher, und verschwinden nach Programmende. Eine Datensuche, die den persistenten Speicher durchsucht, findet die VSAM-Quelldatei und den Ausgabedatensatz, jedoch nicht die Zwischenverarbeitung, in der die Daten zusammengestellt, transformiert und gegebenenfalls protokolliert werden.
Personenbezogene Daten (PII) passieren die IT/OT-Grenze über Flatfile-Schnittstellen. Kundendaten, die aus VSAM-Dateien von Mainframes extrahiert werden, gelangen häufig über Flatfile-Schnittstellen, CSV-Extrakte, Dateien mit fester Länge oder positionsbasierte Dateien, die keine Spaltenmetadaten enthalten, an nachgelagerte Systeme. Die Flatfile enthält PII an bestimmten Bytepositionen, aber der nachgelagerte Scanner, der die Datei empfängt, verfügt über kein Schema, um Positionen Feldbedeutungen zuzuordnen, es sei denn, der COBOL-FD-Eintrag, der das Datensatzlayout definiert, wird ebenfalls analysiert.
Die Herausforderung der Erfassung personenbezogener Daten bei einem geteilten Immobilienbestand
Ein Unternehmen mit sowohl Mainframe-Altsystemen als auch modernen Cloud-Plattformen steht vor der Herausforderung, ein Inventar personenbezogener Daten (PII) zu erstellen, das zwei grundlegend verschiedene Ermittlungsansätze erfordert. Die moderne Ebene ist mit Standardtools zugänglich. Die Altsysteme erfordern eine andere Methode. Die Compliance-Anforderungen – das Recht auf Löschung gemäß DSGVO, der HIPAA-Standard der minimal notwendigen Daten, der PCI-DSS-Datenumfang für Karteninhaberdaten und die CCPA-Anforderungen an das Verbraucherdateninventar – gelten für beide Ebenen gleichermaßen. Ein Auskunftsersuchen gemäß DSGVO erfordert ein Inventar aller personenbezogenen Daten, die über eine bestimmte Person in allen Systemen gespeichert sind, nicht nur in den Systemen, die mit dem Datenkatalog verbunden sind.
Das auf mehrere Immobilien verteilte PII-Inventar besteht aus drei Komponenten, die zusammenarbeiten müssen:
Moderne Datenbestände – Cloud-Datenbanken, SaaS-Plattformen, Data Warehouses, API-Protokolle und Dateifreigaben – lassen sich mit Standard-Tools zur Erkennung personenbezogener Daten (PII) erfassen. Diese Tools suchen nach PII-Mustern, klassifizieren die Daten gemäß den geltenden Vorschriften und integrieren sich in Datenkatalogplattformen, um strukturierte Bestände zu erstellen. IBM Guardium deckt strukturierte Datenbanken und Mainframe-Datenbanken (DB2) mit richtlinienbasierter Klassifizierung ab. Microsoft Purview deckt Microsoft-Cloud-Dienste ab. BigID und Varonis umfassen breitere Ökosysteme, einschließlich unstrukturierter Daten.
Die Bestandsaufnahme der Altdaten – VSAM-Dateien, DB2-Schemas auf Mainframes, COBOL-Programm WORKING-STORAGE, JCL-Dataset-Definitionen – erfordert eine Quellcodeanalyse, um festzustellen, wo personenbezogene Daten definiert, gespeichert und verarbeitet werden. Diese Analyse liest die COBOL-Programme, um zu verstehen, welche Daten sie verarbeiten, und beschränkt sich nicht nur auf die Datenspeicher, in die sie schreiben.
Die Bestandsaufnahme der datenübergreifenden Datenflüsse , also der Wege, über die personenbezogene Daten (PII) von Altsystemen auf moderne Plattformen übertragen werden – oft über flache Dateischnittstellen ohne Schema –, erfordert die Nachverfolgung der Datenherkunft von der COBOL-Quelle über JCL-Jobstreams bis zu den Endpunkten, an denen die Daten die anschließbaren Systeme erreichen. Die flache Datei, die den Mainframe jede Nacht verlässt, wird erst dann mit PII-Tags versehen, wenn das Schema, das ihr Datensatzlayout definiert, mit den Spaltendefinitionen des Zieldatensatzes verknüpft ist.
Organisationen, die vollständige Verzeichnisse personenbezogener Daten erstellen, haben alle drei Komponenten berücksichtigt. Organisationen, die bei DSGVO- oder HIPAA-Prüfungen durchfallen, haben häufig nur die erste Komponente abgedeckt und fälschlicherweise angenommen, die anderen seien ebenfalls berücksichtigt.
COBOL-spezifische PII-Muster und wie man sie findet
Muster 1: Direkte PII in FD-Einträgen und Kopierbüchern
Das einfachste COBOL-PII-Muster: ein Feld in einem FD-Eintrag oder COPY-Member, dessen Name, Typ oder Kontext eindeutig auf personenbezogene Daten hinweist. Selbst bei abgekürzten Namenskonventionen sind bestimmte Muster konsistent vorhanden:
Cobol
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
Die statische Analyse identifiziert PII-Kandidatenfelder durch eine Kombination aus Namensmustervergleich (Felder, die enthalten) NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT) und Typanalyse (PIC X-Felder geeigneter Länge für personenbezogene Daten, PIC 9-Felder geeigneter Länge für Sozialversicherungsnummern oder Telefonnummern). Das Ergebnis ist ein Kandidatenverzeichnis personenbezogener Datenfelder, das in den uneindeutigen Fällen manuell überprüft werden muss.
Muster 2: PII in REDEFINES-Strukturen
REDEFINES erzeugt mehrere Interpretationen desselben physischen Speichers. Ein Feld, das in der Basisdefinition als generischer Datenspeicher definiert ist, kann in einer seiner REDEFINES-Varianten personenbezogene Daten enthalten:
Cobol
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).
Der PII-Geltungsbereich ACCT-DETAIL Dies lässt sich nicht allein aus der Definition des Basisfelds bestimmen. Es erfordert eine Analyse der REDEFINES-Struktur, um festzustellen, welche Variante personenbezogene Daten enthält und welche Programme auf die persönliche bzw. die geschäftliche Variante zugreifen. Ein Scanner, der nur die Spalte profiliert, ist erforderlich. ACCT_DETAIL In der Zieldatenbank gibt es keine Möglichkeit, den PII-Inhalt anhand der Spaltendefinition zu identifizieren; der PII befindet sich in der COBOL-Quellstruktur.
Muster 3: PII in ARBEITS- UND LAGERBEREICH montiert
Programme, die personenbezogene Daten aus mehreren Quellen im Arbeitsspeicher zusammenstellen, bevor sie diese in eine Ausgabedatei schreiben, können personenbezogene Daten offenlegen, die in keiner persistenten Dateidefinition erscheinen:
Cobol
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.
Dieses Programm erstellt eine formatierte Sozialversicherungsnummer im Arbeitsspeicher und schreibt sie in eine Berichtsdatei. Die personenbezogenen Daten (PII) befinden sich an zwei Stellen: in der Quell-VSAM-Datei (die durch die PII-Klassifizierung der Datei abgedeckt ist) und in der Berichtsausgabedatei, die möglicherweise nicht als PII-haltig eingestuft wird, sofern das COBOL-Programm, das sie erstellt, nicht analysiert wird. WRITE REPORT-RECORD FROM WS-REPORT-LINE Die Statement-Anweisung ist das Datenherkunftsereignis, das die Sozialversicherungsnummer des Kunden mit der Berichtsdatei verbindet und nur im Abschnitt PROCEDURE DIVISION sichtbar ist.
Muster 4: PII in JCL-Datensatzdefinitionen
JCL definiert die Datensätze, die Programme lesen und schreiben. Eine JCL-DD-Anweisung, die auf einen Datensatz mit personenbezogenen Daten verweist, ist Teil des Datenflusses personenbezogener Daten, auch wenn sie selbst keine Daten enthält:
JCL
//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=*Der Datensatz PROD.CUSTOMER.MASTER.FILE ist im PII-Inventar enthalten, weil das COBOL-Programm CUSTUPDT Es liest daraus und enthält Kundendatensätze. Der Datensatz BATCH.CUSTOMER.EXTRACT.FILE erfordert eine PII-Klassifizierung, weil CUSTUPDT Schreibt Kundendaten hinein. Die JCL ist der Datenherkunftsdatensatz, der den Quelldatensatz über das Programm mit dem Ausgabedatensatz verbindet – eine Verbindung, die nur durch die Analyse der JCL zusammen mit dem Programm, das von der JCL aufgerufen wird, sichtbar wird.
Regulatorische Kartierung: Was die einzelnen Rahmenwerke erfordern und wo Altdaten ihren Platz finden
Unterschiedliche Vorschriften stellen unterschiedliche Anforderungen an den Umfang der Ermittlung personenbezogener Daten:
Die DSGVO (personenbezogene Daten der EU und des EWR) verpflichtet Organisationen zur Führung von Verarbeitungsverzeichnissen (RoPAs). Diese müssen alle Verarbeitungen personenbezogener Daten von EU-Bürgern dokumentieren, einschließlich Speicherort, Zweck, Rechtsgrundlage und Aufbewahrungsdauer. Ein DSGVO-konformes RoPA für eine Organisation, die EU-Kundendaten auf einem Mainframe verarbeitet, erfordert die Angabe der Mainframe-VSAM-Dateien, COBOL-Programme und JCL-Jobstreams, die diese Daten verarbeiten. Das Recht auf Löschung setzt voraus, dass alle Daten einer bestimmten Person identifiziert und gelöscht werden können. Dies erfordert die Kenntnis aller Speicherorte der Daten dieser Person, einschließlich Mainframe-Datensätzen, die seit dreißig Jahren produktiv genutzt werden.
HIPAA (US-amerikanisches Gesetz zum Schutz von Gesundheitsdaten) verpflichtet betroffene Einrichtungen und Geschäftspartner, geschützte Gesundheitsdaten (PHI) unabhängig von ihrem Speicherort zu sichern. Organisationen, die Gesundheitsdaten auf einem Mainframe-COBOL-System verarbeiten (z. B. Patientenakten, Abrechnungsdaten, Genehmigungsdaten), müssen dieses System in ihre HIPAA-Risikobewertung und die Meldepflichten bei Datenschutzverletzungen einbeziehen. Die Aktualisierungen der HIPAA-Sicherheitsregeln von 2025 haben die Überwachung der Sicherheitskontrollen in Altsystemen verstärkt, wodurch die Erfassung der geschützten Gesundheitsdaten in diesen Systemen eine höhere Priorität genießt als in früheren Durchsetzungszyklen.
PCI-DSS v4.0 (Karteninhaberdaten) erfordert eine definierte Karteninhaberdatenumgebung (CDE), die alle Systeme umfasst, die Karteninhaberdaten speichern, verarbeiten oder übertragen. Organisationen, die Zahlungskartentransaktionen über ein COBOL-Programm auf einem Mainframe verarbeiten – wie es bei den meisten großen Banken und Einzelhändlern der Fall ist –, verfügen über ein Mainframe-System innerhalb ihrer CDE. Die PCI-DSS-Anforderung, die relevanten Systeme auf Karteninhaberdaten zu überprüfen, gilt für die Mainframe-Komponenten der CDE.
Der EU-Gesetzentwurf DORA (Digital Operational Resilience Act) für Finanzdienstleistungen schreibt ein umfassendes IT-Risikomanagement vor, das alle Systeme kritischer Funktionen abdeckt und dabei insbesondere Risiken durch Drittanbieter und Altsysteme berücksichtigt. Die Mainframe-COBOL-Systeme von Finanzinstituten, die Transaktionen verarbeiten und Kundendaten speichern, fallen unter den Geltungsbereich des IT-Risikomanagement-Rahmenwerks von DORA. Dies beinhaltet die Pflicht, ein aktuelles Verzeichnis aller IT-Ressourcen zu führen, die kritische Funktionen unterstützen.
Gemeinsamer Nenner: Die regulatorischen Anforderungen an die Erfassung personenbezogener Daten sehen keine Ausnahme für „Altsysteme“ vor. Die am schwersten zu findenden Daten sind auch diejenigen, nach denen die Aufsichtsbehörden im Fehlerfall fragen werden.
Der Discovery-Masking-Governance-Workflow
Die Ermittlung personenbezogener Daten ist der erste Schritt in einem dreistufigen Compliance-Workflow:
Die Discovery-Analyse identifiziert alle personenbezogenen Daten (PII) in allen Datenspeichern, sowohl in älteren als auch in modernen. Das Ergebnis ist ein strukturiertes Inventar: alle Datenspeicher, alle Datensätze, alle Felder, die bestimmten Kategorien von PII zugeordnet sind, sowie die jeweils geltenden regulatorischen Rahmenbedingungen.
Die Maskierung schützt personenbezogene Daten (PII) in Nicht-Produktionsumgebungen, wie Entwicklung, Tests und Analysen, wo zwar die vollständigen Produktionsdaten nicht benötigt werden, Datenstruktur und -menge jedoch relevant sind. Die DSGVO schreibt vor, dass PII in Nicht-Produktionsumgebungen durch Techniken wie Anonymisierung und Pseudonymisierung geschützt werden müssen. Ein Erkennungsprogramm, das PII in VSAM-Dateien von Mainframes identifiziert, ermöglicht die Maskierung, bei der reale Kundendaten in Testumgebungen durch synthetische Äquivalente ersetzt werden. Dies ist jedoch nur möglich, wenn die PII-Felder in den COBOL-FD-Einträgen und Copybooks, die die Datensatzlayouts definieren, korrekt identifiziert wurden.
Die Governance pflegt das PII-Inventar fortlaufend und erfasst, wann neue Systeme mit PII-Daten hinzugefügt, bestehende PII-Daten migriert oder stillgelegt werden und wann sich der Umfang der zu inventarisierenden Daten aufgrund regulatorischer Vorgaben ändert. Bei Altsystemen erfordert die Governance nicht nur regelmäßige Überprüfungen der Datenspeicher, sondern auch die Überwachung von Codeänderungen, die neue PII-Datenquellen schaffen, beispielsweise die Änderung eines COBOL-Programms zum Schreiben eines neuen Felds in eine Ausgabedatei, die Änderung eines JCL-Jobs zur Einbindung eines neuen Datensatzes oder die Änderung eines Copybooks, das einem bestehenden Datensatzlayout ein PII-Feld hinzufügt.
Die Studie „State of Enterprise Data Compliance 2026“, die zeigt, dass nur 2 Prozent der Unternehmen ihre KI-Umgebungen als vollständig konform betrachten, gilt gleichermaßen für Legacy-Systeme: Die Konformität nimmt an der Grenze zwischen dem, was Standardtools abdecken und was nicht, ab. Für die meisten Unternehmen verläuft diese Grenze exakt entlang des Perimeters des Legacy-Systems.
Wie SMART TS XL Unterstützt die Ermittlung personenbezogener Daten in älteren Umgebungen
SMART TS XLDie Rolle von bei der PII-Erkennung besteht in der Quellcodeanalyse, dem Schritt, bevor Standard-PII-Erkennungswerkzeuge ihre Arbeit in Legacy-Umgebungen durchführen können, und dem Schritt, der die Metadaten erzeugt, die diese Werkzeuge benötigen, um Legacy-Datenspeicher korrekt zu klassifizieren.
Die statische Codeanalyse untersucht jeden COBOL-FD-Eintrag, jedes COPY-Element, jede SELECT-Klausel und jede PROCEDURE DIVISION, um potenzielle Felder für personenbezogene Daten (PII) mittels Namensmuster-, Typ- und Kontextanalyse zu identifizieren. Das Ergebnis ist ein Verzeichnis potenzieller PII-Felder, das alle Felder enthält, deren Name, Typ, Länge oder Nutzungskontext auf personenbezogene Daten hindeutet. Die Felder sind nach Programm, Datensatz und Feld geordnet und enthalten die technischen COBOL-Metadaten (Typ, Länge, Genauigkeit), die für nachfolgende Maskierungs- und Klassifizierungswerkzeuge benötigt werden.
Die Abbildung der Anwendungsabhängigkeiten erstellt die PII-Datenflusskarte: Jedes Programm, das aus einer PII-haltigen VSAM-Datei liest, jedes Programm, das in ein nachgelagertes Dataset schreibt, das PII von der Quelle erbt, und jeder JCL-Jobschritt, der PII-haltige Datasets erstellt oder verwendet. Diese Herkunftskarte ist das übergreifende Datenflussinventar und dokumentiert, wie PII von seinem Ursprung auf dem Mainframe über die Transformationsprogramme und JCL-Jobströme zu modernen Systemen gelangt.
Die JCL-Erweiterungsfunktion erfasst den vollständigen Betriebskontext jedes Datensatzes mit personenbezogenen Daten: welche JCL-Jobs darauf zugreifen, in welcher Reihenfolge, mit welchen Dispositionscodes und welche Folgedatensätze der Job daraus erstellt. Für Anträge auf Löschung gemäß DSGVO identifiziert diese Betriebsübersicht alle Speicherorte, an denen die Daten eines bestimmten Kunden infolge der Verarbeitung seines Quelldatensatzes gespeichert wurden, einschließlich temporärer Arbeitsdateien, Sortierdatensätze und Berichtsdateien, die während der Stapelverarbeitung erstellt wurden.
Die unternehmensweite Suchfunktion ermöglicht die Abfrage des PII-Inventars zur Unterstützung von Auskunftsersuchen betroffener Personen und behördlichen Prüfungen: Finden Sie jedes Programm, das auf ein bestimmtes Feld zugreift, jedes Dataset mit Datensätzen mit einem bestimmten Schlüsselwert und jeden JCL-Job, der ein bestimmtes Dataset verarbeitet. Diese Suchfunktion wandelt ein statisches PII-Inventar in eine dynamische Abfrageschnittstelle um – das Werkzeug, das die Frage „Wo befinden sich die Daten dieser Person?“ innerhalb von Stunden statt Wochen beantwortet.
Für Organisationen, die Modernisierung des Altbestands Programme, SMART TS XLDie Analyse personenbezogener Daten (PII) ist eine Voraussetzung für die Einhaltung der Vorschriften: Der Geltungsbereich von PCI-DSS, HIPAA und DSGVO erstreckt sich auf sensible Daten, sobald diese ihre ursprüngliche Umgebung verlassen. Die mit migrierten Daten übertragenen personenbezogenen Daten müssen vor der Migration erfasst, während der Migration geschützt und nach der Migration erneut überprüft werden. Sie migrieren nicht nur Code, sondern auch Risiken.
Der Compliance-Perimeter umfasst alles, was personenbezogene Daten enthält.
Die regulatorischen Rahmenbedingungen für den Schutz personenbezogener Daten – DSGVO, HIPAA, PCI-DSS, CCPA, DORA – sind universell anwendbar. Sie gelten für personenbezogene Daten unabhängig von deren Speicherort, dem Alter des Systems, in dem sie gespeichert sind, der Verfügbarkeit moderner Schnittstellen und der Transparenz der Daten im Datenkatalog des Unternehmens.
Die Lücke bei der Ermittlung personenbezogener Daten in älteren Systemen ist keine technische Einschränkung, die von Aufsichtsbehörden als Entschuldigung akzeptiert wird. Es handelt sich um eine Compliance-Lücke, die von Aufsichtsbehörden als Versäumnis der Implementierung angemessener Schutzmaßnahmen gewertet wird – derselbe Standard, der für moderne Systeme gilt, nur eben für Systeme, die andere Ermittlungsmethoden für eine korrekte Prüfung erfordern.
Um diese Lücke zu schließen, muss anerkannt werden, dass die Mainframe-Ebene der Unternehmensdaten erhebliche Mengen personenbezogener Daten (PII) enthält, dass Standard-Erkennungstools diese über ihre üblichen Verbindungsmethoden nicht erreichen können und dass die Quellcodeanalyse der COBOL-Programme und JCL-Jobstreams, die diese Daten verwalten, den Ansatz darstellt, der ein vollständiges Inventar liefert. Die vollständige Erfassung sowohl der Legacy- als auch der modernen Ebenen ist keine rein technische Vision. Sie ist die Grundlage, anhand derer Compliance-Programme bewertet werden.
