IBM發布的《2025年資料外洩成本報告》指出，平均每次資料外洩的成本為4.44萬美元。根據GDPR和HIPAA的規定，涉及個人資料的外洩事件會招致最嚴厲的監管處罰，這並非因為個人資料外洩的修復成本更高，而是因為監管機構對此類事件的處理方式不同。 GDPR的罰款最高可達全球年收入的4%。 HIPAA的民事罰款則高達每年每類違規行為190萬美元。如果某個系統的個人識別資訊（PII）清單不完整（因為本應發現此類洩漏的發現程序僅涵蓋了現代技術棧，止步於大型機邊界），那麼由此造成的組織風險並非資料工程問題，而是必須列入董事會議程的監管和財務風險。
大多數組織無法按需產生完整的個人識別資訊 (PII) 清單。標準的 PII 發現工具，例如 Varonis、IBM Guardium、BigID、Microsoft Purview 和 Strac，擅長掃描結構化資料庫、雲端儲存、SaaS 平台和檔案共用。它們只能連接到它們能夠連接的物件。無法連接的對象，它們也無法掃描。 z/OS 上的 VSAM 檔案沒有 JDBC 連接器。在批次期間將客戶資料儲存在工作儲存 (WORKING-STORAGE) 中的 COBOL 程式不會透過 API 公開資料。 JCL 資料集定義不會在資料目錄中註冊。大型主機層處理 95% 的 ATM 交易，每天處理約 3 兆美元的商業交易，它是企業資料資產中規模最大、PII 密度最高、且系統性掃描不足最多的層。你無法保護你找不到的東西，而大多數組織尚未找到所有 PII。
為什麼遺留層是個人識別資訊發現中最困難的部分
標準的個人識別資訊 (PII) 發現挑戰在於，如何在數百個資料庫和文件共享中找到姓名、地址、社會安全號碼和支付卡資料。雖然難度很高，但藉助現代工具是可以應付的。大多數 PII 發現工具所依賴的模式匹配方法，對於具有易於存取的連接器的結構化資料非常有效：掃描列、應用正規表示式模式、標記與 PII 簽章相符的欄位、進行分類和清點。
遺留層引入了四個特性，這些特性破壞了模式匹配方法：
不帶語意資訊的縮寫欄位名稱。 現代 COBOL 方言中字段名稱限制為 30 個字符，而舊代碼中通常使用 8 個字符的縮寫形式： CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DT一種用於識別的模式匹配掃描器 social_security_number or customer_name 作為PII領域指標，沒有分類依據 SSN-NO or CUST-NM 如果不了解 COBOL 的命名規則，就會出現問題。縮寫規則本身就是一個元資料問題，該欄位包含個人識別資訊 (PII)，但其名稱無法向專為現代命名規則設計的掃描器清晰地表明這一點。
PII 嵌入複合結構中。 COBOL 記錄經常將多個資料元素打包到一個欄位中，或使用 REDEFINES 對相同的位元組進行不同的解釋。客戶記錄字段 CUST-FULL-DATA 定義為 PIC X(100) 可能包含姓名、地址和電話號碼，這些名稱、地址和電話號碼連接成一個字串，其中包含固定位置的子欄位。對於任何只讀取字段定義而不理解填充和讀取該字段的程式邏輯的掃描器來說，這種結構看起來就像一個不透明的文字字段。
個人識別資訊 (PII) 在工作儲存區 (WORKING-STORAGE) 中傳輸。 COBOL批次程式經常從 VSAM 檔案讀取 PII，在工作儲存區變數中處理這些訊息，並將輸出寫入資料集。 PII 在程式執行期間存在於工作儲存區記憶體中，而非持久性資料儲存區，並在程式終止時消失。持久儲存區的資料發現掃描可以找到 VSAM 來源和輸出資料集，但無法找到資料組裝、轉換和可能記錄的中間處理過程。
個人識別資訊(PII) 透過平面文件介面跨越 IT/OT 邊界。從大型主機 VSAM 檔案中提取的客戶資料經常透過平面檔案介面、CSV 提取檔案、固定長度記錄檔案和位置格式檔案等方式傳輸到下游系統，而這些檔案不包含列元資料。平面檔案在特定位元組位置包含 PII，但接收該檔案的下游掃描器沒有對應的模式來將位置對應到欄位意義，除非同時分析定義記錄佈局的 COBOL FD 條目。
跨分散架構的個人識別資訊清單挑戰
同時擁有大型主機傳統系統和現代雲端平台的企業，在個人識別資訊 (PII) 清點方面面臨著一項挑戰，該挑戰涉及兩種截然不同的發現方法。現代系統層可以使用標準工具進行訪問，而傳統系統層則需要不同的方法。合規性要求，例如 GDPR 的刪除權、HIPAA 的最小必要標準、PCI-DSS 的持卡人資料範圍以及 CCPA 的消費者資料清單，對這兩個系統層均適用。 GDPR 資料主體存取請求需要清點所有系統中關於特定個人的所有 PII，而不僅僅是那些連接到資料目錄的系統。
分拆遺產的個人識別資訊清單包含三個必須協同運作的組成部分：
現代資料清單，包括雲端資料庫、SaaS平台、資料倉儲、API日誌和文件共享，均可透過標準的個人識別資訊 (PII) 發現工具進行管理。此類工具可掃描 PII 模式，按法規進行分類，並與資料目錄平台集成，從而產生結構化清單。 IBM Guardium 涵蓋結構化資料庫和大型主機資料庫 (DB2)，並提供基於策略的分類。 Microsoft Purview 涵蓋 Microsoft 雲端服務。 BigID 和 Varonis 則涵蓋更廣泛的生態系統，包括非結構化資料。
遺留資料清單（包括 VSAM 檔案、大型主機 DB2 模式、COBOL 程式工作儲存、JCL 資料集定義等）需要進行原始碼分析，以確定個人識別資訊 (PII) 的定義、儲存和處理位置。此分析會讀取 COBOL 程序，以了解它們處理的特定數據，而不僅僅是它們寫入的資料儲存。
跨邊界資料流清單，即個人識別資訊 (PII) 從傳統系統流向現代平台的路徑（通常透過不包含模式的平面文件介面），需要追蹤資料沿襲，從 COBOL 原始碼經由 JCL 作業流直到資料到達可連接系統的端點。每晚從主機輸出的平面檔案只有在定義其記錄佈局的模式與目標資料集的列定義關聯後，才會被標記 PII。
能夠編製完整個人識別資訊清單的機構，都已涵蓋了所有三個組成部分。而那些未能透過 GDPR 審計或 HIPAA 審查的機構，通常只涵蓋了第一個組成部分，就想當然地認為其他部分也已包含在內。
COBOL特有的PII模式及其查找方法
模式 1：直接在財務報表條目和副本簿中揭露個人識別資訊
最直接的 COBOL PII 模式：FD 條目或 COPY 成員中的字段，其名稱、類型或上下文明確指示為 PII。即使採用縮寫命名約定，某些模式仍然始終存在：
科博爾
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
靜態分析透過名稱模式匹配（包含以下欄位的欄位）來識別 PII 候選欄位。 NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT）以及類型分析（PIC X 欄位長度適宜，用於個人資料；PIC 9 欄位長度適宜，用於社會保障號碼或電話號碼）。輸出結果是一個候選個人識別資訊 (PII) 欄位清單，其中存在歧義的情況需要人工驗證。
模式 2：REDEFINES 結構中的 PII
REDEFINES 會建立同一實體儲存的多種解釋。在基本定義中被定義為通用資料儲存的字段，在其某個 REDEFINES 變體中可能包含個人識別資訊 (PII)：
科博爾
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).
個人識別資訊範圍 ACCT-DETAIL 僅憑基本欄位定義無法確定。需要分析 REDEFINES 結構，以確定哪個變體包含 PII，以及哪些程式存取個人變體，哪些程式存取業務變體。僅對該列進行分析的掃描器 ACCT_DETAIL 目標資料庫中無法從列定義中辨識 PII 內容，PII 存在於 COBOL 來源結構中。
模式 3：PII 在工作儲存中組裝
在寫入輸出之前，將工作儲存區中的多個來源的個人識別資訊 (PII) 彙編在一起的程式可能會造成 PII 洩露，而這種洩露不會出現在任何持久性文件定義中：
科博爾
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.
此程式會在工作儲存區 (WORKING-STORAGE) 中建立一個格式化的社會安全號碼 (SSN)，並將其寫入報告文件。個人識別資訊 (PII) 存在於兩個位置：來源 VSAM 檔案（受該檔案的 PII 分類保護）和報告輸出檔案。除非分析寫入該檔案的 COBOL 程序，否則報告輸出檔案可能不會被分類為包含 PII。 WRITE REPORT-RECORD FROM WS-REPORT-LINE 聲明是將客戶 SSN 與報告文件連接起來的資料沿襲事件，僅在 PROCEDURE DIVISION 中可見。
模式 4：JCL 資料集定義中的 PII
JCL 定義了程式讀取和寫入的資料集。即使 JCL DD 語句本身不包含任何數據，但如果它引用了包含 PII 的資料集，則該語句也是 PII 資料流的一部分：
cl
//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=*數據集 PROD.CUSTOMER.MASTER.FILE 由於 COBOL 程序，因此它已列入 PII 清單。 CUSTUPDT 從中讀取數據，其中包含客戶記錄。該數據集 BATCH.CUSTOMER.EXTRACT.FILE 需要進行PII分類，因為 CUSTUPDT 向其中寫入客戶資料。 JCL 是資料沿襲記錄，它透過程式將來源資料集連接到輸出資料集，這種連接只有透過分析 JCL 以及 JCL 呼叫的程式才能看到。
監理架構映射：各框架的要求以及歷史資料的適用範圍
不同的法規對個人識別資訊（PII）的發現範圍有不同的要求：
GDPR（歐盟和歐洲經濟區個人資料）要求組織機構維護處理活動記錄 (RoPA)，記錄所有歐盟居民個人資料的處理過程，包括資料的儲存位置、處理目的、法律依據和保留期限。對於在大型主機上處理歐盟客戶資料的組織機構而言，符合 GDPR 規定的 RoPA 要求處理這些資料的大型主機 VSAM 檔案、COBOL 程序和 JCL 作業流程都必須包含在 RoPA 中。被遺忘權要求能夠識別並刪除關於特定個人的所有數據，這就需要了解該個人資料存在的所有位置，包括已在生產環境中運行三十年的大型主機資料集。
美國《受保護健康資訊法案》(HIPAA)要求受監管實體和業務夥伴保護其所有儲存位置的受保護健康資訊 (PHI)。如果某個組織在大型主機 COBOL 系統上處理健康資訊、病患記錄、理賠資料和授權記錄，則必須將系統納入其 HIPAA 風險評估和違規通知範圍。 2025 年 HIPAA 安全規則的更新加強了對遺留系統安全控制的執法力度，使得遺留系統的 PHI 清單比以往的執法週期更為重要。
PCI-DSS v4.0（持卡人資料）要求定義一個持卡人資料環境 (CDE)，該環境涵蓋所有儲存、處理或傳輸持卡人資料的系統。對於透過運行在大型主機上的 COBOL 程式處理支付卡交易的機構（這描述了大多數主要銀行和零售商的交易處理架構），其 CDE 中包含一個大型主機系統。 PCI-DSS 對適用範圍內的系統進行持卡人資料掃描的要求同樣適用於大型主機 CDE 組件。
歐盟《數位營運韌性法案》(DORA)針對金融服務業，要求對所有關鍵功能係統進行資訊通訊技術 (ICT) 風險管理，尤其關注第三方風險和遺留系統風險。金融機構用於處理交易和儲存客戶資料的主機 COBOL 系統均在 DORA 的 ICT 風險框架範圍內，其中包括維護所有支援關鍵功能的 ICT 資產的最新清單的要求。
共同點是：監管機構對個人識別資訊 (PII) 清單的要求並沒有「排除遺留系統」的例外條款。最難取得的數據，恰恰也是監管機構在出現問題時會要求提供的數據。
發現-掩蔽-治理工作流程
個人識別資訊 (PII) 發現是三步驟合規工作流程的第一步：
發現功能可識別所有資料儲存（包括傳統資料儲存和現代資料儲存）中個人識別資訊 (PII) 的位置。輸出結果為結構化清單：包含每個資料儲存、每個資料集、每個被分類為包含特定類別 PII 的字段，以及適用於每項發現的監管框架。
在非生產環境（例如開發、測試和分析環境）中，遮罩技術可以保護個人識別資訊 (PII)。在這些環境中，雖然不需要完整的生產數據，但需要數據結構和數據量。 GDPR 規定，在非生產環境中必須使用匿名化和假名化等技術來保護 PII。透過發現大型主機 VSAM 檔案中的 PII，可以在測試環境中使用遮罩技術，將真實的客戶資料替換為合成的等效資料。但前提是，必須在定義記錄佈局的 COBOL FD 條目和副本中正確識別 PII 欄位。
治理機制負責維護個人識別資訊 (PII) 清單，追蹤何時新增包含 PII 的系統、何時遷移或停用現有 PII 數據，以及監管要求何時變更清單範圍。對於遺留系統，治理不僅需要定期重新掃描資料存儲，還需要監控導致新的 PII 洩漏的代碼變更，例如：修改 COBOL 程式以向輸出檔案寫入新欄位、修改 JCL 作業以包含新資料集，或修改副本簿以向現有記錄佈局新增 PII 欄位。
2026 年企業資料合規性調查發現，只有 2% 的組織認為其人工智慧環境完全合規，這項發現同樣適用於傳統環境：合規性在標準工具的覆蓋範圍與不覆蓋範圍的交界處會減弱。對大多數組織而言，這條交界線恰好位於傳統系統的邊界上。
SMART TS XL 支持在傳統環境中發現個人識別訊息
SMART TS XL的 PII 發現功能是原始碼分析層，是標準 PII 發現工具在遺留環境中進行工作之前的步驟，也是產生這些工具正確分類遺留資料儲存所需的元資料的步驟。
靜態程式碼分析功能會分析每個 COBOL 函數定義條目、COPY 成員、SELECT 子句和流程部，透過名稱模式分析、類型分析和上下文分析來識別個人識別資訊 (PII) 候選欄位。輸出結果是一個字段級 PII 候選清單，其中包含所有名稱、類型、長度或使用上下文表明其包含個人資料的字段，並按程序、資料集和字段進行組織，同時包含下游脫敏和分類工具所需的 COBOL 技術元資料（類型、長度、精度）。
應用程式依賴關係映射建構了PII資料流程圖：它涵蓋了從包含PII的VSAM檔案中讀取資料的每個程式、寫入從來源繼承PII的下游資料集的每個程序，以及建立或使用包含PII的資料集的每個JCL作業步驟。此血緣關係圖是跨邊界資料流清單，記錄了PII如何從其主機來源透過轉換程序和JCL作業流最終交付到現代系統的過程。
JCL擴充功能可追蹤每個包含個人識別資訊 (PII) 的資料集的完整操作上下文：哪些 JCL 作業引用了該資料集，引用順序如何，使用了哪些處置代碼，以及作業從中建立了哪些下游資料集。對於 GDPR 刪除權請求，此操作圖譜可識別出在處理特定客戶來源記錄過程中可能寫入其資料的每個位置，包括中間工作文件、排序工作資料集以及批次期間建立的報表檔案。
企業級搜尋功能使個人識別資訊 (PII) 清單可進行查詢，從而支援資料主體存取請求和監管稽核：查找存取特定欄位的每個程式、包含具有特定鍵值記錄的每個資料集、處理特定資料集的每個 JCL 作業。此搜尋功能將 PII 清單從靜態文件轉換為即時查詢介面，只需數小時而非數週即可解答「此人的資料在哪裡？」的問題。
對於進行以下活動的組織 遺產現代化 程式， SMART TS XL個人識別資訊 (PII) 的發現分析是合規性的先決條件：根據 PCI-DSS、HIPAA 和 GDPR 的規定，一旦敏感資料離開其原始環境，合規範圍即擴展至這些資料。隨遷移資料一起遷移的 PII 必須在遷移前進行清點，在遷移過程中進行保護，並在遷移後進行重新驗證。您遷移的不僅是程式碼，更是風險。
合規範圍涵蓋所有儲存個人資料的內容
規範個人資料保護的監管框架，如GDPR、HIPAA、PCI-DSS、CCPA和DORA，其製定時就具有普遍適用性。這些框架適用於任何形式的個人數據，無論其存在於何處，也無論儲存資料的系統有多麼新舊，無論該系統是否配備了現代化的連接器，以及無論組織的資料目錄是否能夠存取這些資料。
傳統環境中個人識別資訊 (PII) 發現的不足並非監管機構可以接受的技術限制，而是合規性方面的缺陷。執法行動將其視為未能實施適當安全措施，此標準與適用於現代系統的標準相同，同樣適用於需要不同發現方法才能進行正確審計的系統。
彌合這一差距需要認識到，企業資料資產的主機層儲存大量的個人識別資訊 (PII)，標準發現工具無法透過其標準連接方式存取該層，而對管理這些資料的 COBOL 程式和 JCL 作業流程進行原始程式碼分析才是產生完整清單的唯一方法。對傳統層和現代層進行全面發現並非技術上的願望，而是合規性評估的基準。
