The IBM Cost of a Data Breach Report 2025 puts the average breach cost at $4.44 million. Breaches involving personal data draw the largest regulatory penalties under GDPR and HIPAA, not because personal data breaches are more expensive to remediate in technical terms, but because regulators treat them differently. GDPR fines can reach four percent of global annual revenue. HIPAA civil penalties reach $1.9 million per violation category per year. The organizational exposure from a single breach of a system whose PII inventory was incomplete, because the discovery program that should have found it covered only the modern stack and stopped at the mainframe boundary, is not a data engineering problem. It is a regulatory and financial risk that sits on the board agenda.
Most organizations cannot produce a complete PII inventory on demand. The standard PII discovery tools, Varonis, IBM Guardium, BigID, Microsoft Purview, Strac, excel at scanning structured databases, cloud storage, SaaS platforms, and file shares. They connect to what they can connect to. What they cannot connect to, they cannot scan. VSAM files on z/OS do not have JDBC connectors. COBOL programs that hold customer data in WORKING-STORAGE during batch processing do not expose data through APIs. JCL dataset definitions do not register in a data catalog. The mainframe layer, which processes 95 percent of ATM transactions and handles an estimated $3 trillion in daily commerce, is the largest, most PII-dense, and most systematically under-scanned layer in enterprise data estates. You cannot protect what you cannot find, and most organizations have not found all of it.
The PII Your Catalog Cannot Reach
SMART TS XL traces PII from VSAM source through COBOL programs to every downstream dataset that inherits it.
FÅ MERE AT VIDE…Why the Legacy Layer Is the Hardest Part of PII Discovery
The standard PII discovery challenge, finding names, addresses, social security numbers, and payment card data scattered across hundreds of databases and file shares, is difficult but tractable with modern tooling. The pattern-matching approaches that underpin most PII discovery tools work well against structured data with accessible connectors: scan the columns, apply regex patterns, flag fields that match PII signatures, classify and inventory.
The legacy layer introduces four properties that break the pattern-matching approach:
Abbreviated field names with no semantic signal. COBOL field names are limited to 30 characters in modern dialects and were commonly written in 8-character abbreviated form in older code: CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DT. A pattern-matching scanner that identifies social_security_number or customer_name as PII field indicators has no basis for classifying SSN-NO or CUST-NM without understanding COBOL naming conventions. The abbreviation convention is itself a metadata problem, the field contains PII, but its name does not clearly signal that to a scanner designed for modern naming conventions.
PII embedded in composite structures. COBOL records frequently pack multiple data elements into a single field or use REDEFINES to overlay different interpretations on the same bytes. A customer record field CUST-FULL-DATA defineret som PIC X(100) may contain name, address, and phone number concatenated into a single string with fixed-position subfields, a structure that appears as a single opaque text field to any scanner that reads only the field definition without understanding the program logic that populates and reads it.
PII in transit through WORKING-STORAGE. COBOL batch programs frequently read PII from VSAM files, process it in WORKING-STORAGE variables, and write outputs to datasets. The PII exists in WORKING-STORAGE during execution, in memory, not in a persistent data store, and then disappears when the program terminates. A data discovery scan that scans persistent storage finds the VSAM source and the output dataset but not the processing intermediate where the data is assembled, transformed, and potentially logged.
PII crossing the IT/OT boundary through flat file interfaces. Customer data extracted from mainframe VSAM files frequently crosses to downstream systems through flat file interfaces, CSV extracts, fixed-length record files, positional format files, that do not carry column metadata. The flat file contains PII in specific byte positions, but the downstream scanner that receives the file has no schema to map positions to field meanings unless the COBOL FD entry that defines the record layout is also analyzed.
The PII Inventory Challenge Across a Split Estate
An enterprise with both mainframe legacy systems and modern cloud platforms has a PII inventory challenge that spans two fundamentally different discovery approaches. The modern layer is accessible to standard tooling. The legacy layer requires a different method. The compliance requirement, GDPR’s right to erasure, HIPAA’s minimum necessary standard, PCI-DSS’s cardholder data scope, CCPA’s consumer data inventory, applies to both layers equally. A GDPR data subject access request requires an inventory of all PII held about a specific individual across all systems, not just the ones that connect to the data catalog.
The split-estate PII inventory has three components that must work together:
The modern data inventory, cloud databases, SaaS platforms, data warehouses, API logs, and file shares, is addressable by standard PII discovery tools. The tools in this category scan for PII patterns, classify by regulation, and integrate with data catalog platforms to produce structured inventories. IBM Guardium covers structured databases and mainframe databases (DB2) with policy-driven classification. Microsoft Purview covers Microsoft cloud services. BigID and Varonis cover broader ecosystems including unstructured data.
The legacy data inventory, VSAM files, mainframe DB2 schemas, COBOL program WORKING-STORAGE, JCL dataset definitions, requires source code analysis to identify where PII is defined, stored, and processed. This analysis reads the COBOL programs to understand what data they handle, not just the data stores they write to.
The cross-boundary data flow inventory, the pathways through which PII moves from legacy systems to modern platforms, often through flat file interfaces that carry no schema, requires tracing data lineage from COBOL source through JCL job streams to the endpoints where the data reaches connectable systems. The flat file that exits the mainframe nightly is not PII-tagged until the schema that defines its record layout is connected to the destination dataset’s column definitions.
The organizations that produce complete PII inventories are the ones that have addressed all three components. The organizations that fail GDPR audits or HIPAA reviews frequently have addressed the first component and assumed the others were covered.
COBOL-Specific PII Patterns and How to Find Them
Pattern 1: Direct PII in FD Entries and Copybooks
The most straightforward COBOL PII pattern: a field in an FD entry or COPY member whose name, type, or context clearly indicates PII. Even with abbreviated naming conventions, certain patterns are consistently present:
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
Static analysis identifies PII candidate fields through a combination of name pattern matching (fields containing NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT) and type analysis (PIC X fields of appropriate length for personal data, PIC 9 fields of appropriate length for SSN or phone numbers). The output is a candidate PII field inventory that requires human validation for the ambiguous cases.
Pattern 2: PII in REDEFINES Structures
REDEFINES creates multiple interpretations of the same physical storage. A field that is defined as generic data storage in the base definition may contain PII in one of its REDEFINES variants:
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).
The PII scope of ACCT-DETAIL is not determinable from the base field definition alone. It requires analysis of the REDEFINES structure to determine which variant contains PII and which programs access the personal variant versus the business variant. A scanner that profiles only the column ACCT_DETAIL in the target database has no way to identify the PII content from the column definition, the PII lives in the COBOL source structure.
Pattern 3: PII Assembled in WORKING-STORAGE
Programs that assemble PII from multiple sources in WORKING-STORAGE before writing to an output may create PII exposure that does not appear in any persistent file definition:
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.
This program creates a formatted SSN in WORKING-STORAGE and writes it to a report file. The PII exists in two places: the source VSAM file (covered by the file’s PII classification) and the report output file, which may not be classified as PII-bearing unless the COBOL program that writes it is analyzed. The WRITE REPORT-RECORD FROM WS-REPORT-LINE statement is the data lineage event that connects customer SSN to the report file, visible only in the PROCEDURE DIVISION.
Pattern 4: PII in JCL Dataset Definitions
JCL defines the datasets that programs read and write. A JCL DD statement that references a dataset containing PII is part of the PII data flow even though it contains no data itself:
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 is in the PII inventory because the COBOL program CUSTUPDT reads from it and it contains customer records. The dataset BATCH.CUSTOMER.EXTRACT.FILE requires PII classification because CUSTUPDT writes customer data to it. The JCL is the data lineage record that connects the source dataset to the output dataset through the program, a connection visible only by analyzing the JCL alongside the program that the JCL invokes.
Regulatory Mapping: What Each Framework Requires and Where Legacy Data Fits
Different regulations impose different requirements on PII discovery scope:
GDPR (EU and EEA personal data) requires organizations to maintain Records of Processing Activities (RoPAs) documenting all processing of EU residents’ personal data, where it is stored, for what purpose, under what legal basis, and with what retention period. A GDPR-compliant RoPA for an organization processing EU customer data on a mainframe requires the mainframe VSAM files, COBOL programs, and JCL job streams that handle that data to appear in the RoPA. The right to erasure requires the ability to identify and delete all data about a specific individual, which requires knowing all the locations where that individual’s data appears, including mainframe datasets that have been in production for thirty years.
HIPAA (US Protected Health Information) requires covered entities and business associates to safeguard PHI wherever it exists. An organization that processes health information on a mainframe COBOL system, patient records, claims data, authorization records, must include that system in its HIPAA risk assessment and breach notification scope. The 2025 HIPAA Security Rule updates have increased enforcement attention on legacy system security controls, making the PHI inventory for legacy systems a higher priority than it was in previous enforcement cycles.
PCI-DSS v4.0 (cardholder data) requires a defined Cardholder Data Environment (CDE) that encompasses all systems that store, process, or transmit cardholder data. An organization that processes payment card transactions through a COBOL program running on a mainframe, which describes the transaction processing architecture of most major banks and retailers, has a mainframe system within its CDE. The PCI-DSS requirement to scan in-scope systems for cardholder data applies to the mainframe CDE components.
DORA (EU Digital Operational Resilience Act) for financial services requires ICT risk management that covers all systems involved in critical functions, with specific attention to third-party and legacy system risk. A financial institution’s mainframe COBOL systems that process transactions and hold customer data are in scope for DORA’s ICT risk framework, including the requirement to maintain an up-to-date inventory of all ICT assets supporting critical functions.
The common thread: regulatory PII inventory requirements do not have a “legacy systems excluded” carve-out. The data that is hardest to find is also the data that regulators will ask about when something goes wrong.
The Discovery-Masking-Governance Workflow
PII discovery is the first step in a three-step compliance workflow:
Discovery identifies where PII exists across all data stores, legacy and modern. The output is a structured inventory: every data store, every dataset, every field classified as containing specific categories of PII, with the regulatory frameworks that apply to each finding.
Masking protects PII in non-production environments, development, testing, analytics, where the full production data is not required but the data structure and volume are. GDPR mandates that PII must be protected through techniques like anonymization and pseudonymization in non-production environments. A discovery program that identifies PII in mainframe VSAM files enables masking that replaces real customer data with synthetic equivalents in test environments, but only if the PII fields have been correctly identified in the COBOL FD entries and copybooks that define the record layouts.
Governance maintains the PII inventory over time, tracking when new PII-containing systems are added, when existing PII data is migrated or retired, and when regulatory requirements change the scope of what must be inventoried. For legacy systems, governance requires not just periodic re-scanning of data stores but monitoring of the code changes that create new PII exposures, a COBOL program modified to write a new field to an output file, a JCL job modified to include a new dataset, a copybook change that adds a PII field to an existing record layout.
The 2026 State of Enterprise Data Compliance survey finding that only 2 percent of organizations consider their AI environments fully compliant applies equally to legacy environments: compliance weakens at the boundary between what standard tools cover and what they do not. For most organizations, that boundary runs exactly along the legacy system perimeter.
Hvordan SMART TS XL Supports PII Discovery in Legacy Environments
SMART TS XL’s role in PII discovery is the source code analysis layer, the step before standard PII discovery tools can do their work in legacy environments, and the step that produces the metadata those tools need to classify legacy data stores correctly.
statisk kodeanalyse capability analyzes every COBOL FD entry, COPY member, SELECT clause, and PROCEDURE DIVISION to identify PII candidate fields through name pattern analysis, type analysis, and context analysis. The output is a field-level PII candidate inventory, every field whose name, type, length, or usage context suggests it contains personal data, organized by program, dataset, and field, with the COBOL technical metadata (type, length, precision) that downstream masking and classification tools require.
kortlægning af applikationsafhængighed builds the PII data flow map: every program that reads from a PII-containing VSAM file, every program that writes to a downstream dataset that inherits PII from the source, every JCL job step that creates or consumes PII-bearing datasets. This lineage map is the cross-boundary data flow inventory, the record of how PII moves from its mainframe origin through the transformation programs and JCL job streams that eventually deliver it to modern systems.
JCL udvidelse capability traces the complete operational context of every PII-bearing dataset: which JCL jobs reference it, in what sequence, with what disposition codes, and which downstream datasets the job creates from it. For GDPR right-to-erasure requests, this operational map identifies every place where a specific customer’s data may have been written as a consequence of processing their source record, including intermediate work files, sort work datasets, and report files created during batch processing.
virksomhedssøgning capability makes the PII inventory queryable in support of data subject access requests and regulatory audits: find every program that accesses a specific field, every dataset that contains records with a specific key value, every JCL job that processes a specific dataset. This search capability transforms a PII inventory from a static document into a live query interface, the tool that answers “where is this person’s data” in hours rather than weeks.
For organisationer, der udfører arvemodernisering programmer, SMART TS XL’s PII discovery analysis is a compliance prerequisite: the compliance scope under PCI-DSS, HIPAA, and GDPR extends to sensitive data as soon as it leaves its original environment. The PII that travels with migrated data must be inventoried before migration, protected during migration, and re-verified after migration. You are not just migrating code. You are migrating risk.
The Compliance Perimeter Includes Everything That Holds Personal Data
The regulatory frameworks governing personal data protection, GDPR, HIPAA, PCI-DSS, CCPA, DORA, were written with universal scope. They apply to personal data wherever it exists, regardless of the age of the system that holds it, regardless of whether that system has a modern connector, and regardless of whether the organization’s data catalog has visibility into it.
The PII discovery gap in legacy environments is not a technical limitation that regulators accept as an excuse. It is a compliance gap that enforcement actions treat as a failure to implement appropriate safeguards, the same standard that applies to modern systems, applied to systems that require different discovery methods to audit correctly.
Closing that gap requires acknowledging that the mainframe layer of the enterprise data estate holds significant quantities of PII, that standard discovery tools cannot reach it through their standard connection methods, and that source code analysis of the COBOL programs and JCL job streams that manage that data is the approach that produces a complete inventory. Complete discovery across both the legacy and modern layers is not a technical aspiration. It is the baseline that compliance programs are evaluated against.
