O relatório da IBM sobre o custo de uma violação de dados em 2025 estima o custo médio de uma violação em US$ 4.44 milhões. Violações envolvendo dados pessoais acarretam as maiores penalidades regulatórias sob o GDPR e o HIPAA, não porque as violações de dados pessoais sejam mais caras de remediar em termos técnicos, mas sim porque os órgãos reguladores as tratam de forma diferente. As multas do GDPR podem chegar a 4% da receita global anual. As penalidades civis do HIPAA chegam a US$ 1.9 milhão por categoria de violação por ano. A exposição organizacional decorrente de uma única violação de um sistema cujo inventário de informações pessoais identificáveis (PII) estava incompleto, porque o programa de descoberta que deveria tê-la detectado abrangia apenas a infraestrutura moderna e parava no limite do mainframe, não é um problema de engenharia de dados. É um risco regulatório e financeiro que consta da agenda do conselho administrativo.
A maioria das organizações não consegue gerar um inventário completo de informações pessoais identificáveis (PII) sob demanda. As ferramentas padrão de descoberta de PII, como Varonis, IBM Guardium, BigID, Microsoft Purview e Strac, são excelentes para escanear bancos de dados estruturados, armazenamento em nuvem, plataformas SaaS e compartilhamentos de arquivos. Elas se conectam ao que conseguem. O que não conseguem, não conseguem escanear. Arquivos VSAM no z/OS não possuem conectores JDBC. Programas COBOL que armazenam dados de clientes em WORKING-STORAGE durante o processamento em lote não expõem os dados por meio de APIs. Definições de conjuntos de dados JCL não são registradas em um catálogo de dados. A camada de mainframe, que processa 95% das transações em caixas eletrônicos e movimenta cerca de US$ 3 trilhões em transações diárias, é a maior, mais densa em PII e mais sistematicamente subescaneada camada nos ambientes de dados corporativos. Não se pode proteger o que não se consegue encontrar, e a maioria das organizações ainda não encontrou tudo.
As informações pessoais que seu catálogo não pode acessar.
SMART TS XL Rastreia informações pessoais identificáveis (PII) desde a fonte VSAM, passando por programas COBOL, até cada conjunto de dados subsequente que as herda.
SAIBA MAIS…Por que a camada legada é a parte mais difícil da descoberta de informações pessoais identificáveis?
O desafio padrão de descoberta de informações pessoais identificáveis (PII), que consiste em encontrar nomes, endereços, números de segurança social e dados de cartões de pagamento dispersos em centenas de bases de dados e partilhas de ficheiros, é difícil, mas viável com ferramentas modernas. As abordagens de correspondência de padrões que sustentam a maioria das ferramentas de descoberta de PII funcionam bem com dados estruturados e conectores acessíveis: analisar as colunas, aplicar padrões de expressões regulares, sinalizar campos que correspondam a assinaturas de PII, classificar e inventariar.
A camada legada introduz quatro propriedades que quebram a abordagem de correspondência de padrões:
Nomes de campos abreviados sem qualquer sinal semântico. Os nomes de campos em COBOL são limitados a 30 caracteres nas versões modernas e eram comumente escritos em forma abreviada de 8 caracteres em códigos mais antigos: CUST-NM, SSN-NO, ACCT-ADDR, BRTH-DTUm scanner de reconhecimento de padrões que identifica social_security_number or customer_name visto que os indicadores de campo PII não têm base para classificação SSN-NO or CUST-NM Sem entender as convenções de nomenclatura do COBOL, a própria convenção de abreviação representa um problema de metadados: o campo contém informações pessoais identificáveis (PII), mas seu nome não indica isso claramente para um analisador léxico projetado para convenções de nomenclatura modernas.
PII incorporado em estruturas compostas. Os registros COBOL frequentemente agrupam vários elementos de dados em um único campo ou usam REDEFINES para sobrepor diferentes interpretações aos mesmos bytes. Um campo de registro de cliente. CUST-FULL-DATA definido como PIC X(100) Pode conter nome, endereço e número de telefone concatenados em uma única string com subcampos de posição fixa, uma estrutura que aparece como um único campo de texto opaco para qualquer leitor que leia apenas a definição do campo sem entender a lógica do programa que o preenche e lê.
Informações pessoais identificáveis (PII) em trânsito pelo WORKING-STORAGE. Programas em lote COBOL frequentemente leem PII de arquivos VSAM, processam-nas em variáveis do WORKING-STORAGE e gravam as saídas em conjuntos de dados. As PII existem no WORKING-STORAGE durante a execução, na memória, e não em um armazenamento de dados persistente, desaparecendo quando o programa termina. Uma varredura de descoberta de dados que examina o armazenamento persistente encontra a origem VSAM e o conjunto de dados de saída, mas não o intermediário de processamento onde os dados são reunidos, transformados e potencialmente registrados.
Informações pessoais identificáveis (PII) cruzando a fronteira entre TI e TO por meio de interfaces de arquivos planos. Os dados do cliente extraídos de arquivos VSAM de mainframe frequentemente são transferidos para sistemas subsequentes por meio de interfaces de arquivos planos, extrações CSV, arquivos de registro de comprimento fixo e arquivos de formato posicional, que não contêm metadados de coluna. O arquivo plano contém PII em posições de byte específicas, mas o scanner subsequente que recebe o arquivo não possui um esquema para mapear as posições aos significados dos campos, a menos que a entrada COBOL FD que define o layout do registro também seja analisada.
O desafio do inventário de informações pessoais em um patrimônio dividido.
Uma empresa com sistemas legados em mainframe e plataformas modernas em nuvem enfrenta um desafio de inventário de informações pessoais identificáveis (PII) que abrange duas abordagens de descoberta fundamentalmente diferentes. A camada moderna é acessível a ferramentas padrão. A camada legada exige um método diferente. Os requisitos de conformidade, o direito ao apagamento do GDPR, o padrão mínimo necessário do HIPAA, o escopo de dados do titular do cartão do PCI-DSS e o inventário de dados do consumidor do CCPA aplicam-se igualmente a ambas as camadas. Uma solicitação de acesso do titular dos dados do GDPR exige um inventário de todas as PII mantidas sobre um indivíduo específico em todos os sistemas, não apenas naqueles que se conectam ao catálogo de dados.
O inventário de informações pessoais identificáveis (PII) de propriedade dividida possui três componentes que devem funcionar em conjunto:
O inventário de dados moderno , incluindo bancos de dados em nuvem, plataformas SaaS, data warehouses, logs de API e compartilhamentos de arquivos, pode ser acessado por ferramentas padrão de descoberta de informações pessoais identificáveis (PII). As ferramentas desta categoria buscam padrões de PII, classificam-nas de acordo com as regulamentações e integram-se a plataformas de catálogo de dados para produzir inventários estruturados. O IBM Guardium abrange bancos de dados estruturados e bancos de dados mainframe (DB2) com classificação orientada por políticas. O Microsoft Purview abrange os serviços de nuvem da Microsoft. O BigID e o Varonis abrangem ecossistemas mais amplos, incluindo dados não estruturados.
O inventário de dados legados , arquivos VSAM, esquemas DB2 de mainframe, WORKING-STORAGE de programas COBOL e definições de conjuntos de dados JCL exigem análise de código-fonte para identificar onde as informações pessoais identificáveis (PII) são definidas, armazenadas e processadas. Essa análise lê os programas COBOL para entender quais dados eles manipulam, e não apenas os armazenamentos de dados nos quais gravam.
O inventário do fluxo de dados entre sistemas, ou seja, os caminhos pelos quais as informações pessoais identificáveis (PII) se movem de sistemas legados para plataformas modernas, frequentemente por meio de interfaces de arquivos planos sem esquema, exige o rastreamento da linhagem de dados desde a origem COBOL, passando pelos fluxos de tarefas JCL, até os pontos finais onde os dados chegam aos sistemas conectáveis. O arquivo plano que sai do mainframe diariamente não é marcado com PII até que o esquema que define seu layout de registro seja conectado às definições de coluna do conjunto de dados de destino.
As organizações que produzem inventários completos de informações pessoais identificáveis (PII) são aquelas que abordaram todos os três componentes. As organizações que falham em auditorias de GDPR ou revisões de HIPAA frequentemente abordaram o primeiro componente e presumiram que os outros estavam cobertos.
Padrões de PII específicos do COBOL e como encontrá-los
Padrão 1: Informações Pessoais Identificáveis (PII) diretas em lançamentos contábeis e livros de demonstração.
O padrão de PII mais simples em COBOL: um campo em uma entrada de FD ou membro COPY cujo nome, tipo ou contexto indica claramente PII. Mesmo com convenções de nomenclatura abreviadas, certos padrões estão sempre presentes:
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
A análise estática identifica campos candidatos a PII por meio de uma combinação de correspondência de padrões de nomes (campos contendo NM, NAME, SSN, DOB, ADDR, PHONE, EMAIL, BRTH, ACCT) e análise de tipo (campos PIC X de comprimento apropriado para dados pessoais, campos PIC 9 de comprimento apropriado para números de segurança social ou números de telefone). O resultado é um inventário de campos PII candidatos que requer validação humana para os casos ambíguos.
Padrão 2: PII em estruturas REDEFINES
REDEFINES cria múltiplas interpretações do mesmo armazenamento físico. Um campo definido como armazenamento de dados genérico na definição base pode conter informações pessoais identificáveis (PII) em uma de suas variantes REDEFINES:
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).
O escopo de PII de ACCT-DETAIL Não é possível determinar apenas pela definição do campo base. É necessário analisar a estrutura REDEFINES para determinar qual variante contém informações pessoais identificáveis (PII) e quais programas acessam a variante pessoal em vez da variante comercial. Um scanner que analisa apenas a coluna ACCT_DETAIL No banco de dados de destino, não há como identificar o conteúdo de informações pessoais identificáveis (PII) a partir da definição da coluna; as informações pessoais identificáveis residem na estrutura de origem COBOL.
Padrão 3: PII Montado em ARMAZENAMENTO DE TRABALHO
Programas que reúnem informações pessoais identificáveis (PII) de múltiplas fontes no WORKING-STORAGE antes de gravar em um arquivo de saída podem criar exposição de PII que não aparece em nenhuma definição de arquivo persistente:
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.
Este programa cria um número de Segurança Social (SSN) formatado na área de armazenamento de trabalho (WORKING-STORAGE) e o grava em um arquivo de relatório. As informações pessoais identificáveis (PII) existem em dois locais: o arquivo VSAM de origem (coberto pela classificação de PII do arquivo) e o arquivo de saída do relatório, que pode não ser classificado como contendo PII, a menos que o programa COBOL que o grava seja analisado. WRITE REPORT-RECORD FROM WS-REPORT-LINE A declaração é o evento de linhagem de dados que conecta o número de segurança social do cliente ao arquivo de relatório, visível apenas na DIVISÃO DE PROCEDIMENTOS.
Padrão 4: Informações Pessoais Identificáveis (PII) em Definições de Conjunto de Dados JCL
O JCL define os conjuntos de dados que os programas leem e gravam. Uma instrução DD do JCL que referencia um conjunto de dados contendo informações pessoais identificáveis (PII) faz parte do fluxo de dados PII, mesmo que não contenha dados em si.
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=*O conjunto de dados PROD.CUSTOMER.MASTER.FILE está no inventário de informações pessoais identificáveis (PII) porque o programa COBOL CUSTUPDT lê dele e ele contém registros de clientes. O conjunto de dados BATCH.CUSTOMER.EXTRACT.FILE requer classificação PII porque CUSTUPDT O JCL grava os dados do cliente nele. O JCL é o registro de linhagem de dados que conecta o conjunto de dados de origem ao conjunto de dados de saída por meio do programa, uma conexão visível apenas analisando o JCL juntamente com o programa que o JCL invoca.
Mapeamento regulatório: o que cada estrutura exige e onde os dados legados se encaixam.
Diferentes regulamentações impõem diferentes requisitos ao escopo da descoberta de informações pessoais identificáveis (PII):
O RGPD (Regulamento Geral sobre a Proteção de Dados) (dados pessoais da UE e do EEE) exige que as organizações mantenham Registos de Atividades de Tratamento (RATs) que documentem todo o tratamento de dados pessoais de residentes da UE, onde são armazenados, para que finalidade, com que fundamento jurídico e com que período de retenção. Um RAT em conformidade com o RGPD para uma organização que trata dados de clientes da UE num mainframe exige que os ficheiros VSAM do mainframe, os programas COBOL e os fluxos de trabalho JCL que manipulam esses dados constem no RAT. O direito ao apagamento exige a capacidade de identificar e eliminar todos os dados relativos a um indivíduo específico, o que requer o conhecimento de todos os locais onde os dados desse indivíduo se encontram, incluindo conjuntos de dados do mainframe que estejam em produção há trinta anos.
A HIPAA (Lei de Portabilidade e Responsabilidade de Seguros de Saúde dos EUA) exige que as entidades cobertas e seus parceiros comerciais protejam as Informações de Saúde Protegidas (PHI, na sigla em inglês) onde quer que elas existam. Uma organização que processa informações de saúde em um sistema mainframe COBOL, como registros de pacientes, dados de sinistros e registros de autorização, deve incluir esse sistema em sua avaliação de risco HIPAA e no escopo de notificação de violação de dados. As atualizações da Regra de Segurança da HIPAA de 2025 aumentaram o foco da fiscalização nos controles de segurança de sistemas legados, tornando o inventário de PHI para esses sistemas uma prioridade maior do que em ciclos de fiscalização anteriores.
O PCI-DSS v4.0 (dados do titular do cartão) exige um Ambiente de Dados do Titular do Cartão (CDE) definido, que abranja todos os sistemas que armazenam, processam ou transmitem dados do titular do cartão. Uma organização que processa transações com cartão de pagamento por meio de um programa COBOL executado em um mainframe, que descreve a arquitetura de processamento de transações da maioria dos grandes bancos e varejistas, possui um sistema mainframe em seu CDE. O requisito do PCI-DSS de verificar os sistemas abrangidos em busca de dados do titular do cartão se aplica aos componentes do CDE do mainframe.
A DORA (Lei Europeia de Resiliência Operacional Digital) para serviços financeiros exige uma gestão de riscos de TIC que abranja todos os sistemas envolvidos em funções críticas, com atenção especial aos riscos de terceiros e de sistemas legados. Os sistemas COBOL de mainframe de uma instituição financeira que processam transações e armazenam dados de clientes estão abrangidos pela estrutura de gestão de riscos de TIC da DORA, incluindo a exigência de manter um inventário atualizado de todos os ativos de TIC que suportam funções críticas.
O ponto em comum: os requisitos regulamentares para inventário de informações pessoais identificáveis (PII) não preveem uma exceção para "sistemas legados excluídos". Os dados mais difíceis de encontrar são também os que os reguladores solicitam quando algo dá errado.
Fluxo de trabalho de descoberta, mascaramento e governança
A descoberta de informações pessoais identificáveis (PII) é o primeiro passo em um fluxo de trabalho de conformidade de três etapas:
A ferramenta Discovery identifica onde existem informações pessoais identificáveis (PII) em todos os repositórios de dados, legados e modernos. O resultado é um inventário estruturado: cada repositório de dados, cada conjunto de dados, cada campo classificado como contendo categorias específicas de PII, com as respectivas estruturas regulatórias aplicáveis a cada descoberta.
A mascaramento protege informações pessoais identificáveis (PII) em ambientes de não produção, desenvolvimento, teste e análise, onde os dados completos de produção não são necessários, mas a estrutura e o volume dos dados são. O GDPR exige que as PII sejam protegidas por meio de técnicas como anonimização e pseudonimização em ambientes de não produção. Um programa de descoberta que identifica PII em arquivos VSAM de mainframe permite o mascaramento, substituindo dados reais de clientes por equivalentes sintéticos em ambientes de teste, mas somente se os campos de PII tiverem sido corretamente identificados nas entradas COBOL FD e nos copybooks que definem os layouts de registro.
A governança mantém o inventário de informações pessoais identificáveis (PII) ao longo do tempo, rastreando quando novos sistemas que contêm PII são adicionados, quando dados de PII existentes são migrados ou desativados e quando os requisitos regulatórios alteram o escopo do que deve ser inventariado. Para sistemas legados, a governança exige não apenas a reavaliação periódica dos repositórios de dados, mas também o monitoramento das alterações de código que criam novas exposições de PII, como um programa COBOL modificado para gravar um novo campo em um arquivo de saída, um job JCL modificado para incluir um novo conjunto de dados ou uma alteração de copybook que adiciona um campo de PII a um layout de registro existente.
A pesquisa State of Enterprise Data Compliance de 2026, que constatou que apenas 2% das organizações consideram seus ambientes de IA totalmente compatíveis, aplica-se igualmente a ambientes legados: a conformidade enfraquece na fronteira entre o que as ferramentas padrão abrangem e o que elas não abrangem. Para a maioria das organizações, essa fronteira se estende exatamente ao longo do perímetro do sistema legado.
Como SMART TS XL Suporta a descoberta de informações pessoais identificáveis (PII) em ambientes legados.
SMART TS XLO papel do [nome da ferramenta/serviço] na descoberta de informações pessoais identificáveis (PII) é a camada de análise do código-fonte, a etapa anterior à qual as ferramentas padrão de descoberta de PII podem funcionar em ambientes legados, e a etapa que produz os metadados necessários para que essas ferramentas classifiquem corretamente os armazenamentos de dados legados.
A funcionalidade de análise estática de código analisa cada entrada de FD COBOL, membro COPY, cláusula SELECT e PROCEDURE DIVISION para identificar campos candidatos a PII por meio de análise de padrões de nomes, análise de tipos e análise de contexto. O resultado é um inventário de campos candidatos a PII, contendo todos os campos cujo nome, tipo, comprimento ou contexto de uso sugerem que contêm dados pessoais, organizados por programa, conjunto de dados e campo, com os metadados técnicos COBOL (tipo, comprimento, precisão) que as ferramentas de mascaramento e classificação subsequentes exigem.
O mapeamento de dependências de aplicativos constrói o mapa de fluxo de dados PII: cada programa que lê de um arquivo VSAM contendo PII, cada programa que grava em um conjunto de dados downstream que herda PII da origem, cada etapa de job JCL que cria ou consome conjuntos de dados contendo PII. Esse mapa de linhagem é o inventário de fluxo de dados entre fronteiras, o registro de como o PII se move de sua origem no mainframe através dos programas de transformação e fluxos de jobs JCL que eventualmente o entregam aos sistemas modernos.
A funcionalidade de expansão JCL rastreia o contexto operacional completo de cada conjunto de dados que contém informações pessoais identificáveis (PII): quais jobs JCL o referenciam, em que sequência, com quais códigos de disposição e quais conjuntos de dados subsequentes o job cria a partir dele. Para solicitações de direito ao apagamento de dados, conforme o GDPR, esse mapa operacional identifica todos os locais onde os dados de um cliente específico podem ter sido gravados como consequência do processamento de seu registro de origem, incluindo arquivos de trabalho intermediários, conjuntos de dados de classificação e arquivos de relatório criados durante o processamento em lote.
A funcionalidade de busca corporativa torna o inventário de informações pessoais identificáveis (PII) consultável, auxiliando em solicitações de acesso de titulares de dados e auditorias regulatórias: encontre todos os programas que acessam um campo específico, todos os conjuntos de dados que contêm registros com um valor de chave específico, todos os jobs JCL que processam um conjunto de dados específico. Essa funcionalidade de busca transforma um inventário de PII de um documento estático em uma interface de consulta em tempo real, a ferramenta que responde à pergunta “onde estão os dados desta pessoa?” em horas, em vez de semanas.
Para organizações que realizam modernização legada programas, SMART TS XLA análise de descoberta de PII (Informações Pessoais Identificáveis) é um pré-requisito de conformidade: o escopo de conformidade com PCI-DSS, HIPAA e GDPR se estende a dados sensíveis assim que eles saem de seu ambiente original. As PII que acompanham os dados migrados devem ser inventariadas antes da migração, protegidas durante a migração e verificadas novamente após a migração. Você não está apenas migrando código. Você está migrando riscos.
O perímetro de conformidade inclui tudo o que contém dados pessoais.
Os marcos regulatórios que regem a proteção de dados pessoais, GDPR, HIPAA, PCI-DSS, CCPA e DORA, foram elaborados com escopo universal. Eles se aplicam a dados pessoais onde quer que estejam, independentemente da idade do sistema que os armazena, independentemente de esse sistema possuir um conector moderno e independentemente de o catálogo de dados da organização ter visibilidade sobre eles.
A lacuna na descoberta de informações pessoais identificáveis (PII) em ambientes legados não é uma limitação técnica que os reguladores aceitam como desculpa. Trata-se de uma lacuna de conformidade que as ações de fiscalização consideram como uma falha na implementação de salvaguardas adequadas, o mesmo padrão aplicado a sistemas modernos, porém aplicado a sistemas que exigem métodos de descoberta diferentes para uma auditoria correta.
Preencher essa lacuna exige reconhecer que a camada mainframe do ambiente de dados corporativos contém quantidades significativas de informações pessoais identificáveis (PII), que as ferramentas de descoberta padrão não conseguem acessá-la por meio de seus métodos de conexão padrão e que a análise do código-fonte dos programas COBOL e dos fluxos de trabalho JCL que gerenciam esses dados é a abordagem que produz um inventário completo. A descoberta completa em ambas as camadas, legada e moderna, não é uma aspiração técnica. É a base de comparação com a qual os programas de conformidade são avaliados.
