LGPD no departamento de TI: logs, acessos, backups e os riscos invisíveis da infraestrutura

Introdução

Quando se fala em adequação à Lei Geral de Proteção de Dados Pessoais (LGPD), ainda é comum que a responsabilidade pelo tema seja associada principalmente ao Jurídico, ao Compliance, à área de Privacidade ou ao Encarregado pelo Tratamento de Dados Pessoais. No entanto, grande parte das medidas necessárias para garantir a proteção efetiva dos dados depende diretamente da Tecnologia da Informação.

Isso ocorre porque a TI ocupa uma posição central na infraestrutura que sustenta o tratamento de dados pessoais dentro das organizações. Sistemas corporativos, bancos de dados, credenciais de acesso, registros de atividades, backups, servidores, dispositivos, integrações, ferramentas de comunicação e ambientes em nuvem são apenas alguns dos recursos que podem estar sob sua administração ou supervisão técnica.

Na prática, isso significa que a área possui condições técnicas para viabilizar o acesso, armazenamento, cópia, transmissão, recuperação, alteração e exclusão de grandes volumes de informações. Dados de clientes, colaboradores, candidatos, fornecedores e outros titulares podem circular diariamente por ambientes administrados pela TI, ainda que a coleta original ou a definição da finalidade do tratamento tenha ocorrido em outra área da organização.

Essa posição, entretanto, não deve ser confundida com uma autorização irrestrita sobre as informações disponíveis nos sistemas. Estar tecnicamente autorizado a acessar um dado não significa estar autorizado a utilizá-lo para qualquer finalidade. A existência de uma permissão administrativa, de uma credencial privilegiada ou mesmo da possibilidade técnica de consultar determinada base não afasta a necessidade de observar critérios de finalidade, necessidade, segurança, prevenção e responsabilização previstos pela LGPD.

É justamente nesse ponto que segurança da informação e proteção de dados se encontram. A TI desempenha papel essencial na implementação dos controles técnicos necessários à proteção das informações, mas sua participação na conformidade com a LGPD vai além de impedir ataques externos ou manter sistemas disponíveis. Também envolve compreender quais dados estão sob sua gestão, onde estão armazenados, quem pode acessá-los, quais cópias existem, por quanto tempo devem permanecer disponíveis e como serão protegidos durante todo o seu ciclo de vida.

Ao longo deste artigo, analisaremos alguns dos principais pontos de atenção da LGPD aplicados à rotina da Tecnologia da Informação, passando pela gestão de acessos e privilégios, registros de logs, monitoramento de redes, backups, desligamento de colaboradores, ambientes de desenvolvimento e homologação, serviços em nuvem e contratação de fornecedores de tecnologia.

Qual é o papel da TI na LGPD?

Antes de analisar logs, backups, credenciais, ambientes em nuvem ou outros controles específicos, é necessário esclarecer uma questão conceitual que ainda costuma gerar confusão dentro das organizações: a área interna de Tecnologia da Informação não se torna automaticamente uma operadora de dados pessoais simplesmente porque possui acesso técnico às informações ou executa atividades que envolvem seu tratamento.

A LGPD define como agentes de tratamento o controlador e o operador. Enquanto o controlador é responsável pelas decisões referentes ao tratamento de dados pessoais, o operador realiza o tratamento em nome do controlador e de acordo com suas instruções. Essa definição deve considerar as atividades efetivamente desempenhadas em cada operação, e não apenas a nomenclatura atribuída às partes em contratos, políticas internas ou estruturas organizacionais.

Essa distinção é especialmente importante quando analisamos os departamentos internos de uma empresa. Conforme orientação da Autoridade Nacional de Proteção de Dados (ANPD), funcionários, equipes de trabalho e demais unidades que integram uma mesma organização não são considerados, em regra, agentes de tratamento distintos quando atuam sob o poder diretivo da própria instituição. É a organização que assume a posição de agente de tratamento, enquanto suas áreas internas executam atividades em seu nome.

Assim, quando a equipe de TI cria uma conta de usuário, configura permissões, administra um banco de dados, restaura um backup, disponibiliza uma infraestrutura ou presta suporte técnico a um sistema que contém informações pessoais, normalmente está desempenhando atribuições dentro da estrutura da própria organização. O fato de essas atividades envolverem acesso ou manipulação de dados pessoais não transforma a área, isoladamente, em operadora.

Isso não significa, contudo, que sua responsabilidade na proteção dos dados seja reduzida. Pelo contrário. A LGPD exige a adoção de medidas técnicas e administrativas capazes de proteger os dados pessoais contra acessos não autorizados e situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou tratamento inadequado. Grande parte da implementação prática dessas medidas passa diretamente pelas equipes de TI e de Segurança da Informação.

É nesse contexto que surge uma diferença fundamental entre responsabilidade técnica e posição jurídica no tratamento de dados. A TI pode ser responsável por implementar autenticação multifator, criptografia, segregação de ambientes, controles de acesso, políticas de backup, mecanismos de rastreabilidade e outras salvaguardas sem, por isso, constituir um agente de tratamento separado da organização.

Da mesma forma, possuir privilégios técnicos elevados não representa uma autorização irrestrita para utilizar as informações disponíveis. Administradores de sistemas, profissionais de infraestrutura, DBAs, desenvolvedores e equipes de suporte podem possuir credenciais capazes de permitir o acesso a bancos de dados, arquivos, caixas de e-mail, registros de atividades ou outras informações que não fazem parte de suas atribuições cotidianas. Ainda assim, os princípios da finalidade, adequação e necessidade previstos na LGPD permanecem aplicáveis. Ter capacidade técnica para acessar determinado dado não significa possuir autorização para consultá-lo ou utilizá-lo para qualquer finalidade.

Por isso, a gestão da TI sob a perspectiva da proteção de dados não deve se limitar a perguntar quem consegue acessar determinada informação. É necessário compreender por que esse acesso é necessário, em quais circunstâncias ele pode ocorrer, quais privilégios são realmente indispensáveis e como a organização poderá identificar posteriormente as ações realizadas. Um administrador pode precisar possuir condições técnicas para acessar grande parte de um ambiente para exercer suas funções, mas isso não significa que precise consultar todo o conteúdo existente nele.

Também é por essa razão que a conformidade com a LGPD exige uma atuação coordenada entre TI, Segurança da Informação, Privacidade, Encarregado e áreas de negócio. Cada uma dessas áreas possui informações e responsabilidades diferentes dentro do ciclo de vida dos dados. As áreas de negócio conhecem as finalidades das operações e as necessidades relacionadas à utilização das informações; Privacidade e Jurídico avaliam os requisitos legais e de governança; o Encarregado exerce suas atribuições de orientação e interlocução; Segurança da Informação avalia riscos, ameaças e medidas de proteção; e a TI transforma muitas dessas definições em configurações, permissões, arquiteturas e controles efetivamente aplicados aos ambientes tecnológicos.

Quando essa integração não existe, podem surgir situações em que a organização possui bons controles técnicos de segurança, mas mantém dados por períodos superiores ao necessário, concede acessos incompatíveis com as funções desempenhadas, conserva contas que deveriam ter sido desativadas ou mantém informações pessoais espalhadas por sistemas, cópias e ambientes que sequer são conhecidos pelas áreas responsáveis pela governança de dados. Da mesma forma, decisões tomadas exclusivamente sob uma perspectiva jurídica podem se tornar inexequíveis quando não consideram as características técnicas da infraestrutura.

A lógica passa a ser diferente quando a organização contrata terceiros para executar atividades tecnológicas. Provedores de cloud, empresas de hospedagem, plataformas SaaS, desenvolvedores, empresas de suporte e fornecedores de infraestrutura podem armazenar, transmitir ou acessar dados pessoais durante a prestação de seus serviços. Nesses casos, é necessário avaliar concretamente qual papel o fornecedor desempenha em relação a cada operação de tratamento.

Quando o terceiro realiza o tratamento de dados pessoais em nome da organização e seguindo suas instruções, poderá assumir a posição de operador. Isso, entretanto, não permite concluir que todo fornecedor de tecnologia seja automaticamente um operador. A definição depende da realidade da operação. Um fornecedor pode atuar como operador em determinada atividade e assumir maior autonomia decisória em outra, circunstância que pode alterar sua qualificação perante a LGPD.

A análise se torna ainda mais relevante em cadeias tecnológicas complexas, nas quais o fornecedor contratado utiliza outros prestadores para armazenamento, processamento, infraestrutura ou suporte. Nesses cenários, também é necessário compreender a participação de suboperadores, os fluxos de dados existentes e as responsabilidades assumidas por cada parte.

Por esse motivo, a contratação de serviços de software, cloud ou infraestrutura não deveria ser analisada exclusivamente sob critérios como funcionalidade, preço, disponibilidade ou nível de serviço. A avaliação também deve considerar quais dados pessoais serão tratados, para quais finalidades, onde serão armazenados, quais terceiros poderão ter acesso, quais medidas de segurança serão adotadas, como serão tratados eventuais incidentes e o que acontecerá com as informações ao término da relação contratual.

Compreender o papel da TI na LGPD exige, portanto, abandonar duas simplificações recorrentes: a primeira é considerar que proteção de dados é responsabilidade exclusiva do Jurídico, de Privacidade ou do DPO; a segunda é presumir que qualquer pessoa ou empresa que possua acesso técnico a dados pessoais seja automaticamente uma operadora. Dentro da organização, a TI exerce papel essencial na materialização dos controles de proteção de dados. Fora dela, fornecedores tecnológicos precisam ter sua atuação avaliada conforme as atividades, instruções e decisões efetivamente envolvidas em cada operação de tratamento.

Logs: necessários para segurança, mas também são dados pessoais

Os logs estão entre os recursos mais importantes para a segurança e a rastreabilidade dos ambientes tecnológicos. São eles que permitem reconstruir eventos, identificar tentativas de acesso indevido, verificar alterações realizadas em sistemas, detectar comportamentos anômalos e compreender o que aconteceu antes, durante e depois de um incidente. Em uma investigação, a ausência desses registros pode significar a diferença entre conseguir identificar a origem de um problema e simplesmente não possuir evidências suficientes para compreender o ocorrido.

Sob a perspectiva da LGPD, entretanto, existe um aspecto que nem sempre recebe a mesma atenção: os próprios logs podem conter dados pessoais.

A Lei define dado pessoal de maneira ampla, como toda informação relacionada a uma pessoa natural identificada ou identificável. Por essa razão, registros contendo nome ou identificação do usuário, endereço IP, data e horário de acesso, dispositivo utilizado, localização, histórico de autenticação ou ações realizadas em determinado sistema podem permitir a identificação direta ou indireta de uma pessoa e, consequentemente, estar sujeitos às regras de proteção de dados pessoais.

Isso significa que registrar atividades para fins de segurança não afasta a necessidade de governança sobre as informações geradas. Pelo contrário: quanto mais detalhado for o registro, maior pode ser sua utilidade para fins de auditoria e investigação, mas também maior pode ser a quantidade de informações acumuladas sobre a atividade de usuários, colaboradores e outros titulares.

O primeiro desafio está justamente em definir o que precisa ser registrado. Nem todo sistema demanda o mesmo nível de detalhamento. Em ambientes mais críticos, pode ser necessário registrar autenticações bem-sucedidas e malsucedidas, alterações de privilégios, acessos administrativos, criação e exclusão de usuários, modificações relevantes em bases de dados, operações realizadas por contas privilegiadas e outros eventos capazes de auxiliar na identificação de incidentes ou usos indevidos. A escolha deve estar relacionada aos riscos do ambiente e à finalidade de segurança pretendida, evitando tanto a ausência de informações essenciais quanto a coleta indiscriminada de dados sem necessidade definida.

A própria ANPD conceitua o controle de acesso como uma medida técnica destinada a garantir que os dados sejam acessados apenas por pessoas autorizadas, envolvendo processos de autenticação, autorização e auditoria. Nesse contexto, os logs assumem uma função relevante não apenas para registrar que determinado usuário entrou em um sistema, mas para permitir que a organização tenha condições de verificar posteriormente eventos relacionados aos seus acessos.

Essa rastreabilidade ganha especial importância diante do dever previsto no art. 46 da LGPD, segundo o qual os agentes de tratamento devem adotar medidas técnicas e administrativas aptas a proteger os dados pessoais contra acessos não autorizados e situações acidentais ou ilícitas de destruição, perda, alteração, comunicação ou qualquer forma de tratamento inadequado ou ilícito. Os registros de atividades podem contribuir para essa estrutura de segurança ao auxiliar na identificação de acessos indevidos, investigação de incidentes e realização de auditorias.

Contudo, de pouco adianta manter registros detalhados se eles próprios puderem ser livremente acessados ou modificados. A proteção dos logs deve fazer parte da estratégia de segurança da organização. Isso envolve restringir sua consulta às pessoas que efetivamente necessitam dessas informações, estabelecer níveis adequados de permissão e adotar mecanismos capazes de preservar sua integridade e confiabilidade.

Esse cuidado é particularmente relevante porque um log alterável pelo próprio usuário cuja atividade está sendo registrada perde parte significativa de sua utilidade como evidência. Da mesma forma, registros armazenados sem controles adequados podem revelar informações valiosas sobre a estrutura tecnológica da organização, usuários existentes, horários de acesso, endereços IP, sistemas utilizados e outras características que podem ser exploradas em caso de comprometimento do ambiente.

Outro ponto que merece atenção é o tempo de retenção. Manter todos os registros indefinidamente pode parecer uma estratégia conservadora de segurança, mas não necessariamente representa uma boa prática de proteção de dados. A LGPD estabelece, entre seus princípios, a necessidade de limitar o tratamento ao mínimo necessário para a realização de suas finalidades e prevê o término do tratamento quando a finalidade for alcançada ou quando os dados deixarem de ser necessários ou pertinentes, ressalvadas as hipóteses legais de conservação.

Não existe, portanto, um único prazo de retenção aplicável indistintamente a todos os logs. A definição deve considerar a finalidade do registro, os riscos envolvidos, as necessidades de auditoria e investigação, obrigações legais ou regulatórias específicas e as características do ambiente tecnológico. Em determinados contextos, inclusive, outras legislações podem estabelecer períodos próprios de guarda, razão pela qual a retenção não deve ser definida apenas por uma configuração padrão da ferramenta utilizada.

A organização também precisa saber quando um registro deixa de cumprir uma função legítima de segurança e passa a representar apenas um acúmulo desnecessário de informações.

Essa preocupação se torna ainda mais relevante quando os logs são utilizados para acompanhar atividades de colaboradores. Ferramentas corporativas podem registrar horários de acesso, sites consultados, dispositivos utilizados, arquivos movimentados, comandos executados e uma série de outras ações. Embora parte desse monitoramento possa ser necessária para proteger sistemas, prevenir fraudes ou investigar incidentes, a existência da capacidade tecnológica de registrar uma atividade não significa que toda informação disponível deva ser coletada.

A fronteira entre logging para segurança e monitoramento excessivo precisa ser observada. Os princípios da finalidade, adequação, necessidade e transparência exigem que a organização saiba explicar por que determinado registro é produzido e de que forma ele será utilizado. Utilizar posteriormente essas informações para objetivos incompatíveis com aqueles que justificaram sua coleta pode criar novos riscos de proteção de dados.

Por isso, uma estratégia adequada de logging não deve responder apenas à pergunta “o que conseguimos registrar?”. Ela deve definir quais eventos realmente precisam ser registrados, para quais finalidades, quem poderá consultar essas informações, como sua integridade será preservada, por quanto tempo permanecerão armazenadas e quais procedimentos serão adotados para sua eliminação ou anonimização quando deixarem de ser necessários.

Os logs, portanto, ocupam uma posição peculiar dentro da governança de TI: ao mesmo tempo em que são instrumentos fundamentais para proteger dados pessoais, podem ser eles próprios conjuntos relevantes de dados pessoais que precisam ser protegidos. Registrar pouco pode comprometer a capacidade de detectar e investigar incidentes; registrar indiscriminadamente pode gerar um novo risco de privacidade.

Monitoramento de redes e dispositivos corporativos: até onde a TI pode ir?

O monitoramento de redes, sistemas e dispositivos corporativos integra a estrutura de segurança da informação de muitas organizações. A partir dele, as equipes de Tecnologia da Informação e Segurança da Informação conseguem identificar tentativas de acesso indevido, conexões suspeitas, movimentações anormais de arquivos, instalação de softwares não autorizados, utilização de dispositivos externos e outros eventos que possam indicar ameaças ao ambiente tecnológico.

Essa capacidade de monitoramento tem relação direta com a proteção de dados pessoais. O art. 46 da LGPD determina que os agentes de tratamento adotem medidas técnicas e administrativas aptas a proteger os dados contra acessos não autorizados e situações acidentais ou ilícitas. Nesse contexto, possuir mecanismos capazes de prevenir, detectar e investigar eventos de segurança pode constituir parte importante das medidas adotadas pela organização.

Na prática, diferentes tecnologias podem ser utilizadas para essa finalidade. Soluções de Endpoint Detection and Response (EDR) permitem identificar comportamentos potencialmente maliciosos em computadores e outros dispositivos; ferramentas de Data Loss Prevention (DLP) auxiliam na identificação e prevenção da saída indevida de informações; sistemas de gerenciamento de dispositivos podem controlar configurações, aplicações e atualizações de segurança; enquanto soluções de monitoramento de redes podem detectar conexões, tráfego e comportamentos potencialmente anômalos.

O funcionamento dessas ferramentas, entretanto, pode envolver o tratamento de uma quantidade significativa de dados relacionados aos usuários. Dependendo da solução e de sua configuração, podem ser registrados horários de utilização, identificação do usuário, endereço IP, dispositivo utilizado, aplicações executadas, páginas acessadas, arquivos movimentados, dispositivos conectados, tentativas de autenticação e outras informações relacionadas à atividade realizada no ambiente corporativo.

É justamente por isso que a implementação de mecanismos de monitoramento precisa considerar não apenas a segurança da infraestrutura, mas também os princípios estabelecidos pela LGPD. Finalidade, adequação, necessidade e transparência são especialmente relevantes nesse contexto. O monitoramento deve estar relacionado a objetivos previamente determinados e a coleta de informações deve ser compatível e proporcional ao risco que se pretende controlar.

Uma ferramenta destinada a prevenir o vazamento de informações confidenciais, por exemplo, pode precisar identificar determinados tipos de arquivos, canais de transferência ou utilização de mídias removíveis. Essa finalidade, por si só, não torna necessária a captura contínua e indiscriminada de todas as atividades realizadas pelo usuário. Da mesma forma, uma solução destinada a identificar malware pode precisar analisar processos, conexões e comportamentos do dispositivo sem que isso implique necessariamente acessar o conteúdo de comunicações ou documentos que não sejam relevantes para a finalidade de segurança.

Essa diferenciação é importante porque monitoramento de segurança e monitoramento de comportamento não são necessariamente equivalentes. O primeiro busca identificar eventos relacionados à proteção dos sistemas, informações e ativos da organização. O segundo pode permitir a formação de um histórico detalhado sobre a rotina de determinada pessoa e, dependendo de sua extensão, representar uma operação de tratamento significativamente mais intrusiva.

A propriedade corporativa do equipamento também não elimina essa preocupação. Embora a organização possa estabelecer regras para utilização de seus dispositivos, redes e sistemas, as informações relacionadas a uma pessoa natural identificada ou identificável continuam sujeitas à LGPD. Assim, o fato de determinado computador, conta corporativa ou infraestrutura pertencer à empresa não significa que todos os dados gerados durante sua utilização possam ser coletados, analisados ou reutilizados sem critérios definidos.

A transparência é outro elemento relevante dessa governança. As organizações podem estabelecer políticas de uso aceitável de recursos tecnológicos, normas de segurança da informação, avisos destinados aos colaboradores e outros instrumentos capazes de informar sobre a existência e as principais finalidades do monitoramento. Essa transparência deve ser estruturada de forma a permitir que os usuários compreendam as regras aplicáveis ao ambiente corporativo, sem exigir a divulgação de detalhes técnicos cuja exposição possa comprometer os próprios controles de segurança.

Também merece atenção a utilização posterior das informações coletadas. Dados obtidos originalmente para detectar ameaças, prevenir incidentes ou proteger informações não devem ser automaticamente considerados disponíveis para qualquer outra finalidade. A utilização desses registros para avaliação de produtividade, controle disciplinar ou outras finalidades distintas demanda análise específica quanto à compatibilidade, necessidade e legitimidade desse novo tratamento.

Esse cuidado se torna ainda mais relevante com o avanço de ferramentas de User and Entity Behavior Analytics (UEBA) e outras soluções capazes de estabelecer padrões de comportamento e identificar atividades consideradas anômalas. Essas tecnologias podem contribuir para detectar credenciais comprometidas, ameaças internas ou comportamentos incompatíveis com o perfil habitual de uma conta. Entretanto, um comportamento diferente do padrão não representa, por si só, uma conduta irregular. Acesso em horário incomum, download de grande volume de arquivos ou conexão originada de um local diferente podem constituir sinais relevantes para investigação, mas precisam ser contextualizados antes de qualquer conclusão sobre a atuação do usuário.

Além da coleta, a organização precisa estabelecer governança sobre os resultados produzidos pelo monitoramento. Relatórios de navegação, alertas de DLP, históricos de dispositivos, registros de comportamento e painéis de segurança podem conter informações detalhadas sobre pessoas e, por isso, seu acesso deve ser limitado aos profissionais que efetivamente necessitam desses dados para o desempenho de suas funções. Também devem existir critérios para armazenamento, retenção, descarte e proteção contra acessos ou alterações indevidas.

Monitoramentos capazes de produzir impactos mais relevantes sobre os titulares também podem demandar uma avaliação prévia mais aprofundada dos riscos envolvidos. Nesse contexto, o Relatório de Impacto à Proteção de Dados Pessoais (RIPD), previsto pela LGPD e regulamentado pela ANPD, constitui importante instrumento de governança para documentar operações de tratamento que possam gerar alto risco, incluindo a descrição dos riscos identificados e das medidas, salvaguardas e mecanismos adotados para mitigá-los.

Por essa razão, a configuração de ferramentas de monitoramento não deveria ser uma decisão exclusivamente técnica. A TI e a Segurança da Informação possuem papel fundamental na identificação das ameaças e na escolha dos controles adequados, enquanto Privacidade, Jurídico, Encarregado e, quando pertinente, Recursos Humanos podem contribuir para avaliar as finalidades, os impactos sobre os titulares, os critérios de utilização das informações e as regras internas aplicáveis.

Uma estrutura adequada de monitoramento, portanto, não pressupõe reduzir a capacidade da organização de proteger sua infraestrutura. Significa estabelecer uma relação proporcional entre o risco identificado, a informação coletada e o controle implementado. A maturidade está justamente em utilizar a visibilidade proporcionada pela tecnologia para proteger sistemas e dados pessoais sem transformar mecanismos legítimos de segurança em instrumentos de coleta indiscriminada de informações sobre os colaboradores.

Backups: o dado foi excluído, mas continua existindo?

Os backups são um dos principais mecanismos utilizados pelas organizações para assegurar a disponibilidade das informações e a continuidade das operações. Falhas de hardware, erros humanos, corrupção de bases de dados, ataques de ransomware e outros incidentes podem comprometer sistemas inteiros, tornando as cópias de segurança essenciais para que ambientes e informações possam ser recuperados.

Sob a perspectiva da proteção de dados, entretanto, os backups apresentam uma particularidade importante: a exclusão de um dado do ambiente de produção não significa, necessariamente, que todas as suas cópias tenham deixado de existir.

Quando uma informação é removida de um sistema, ela pode continuar presente em backups, snapshots, réplicas ou outras estruturas utilizadas para recuperação. Isso significa que dados pessoais que aparentemente já não estão disponíveis na aplicação utilizada pela organização podem permanecer armazenados em sua infraestrutura durante determinado período.

A questão se torna ainda mais relevante quando se considera a forma como as cópias são produzidas. Em um backup completo, todo o conjunto de informações definido para aquela rotina é copiado novamente. Já no backup incremental, normalmente são armazenadas apenas as alterações ocorridas desde o backup anterior. Há ainda estratégias diferenciais, snapshots e mecanismos próprios de replicação e recuperação utilizados em ambientes locais e em nuvem. Como consequência, um mesmo dado pessoal pode estar distribuído entre diferentes cópias, períodos e camadas da infraestrutura.

Essa característica torna inadequada uma gestão de dados pessoais concentrada exclusivamente no ambiente produtivo. A governança precisa alcançar também o ciclo de vida das cópias, desde sua criação até sua expiração ou destruição.

A LGPD estabelece que o tratamento de dados deve observar, entre outros, o princípio da necessidade e disciplina, em seus arts. 15 e 16, o término do tratamento e as hipóteses em que os dados podem ser conservados posteriormente. Ao mesmo tempo, o art. 46 exige medidas técnicas e administrativas destinadas a protegê-los contra acessos não autorizados e situações acidentais ou ilícitas. A gestão de backups se encontra justamente na interseção entre essas obrigações: as informações precisam estar disponíveis quando houver necessidade legítima de recuperação, mas sua conservação não deve se tornar indefinida simplesmente porque estão armazenadas em uma cópia de segurança.

Por isso, políticas de backup precisam estabelecer ciclos de retenção. A frequência das cópias e o período durante o qual serão mantidas devem considerar a criticidade dos sistemas, necessidades de recuperação, continuidade de negócio, riscos envolvidos e eventuais obrigações legais ou regulatórias. Cópias diárias, semanais, mensais ou históricas podem possuir períodos distintos de retenção, desde que exista uma justificativa para sua manutenção.

Também é importante diferenciar backup de arquivamento. Embora os conceitos possam se confundir na prática, suas finalidades são diferentes. O backup existe primordialmente para permitir a recuperação de sistemas e informações diante de perda ou indisponibilidade. O arquivamento, por outro lado, está relacionado à conservação de informações por determinado período para consulta futura, atendimento de obrigações ou outras finalidades específicas. Utilizar backups como arquivos permanentes pode dificultar a aplicação de critérios adequados de retenção e eliminação.

Além do período de conservação, é necessário controlar o acesso às cópias. Backups podem concentrar grandes volumes de dados provenientes de diferentes áreas da organização e, justamente por isso, constituir ativos particularmente sensíveis. Um profissional que não possui acesso direto a determinados dados no sistema produtivo não deveria adquirir esse acesso simplesmente porque possui permissão irrestrita sobre a infraestrutura de backup.

A aplicação de controles de acesso baseados em funções, segregação de privilégios e registro das atividades administrativas contribui para reduzir esse risco. O acesso às cópias deve permanecer limitado às pessoas que efetivamente necessitam dele para administração, manutenção, recuperação ou outras atividades previamente estabelecidas.

A criptografia também pode representar uma medida relevante de proteção, especialmente para cópias armazenadas em mídias removíveis, ambientes externos, data centers ou serviços em nuvem. Dependendo da arquitetura e dos riscos envolvidos, a proteção pode abranger tanto os dados durante a transmissão quanto as informações armazenadas. A segurança das chaves criptográficas, contudo, precisa integrar a mesma estratégia: criptografar um backup e manter a chave acessível no mesmo ambiente comprometido pode reduzir significativamente a efetividade do controle.

A preocupação ganhou ainda mais importância com ataques de ransomware capazes de alcançar não apenas os sistemas produtivos, mas também as próprias estruturas utilizadas para recuperação. A segregação das cópias, a existência de backups offline ou imutáveis e a separação adequada de credenciais podem contribuir para evitar que um único comprometimento inviabilize simultaneamente o ambiente principal e sua capacidade de restauração.

Manter cópias, contudo, não é suficiente. Uma estratégia de backup somente cumpre sua finalidade quando existe capacidade efetiva de recuperação. Testes periódicos de restauração permitem verificar a integridade das informações e a efetividade dos procedimentos estabelecidos. Nesse contexto, parâmetros como Recovery Point Objective (RPO) e Recovery Time Objective (RTO) auxiliam na definição da quantidade de informação que a organização admite perder entre uma cópia e outra e do período esperado para restabelecimento de determinado serviço.

A restauração também possui uma implicação relevante para a proteção de dados. Ao recuperar um ambiente a partir de uma cópia anterior, a organização pode reintroduzir informações que haviam sido posteriormente corrigidas, eliminadas ou submetidas a alguma restrição.

Esse cenário é particularmente importante diante de pedidos de eliminação formulados por titulares. A LGPD prevê o direito à eliminação dos dados pessoais tratados com consentimento, observadas as hipóteses previstas na própria legislação, e também disciplina as situações em que informações podem continuar sendo conservadas. Na prática, porém, remover imediatamente um registro específico de todas as cópias existentes pode ser tecnicamente inviável em determinadas arquiteturas ou comprometer a integridade do próprio conjunto utilizado para recuperação.

Isso não significa que os dados existentes em backups possam permanecer disponíveis para utilização ordinária.

Uma abordagem de governança deve distinguir dados ativos no ambiente produtivo de dados temporariamente remanescentes em cópias destinadas exclusivamente à recuperação. Enquanto permanecerem nos backups durante o ciclo de retenção estabelecido, essas informações devem continuar protegidas e ter sua utilização restrita às finalidades compatíveis com a existência da cópia.

Além disso, os procedimentos de restauração precisam considerar as alterações ocorridas depois da geração do backup. Se uma cópia anterior à eliminação de determinado registro for restaurada, mecanismos técnicos ou procedimentais devem assegurar que exclusões, restrições e outras determinações aplicadas posteriormente sejam novamente refletidas no ambiente recuperado. Caso contrário, um dado corretamente eliminado pode retornar ao sistema e voltar a ser utilizado como se a exclusão nunca tivesse ocorrido.

Esse controle pode ser implementado de diferentes maneiras conforme a arquitetura tecnológica, incluindo rotinas de reprocessamento, registros das solicitações de exclusão, mecanismos de supressão ou procedimentos específicos executados após a restauração. O importante é que a recuperação de um ambiente não desfaça silenciosamente decisões de proteção de dados já implementadas.

A mesma governança precisa alcançar os fornecedores. Plataformas SaaS, provedores de cloud, serviços de hospedagem e bancos de dados gerenciados frequentemente mantêm suas próprias estruturas de redundância e recuperação. A organização deve conhecer os ciclos de retenção adotados, os mecanismos de proteção das cópias e o tratamento conferido às informações após exclusões ou encerramento contratual. A simples remoção de uma conta ou banco de dados visível ao cliente não significa, necessariamente, eliminação instantânea de todas as cópias existentes na infraestrutura do prestador.

Por fim, o encerramento do ciclo de vida do backup precisa contemplar seu descarte. Cópias expiradas e mídias retiradas de operação não devem permanecer indefinidamente disponíveis ou ser descartadas sem procedimentos adequados. Dependendo da tecnologia utilizada e da sensibilidade das informações, podem ser necessárias técnicas de apagamento seguro, destruição da mídia ou outros mecanismos capazes de reduzir o risco de recuperação posterior dos dados.

A governança de backups, portanto, não termina quando a cópia é criada. Ela envolve definição da finalidade, periodicidade, tipo de backup, prazo de retenção, localização, controle de acesso, criptografia, testes de restauração, tratamento de exclusões e descarte seguro.

Para fins de proteção de dados, essa visão é fundamental. O ciclo de vida de uma informação não ocorre apenas no banco de produção: ele também se prolonga pelas cópias criadas para garantir a continuidade da organização. Uma estratégia madura precisa conciliar disponibilidade e proteção, garantindo que os backups permaneçam recuperáveis enquanto necessários, protegidos enquanto existentes e efetivamente eliminados quando seu período legítimo de conservação chegar ao fim.

Gestão de acessos: quem realmente precisa enxergar esses dados?

Uma organização pode investir em criptografia, firewalls, ferramentas de detecção de ameaças e outras soluções avançadas de segurança e, ainda assim, manter uma fragilidade significativa de proteção de dados se pessoas que não precisam consultar determinadas informações continuarem autorizadas a acessá-las.

A gestão de acessos ocupa, por isso, uma posição central na relação entre Tecnologia da Informação e LGPD. O art. 46 da Lei estabelece que os agentes de tratamento devem adotar medidas técnicas e administrativas capazes de proteger os dados pessoais, inclusive contra acessos não autorizados. Na prática, isso exige não apenas impedir a entrada de agentes externos nos sistemas, mas também controlar adequadamente quais usuários internos e terceiros podem acessar cada recurso e quais ações estão autorizados a realizar.

A própria ANPD define o controle de acesso como uma medida técnica destinada a garantir que os dados sejam acessados somente por pessoas autorizadas, estruturada a partir de três processos: autenticação, autorização e auditoria. A autenticação permite identificar quem está tentando acessar o ambiente; a autorização estabelece o que aquele usuário poderá fazer; e a auditoria possibilita registrar e verificar posteriormente as atividades realizadas.

Essa estrutura demonstra que possuir usuário e senha não é suficiente para caracterizar uma gestão adequada de acessos. Depois de confirmar a identidade de uma pessoa, a organização ainda precisa definir quais sistemas, funcionalidades e informações são efetivamente necessários para o desempenho de suas atividades.

Nesse contexto, ganha importância o princípio do menor privilégio, segundo o qual cada usuário deve receber apenas os acessos necessários para executar suas funções. Essa lógica também dialoga diretamente com o princípio da necessidade previsto na LGPD: se determinado colaborador não precisa consultar uma categoria de dados para desempenhar suas atribuições, a disponibilização dessas informações amplia desnecessariamente a superfície de exposição.

Uma forma de operacionalizar esse controle é estruturar permissões de acordo com funções ou perfis previamente definidos. Em um modelo de Role-Based Access Control (RBAC), por exemplo, os privilégios são associados às funções desempenhadas e não concedidos indiscriminadamente a cada usuário. Um profissional de atendimento pode precisar visualizar determinadas informações cadastrais de clientes sem necessariamente possuir acesso a dados financeiros; um colaborador do RH pode precisar acessar informações funcionais sem ter privilégios administrativos sobre o sistema; e um profissional da TI pode administrar a infraestrutura sem que isso implique acesso permanente ao conteúdo de todas as bases existentes.

A definição desses perfis também reduz um problema recorrente: o acúmulo de permissões ao longo da trajetória do colaborador. Mudanças de função, transferências entre departamentos e participação temporária em projetos podem fazer com que novos acessos sejam concedidos sem que os anteriores sejam retirados. Com o passar do tempo, uma pessoa pode acumular permissões incompatíveis com suas atribuições atuais, fenômeno frequentemente tratado como privilege creep.

Por isso, a gestão de acessos não termina no momento em que uma permissão é concedida. A ANPD recomenda que o controle contemple processos de concessão, revisão e suspensão de acessos. Revisões periódicas permitem identificar contas sem utilização, permissões excessivas, privilégios incompatíveis com a função atual e acessos que permaneceram ativos mesmo depois de desaparecer a necessidade que originalmente os justificava.

A atenção deve ser ainda maior em relação aos usuários privilegiados. Administradores de sistemas, bancos de dados, redes, ambientes cloud e outras infraestruturas podem possuir capacidade para criar usuários, alterar permissões, modificar configurações, consultar registros ou executar operações que usuários comuns não conseguem realizar. O comprometimento ou uso inadequado dessas contas tende, portanto, a produzir impactos significativamente maiores.

Contas administrativas devem ser tratadas de forma distinta das contas utilizadas para atividades cotidianas. Sempre que a arquitetura permitir, é recomendável separar o perfil utilizado para tarefas comuns daquele destinado à administração do ambiente, restringindo o uso de privilégios elevados aos momentos em que forem efetivamente necessários. Soluções de Privileged Access Management (PAM) também podem contribuir para controlar, registrar e, em determinados ambientes, conceder privilégios elevados apenas durante períodos específicos.

A autenticação multifator (MFA) acrescenta outra camada relevante de proteção. Senhas podem ser descobertas, reutilizadas, compartilhadas ou obtidas por meio de phishing e outros ataques. Exigir um fator adicional reduz a possibilidade de que a obtenção isolada da credencial seja suficiente para permitir o acesso. Sua adoção é particularmente relevante em contas administrativas, acessos remotos, VPNs, serviços em nuvem e sistemas que concentram informações de maior criticidade.

Outro ponto sensível são as contas compartilhadas. Quando diferentes pessoas utilizam a mesma credencial, torna-se mais difícil determinar quem realizou determinada atividade, enfraquecendo a rastreabilidade e a responsabilização. Sempre que possível, cada usuário deve possuir identificação individual, permitindo que permissões e registros de atividade sejam associados à pessoa efetivamente responsável pelo acesso.

Contas genéricas ou técnicas podem ser necessárias em determinadas arquiteturas, especialmente para execução de serviços, aplicações e integrações. Nesses casos, entretanto, sua existência deve ser justificada e acompanhada de controles específicos, como limitação de privilégios, proteção das credenciais, definição dos responsáveis, restrição de utilização interativa e mecanismos de monitoramento compatíveis com o risco.

A segregação de funções complementa essa estrutura ao evitar a concentração excessiva de poderes em uma única pessoa. Em operações mais críticas, o mesmo usuário não deveria necessariamente possuir condições de iniciar, aprovar e concluir sozinho uma atividade sensível. A separação entre solicitação e aprovação de acessos, administração e auditoria ou desenvolvimento e implantação em produção pode reduzir riscos de fraude, erro e utilização indevida das informações.

Também é necessário manter evidências sobre o próprio processo de gestão. Solicitações de acesso, aprovações, alterações de perfil, concessões excepcionais e revogações devem possuir rastreabilidade compatível com a criticidade dos ambientes envolvidos. Esses registros permitem compreender não apenas quem acessou determinado sistema, mas também por que aquela pessoa possuía autorização para fazê-lo.

Essa governança é especialmente importante para acessos concedidos a terceiros. Empresas de suporte, consultorias, desenvolvedores e fornecedores de infraestrutura podem precisar acessar sistemas corporativos para executar atividades específicas. A necessidade operacional, entretanto, não deve resultar automaticamente na criação de uma conta permanente ou com privilégios superiores aos necessários.

Quando possível, acessos de terceiros devem possuir escopo e período previamente definidos, ser vinculados a usuários identificáveis, utilizar mecanismos adequados de autenticação e ser revogados após o encerramento da atividade. Para intervenções pontuais, permissões temporárias ou modelos de just-in-time access podem reduzir a exposição ao evitar que privilégios elevados permaneçam disponíveis continuamente.

A gestão de acessos precisa ainda acompanhar o ciclo de vida das pessoas dentro da organização. Admissões, mudanças de função, afastamentos, encerramentos de contratos e desligamentos devem gerar reflexos nas permissões existentes. A integração entre Recursos Humanos, gestores, TI e Segurança da Informação é essencial para que alterações organizacionais sejam traduzidas rapidamente em concessão, revisão ou retirada de privilégios.

Esse conjunto de controles evidencia que a gestão de acessos não deve ser tratada como uma simples atividade operacional de criação e exclusão de usuários. Trata-se de um processo contínuo de governança destinado a assegurar que a pessoa correta tenha acesso à informação correta, pelo nível de privilégio adequado e durante o período em que esse acesso for efetivamente necessário.

Sob a perspectiva da LGPD, esse controle é particularmente relevante porque o risco de acesso indevido não surge apenas quando um invasor rompe as barreiras externas da organização. Ele também existe quando permissões excessivas, antigas, compartilhadas ou mal administradas permitem que dados pessoais sejam consultados por pessoas que não possuem necessidade legítima de utilizá-los.

Uma estrutura tecnológica pode, portanto, estar protegida contra ameaças externas e continuar excessivamente exposta internamente. A maturidade da gestão de acessos está justamente em substituir a lógica de acesso amplo por uma governança baseada em necessidade, menor privilégio, segregação, rastreabilidade e revisão contínua das permissões.

O colaborador saiu. E os acessos?

O desligamento de um colaborador não encerra automaticamente sua capacidade de acessar os recursos tecnológicos da organização. Enquanto contas, credenciais, sessões, tokens ou dispositivos permanecerem ativos, uma pessoa que já não integra a empresa pode continuar tecnicamente habilitada a acessar sistemas e, consequentemente, dados pessoais.

É por isso que o processo de offboarding também deve ser compreendido como uma medida de segurança e proteção de dados.

A própria ANPD, em suas orientações sobre segurança da informação, estabelece que as medidas de controle de acesso devem abranger processos de concessão, revisão e suspensão de acessos e recomenda expressamente que usuários afastados ou desligados tenham suas autorizações imediatamente canceladas. Essa orientação está diretamente relacionada à lógica do art. 46 da LGPD, que exige medidas capazes de proteger dados pessoais contra acessos não autorizados.

Na prática, o primeiro desafio costuma ser menos tecnológico do que organizacional. A TI somente consegue revogar tempestivamente um acesso se souber que o vínculo foi encerrado. Por essa razão, a comunicação entre Recursos Humanos, gestor responsável, TI e Segurança da Informação precisa integrar formalmente o processo de desligamento.

Esse fluxo deve permitir que a área responsável pelos acessos conheça previamente, sempre que possível, a data e o horário em que as permissões deverão ser desativadas. Em situações que demandem encerramento imediato, a comunicação também precisa ocorrer de maneira suficientemente rápida para que não exista uma janela desnecessária entre o término do vínculo e a revogação das credenciais.

O cuidado é importante porque a identidade digital de um colaborador normalmente não está concentrada em um único sistema. Uma mesma pessoa pode possuir acesso ao diretório corporativo, e-mail, VPN, ERP, CRM, plataformas de Recursos Humanos, ferramentas de colaboração, repositórios de documentos, sistemas internos, aplicações SaaS e diferentes ambientes em nuvem.

Consequentemente, bloquear a conta principal não significa necessariamente encerrar todos os acessos existentes.

Ambientes que utilizam mecanismos centralizados de identidade e Single Sign-On (SSO) facilitam esse processo ao permitir que diferentes aplicações sejam vinculadas a uma identidade corporativa. Ainda assim, a organização precisa conhecer as exceções. Sistemas não integrados ao diretório central, contas criadas diretamente em plataformas SaaS, credenciais locais e aplicações legadas podem permanecer acessíveis mesmo depois da desativação da identidade principal.

O acesso remoto também precisa fazer parte desse levantamento. Contas de VPN, soluções de acesso remoto, ambientes virtuais e outras formas de conexão externa devem ser revogadas de acordo com o encerramento do vínculo. Sessões previamente autenticadas também merecem atenção, já que determinados serviços podem continuar funcionando durante algum período por meio de sessões ou tokens ainda válidos mesmo depois de uma alteração de senha.

A situação exige cuidado adicional quando o colaborador possuía privilégios administrativos. Profissionais de infraestrutura, desenvolvimento, bancos de dados, DevOps, Segurança da Informação e suporte podem ter acessos significativamente mais amplos do que usuários convencionais. Em alguns casos, podem possuir condições de administrar servidores, alterar permissões, acessar bases de dados, modificar configurações ou criar novas credenciais.

Nessas situações, o offboarding precisa alcançar não apenas a conta nominal do usuário, mas todo o conjunto de mecanismos de autenticação sob sua responsabilidade. Isso pode incluir credenciais administrativas, chaves SSH, chaves de API, certificados digitais, tokens de acesso, secrets utilizados em aplicações e outros elementos capazes de permitir autenticação direta ou indireta nos ambientes.

Quando uma credencial era conhecida ou controlada exclusivamente pelo profissional desligado, também pode ser necessário realizar sua substituição ou rotação. Apenas remover o usuário de um grupo não resolve o problema se uma chave, senha administrativa ou token anteriormente conhecido continuar válido.

Essa preocupação é particularmente relevante em ambientes cloud e estruturas de desenvolvimento. Provedores de nuvem, plataformas de código-fonte, ferramentas de CI/CD, containers, repositórios e serviços de infraestrutura podem possuir mecanismos próprios de identidade e credenciais que não necessariamente acompanham o diretório corporativo. Uma gestão adequada precisa conhecer esses pontos de acesso e incorporá-los ao procedimento de desligamento.

As contas genéricas e compartilhadas tornam o processo ainda mais complexo. Quando diferentes pessoas utilizam a mesma credencial, a saída de um único integrante pode exigir alteração da senha ou substituição de outros elementos de autenticação, já que simplesmente excluir a conta individual não impede a continuidade do acesso por meio da credencial compartilhada.

Essa é mais uma razão para reduzir o uso de contas compartilhadas sempre que tecnicamente possível. Além de dificultarem a rastreabilidade das atividades, elas também tornam os processos de admissão, movimentação e desligamento mais difíceis de controlar.

O e-mail corporativo apresenta outra questão relevante. O desligamento não significa necessariamente que todo o conteúdo da caixa postal deva ser imediatamente eliminado. Mensagens podem conter registros relacionados às atividades da organização, comunicações com clientes, documentos ou outras informações que precisem ser preservadas por período determinado. Por outro lado, a manutenção da caixa não justifica preservar o acesso do antigo colaborador.

A organização pode estabelecer procedimentos para bloqueio da autenticação, preservação das informações necessárias, redirecionamento de comunicações quando pertinente e posterior aplicação dos critérios de retenção definidos. O acesso ao conteúdo remanescente também deve ser limitado às pessoas autorizadas e possuir finalidade definida, evitando que o desligamento resulte em consulta indiscriminada ao histórico de comunicações do antigo usuário.

Os dispositivos corporativos também integram o processo. Notebooks, smartphones, tablets, tokens físicos, mídias removíveis e outros equipamentos devem ser devolvidos e submetidos aos procedimentos definidos pela organização. Dependendo do dispositivo e da arquitetura utilizada, ferramentas de gerenciamento como Mobile Device Management (MDM) ou outras soluções de administração podem permitir bloqueio, remoção de perfis corporativos ou apagamento remoto de informações.

Antes que um equipamento seja entregue a outro colaborador, vendido, devolvido ao fornecedor ou descartado, também é necessário avaliar a presença de dados pessoais e informações corporativas armazenadas localmente. A simples criação de um novo usuário ou exclusão convencional de arquivos pode não representar um procedimento adequado de sanitização do dispositivo.

O offboarding também deve contemplar acessos concedidos indiretamente. Grupos de distribuição, pastas compartilhadas, repositórios de documentos, calendários, ferramentas de comunicação, cofres de senhas, plataformas de gerenciamento de projetos e grupos administrativos podem permanecer associados ao usuário. A existência de um inventário de sistemas e de um processo estruturado de gestão de identidades facilita significativamente a identificação desses vínculos.

Outro aspecto relevante é a rastreabilidade do próprio desligamento. A organização deve possuir condições de demonstrar quais acessos foram revogados, quando a revogação ocorreu e, especialmente em ambientes críticos, se permaneceram credenciais ou privilégios que demandavam tratamento adicional. Checklists de offboarding, registros de chamados e automações de Identity and Access Management (IAM) podem contribuir para tornar o processo consistente e verificável.

Em determinados contextos, também pode ser pertinente analisar os registros de acesso relacionados ao período imediatamente anterior e posterior ao desligamento, especialmente quando houver circunstâncias concretas que indiquem risco de uso indevido de credenciais ou movimentação irregular de informações. Essa análise, contudo, deve permanecer vinculada a uma finalidade legítima de segurança e observar os mesmos critérios de necessidade e proporcionalidade aplicáveis ao monitoramento corporativo.

A automação pode reduzir parte considerável dos riscos. A integração entre sistemas de Recursos Humanos e ferramentas de gestão de identidades pode permitir que alterações no vínculo do colaborador desencadeiem fluxos previamente definidos de bloqueio, remoção de grupos e revogação de permissões. Mesmo nesses ambientes, contudo, contas administrativas independentes, credenciais técnicas e aplicações não integradas precisam ser identificadas e tratadas separadamente.

Por isso, um processo de desligamento tecnologicamente adequado não consiste apenas em “desativar o usuário”. Ele deve considerar a identidade digital do colaborador de maneira ampla: e-mail, VPN, sistemas internos, aplicações SaaS, ambientes cloud, contas administrativas, tokens, chaves, dispositivos, grupos, credenciais compartilhadas e demais recursos aos quais aquela pessoa possuía acesso.

Sob a perspectiva da LGPD, a lógica é direta: se o acesso havia sido concedido porque determinada pessoa precisava dos dados para exercer suas funções, o encerramento dessa necessidade deve produzir reflexos sobre sua autorização. Manter privilégios ativos após o fim do vínculo amplia desnecessariamente a superfície de exposição e pode permitir acessos que já não encontram justificativa operacional.

O offboarding, portanto, não é apenas uma rotina administrativa de RH nem uma tarefa operacional da TI. É um processo de segurança da informação e proteção de dados que encerra o ciclo de acesso iniciado no momento da admissão. Quanto mais distribuída for a infraestrutura tecnológica da organização, mais importante será possuir um procedimento capaz de localizar e revogar, de forma coordenada e tempestiva, todas as formas pelas quais aquele usuário ainda poderia alcançar sistemas, recursos e dados pessoais.

Cloud, SaaS e fornecedores: seus dados estão na infraestrutura de quem?

A adoção de serviços em nuvem e plataformas SaaS modificou profundamente a forma como as organizações estruturam sua infraestrutura tecnológica. Sistemas que anteriormente dependiam de servidores, bancos de dados e aplicações mantidos internamente passaram a ser disponibilizados por fornecedores especializados, muitas vezes distribuídos entre diferentes data centers, regiões e prestadores de serviços.

Essa mudança proporciona escalabilidade, disponibilidade, redução da necessidade de infraestrutura própria e acesso a tecnologias que seriam mais complexas de manter internamente. Sob a perspectiva da proteção de dados, entretanto, também amplia a quantidade de organizações que podem participar das operações de tratamento.

Quando uma empresa contrata uma plataforma de CRM, um sistema de Recursos Humanos, uma ferramenta de atendimento, um serviço de armazenamento ou qualquer outra solução que receba dados pessoais, a infraestrutura pode deixar de estar sob seu controle técnico direto. Isso não significa, contudo, que as obrigações relacionadas à proteção dessas informações sejam automaticamente transferidas ao fornecedor.

A terceirização da infraestrutura transfere determinadas atividades técnicas, mas não elimina as responsabilidades que cabem à organização de acordo com o papel que exerce no tratamento dos dados.

Essa distinção é importante porque a própria qualificação do fornecedor depende da operação realizada. Conforme as orientações da ANPD sobre agentes de tratamento, o operador realiza o tratamento de dados pessoais em nome do controlador e segundo suas instruções. Assim, um fornecedor que armazena, processa ou disponibiliza dados exclusivamente para prestar determinado serviço poderá atuar como operador em relação àquela atividade. Isso não significa, porém, que todo fornecedor de tecnologia seja automaticamente operador ou que desempenhe necessariamente o mesmo papel em todas as operações.

A realidade da prestação precisa ser analisada concretamente.

É nesse contexto que a Due Diligence de fornecedores assume papel relevante. A avaliação de privacidade e segurança anterior à contratação permite compreender os riscos associados ao serviço antes que dados pessoais sejam efetivamente inseridos na infraestrutura do terceiro.

Essa análise deve ser proporcional ao risco. Um fornecedor que terá acesso eventual a poucos dados cadastrais não necessariamente demanda o mesmo nível de avaliação de uma plataforma responsável por armazenar bases extensas de clientes, informações financeiras, dados de saúde ou outros dados pessoais sensíveis. A natureza e o volume das informações, a quantidade de titulares, a criticidade do serviço, o nível de acesso concedido e as consequências de eventual indisponibilidade ou comprometimento são fatores que podem orientar a profundidade da avaliação.

Um dos primeiros aspectos a ser compreendido é onde os dados serão armazenados e processados. Em arquiteturas de nuvem, a localização nem sempre é evidente para o cliente. A contratação pode ocorrer com uma empresa estabelecida no Brasil enquanto o processamento, suporte, replicação ou armazenamento das informações ocorre em infraestrutura localizada em outros países.

Esse cenário pode caracterizar transferência internacional de dados pessoais e exige análise das regras previstas na LGPD e no Regulamento de Transferência Internacional de Dados aprovado pela Resolução CD/ANPD nº 19/2024. A existência de uma infraestrutura global não é, por si só, incompatível com a LGPD, mas a organização precisa conhecer o fluxo internacional e verificar o mecanismo juridicamente aplicável à transferência.

Conhecer apenas o fornecedor contratado diretamente também pode ser insuficiente.

Serviços tecnológicos frequentemente dependem de outros prestadores. Uma plataforma SaaS pode utilizar um provedor de cloud para hospedar seus sistemas, contratar outra empresa para envio de comunicações, utilizar ferramentas de monitoramento, recorrer a prestadores externos de suporte ou integrar serviços especializados para determinadas funcionalidades.

Surge, assim, uma cadeia de tratamento na qual podem existir suboperadores. A ANPD reconhece essa figura em suas orientações como o terceiro contratado pelo operador para auxiliá-lo na realização do tratamento em nome do controlador. Embora a LGPD não apresente expressamente o conceito de suboperador, a Autoridade considera sua existência compatível com estruturas mais complexas de tratamento.

Para a organização contratante, essa cadeia precisa ser minimamente compreendida. É relevante conhecer quais categorias de terceiros poderão participar do tratamento, quais atividades desempenharão, quais dados poderão acessar e quais mecanismos existem para controlar alterações relevantes nessa estrutura. Em serviços mais críticos, mudanças de suboperadores podem alterar a localização, os riscos e até mesmo os fluxos internacionais inicialmente avaliados.

A Due Diligence também precisa verificar os controles de segurança adotados pelo fornecedor. Gestão de acessos, autenticação multifator, criptografia, segregação de ambientes, gerenciamento de vulnerabilidades, backups, registros de atividades, gestão de incidentes, continuidade de negócio, desenvolvimento seguro e procedimentos de recuperação são exemplos de aspectos que podem ser avaliados conforme as características do serviço.

Nesse processo, declarações genéricas de conformidade possuem utilidade limitada quando não são acompanhadas de elementos capazes de demonstrar a implementação dos controles informados.

Por isso, a análise pode incluir evidências de segurança e privacidade compatíveis com o risco da contratação, como políticas e procedimentos internos, relatórios de auditoria, certificações aplicáveis, testes de segurança, documentos relacionados à continuidade de negócio, políticas de resposta a incidentes, registros de treinamentos ou outros elementos capazes de demonstrar a existência dos controles declarados.

Certificações e relatórios independentes podem contribuir para a avaliação, mas não devem ser interpretados isoladamente como garantia absoluta de conformidade com a LGPD. O escopo da certificação, os ambientes abrangidos, a data da avaliação e sua relação com o serviço efetivamente contratado precisam ser considerados.

A gestão de incidentes constitui outro elemento essencial. Quando os dados estão armazenados na infraestrutura de um terceiro, esse fornecedor pode ser o primeiro a identificar uma violação de segurança. O tempo transcorrido entre a detecção pelo prestador e a comunicação à organização pode afetar significativamente a capacidade de investigação, contenção e atendimento das obrigações aplicáveis.

Por isso, contratos e procedimentos devem estabelecer fluxos claros de comunicação, responsabilidades, informações mínimas a serem fornecidas e mecanismos de cooperação em caso de incidente. O fornecedor precisa estar preparado para disponibilizar elementos suficientes para que a organização compreenda a natureza do evento, os dados e titulares potencialmente afetados, as medidas de contenção adotadas e os riscos envolvidos.

A contratação também precisa considerar a continuidade do negócio. A indisponibilidade de um fornecedor crítico pode impedir o acesso não apenas ao sistema, mas às próprias informações necessárias à operação. Por isso, a avaliação pode abranger mecanismos de redundância, backups, planos de continuidade e recuperação, níveis de serviço, dependências de infraestrutura e procedimentos para situações de indisponibilidade prolongada.

Em serviços particularmente críticos, também é importante compreender a possibilidade de portabilidade e recuperação das informações. Uma dependência tecnológica excessiva pode criar situações de vendor lock-in, nas quais a organização possui dificuldades significativas para migrar seus dados ou substituir o fornecedor. A governança de proteção de dados também se beneficia de contratos e arquiteturas que permitam compreender como as informações poderão ser recuperadas, exportadas ou transferidas quando necessário.

O encerramento da relação contratual merece a mesma atenção dedicada ao início.

Ao término do serviço, deve existir uma definição sobre devolução, exportação, exclusão ou anonimização dos dados pessoais. A organização precisa saber em qual formato poderá recuperar suas informações, durante quanto tempo elas permanecerão disponíveis após o encerramento, quando serão eliminadas dos ambientes ativos e como serão tratadas eventuais cópias existentes em backups.

Esse ponto é particularmente relevante em serviços em nuvem porque a exclusão visível ao cliente não significa necessariamente desaparecimento instantâneo de todas as cópias existentes. Os ciclos de backup e retenção do fornecedor podem fazer com que determinadas informações permaneçam temporariamente em estruturas de recuperação, devendo continuar protegidas e submetidas aos critérios definidos para sua eliminação.

As responsabilidades relacionadas a esses aspectos precisam estar refletidas nos instrumentos contratuais. Cláusulas sobre finalidade e limites do tratamento, confidencialidade, medidas de segurança, subcontratação, transferências internacionais, atendimento aos direitos dos titulares, incidentes, auditoria, retenção, devolução e eliminação de informações contribuem para estabelecer expectativas e responsabilidades entre as partes.

O contrato, entretanto, não substitui a avaliação técnica.

Uma cláusula que determine a adoção de medidas adequadas de segurança possui pouco valor preventivo se a organização nunca verificar quais controles o fornecedor efetivamente implementa. Da mesma forma, uma Due Diligence realizada antes da contratação perde parte de sua utilidade se alterações relevantes na prestação do serviço nunca forem acompanhadas posteriormente.

Por isso, a gestão de terceiros deve ser compreendida como um processo contínuo e baseado em risco. Fornecedores críticos podem demandar reavaliações periódicas, acompanhamento de planos de ação, atualização de evidências e nova análise diante de mudanças relevantes na infraestrutura, no serviço prestado, nas categorias de dados tratadas ou na cadeia de suboperadores.

Também é importante que as recomendações decorrentes da Due Diligence sejam tratadas de forma compatível com o risco identificado. A avaliação fornece elementos para que a organização compreenda vulnerabilidades, lacunas e medidas recomendadas; a decisão sobre contratação, continuidade ou aceitação de riscos deve ser formalizada pelas áreas responsáveis, de acordo com sua estrutura de governança.

Essa abordagem evita dois erros comuns: considerar que a contratação de um grande fornecedor de tecnologia elimina a necessidade de avaliação ou exigir de todos os prestadores exatamente os mesmos controles, independentemente do risco representado por cada serviço.

Cloud e SaaS não retiram da organização a necessidade de conhecer o caminho percorrido pelos dados. Ao contrário, quanto mais distribuída for a infraestrutura, maior se torna a importância de compreender quem trata as informações, onde elas estão, quais terceiros participam da operação, quais controles as protegem e o que acontecerá com elas quando o serviço terminar.

A contratação de tecnologia, portanto, não deve representar a terceirização da governança. Uma organização pode não administrar fisicamente o servidor que armazena seus dados, mas continua precisando conhecer e administrar os riscos decorrentes da escolha de colocar essas informações na infraestrutura de terceiros.

Ambientes de teste, homologação e desenvolvimento: dados reais deveriam estar aqui?

Ambientes de desenvolvimento, teste e homologação são essenciais para a evolução segura de sistemas. É neles que novas funcionalidades são construídas, correções são validadas, integrações são verificadas e problemas são reproduzidos antes que qualquer alteração alcance o ambiente produtivo.

Apesar disso, esses ambientes podem se transformar em pontos relevantes de exposição de dados pessoais quando recebem cópias integrais de bases produtivas sem uma avaliação prévia sobre sua real necessidade.

A prática é comum porque dados reais reproduzem com maior fidelidade os cenários encontrados em produção. Estruturas de tabelas, relacionamentos, formatos de campos, registros incompletos, exceções e combinações específicas podem facilitar testes que seriam mais difíceis de executar com bases artificiais. A conveniência técnica, entretanto, não elimina os riscos associados ao tratamento dessas informações fora do ambiente originalmente destinado à operação.

Ao copiar uma base produtiva para homologação ou desenvolvimento, a organização não está apenas reproduzindo a estrutura do sistema. Ela pode estar criando uma nova cópia de dados pessoais, em outro ambiente, com novos usuários autorizados, novas credenciais, diferentes períodos de retenção e controles de segurança que nem sempre possuem o mesmo nível de maturidade existente em produção.

Esse cenário dialoga diretamente com o princípio da necessidade previsto na LGPD. Se determinada atividade de teste pode ser realizada com dados sintéticos, anonimizados ou com um conjunto reduzido de informações, a utilização integral de uma base real amplia o tratamento sem que isso necessariamente seja indispensável para a finalidade pretendida.

Por isso, uma abordagem mais adequada consiste em adotar, sempre que possível, dados sintéticos ou informações efetivamente anonimizadas nos ambientes não produtivos.

Dados sintéticos são registros artificialmente criados para reproduzir características relevantes da aplicação sem corresponder a pessoas reais. Para muitos testes funcionais, eles permitem simular cadastros, transações, regras de negócio e diferentes cenários sem introduzir dados pessoais reais no ambiente.

A anonimização representa outra possibilidade. A LGPD define como anonimizado o dado que, considerados os meios técnicos razoáveis e disponíveis no momento do tratamento, perde a possibilidade de associação, direta ou indireta, a um indivíduo. Quando essa condição é efetivamente alcançada, a informação deixa de ser considerada dado pessoal para fins da Lei, ressalvadas as hipóteses em que o processo possa ser revertido com esforços razoáveis.

Essa distinção é importante porque mascarar um campo não significa necessariamente anonimizar um conjunto de dados.

Substituir nomes por códigos, ocultar parte de um CPF, alterar endereços de e-mail ou trocar identificadores diretos pode reduzir o risco de identificação, mas os registros ainda podem permanecer relacionados a uma pessoa quando combinados com outras informações. Data de nascimento, localização, histórico de transações, cargo, comportamento de utilização ou outros atributos podem permitir a reidentificação mesmo quando os identificadores mais evidentes foram removidos.

Quando a associação ao titular continua possível mediante utilização de informação adicional mantida separadamente, estamos mais próximos de uma situação de pseudonimização. A ANPD define a pseudonimização como o tratamento em que o dado somente pode ser atribuído a um titular por meio de informação adicional mantida separadamente em ambiente controlado e seguro. Diferentemente da anonimização efetiva, dados pseudonimizados continuam sendo dados pessoais e permanecem sujeitos às exigências da LGPD.

Isso não reduz o valor do mascaramento ou da pseudonimização como medidas de segurança. Pelo contrário: essas técnicas podem diminuir significativamente os riscos decorrentes de uma eventual exposição. O ponto é compreender que elas não eliminam automaticamente a necessidade de aplicar controles de proteção de dados.

Há situações em que a utilização de dados reais pode ser tecnicamente necessária. Determinados defeitos podem depender de combinações específicas presentes apenas na produção; integrações complexas podem exigir reprodução fiel de uma ocorrência; problemas de performance podem demandar volumes e estruturas semelhantes aos do ambiente real; e atividades de troubleshooting podem exigir análise de registros concretos para identificar a origem de determinada falha.

Nesses casos, a utilização de dados pessoais em ambiente não produtivo deveria ser tratada como exceção controlada, e não como padrão operacional.

Isso envolve limitar a quantidade de dados ao estritamente necessário, restringir as pessoas autorizadas, definir previamente a finalidade do acesso, estabelecer um período para permanência das informações e eliminar as cópias após a conclusão da atividade. Quando possível, identificadores ou atributos que não sejam necessários para a investigação devem ser removidos ou transformados antes da transferência.

A segregação entre os ambientes também é fundamental.

Desenvolvimento, homologação e produção desempenham funções diferentes e, por isso, não deveriam compartilhar indiscriminadamente credenciais, contas administrativas, secrets, chaves, bancos de dados ou permissões. Boas práticas de segurança recomendam separar estruturalmente os ambientes e limitar o acesso às equipes que efetivamente necessitam de cada um deles. A OWASP, por exemplo, recomenda isolar ambientes de desenvolvimento dos ambientes produtivos e conceder acesso somente aos grupos autorizados de desenvolvimento e teste.

Essa separação também reduz o risco de uma alteração, vulnerabilidade ou credencial comprometida em um ambiente de teste produzir impacto direto sobre a produção.

Na prática, ambientes não produtivos muitas vezes possuem características que aumentam seu risco. Ferramentas de depuração podem estar habilitadas, configurações de segurança podem ser mais permissivas, controles de acesso podem ser simplificados e uma quantidade maior de desenvolvedores ou fornecedores pode possuir privilégios administrativos. Além disso, esses ambientes podem receber menos monitoramento ou atualizações do que os sistemas produtivos.

Quando dados reais são inseridos nesse contexto, a organização pode criar uma cópia das informações justamente em um ambiente menos protegido.

Esse risco também aparece em atividades de troubleshooting e suporte. Para investigar um erro, equipes internas ou fornecedores podem solicitar exportações de bancos de dados, arquivos contendo registros de usuários, logs ou cópias de telas. Esses materiais frequentemente deixam o ambiente original e passam a circular por ferramentas de chamados, e-mails, computadores de desenvolvedores ou plataformas utilizadas pelo fornecedor.

A necessidade de investigação não elimina a exigência de limitar o tratamento. Sempre que possível, o material enviado deve conter apenas as informações necessárias para reproduzir ou analisar o problema. Dados irrelevantes podem ser removidos, mascarados ou substituídos antes do compartilhamento.

A mesma lógica se aplica ao controle de acessos. Desenvolvedores que trabalham em determinada funcionalidade não precisam necessariamente visualizar toda a base de clientes, colaboradores ou usuários da organização. Quando dados reais forem indispensáveis, permissões temporárias, acessos individualizados, registro das atividades e limitação por escopo podem reduzir significativamente o risco.

O período de retenção das cópias também deve ser definido. Uma base transferida para solucionar um problema específico não deveria permanecer indefinidamente em homologação depois que a investigação terminou. A ausência de rotinas de descarte faz com que ambientes não produtivos acumulem versões antigas de bases, dumps de bancos de dados, arquivos de exportação e outros conjuntos de informações que já não possuem finalidade operacional.

Há ainda um risco adicional: o chamado data sprawl, caracterizado pela dispersão das informações entre diferentes ambientes, ferramentas e cópias. Quanto mais vezes uma base produtiva é exportada para testes, desenvolvimento, suporte ou homologação, mais difícil se torna saber quantas cópias existem, quem possui acesso e quais delas ainda deveriam permanecer armazenadas.

Essa dispersão também afeta o atendimento aos direitos dos titulares e os próprios processos internos de retenção e eliminação. Uma organização pode excluir um dado do ambiente produtivo e, ainda assim, conservar diversas cópias antigas em ambientes de teste que não foram incluídos no processo de descarte.

Por isso, a governança desses ambientes deve prever não apenas sua separação técnica, mas também regras específicas para entrada, utilização e saída de dados pessoais.

Uma política adequada pode estabelecer que dados sintéticos ou anonimizados sejam utilizados como padrão; que a utilização de dados reais dependa de justificativa e autorização; que apenas o subconjunto necessário seja transferido; que técnicas de mascaramento ou pseudonimização sejam aplicadas quando compatíveis com o teste; que acessos sejam restritos e rastreáveis; e que exista prazo definido para eliminação das cópias após o encerramento da atividade.

Essa abordagem também está alinhada à lógica de prevenção e segurança prevista na LGPD. A própria ANPD reconhece anonimização, pseudonimização, criptografia e minimização como técnicas capazes de contribuir para a mitigação dos riscos relacionados ao tratamento de dados pessoais.

Ambientes de teste, desenvolvimento e homologação não precisam reproduzir integralmente o nível de exposição existente em produção para cumprir sua finalidade. O objetivo deve ser reproduzir as condições técnicas necessárias ao teste, e não necessariamente reproduzir todas as informações pessoais existentes no sistema real.

Uma governança madura, portanto, trata dados produtivos em ambientes não produtivos como uma exceção que precisa ser tecnicamente justificada e protegida. Quanto menor a quantidade de dados reais utilizada fora de produção, menor será a superfície de exposição criada durante o desenvolvimento, a homologação e a investigação de falhas.

Incidentes de segurança: o que a TI precisa fazer antes de chamar o DPO?

Quando ocorre um incidente de segurança, a atuação inicial da Tecnologia da Informação costuma ser decisiva. É nesse primeiro momento que a organização precisa identificar o que aconteceu, conter a ameaça, preservar evidências, compreender quais sistemas foram afetados e reunir informações suficientes para avaliar a dimensão do evento.

Sob a perspectiva da LGPD, porém, a resposta não deve ser tratada exclusivamente como uma atividade técnica.

Um incidente que comprometa confidencialidade, integridade ou disponibilidade de dados pessoais pode gerar consequências regulatórias, contratuais e reputacionais para a organização. Por isso, a atuação da TI precisa estar integrada, desde o início, às áreas responsáveis por Privacidade, Segurança da Informação, Jurídico, Compliance e ao Encarregado pelo Tratamento de Dados Pessoais.

A própria ANPD recomenda que, diante de um incidente envolvendo dados pessoais, seja executado imediatamente o plano de resposta a incidentes, com adoção das medidas necessárias para cessar o evento e restabelecer os serviços de forma segura. Na sequência, devem ser avaliados aspectos como natureza do incidente, categorias e quantidade de dados afetados, titulares envolvidos e consequências concretas ou prováveis.

Isso demonstra que a comunicação com o DPO não deveria começar apenas depois que a TI concluiu toda a investigação.

A análise técnica e a avaliação de proteção de dados precisam ocorrer de forma paralela. Enquanto a equipe técnica trabalha para compreender e conter o incidente, Privacidade e o Encarregado precisam ter visibilidade suficiente para avaliar seus possíveis impactos sobre os titulares e verificar se existem obrigações de comunicação.

O primeiro passo é a identificação e classificação inicial do evento.

Nem todo problema de segurança configura um incidente com dados pessoais. Uma indisponibilidade provocada por falha de hardware, por exemplo, pode não envolver qualquer comprometimento de dados. Da mesma forma, a mera existência de uma vulnerabilidade não constitui, por si só, um incidente. A situação muda quando essa vulnerabilidade é explorada ou quando há comprometimento efetivo da confidencialidade, integridade ou disponibilidade de informações pessoais. A ANPD distingue expressamente essas situações e estabelece que cabe ao controlador identificar, tratar e avaliar os riscos dos incidentes que afetem suas operações de tratamento.

A identificação inicial deve buscar compreender quais sistemas foram afetados, quando o evento começou, como foi detectado, quais contas ou ativos estão envolvidos e se existem indícios de acesso, alteração, destruição, perda, indisponibilidade ou divulgação não autorizada de dados pessoais.

Em paralelo, a organização precisa adotar medidas de contenção.

Dependendo da natureza do incidente, isso pode envolver isolamento de dispositivos, bloqueio de contas, revogação de sessões e credenciais, segmentação de redes, suspensão temporária de integrações, bloqueio de tráfego malicioso ou retirada controlada de determinados serviços do ar.

A contenção deve buscar impedir a continuidade ou ampliação do dano sem comprometer desnecessariamente as evidências necessárias à investigação.

Esse equilíbrio é particularmente importante porque uma resposta precipitada pode eliminar registros úteis para compreender o evento. Reiniciar servidores, apagar arquivos, formatar dispositivos ou alterar configurações antes da preservação adequada das evidências pode dificultar ou até inviabilizar a reconstrução posterior do incidente.

Por isso, a preservação de evidências deve integrar o plano de resposta.

Logs de autenticação, registros de firewall, eventos de endpoint, acessos administrativos, alertas de ferramentas de segurança, registros de banco de dados, e-mails, endereços IP, timestamps, imagens de sistemas e outros elementos técnicos podem ser relevantes para determinar a origem, extensão e duração do comprometimento.

A preservação também contribui para a responsabilização e prestação de contas. A organização precisa ser capaz de demonstrar não apenas que sofreu um incidente, mas também como o identificou, quais medidas adotou e quais elementos fundamentaram sua avaliação de risco.

Outro passo essencial é o dimensionamento dos dados afetados.

Para a área de Privacidade, saber que “um servidor foi comprometido” costuma ser insuficiente. É necessário traduzir o evento técnico para a linguagem do tratamento de dados.

Isso inclui identificar quais bases estavam presentes naquele ambiente, quais categorias de dados poderiam ter sido acessadas, se havia dados pessoais sensíveis, informações financeiras, credenciais de autenticação, dados protegidos por sigilo ou informações relacionadas a crianças, adolescentes ou outros grupos potencialmente vulneráveis.

A Resolução CD/ANPD nº 15/2024 considera esses elementos especialmente relevantes para avaliar a existência de risco ou dano relevante aos titulares. Também deve ser considerado se o incidente envolveu tratamento em larga escala.

O número de titulares potencialmente afetados também precisa ser estimado.

Em alguns incidentes, essa identificação é relativamente simples. Em outros, especialmente quando há comprometimento de grandes bancos de dados ou ambientes compartilhados, pode ser necessário cruzar registros técnicos, tabelas, logs e informações de negócio para determinar quais pessoas estavam presentes no conjunto afetado.

Essa análise não deve ser reduzida à quantidade de registros. O impacto sobre os titulares depende também da natureza das informações expostas e das consequências que podem decorrer do incidente.

Uma exposição envolvendo centenas de registros de dados altamente sensíveis pode representar risco maior do que um incidente envolvendo volume muito superior de informações pouco críticas. A avaliação precisa considerar o contexto.

A documentação técnica produzida pela TI é fundamental nesse processo.

É recomendável registrar a linha do tempo do incidente, os sistemas envolvidos, as evidências analisadas, as hipóteses consideradas, as medidas de contenção adotadas, as alterações realizadas no ambiente, as informações confirmadas e os pontos que ainda permanecem sob investigação.

Esse registro ajuda a evitar decisões baseadas apenas em memória ou informações fragmentadas e permite que diferentes áreas trabalhem sobre uma mesma base factual.

A Resolução CD/ANPD nº 15/2024 determina, inclusive, que os controladores mantenham registro dos incidentes de segurança envolvendo dados pessoais por pelo menos cinco anos. Esse registro deve abranger, entre outros elementos, a data do conhecimento do incidente, descrição geral das circunstâncias, natureza e categoria dos dados afetados, avaliação de risco, medidas adotadas e justificativas relacionadas à eventual não comunicação.

A comunicação interna também precisa possuir um fluxo previamente definido.

Em organizações maduras, não cabe à equipe técnica decidir informalmente quem será avisado após cada evento. O plano de resposta deve estabelecer critérios de escalonamento, responsáveis, canais de comunicação e procedimentos para acionamento de Segurança da Informação, Privacidade, DPO, Jurídico, gestão executiva e outras áreas necessárias.

Fornecedores também precisam estar inseridos nessa estrutura.

Quando o incidente ocorre na infraestrutura de um operador, é essencial que exista um fluxo rápido de comunicação ao controlador. A própria ANPD recomenda que as obrigações relacionadas à comunicação de incidentes entre controladores e operadores sejam previstas contratualmente, justamente para agilizar o tratamento do evento e reduzir seus possíveis impactos.

Esse ponto é particularmente importante porque o prazo regulatório do controlador não necessariamente acompanha o tempo que o fornecedor deseja utilizar para concluir sua própria investigação.

A Resolução CD/ANPD nº 15/2024 estabelece que o controlador deve comunicar à ANPD os incidentes que possam acarretar risco ou dano relevante aos titulares no prazo de três dias úteis contado do conhecimento de que o evento afetou dados pessoais, ressalvada a existência de prazo específico em outra legislação. A comunicação aos titulares segue, em regra, o mesmo prazo.

Por isso, esperar a conclusão absoluta da investigação técnica pode não ser compatível com o prazo regulatório.

A própria regulamentação reconhece que nem todas as informações estarão necessariamente disponíveis nesse primeiro momento e permite, em determinadas circunstâncias, que a comunicação à ANPD seja realizada de forma preliminar e posteriormente complementada.

Isso reforça a necessidade de integração rápida entre TI e DPO.

A função da TI é fornecer elementos técnicos confiáveis sobre o incidente. Já a avaliação sobre risco aos titulares, incidência das obrigações de comunicação, conteúdo das notificações e outras consequências jurídicas deve ser construída com a participação das áreas responsáveis pela proteção de dados.

Algumas informações técnicas se tornam especialmente relevantes nessa interação: natureza do evento, período de exposição, origem provável, sistemas afetados, possibilidade de exfiltração, volume de dados, categorias de informações presentes, quantidade estimada de titulares, controles existentes antes do incidente e medidas implementadas posteriormente.

Esses elementos dialogam diretamente com as informações que a ANPD exige na comunicação do incidente, que incluem natureza e categoria dos dados afetados, número de titulares envolvidos, medidas técnicas e de segurança adotadas, riscos relacionados ao incidente e possíveis impactos aos titulares.

Depois da contenção e da avaliação inicial, o processo não termina.

A organização deve avançar para erradicação da causa, recuperação segura dos serviços e análise posterior do incidente. Isso pode envolver correção de vulnerabilidades, alteração de credenciais, atualização de sistemas, revisão de permissões, restauração de ambientes, implementação de controles adicionais e monitoramento reforçado.

Também é importante conduzir uma análise de causa raiz e registrar as lições aprendidas.

Um incidente frequentemente revela falhas que não estavam restritas ao ponto técnico em que ocorreu. Pode evidenciar ausência de MFA, privilégios excessivos, logs insuficientes, sistemas desatualizados, fornecedores sem controles adequados, falta de segmentação, processos de backup frágeis ou deficiências no próprio fluxo de resposta.

Por isso, a documentação posterior deve alimentar a melhoria contínua dos controles.

O ponto mais relevante, portanto, é que a resposta a incidentes precisa existir antes do incidente.

Planos, responsáveis, canais de comunicação, critérios de severidade, procedimentos de preservação de evidências, inventários de sistemas, contatos de fornecedores e fluxos de acionamento do DPO devem ser definidos previamente e, idealmente, testados por meio de exercícios ou simulações.

Quando essa estrutura não existe, as primeiras horas de um incidente tendem a ser consumidas descobrindo quem deve ser chamado, quais informações precisam ser levantadas e quem possui autoridade para tomar decisões.

Sob a perspectiva da LGPD, responder bem a um incidente não significa apenas restaurar o sistema. Significa compreender rapidamente se dados pessoais foram afetados, reduzir os riscos aos titulares, preservar evidências, documentar as decisões e disponibilizar às áreas responsáveis informações suficientes para cumprir as obrigações regulatórias dentro dos prazos aplicáveis.

Por isso, a relação entre TI e DPO não deve começar quando o incidente já aconteceu. Ela precisa estar incorporada ao plano de resposta da organização, de forma que contenção técnica, investigação e avaliação de proteção de dados ocorram de maneira coordenada desde os primeiros momentos do evento.

Como estruturar a LGPD dentro da TI sem travar a operação

Integrar a LGPD à rotina da Tecnologia da Informação não significa criar uma etapa jurídica para cada alteração de sistema, exigir aprovação do DPO para toda decisão técnica ou acrescentar controles que tornem a operação mais lenta. Uma estrutura madura funciona justamente no sentido contrário: transforma requisitos de proteção de dados em critérios previamente definidos, incorporados aos processos tecnológicos que a organização já executa.

Quando isso acontece, segurança e privacidade deixam de depender de intervenções pontuais. A criação de usuários já segue critérios de acesso; novos sistemas passam por avaliação antes da contratação; ambientes de desenvolvimento possuem regras próprias; backups seguem ciclos definidos; incidentes acionam fluxos previamente estabelecidos; e mudanças relevantes na infraestrutura são analisadas considerando também seus impactos sobre os dados pessoais.

O primeiro passo para essa estrutura é conhecer o ambiente tecnológico que sustenta o tratamento dos dados. A organização precisa possuir visibilidade sobre sistemas, aplicações, bancos de dados, servidores, serviços em nuvem, integrações, dispositivos, repositórios e fornecedores que armazenam ou permitem acesso a informações pessoais. Esse mapeamento tecnológico complementa o inventário das operações de tratamento, porque permite relacionar a finalidade de negócio à infraestrutura que efetivamente executa aquela atividade.

Um registro de tratamento pode indicar, por exemplo, que Recursos Humanos utiliza dados pessoais para administração da folha de pagamento. Para a TI, é necessário compreender onde essas informações estão: qual sistema é utilizado, onde o banco de dados está hospedado, quais integrações existem, quem possui acesso, quais cópias são geradas, quais fornecedores participam da operação e como as informações são protegidas.

Essa conexão entre processo de negócio e infraestrutura tecnológica evita que a governança da LGPD permaneça restrita a documentos que não refletem a arquitetura real da organização.

O mapeamento também contribui para a classificação da informação. Nem todos os sistemas e dados possuem o mesmo nível de criticidade. Uma base que contém dados pessoais sensíveis, informações financeiras ou credenciais de autenticação pode demandar controles diferentes daqueles aplicáveis a um diretório contendo apenas informações corporativas de contato.

Classificar as informações permite estabelecer níveis proporcionais de proteção e orientar decisões sobre acesso, criptografia, compartilhamento, monitoramento, backup, retenção e resposta a incidentes. Em vez de tentar aplicar indistintamente o controle mais rigoroso a todos os ambientes, a organização direciona suas medidas de acordo com o risco e a criticidade das informações efetivamente tratadas.

A gestão de identidades e acessos deve constituir outro eixo permanente dessa estrutura. A concessão de permissões precisa estar relacionada às funções desempenhadas, seguir o princípio do menor privilégio e possuir mecanismos para aprovação, alteração, revisão e revogação.

Isso exige olhar para o acesso como um ciclo de vida. Quando alguém ingressa na organização, recebe as permissões necessárias e, quando muda de função, seus privilégios devem ser reavaliados. Quando participa temporariamente de determinado projeto, acessos excepcionais precisam possuir duração compatível com essa necessidade. E, quando o vínculo termina, contas, sessões, credenciais e demais formas de autenticação devem ser revogadas tempestivamente.

Revisões periódicas são particularmente importantes para identificar o acúmulo de privilégios, contas inativas, acessos concedidos excepcionalmente e permissões que já não correspondem às funções atuais dos usuários. Contas administrativas e usuários privilegiados demandam controles ainda mais rigorosos, incluindo, conforme o risco, autenticação multifator, segregação de contas, monitoramento e soluções específicas de gestão de privilégios.

A governança dos logs precisa acompanhar essa estrutura. Os registros devem permitir que a organização identifique eventos relevantes, investigue incidentes e mantenha rastreabilidade sobre atividades críticas, mas sua coleta não deve ocorrer de maneira indiscriminada. É necessário definir quais eventos serão registrados, por quais sistemas, durante quanto tempo, quem poderá consultar essas informações e como sua integridade será preservada. Logs também podem conter dados pessoais e, portanto, precisam estar sujeitos aos mesmos princípios de finalidade, necessidade, segurança e retenção aplicáveis aos demais tratamentos.

A política de backups deve seguir lógica semelhante. Não basta determinar que determinada base seja copiada diariamente. É necessário estabelecer ciclos de retenção, localização das cópias, mecanismos de proteção, controle de acesso, criptografia quando pertinente, procedimentos de restauração e descarte.

Também deve existir uma definição sobre como exclusões e alterações realizadas no ambiente produtivo serão tratadas caso uma cópia anterior seja restaurada. Dessa forma, a continuidade do negócio não entra em conflito com as decisões já implementadas sobre o ciclo de vida dos dados.

Outro elemento indispensável é um processo estruturado de gestão de vulnerabilidades. Sistemas operacionais, bibliotecas, aplicações, dispositivos, equipamentos de rede e componentes de terceiros estão sujeitos ao surgimento contínuo de vulnerabilidades. A organização precisa possuir mecanismos para identificá-las, avaliar sua criticidade, priorizar correções e acompanhar sua resolução.

Isso pode envolver varreduras automatizadas, testes de segurança, gestão de patches, acompanhamento de vulnerabilidades conhecidas, atualização de componentes e tratamento de sistemas legados. O processo deve considerar não apenas a severidade técnica da vulnerabilidade, mas também o contexto do ativo afetado. Uma falha existente em um sistema exposto à internet e que concentra grandes volumes de dados pessoais pode demandar prioridade diferente daquela existente em um ambiente isolado e de baixa criticidade.

A gestão de vulnerabilidades também precisa dialogar com o desenvolvimento e a gestão de mudanças. Novos sistemas, funcionalidades e integrações não deveriam chegar à produção para somente depois serem avaliados sob a perspectiva de segurança e proteção de dados.

Requisitos como autenticação, controle de acesso, registros de atividades, criptografia, minimização de dados, retenção e segregação de ambientes podem ser considerados ainda nas etapas de desenho e desenvolvimento. Essa abordagem reduz a necessidade de adaptações posteriores e aproxima a rotina da TI da lógica de proteção de dados desde a concepção e por padrão.

Os ambientes de desenvolvimento, teste e homologação também devem possuir regras claras. Dados sintéticos ou anonimizados podem ser adotados como padrão sempre que forem suficientes para a atividade. Quando houver necessidade excepcional de utilizar dados pessoais reais, a organização deve limitar o conjunto utilizado, restringir acessos, aplicar técnicas de mascaramento ou pseudonimização quando pertinentes e estabelecer prazo para descarte das cópias.

A gestão dos fornecedores de tecnologia constitui outro componente dessa estrutura. A contratação de cloud, SaaS, hospedagem, suporte, desenvolvimento ou outras soluções que envolvam dados pessoais deve ser precedida por uma avaliação proporcional aos riscos da atividade.

A Due Diligence pode verificar aspectos relacionados à privacidade e à segurança, incluindo controles de acesso, criptografia, gestão de incidentes, backups, continuidade de negócio, suboperadores, localização dos dados, transferências internacionais e procedimentos de exclusão ou devolução das informações ao término da relação.

Mais importante do que simplesmente encaminhar um questionário ao fornecedor é avaliar as respostas e, quando necessário, solicitar evidências capazes de demonstrar a implementação dos controles declarados.

As lacunas identificadas devem resultar em recomendações, planos de ação ou decisões formais de aceitação de risco, de acordo com a governança da organização. Fornecedores mais críticos também podem demandar reavaliações periódicas, especialmente quando houver mudanças relevantes no serviço, na infraestrutura, nas categorias de dados tratadas ou nos terceiros envolvidos na operação.

A resposta a incidentes precisa integrar todos esses elementos. TI e Segurança da Informação devem possuir procedimentos para identificação, contenção, preservação de evidências, investigação, recuperação e documentação. Ao mesmo tempo, o fluxo precisa prever o acionamento tempestivo de Privacidade, DPO, Jurídico e demais áreas responsáveis quando houver possibilidade de envolvimento de dados pessoais.

Essa integração deve existir antes do incidente. Responsáveis, canais de comunicação, critérios de severidade, informações mínimas a serem levantadas e fluxos com fornecedores precisam estar previamente definidos. Exercícios e simulações também podem ser utilizados para identificar lacunas no procedimento antes que uma situação real exija sua utilização.

Para que tudo isso funcione sem transformar a LGPD em uma barreira operacional, a organização precisa evitar um modelo em que toda decisão dependa de análise individual da área de Privacidade.

O caminho mais eficiente é transformar requisitos recorrentes em padrões. Perfis de acesso podem ser previamente definidos. Sistemas podem seguir requisitos mínimos de segurança. Contratações podem ser submetidas a critérios de risco. Ambientes não produtivos podem possuir regras padronizadas. Backups podem seguir políticas de retenção. Projetos podem utilizar checklists de privacidade e segurança. Situações excepcionais, de maior risco ou que não se enquadrem nos padrões estabelecidos são então direcionadas para análise específica.

Essa lógica permite que a governança acompanhe a velocidade da operação. Também é importante estabelecer responsabilidades claras. A LGPD não deve transformar o DPO em administrador de sistemas, assim como a existência de uma equipe de Segurança da Informação não transfere a ela todas as decisões relacionadas ao tratamento de dados pessoais.

As áreas de negócio precisam compreender por que utilizam os dados e quais informações são necessárias para suas atividades. A TI conhece a infraestrutura, as integrações e as possibilidades técnicas. Segurança da Informação avalia ameaças, vulnerabilidades e controles. Privacidade e Jurídico contribuem para a interpretação dos requisitos aplicáveis. O Encarregado exerce suas atribuições de orientação e interlocução. A gestão executiva, por sua vez, precisa assegurar recursos, definir responsabilidades e decidir sobre riscos que excedam os limites estabelecidos pela organização.

A efetividade depende justamente da integração entre essas competências. Reuniões periódicas, canais de escalonamento, processos de gestão de mudanças e fóruns de governança podem aproximar essas áreas sem exigir que todas participem de todas as decisões. O objetivo é identificar quais eventos precisam acionar Privacidade ou Segurança e quais podem seguir procedimentos previamente aprovados.

Indicadores também podem contribuir para avaliar se os controles estão funcionando na prática. Quantidade de contas inativas, percentual de usuários com MFA, tempo médio para revogação de acessos após desligamentos, vulnerabilidades críticas pendentes, fornecedores aguardando adequações, incidentes identificados, restaurações de backup testadas e revisões de privilégios concluídas são exemplos de métricas que podem demonstrar a maturidade operacional.

Mais do que produzir políticas, a organização precisa conseguir demonstrar que essas políticas se transformaram em controles efetivamente executados.

Esse aspecto está diretamente relacionado ao princípio da responsabilização e prestação de contas previsto na LGPD. Procedimentos documentados, registros de aprovação, evidências de revisão, relatórios de testes, históricos de chamados, resultados de Due Diligence e registros de incidentes ajudam a demonstrar que as medidas de proteção não existem apenas formalmente.

Por fim, a estrutura precisa ser revisada à medida que a própria tecnologia evolui. Novas aplicações SaaS são contratadas, integrações são criadas, ambientes migram para a nuvem, equipes mudam, sistemas são substituídos e novos riscos surgem. Um programa de proteção de dados que permaneça estático tende a deixar de refletir rapidamente a realidade tecnológica da organização.

Estruturar a LGPD dentro da TI, portanto, não significa criar uma camada adicional de burocracia sobre a tecnologia. Significa incorporar proteção de dados aos processos que já sustentam a operação: arquitetura, acessos, desenvolvimento, fornecedores, backups, monitoramento, vulnerabilidades, mudanças e resposta a incidentes.

Quando esses controles são definidos antecipadamente e aplicados de forma proporcional ao risco, privacidade deixa de ser uma validação realizada no final do processo e passa a integrar a própria forma como a tecnologia é administrada.

A maturidade está justamente nesse ponto: a organização não precisa escolher entre velocidade operacional e proteção de dados. Precisa construir processos nos quais operar de forma segura, rastreável e proporcional seja o caminho normal da TI, e não uma exceção criada apenas quando o DPO é acionado.

Conclusão

A Tecnologia da Informação ocupa uma posição central na proteção de dados pessoais porque grande parte das operações de tratamento depende, direta ou indiretamente, da infraestrutura que ela administra. Sistemas, bancos de dados, credenciais, logs, backups, dispositivos, integrações, ambientes em nuvem e ferramentas corporativas constituem a camada técnica sobre a qual os dados circulam, permanecem armazenados e são acessados diariamente.

Por essa razão, tratar a LGPD dentro da TI apenas como uma questão de cibersegurança é insuficiente.

A segurança da informação é uma parte fundamental da conformidade, especialmente diante da obrigação de adoção de medidas técnicas e administrativas capazes de proteger os dados pessoais. No entanto, proteção de dados envolve um conjunto mais amplo de decisões relacionadas à finalidade, necessidade, acesso, retenção, compartilhamento, transparência, responsabilização e ciclo de vida das informações.

Uma infraestrutura pode estar protegida contra ataques externos e, ainda assim, apresentar problemas relevantes de proteção de dados. Isso ocorre quando informações permanecem armazenadas por períodos superiores ao necessário, usuários acumulam privilégios incompatíveis com suas funções, ambientes de teste recebem bases produtivas sem controles adequados, ex-colaboradores continuam com acessos ativos, fornecedores são contratados sem avaliação suficiente ou dados coletados para uma finalidade passam a ser utilizados para outra sem a devida análise.

Da mesma forma, possuir ferramentas avançadas não representa, isoladamente, maturidade. Firewalls, soluções de monitoramento, criptografia, DLP, EDR, sistemas de IAM e outras tecnologias são importantes, mas sua efetividade depende da governança existente ao redor delas. Controles precisam possuir finalidade definida, responsáveis, critérios de utilização, processos de revisão e evidências capazes de demonstrar que permanecem funcionando ao longo do tempo.

É justamente nesse ponto que a LGPD deixa de ser uma discussão exclusivamente jurídica e passa a integrar a própria arquitetura operacional da organização.

A TI precisa conhecer não apenas os sistemas que administra, mas também compreender quais dados pessoais circulam por eles, quais áreas dependem dessas informações, quais terceiros participam do tratamento, onde existem cópias, quais acessos são necessários e como cada informação deixa de existir quando sua finalidade chega ao fim.

Ao mesmo tempo, não cabe à Tecnologia da Informação definir isoladamente todos esses critérios. A proteção de dados exige integração permanente entre TI, Segurança da Informação, Privacidade, Encarregado, Jurídico e áreas de negócio. É essa interação que permite transformar necessidades jurídicas e organizacionais em controles técnicos viáveis e, no sentido inverso, traduzir características e limitações tecnológicas em decisões adequadas de governança.

A maturidade de um programa de privacidade também pode ser percebida pela capacidade de responder a questões aparentemente simples: quais dados pessoais estão sob responsabilidade técnica da TI? Onde estão armazenados? Quem possui acesso? Quais cópias existem? Por quanto tempo permanecem disponíveis? O que acontece com esses acessos quando alguém muda de função ou deixa a organização? Quais fornecedores conseguem alcançar essas informações? E quais evidências demonstram que os controles definidos realmente estão sendo executados?

Responder a essas perguntas exige mais do que políticas formalmente aprovadas. Exige inventários atualizados, processos de acesso, registros, testes, revisões, avaliações de fornecedores, procedimentos de descarte, planos de resposta a incidentes e uma governança capaz de acompanhar continuamente as transformações da infraestrutura tecnológica.

No fim, a relação entre TI e LGPD não consiste apenas em proteger um banco de dados contra invasões. Consiste em garantir que os dados pessoais sejam tratados de forma controlada durante todo o tempo em que permanecem sob a infraestrutura da organização, desde sua entrada nos sistemas até sua efetiva eliminação.

Segurança da informação protege a infraestrutura e as informações contra riscos. Proteção de dados acrescenta uma pergunta essencial a essa equação: mesmo quando conseguimos tratar determinado dado de forma segura, ainda precisamos tratá-lo, daquela forma, por aquela pessoa e durante todo aquele período?

É dessa combinação entre segurança, necessidade, governança e responsabilização que surge uma atuação de TI verdadeiramente alinhada à LGPD.

Referências
https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia_agentes_de_tratamento_e_encarregado___defeso_eleitoral.pdf
https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia-vf.pdf
https://www.gov.br/anpd/pt-br/documentos-e-publicacoes/glossario-anpd
https://www.gov.br/anpd/pt-br/canais_atendimento/agente-de-tratamento/comunicado-de-incidente-de-seguranca-cis
https://www.gov.br/anpd/pt-br/acesso-a-informacao/institucional/atos-normativos/regulamentacoes_anpd/resolucao-cd-anpd-no-15-de-24-de-abril-de-2024

https://www.gov.br/anpd/pt-br/acesso-a-informacao/institucional/atos-normativos/regulamentacoes_anpd/resolucao-cd-anpd-no-19-de-23-de-agosto-de-2024
https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes
https://devguide.owasp.org/en/04-design/02-web-app-checklist/01-secure-by-default/

O Papel da DPO Expert na Governança e Prevenção de Riscos

A DPO Expert apoia organizações na estruturação de uma abordagem completa de privacidade e proteção de dados aplicada às atividades de Tecnologia da Informação, considerando todo o ciclo de vida dos dados pessoais e a infraestrutura tecnológica que sustenta seu tratamento. Essa atuação envolve o mapeamento de sistemas, aplicações, bancos de dados, integrações e ambientes em nuvem e sua adequada vinculação ao ROPA, a gestão de identidades, acessos e privilégios, a governança de logs e backups, a definição de processos de offboarding, a avaliação de fornecedores de tecnologia, soluções SaaS e serviços de cloud, o estabelecimento de regras para utilização de dados pessoais em ambientes de desenvolvimento, teste e homologação, bem como a estruturação de processos de gestão de vulnerabilidades e resposta a incidentes. A atuação também contempla a avaliação e o aprimoramento das medidas técnicas e administrativas de segurança, buscando integrar TI, Segurança da Informação, Privacidade, Encarregado e áreas de negócio para que a proteção de dados seja incorporada à própria gestão da infraestrutura tecnológica e aos processos operacionais da organização.

Dessa forma, a DPO Expert não apenas viabiliza a conformidade com a LGPD, mas contribui diretamente para o aumento da maturidade organizacional em proteção de dados, posicionando a empresa de forma mais segura, competitiva e preparada para os desafios do ambiente digital.

Clique aqui e veja como a DPO Expert pode proteger sua empresa.

Siga nossa página no LinkedIn