Lacunas na notificação de violação de dados

Uma instituição financeira do Reino Unido recebeu a notificação de um fornecedor de processamento de pagamentos onze dias depois de o fornecedor ter identificado um incidente de segurança que afetava dados de pagamento de clientes. A notificação confirmava que o fornecedor havia tomado ciência do incidente na terça-feira, conduzido uma investigação interna durante o fim de semana e confirmado o escopo da violação na sexta-feira. A notificação ao cliente foi enviada na quarta-feira seguinte. Nos termos do GDPR do Reino Unido, a instituição financeira era obrigada a notificar o ICO em até 72 horas após tomar ciência de uma violação de dados pessoais. O prazo de 72 horas da instituição financeira havia começado a correr a partir do momento em que o fornecedor tomou ciência, especificamente a partir do momento em que o fornecedor deveria saber que a violação afetava dados pessoais tratados em nome da instituição. O intervalo de onze dias entre a descoberta da violação pelo fornecedor e a notificação ao cliente significou que a instituição financeira tinha uma obrigação de 72 horas que já corria havia onze dias antes que ela soubesse que a tinha. A investigação do ICO apontou tanto o atraso na notificação do fornecedor quanto a falha da instituição na notificação regulatória como fatores contribuintes. A instituição recebeu uma constatação que citava requisitos contratuais de notificação inadequados com seu operador.

Qual é, de fato, o problema das lacunas na notificação de violação de dados?

A governança da notificação de violação de dados nas relações com fornecedores é o conjunto de mecanismos contratuais e operacionais que garantem que o fornecedor comunique ao cliente os incidentes de segurança que afetam dados do cliente em um prazo que permita ao cliente cumprir suas próprias obrigações de notificação regulatória. A lacuna surge do descompasso entre as obrigações regulatórias de notificação aplicáveis ao cliente, que são acionadas pela ciência da violação pelo cliente e medidas em horas, e os processos operacionais do fornecedor para investigar, confirmar e comunicar violações, que são medidos em dias ou semanas.

O problema do relógio regulatório é a dimensão de consequências mais imediatas. Nos termos do GDPR, a obrigação do controlador de notificar a autoridade de controle em 72 horas começa quando o controlador toma ciência da violação, e não quando conclui sua investigação ou tem certeza de seu escopo. A orientação do EDPB deixa claro que um controlador que recebe de um operador a notificação de que ocorreu uma violação tomou ciência da violação para fins regulatórios, mesmo que o escopo ainda não esteja determinado. O atraso do fornecedor em notificar o cliente atrasa a ciência do cliente, mas o relógio regulatório, como o ICO constatou no caso da instituição financeira, pode ter começado a correr em um momento anterior, com base no que o cliente deveria razoavelmente saber por meio de suas obrigações de supervisão.

O problema da especificidade contratual é onde a maioria das cláusulas de notificação falha. Uma cláusula que exige que o fornecedor notifique o cliente sobre incidentes de segurança sem especificar o prazo de notificação, o limiar de ciência que a aciona, o conteúdo exigido da notificação e o caminho de escalonamento para incidentes sob investigação ativa dá ao fornecedor discricionariedade para interpretar a obrigação de modo a atender à sua conveniência operacional, e não às necessidades regulatórias do cliente. Um fornecedor que interpreta “notificar prontamente” como “notificar depois de concluirmos nossa investigação” cumpriu uma cláusula que nunca foi específica o suficiente para impedir o comportamento que pretendia evitar.

As lacunas na notificação de violações se concentram em cinco padrões específicos de falha:

Nenhum prazo de notificação especificado: contratos que exigem notificação sem um tempo máximo definido entre a descoberta da violação e a notificação ao cliente, deixando o prazo a critério do fornecedor
Ambiguidade do limiar de ciência: contratos que não especificam que nível de ciência do fornecedor aciona a obrigação de notificação (suspeita, confirmação ou determinação do escopo)
Atraso da investigação antes da notificação: fornecedores que concluem investigações internas completas antes de notificar os clientes, maximizando a distância entre a ciência deles e a ciência do cliente
Conteúdo de notificação insuficiente: notificações iniciais que reconhecem um incidente sem as informações necessárias para que o cliente avalie suas obrigações de notificação regulatória (natureza dos dados, número aproximado de registros, consequências prováveis)
Subestimação do escopo do incidente: notificações iniciais que descrevem um escopo de violação mais restrito do que o confirmado ao final, exigindo notificações atualizadas que ampliam o prazo e complicam os registros regulatórios

Por que isso importa

As lacunas na notificação de violações são importantes para TPRM porque as obrigações regulatórias do cliente não ficam suspensas enquanto o fornecedor investiga. A obrigação de 72 horas de um controlador sujeito ao GDPR começa na ciência. A obrigação de notificação de violações de uma entidade coberta pela HIPAA tem prazos definidos que começam na descoberta. As obrigações de comunicação de incidentes de uma organização em conformidade com o PCI-DSS começam na confirmação. Todas essas obrigações são do cliente, acionadas por sua própria ciência e exigíveis dele pelos reguladores, e todas dependem de o fornecedor notificar o cliente com rapidez suficiente para que possam ser cumpridas.

As consequências reputacionais e comerciais ampliam o risco regulatório. Quando uma violação se torna pública antes que o cliente tenha notificado os titulares afetados (porque o fornecedor atrasou a notificação, o prazo regulatório do cliente expirou e o regulador ou a imprensa divulgou o incidente antes que o cliente pudesse fazê-lo), o cliente sofre uma consequência reputacional proporcional à negligência percebida em seu processo de notificação. Os clientes do cliente, cujos dados foram violados, ficam sabendo pela imprensa, e não pela organização que detinha seus dados. Essa sequência de eventos é muito mais danosa do que teria sido uma notificação tempestiva e proativa, e foi causada pelo atraso de notificação do fornecedor, não pela resposta do cliente a ele.

Para profissionais de TPRM, a obrigação de governança da notificação é específica e exigível contratualmente: especificar o tempo máximo entre a descoberta da violação pelo fornecedor e a notificação ao cliente, o limiar de ciência que aciona a notificação, o conteúdo mínimo das notificações iniciais e a periodicidade de atualização à medida que o escopo do incidente evolui. Uma cláusula de notificação com essas especificações dá ao cliente um recurso contratual efetivo se o fornecedor atrasar. Uma cláusula de notificação sem elas dá ao cliente um documento que diz que o fornecedor notificará, sem dizer nada sobre quando.

Onde a maioria das equipes erra

A falha mais recorrente é tratar uma cláusula de notificação como um controle de notificação. Uma cláusula contratual que exige que o fornecedor notifique o cliente sobre incidentes de segurança é um instrumento de governança: cria uma obrigação legal. Se essa obrigação é cumprida com a tempestividade e a qualidade de conteúdo necessárias para que o cliente cumpra suas obrigações regulatórias depende da especificidade da cláusula. Requisitos genéricos de notificação que estabelecem a obrigação sem prazo, limiar e conteúdo são instrumentos de governança que não podem ser operacionalizados como controles, porque deixam margem demais à interpretação do fornecedor.

A segunda falha é não incluir requisitos de prazo de notificação no processo de avaliação de fornecedores, ou seja, não confirmar que o programa de resposta a incidentes do fornecedor inclui prazos definidos para a notificação ao cliente como uma etapa distinta do processo, separada do prazo da investigação. Um fornecedor cujo manual de resposta a incidentes define a notificação ao cliente como uma etapa que ocorre após a conclusão da investigação tem uma arquitetura de resposta que deixará de cumprir, de forma sistemática, todo requisito regulatório de notificação rápida.

Tratar a existência de uma cláusula de notificação como controle de notificação: uma obrigação sem prazo não é um controle
Nenhum prazo de notificação especificado no contrato: o momento da notificação fica a critério do fornecedor
Limiar de ciência não definido: suspeita, confirmação ou conclusão do escopo como ponto de acionamento
Conteúdo da notificação não especificado: notificação inicial sem requisitos mínimos de informação
Processo de resposta a incidentes do fornecedor não avaliado: se a notificação ao cliente ocorre em paralelo à investigação ou depois dela

Como é uma boa prática

Uma governança madura da notificação de violações especifica no contrato o prazo de notificação, o limiar de ciência, os requisitos mínimos de conteúdo e a periodicidade de atualização, criando um padrão exigível na prática, e não uma obrigação genérica. E o programa de resposta a incidentes do fornecedor reflete esses requisitos como etapas definidas do processo, e não como orientações aspiracionais.

Prazo de notificação especificado: número máximo de horas entre a descoberta pelo fornecedor e a notificação ao cliente, normalmente 24-48 horas, independentemente da conclusão do escopo
Limiar de ciência definido: notificação acionada por suspeita razoável de que dados pessoais possam ter sido afetados, e não pela determinação confirmada do escopo
Conteúdo mínimo da notificação inicial: natureza do incidente, categorias de dados potencialmente afetadas, número estimado de registros, medidas imediatas adotadas e contato designado para acompanhamento
Periodicidade de atualização para incidentes em evolução: exigência de fornecer atualizações em intervalos definidos durante a investigação em andamento
Revisão da resposta a incidentes do fornecedor: confirmação de que o manual de resposta a incidentes do fornecedor inclui a notificação ao cliente como uma etapa que ocorre dentro do prazo contratual

Ferramentas

A governança da notificação de violações exige tanto mecanismos contratuais quanto ferramentas operacionais que garantam que as obrigações de notificação sejam acompanhadas e cumpridas.

Plataformas de resposta a incidentes: PagerDuty, ServiceNow IR, Jira

As plataformas de resposta a incidentes com fluxos de notificação às partes interessadas garantem que a notificação ao cliente seja uma etapa acompanhada e com prazo definido no processo de resposta a incidentes do fornecedor, e não uma ação discricionária. Para profissionais de TPRM, perguntar se o fornecedor utiliza uma plataforma de resposta a incidentes com fluxo de notificação ao cliente e acompanhamento de SLA revela se a notificação está operacionalizada como um processo com responsabilização ou é tratada como uma atividade de comunicação com prazo flexível.

Gestão de contratos: Ironclad, Icertis

As plataformas de CLM permitem padronizar a redação das cláusulas de notificação em todos os contratos com fornecedores, garantindo que todo DPA inclua um prazo de notificação especificado, um limiar de ciência e um requisito de conteúdo, em vez de uma obrigação genérica de notificação. Para programas de TPRM que gerenciam grandes carteiras de fornecedores, a padronização do CLM impede que lacunas nas cláusulas de notificação persistam em contratos redigidos antes do estabelecimento de requisitos específicos de prazo.

Inteligência de risco de fornecedores: ProcessUnity, OneTrust, BitSight

As plataformas de TPRM com monitoramento de violações em fornecedores oferecem ciência antecipada de incidentes nas organizações fornecedoras por meio de fontes externas de inteligência, alertando os clientes sobre divulgações públicas de violações ou descobertas de pesquisadores de segurança antes que o fornecedor conclua seu processo interno. Para profissionais de TPRM, contar com inteligência externa sobre violações que possa desencadear uma consulta proativa ao fornecedor, sem esperar pela notificação, reduz a lacuna de ciência na cadeia de notificação.

Desafios de governança

O desafio de governança da notificação de violações é a tensão entre investigação e notificação. Os fornecedores, com razão, querem notificar os clientes com informações precisas e completas, em vez de notificações preliminares que exigem várias atualizações à medida que o escopo evolui. Os clientes, com razão, querem a notificação mais rápida possível para viabilizar sua própria conformidade regulatória. Esses objetivos não são totalmente compatíveis: a preferência do fornecedor pela precisão conflita com a necessidade de tempestividade do cliente. A solução contratual é especificar que a notificação inicial deve ocorrer dentro de um prazo definido, independentemente de a determinação do escopo estar concluída, com atualizações subsequentes à medida que a investigação avança.

Para programas de TPRM, a abordagem prática de governança é tratar a especificidade da cláusula de notificação de violações como um item padrão da lista de verificação da revisão de contratos, confirmando que todo DPA inclua prazo, limiar, requisito de conteúdo e periodicidade de atualização antes da assinatura do contrato. Uma cláusula aprovada nessa lista de verificação cria um padrão exigível. Uma cláusula reprovada cria uma obrigação genérica que será interpretada contra os interesses do cliente quando ocorrer uma violação.

Incluir a especificidade da cláusula de notificação na lista de verificação da revisão de contratos: prazo, limiar, conteúdo e periodicidade de atualização exigidos antes da assinatura
Revisar os contratos vigentes com fornecedores em busca de lacunas nas cláusulas de notificação: obrigações genéricas que precisam ser reforçadas na próxima renovação
Avaliar o processo de resposta a incidentes do fornecedor: confirmar que a notificação ao cliente ocorre dentro do prazo contratual como uma etapa definida do processo
Implementar o monitoramento de violações em fornecedores: fontes externas de inteligência que proporcionam ciência antecipada, independentemente da notificação do fornecedor
Testar o processo de notificação do fornecedor: exercícios de mesa que incluam cenários de notificação por fornecedores para validar o processo antes de um incidente real

Se você faz parte de uma equipe pequena

Revise os contratos dos seus três fornecedores de maior risco quanto à especificidade da cláusula de notificação. Para cada um, pergunte: a cláusula especifica um prazo máximo entre a descoberta pelo fornecedor e a notificação ao cliente? Especifica que nível de ciência do fornecedor aciona a obrigação? Especifica um conteúdo mínimo para a notificação inicial? Se qualquer um desses três elementos estiver ausente, a cláusula é uma obrigação genérica, e não um controle exigível. Acrescente os elementos ausentes na próxima renovação do contrato. Nas relações em andamento, pergunte diretamente ao fornecedor o que seu processo interno de resposta a incidentes especifica quanto ao momento da notificação ao cliente: a resposta mostra se a obrigação contratual é respaldada por um processo operacional.

Revisar as cláusulas de notificação quanto à especificidade de prazo, limiar e conteúdo
Acrescentar os elementos ausentes da cláusula na próxima renovação do contrato
Perguntar aos fornecedores o que seu processo de resposta a incidentes especifica quanto ao momento da notificação ao cliente
Implementar o monitoramento de violações em fornecedores para obter ciência externa, independentemente da notificação do fornecedor

O que exigir

Pergunte diretamente:

“O que o seu processo de resposta a incidentes especifica como tempo máximo entre a descoberta de um incidente de segurança que afete dados de clientes e a notificação ao cliente? Essa notificação é acionada pela suspeita de exposição ou pela determinação confirmada do escopo?”

“Que informações mínimas sua notificação inicial de violação aos clientes inclui? Especificamente, vocês podem fornecer um modelo da sua notificação inicial padrão e confirmar que ele inclui as categorias de dados afetadas, a estimativa do volume de registros e as medidas imediatas de resposta?”

“Se a investigação de resposta a incidentes ainda estiver em andamento quando chegar o prazo contratual de notificação, o processo de vocês prevê uma notificação preliminar aos clientes antes da conclusão da investigação ou o prazo começa a contar a partir da conclusão da investigação?”

O que esperar como evidência

Documentação do processo de resposta a incidentes que mostre a notificação ao cliente como uma etapa definida e com prazo
Especificação do prazo de notificação: número máximo de horas entre a descoberta e a notificação
Modelo de notificação inicial com confirmação do conteúdo mínimo
Política de notificação preliminar para investigações em andamento

Um fornecedor que responde à pergunta sobre o prazo de notificação com “notificamos os clientes prontamente após confirmar a violação” descreveu um processo de notificação que começa após a conclusão da investigação. Pergunte especificamente o que “prontamente após confirmar” significa em horas e se a notificação pode ocorrer antes da conclusão da investigação quando o prazo regulatório o exigir. O acionamento pela conclusão da investigação é a preferência operacional do fornecedor. O acionamento pela conformidade regulatória é a obrigação legal do cliente.

Como comprovar

Os requisitos de notificação do artigo 33 do GDPR e do 34, a regra de notificação de violações do HIPAA e as regulamentações setoriais de notificação criam obrigações medidas em horas e dias a partir da ciência. Demonstrar a devida diligência exige evidências de que a especificidade da cláusula de notificação foi avaliada e de que se confirmou que os processos do fornecedor são capazes de cumprir os prazos exigidos.

Registros da revisão das cláusulas contratuais de notificação que confirmam prazo, limiar, conteúdo e periodicidade de atualização
Documentação do processo de resposta a incidentes do fornecedor que confirma o momento da notificação
Registros da implementação do monitoramento externo de violações
Registros de testes de prazo de notificação em exercícios de mesa que incluem cenários com fornecedores

Principal conclusão

O relógio de 72 horas do fornecedor também é o seu relógio de 72 horas. Quando o fornecedor toma ciência de uma violação que afeta dados dos seus clientes, sua obrigação regulatória começa, não no momento em que ele escolhe notificar você, mas no momento em que você deveria saber. Uma cláusula de notificação que exige a notificação sem especificar quando cria uma janela de discricionariedade do fornecedor que o seu prazo regulatório não comporta. A instituição financeira que recebeu uma notificação com onze dias de atraso tinha uma cláusula de notificação. Ela não tinha prazo. O ICO concluiu que requisitos contratuais de notificação inadequados com o operador foram um fator contribuinte. A cláusula dizia notificar. Não dizia quando. O quando é o controle.