IBMs rapport om omkostningerne ved et databrud fra 2025 anslår de gennemsnitlige omkostninger ved brud til 4.44 millioner dollars. Databrud, der involverer personoplysninger, medfører de største regulatoriske sanktioner i henhold til GDPR og HIPAA, ikke fordi brud på persondata er dyrere at afhjælpe rent teknisk, men fordi myndighederne behandler dem forskelligt. GDPR-bøder kan nå op på fire procent af den globale årlige omsætning. De civile HIPAA-sanktioner når op på 1.9 millioner dollars pr. overtrædelseskategori pr. år. Den organisatoriske eksponering fra et enkelt brud på et system, hvis PII-opgørelse var ufuldstændig, fordi det opdagelsesprogram, der burde have fundet det, kun dækkede den moderne stak og stoppede ved mainframe-grænsen, er ikke et datateknisk problem. Det er en regulatorisk og finansiel risiko, der er på bestyrelsens dagsorden.
De fleste organisationer kan ikke producere en komplet PII-opgørelse efter behov. Standardværktøjerne til PII-opdagelse, Varonis, IBM Guardium, BigID, Microsoft Purview og Strac, udmærker sig ved at scanne strukturerede databaser, cloudlagring, SaaS-platforme og fildelinger. De opretter forbindelse til det, de kan oprette forbindelse til. Det, de ikke kan oprette forbindelse til, kan de ikke scanne. VSAM-filer på z/OS har ikke JDBC-forbindelser. COBOL-programmer, der opbevarer kundedata i WORKING-STORAGE under batchbehandling, eksponerer ikke data via API'er. JCL-datasætdefinitioner registreres ikke i et datakatalog. Mainframe-laget, som behandler 95 procent af ATM-transaktioner og håndterer anslået 3 billioner dollars i daglig handel, er det største, mest PII-tætte og mest systematisk underscannede lag i virksomhedsdatabeholdninger. Du kan ikke beskytte det, du ikke kan finde, og de fleste organisationer har ikke fundet det hele.
De personoplysninger, som dit katalog ikke kan nå
SMART TS XL sporer PII fra VSAM-kilden via COBOL-programmer til hvert downstream-datasæt, der arver det.
FÅ MERE AT VIDE…Hvorfor Legacy-laget er den sværeste del af PII-opdagelse
Standardudfordringen med at finde PII, hvor man finder navne, adresser, CPR-numre og betalingskortdata spredt ud over hundredvis af databaser og fildelinger, er vanskelig, men håndterbar med moderne værktøjer. De mønstermatchningsmetoder, der ligger til grund for de fleste PII-opdagelsesværktøjer, fungerer godt mod strukturerede data med tilgængelige forbindelser: scan kolonnerne, anvend regex-mønstre, marker felter, der matcher PII-signaturer, klassificer og optegn.
Legacy-laget introducerer fire egenskaber, der bryder med mønstermatchningsmetoden:
Forkortede feltnavne uden semantisk signal. COBOL-feltnavne er begrænset til 30 tegn i moderne dialekter og blev almindeligvis skrevet i forkortet form på 8 tegn i ældre kode: CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DTEn mønstermatchningsscanner, der identificerer social_security_number or customer_name da PII-feltindikatorer ikke har noget grundlag for klassificering SSN-NO or CUST-NM uden at forstå COBOL-navngivningskonventioner. Forkortelseskonventionen er i sig selv et metadataproblem, feltet indeholder PII, men dets navn signalerer ikke tydeligt det til en scanner designet til moderne navngivningskonventioner.
PII indlejret i kompositstrukturer. COBOL-poster pakker ofte flere dataelementer ind i et enkelt felt eller bruger REDEFINES til at overlejre forskellige fortolkninger på de samme bytes. Et kundepostfelt CUST-FULL-DATA defineret som PIC X(100) kan indeholde navn, adresse og telefonnummer sammenkædet til en enkelt streng med underfelter med fast position, en struktur, der vises som et enkelt uigennemsigtigt tekstfelt for enhver scanner, der kun læser feltdefinitionen uden at forstå programlogikken, der udfylder og læser den.
PII under transit gennem WORKING-STORAGE. COBOL-batchprogrammer læser ofte PII fra VSAM-filer, behandler dem i WORKING-STORAGE-variabler og skriver output til datasæt. PII findes i WORKING-STORAGE under udførelsen, i hukommelsen, ikke i et persistent datalager, og forsvinder derefter, når programmet afsluttes. En data discovery-scanning, der scanner persistent lager, finder VSAM-kilden og outputdatasættet, men ikke det behandlingsmellemliggende, hvor dataene samles, transformeres og potentielt logges.
Personlige oplysninger krydser IT/OT-grænsen via flade filgrænseflader. Kundedata udtrukket fra mainframe VSAM-filer krydser ofte downstream-systemer via flade filgrænseflader, CSV-uddrag, postfiler med fast længde og positionsformatfiler, der ikke indeholder kolonnemetadata. Den flade fil indeholder personoplysninger i specifikke bytepositioner, men den downstream-scanner, der modtager filen, har intet skema til at knytte positioner til feltbetydninger, medmindre COBOL FD-posten, der definerer postlayoutet, også analyseres.
PII-opgørelsesudfordringen på tværs af en delt ejendom
En virksomhed med både mainframe-systemer med ældre mainframe-systemer og moderne cloudplatforme har en udfordring med hensyn til PII-opgørelse, der spænder over to fundamentalt forskellige tilgange til registrering. Det moderne lag er tilgængeligt for standardværktøjer. Legacy-laget kræver en anden metode. Overholdelseskravet, GDPR's ret til sletning, HIPAA's minimumsnødvendige standard, PCI-DSS' omfang af kortholderdata og CCPA's forbrugerdataopgørelse gælder ligeligt for begge lag. En GDPR-anmodning om adgang til registrerede personer kræver en opgørelse over alle PII, der opbevares om en specifik person på tværs af alle systemer, ikke kun dem, der er forbundet til datakataloget.
Den opdelte ejendoms PII-opgørelse har tre komponenter, der skal fungere sammen:
Moderne dataopgørelser , clouddatabaser, SaaS-platforme, datalagre, API-logfiler og fildelinger kan håndteres af standardværktøjer til registrering af personoplysninger. Værktøjerne i denne kategori scanner efter personoplysninger, klassificerer efter regulering og integrerer med datakatalogplatforme for at producere strukturerede opgørelser. IBM Guardium dækker strukturerede databaser og mainframe-databaser (DB2) med politikdrevet klassificering. Microsoft Purview dækker Microsofts cloudtjenester. BigID og Varonis dækker bredere økosystemer, herunder ustrukturerede data.
Legacy-dataopgørelsen , VSAM-filer, mainframe DB2-skemaer, COBOL-program WORKING-STORAGE og JCL-datasætdefinitioner kræver kildekodeanalyse for at identificere, hvor PII er defineret, gemt og behandlet. Denne analyse læser COBOL-programmerne for at forstå, hvilke data de håndterer, ikke kun de datalagre, de skriver til.
Det grænseoverskridende dataflowopgørelse , de veje hvorigennem PII bevæger sig fra ældre systemer til moderne platforme, ofte gennem flade filgrænseflader uden skema, kræver sporing af dataafstamning fra COBOL-kilden via JCL-jobstrømme til de slutpunkter, hvor dataene når systemer, der kan forbindes. Den flade fil, der forlader mainframen hver nat, er ikke PII-mærket, før det skema, der definerer dens postlayout, er forbundet til destinationsdatasættets kolonnedefinitioner.
De organisationer, der producerer komplette PII-opgørelser, er dem, der har adresseret alle tre komponenter. De organisationer, der ikke består GDPR-revisioner eller HIPAA-gennemgange, har ofte adresseret den første komponent og antaget, at de andre var dækket.
COBOL-specifikke PII-mønstre og hvordan man finder dem
Mønster 1: Direkte PII i FD-poster og kopibøger
Det mest ligefremme COBOL PII-mønster: et felt i en FD-post eller et COPY-medlem, hvis navn, type eller kontekst tydeligt angiver PII. Selv med forkortede navngivningskonventioner er visse mønstre konsekvent til stede:
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
Statisk analyse identificerer PII-kandidatfelter gennem en kombination af navnemønstermatchning (felter, der indeholder NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT) og typeanalyse (PIC X-felter med passende længde til personoplysninger, PIC 9-felter med passende længde til CPR- eller telefonnumre). Outputtet er en opgørelse over mulige PII-felter, der kræver menneskelig validering for de tvetydige tilfælde.
Mønster 2: PII i REDEFINES-strukturer
REDEFINES opretter flere fortolkninger af den samme fysiske lagring. Et felt, der er defineret som generisk datalagring i basisdefinitionen, kan indeholde PII i en af dens REDEFINES-varianter:
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).
PII-omfanget af ACCT-DETAIL kan ikke bestemmes alene ud fra basisfeltdefinitionen. Det kræver analyse af REDEFINES-strukturen for at bestemme, hvilken variant der indeholder PII, og hvilke programmer der tilgår den personlige variant versus den forretningsmæssige variant. En scanner, der kun profilerer kolonnen ACCT_DETAIL i måldatabasen ikke har nogen måde at identificere PII-indholdet ud fra kolonnedefinitionen, PII findes i COBOL-kildestrukturen.
Mønster 3: PII samlet i ARBEJDSLAGRING
Programmer, der samler PII fra flere kilder i WORKING-STORAGE, før de skriver til et output, kan skabe PII-eksponering, der ikke vises i nogen permanent fildefinition:
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.
Dette program opretter et formateret CPR-nummer i WORKING-STORAGE og skriver det til en rapportfil. De personlige oplysninger findes to steder: i kilde-VSAM-filen (som er dækket af filens PII-klassificering) og i rapportens outputfil, som muligvis ikke klassificeres som PII-bærende, medmindre det COBOL-program, der skriver den, analyseres. WRITE REPORT-RECORD FROM WS-REPORT-LINE `udsagnet` er den datalineage-hændelse, der forbinder kundens CPR-nummer til rapportfilen og er kun synlig i PROCEDURE DIVISION.
Mønster 4: PII i JCL-datasætdefinitioner
JCL definerer de datasæt, som programmer læser og skriver. En JCL DD-sætning, der refererer til et datasæt, der indeholder PII, er en del af PII-dataflowet, selvom det ikke selv indeholder data:
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=*Datasættet PROD.CUSTOMER.MASTER.FILE er i PII-opgørelsen fordi COBOL-programmet CUSTUPDT læser fra den, og den indeholder kundeposter. Datasættet BATCH.CUSTOMER.EXTRACT.FILE kræver PII-klassificering fordi CUSTUPDT skriver kundedata til den. JCL'en er den datalinjepost, der forbinder kildedatasættet med outputdatasættet gennem programmet, en forbindelse, der kun er synlig ved at analysere JCL'en sammen med det program, som JCL'en kalder.
Reguleringskortlægning: Hvad hver ramme kræver, og hvor ældre data passer ind
Forskellige regler stiller forskellige krav til omfanget af PII-opdagelse:
GDPR (EU- og EØS-personoplysninger) kræver, at organisationer fører registre over behandlingsaktiviteter (RoPA'er), der dokumenterer al behandling af personoplysninger for EU-borgere, hvor de opbevares, til hvilket formål, under hvilket retsgrundlag og med hvilken opbevaringsperiode. En GDPR-kompatibel RoPA for en organisation, der behandler EU-kundedata på en mainframe, kræver, at mainframe-VSAM-filerne, COBOL-programmerne og JCL-jobstrømmene, der håndterer disse data, vises i RoPA'en. Retten til sletning kræver muligheden for at identificere og slette alle data om en bestemt person, hvilket kræver kendskab til alle de steder, hvor den pågældende persons data vises, herunder mainframe-datasæt, der har været i produktion i tredive år.
HIPAA (US Protected Health Information) kræver, at berørte enheder og forretningsforbindelser beskytter PHI, uanset hvor det findes. En organisation, der behandler sundhedsoplysninger på et mainframe COBOL-system, patientjournaler, skadesdata og autorisationsregistre, skal inkludere dette system i sin HIPAA-risikovurdering og omfang af anmeldelse af brud. Opdateringerne af HIPAA-sikkerhedsreglerne i 2025 har øget håndhævelsesfokus på sikkerhedskontroller for ældre systemer, hvilket prioriterer PHI-opgørelsen for ældre systemer højere end i tidligere håndhævelsescyklusser.
PCI-DSS v4.0 (kortholderdata) kræver et defineret kortholderdatamiljø (CDE), der omfatter alle systemer, der lagrer, behandler eller transmitterer kortholderdata. En organisation, der behandler betalingskorttransaktioner via et COBOL-program, der kører på en mainframe, og som beskriver transaktionsbehandlingsarkitekturen for de fleste større banker og detailhandlere, har et mainframe-system i sin CDE. PCI-DSS-kravet om at scanne systemer inden for området for kortholderdata gælder for mainframe-CDE-komponenterne.
DORA (EU's lov om digital operationel robusthed) for finansielle tjenester kræver IKT-risikostyring, der dækker alle systemer involveret i kritiske funktioner, med særlig vægt på tredjeparts- og ældre systemrisici. En finansiel institutions mainframe COBOL-systemer, der behandler transaktioner og opbevarer kundedata, er omfattet af DORA's IKT-risikoramme, herunder kravet om at opretholde en opdateret oversigt over alle IKT-aktiver, der understøtter kritiske funktioner.
Den fælles tråd: Reguleringskrav til PII-opgørelse har ikke en undtagelse for "ældre systemer er udelukket". De data, der er sværest at finde, er også de data, som regulatorer vil spørge om, når noget går galt.
Arbejdsgangen for opdagelse, maskering og styring
PII-opdagelse er det første trin i en tretrins compliance-workflow:
Discovery identificerer, hvor der findes PII på tværs af alle datalagre, både ældre og moderne. Outputtet er en struktureret opgørelse: hvert datalager, hvert datasæt, hvert felt klassificeret som indeholdende specifikke kategorier af PII, med de lovgivningsmæssige rammer, der gælder for hvert fund.
Maskering beskytter PII i ikke-produktionsmiljøer, udvikling, test og analyse, hvor de fulde produktionsdata ikke er påkrævet, men datastrukturen og -volumen er. GDPR kræver, at PII skal beskyttes gennem teknikker som anonymisering og pseudonymisering i ikke-produktionsmiljøer. Et registreringsprogram, der identificerer PII i mainframe VSAM-filer, muliggør maskering, der erstatter rigtige kundedata med syntetiske ækvivalenter i testmiljøer, men kun hvis PII-felterne er blevet korrekt identificeret i COBOL FD-posterne og kopibøgerne, der definerer postlayoutene.
Governance vedligeholder PII-opgørelsen over tid og sporer, hvornår nye systemer, der indeholder PII, tilføjes, hvornår eksisterende PII-data migreres eller trækkes tilbage, og hvornår lovgivningsmæssige krav ændrer omfanget af, hvad der skal opgøres. For ældre systemer kræver governance ikke blot periodisk genscanning af datalagre, men også overvågning af de kodeændringer, der skaber nye PII-eksponeringer, et COBOL-program, der er modificeret til at skrive et nyt felt til en outputfil, et JCL-job, der er modificeret til at inkludere et nyt datasæt, og en ændring af en kopibog, der tilføjer et PII-felt til et eksisterende postlayout.
Undersøgelsen om virksomhedens dataoverholdelse i 2026, der viser, at kun 2 procent af organisationerne anser deres AI-miljøer for fuldt kompatible, gælder ligeledes for ældre miljøer: compliance svækkes ved grænsen mellem, hvad standardværktøjer dækker, og hvad de ikke dækker. For de fleste organisationer løber denne grænse præcist langs det ældre systems perimeter.
Hvordan SMART TS XL Understøtter PII-opdagelse i ældre miljøer
SMART TS XL's rolle i PII-opdagelse er kildekodeanalyselaget, det trin før standardværktøjer til PII-opdagelse kan udføre deres arbejde i ældre miljøer, og det trin der producerer de metadata, som disse værktøjer har brug for til at klassificere ældre datalagre korrekt.
Funktionen til statisk kodeanalyse analyserer alle COBOL FD-poster, COPY-medlemmer, SELECT-klausuler og PROCEDURE DIVISION for at identificere PII-kandidatfelter gennem navnemønsteranalyse, typeanalyse og kontekstanalyse. Outputtet er en PII-kandidatliste på feltniveau, hvor hvert felt, hvis navn, type, længde eller brugskontekst antyder, indeholder personoplysninger, organiseret efter program, datasæt og felt, med de tekniske COBOL-metadata (type, længde, præcision), som downstream-maskerings- og klassificeringsværktøjer kræver.
Programafhængighedskortlægningen opbygger PII-dataflowkortet: hvert program, der læser fra en PII-holdig VSAM-fil, hvert program , der skriver til et downstream-datasæt, der arver PII fra kilden, hvert JCL-jobtrin, der opretter eller forbruger PII-bærende datasæt. Dette lineage-kort er den grænseoverskridende dataflowopgørelse, registreringen af, hvordan PII bevæger sig fra sin mainframe-oprindelse gennem transformationsprogrammerne og JCL-jobstrømmene, der i sidste ende leverer den til moderne systemer.
JCL -udvidelsesfunktionen sporer den komplette operationelle kontekst for hvert PII-bærende datasæt: hvilke JCL-job refererer til det, i hvilken rækkefølge, med hvilke dispositionskoder, og hvilke downstream-datasæt jobbet opretter ud fra det. For GDPR-anmodninger om ret til sletning identificerer dette operationelle kort hvert sted, hvor en specifik kundes data kan være blevet skrevet som følge af behandlingen af deres kildepost, herunder mellemliggende arbejdsfiler, sorteringsarbejdsdatasæt og rapportfiler oprettet under batchbehandling.
Virksomhedssøgningsfunktionen gør det muligt at forespørge på PII-fortegnelsen til understøttelse af anmodninger om indsigt fra registrerede og lovgivningsmæssige revisioner: find alle programmer, der tilgår et specifikt felt, alle datasæt, der indeholder poster med en specifik nøgleværdi, alle JCL-job, der behandler et specifikt datasæt. Denne søgefunktion omdanner en PII-fortegnelse fra et statisk dokument til en live forespørgselsgrænseflade, værktøjet der besvarer "hvor er denne persons data" på timer i stedet for uger.
For organisationer, der udfører arvemodernisering programmer, SMART TS XLs PII-opdagelsesanalyse er en forudsætning for compliance: Compliance-området under PCI-DSS, HIPAA og GDPR omfatter følsomme data, så snart de forlader deres oprindelige miljø. De PII, der transporteres med migrerede data, skal optegnes før migrering, beskyttes under migrering og verificeres igen efter migrering. Du migrerer ikke bare kode. Du migrerer risiko.
Compliance-perimeteret omfatter alt, der indeholder personoplysninger
De lovgivningsmæssige rammer for beskyttelse af personoplysninger, GDPR, HIPAA, PCI-DSS, CCPA og DORA, blev skrevet med universel rækkevidde. De gælder for personoplysninger, uanset hvor de findes, uanset alderen på det system, der opbevarer dem, uanset om systemet har en moderne forbindelse, og uanset om organisationens datakatalog har indsigt i dem.
Manglen på PII-opdagelse i ældre miljøer er ikke en teknisk begrænsning, som tilsynsmyndighederne accepterer som en undskyldning. Det er et compliance-mangel, som håndhævelsesforanstaltninger behandler som en manglende implementering af passende sikkerhedsforanstaltninger, den samme standard, der gælder for moderne systemer, anvendt på systemer, der kræver forskellige opdagelsesmetoder for korrekt revision.
At lukke dette hul kræver en erkendelse af, at mainframe-laget i virksomhedens databeskyttelse indeholder betydelige mængder af PII, at standard discovery-værktøjer ikke kan nå det gennem deres standardforbindelsesmetoder, og at kildekodeanalyse af COBOL-programmerne og JCL-jobstrømme, der administrerer disse data, er den tilgang, der producerer en komplet oversigt. Fuldstændig discovery på tværs af både det ældre og det moderne lag er ikke en teknisk ambition. Det er den baseline, som compliance-programmer evalueres i forhold til.
