Pesquisar conteúdos

Encontre uma trilha ou aula pelo assunto.

Experimente pesquisar por “governança”, “ITIL” ou “planejamento”.

Conteúdo da trilha

Compliance em TI

Entenda como identificar requisitos, tratar riscos, implementar controles e produzir evidências verificáveis.
Governança7 de 1013 min de leitura

O que é Compliance em TI

Compliance em Tecnologia da Informação é a capacidade de identificar os requisitos aplicáveis ao uso da tecnologia, traduzi-los em responsabilidades e controles, acompanhar sua execução e demonstrar conformidade por meio de evidências. O objetivo não é apenas evitar penalidades: é tornar o uso de sistemas, dados e serviços coerente com obrigações e compromissos assumidos pela organização.

Os requisitos variam conforme país, setor, atividade, dados tratados, contratos e políticas internas. Uma instituição financeira, um hospital, uma loja virtual e um órgão público podem usar tecnologias semelhantes, mas enfrentar obrigações diferentes.

De onde vêm os requisitos

Um programa de conformidade começa por um inventário de fontes, e não por uma lista genérica de controles. Os requisitos podem vir de:

  • leis e regulamentos: proteção de dados, registros, consumidor, setor financeiro, saúde ou administração pública;
  • autoridades e órgãos reguladores: resoluções, instruções, decisões e orientações dentro de suas competências;
  • contratos: confidencialidade, localização de dados, níveis de serviço, auditoria e notificação de incidentes;
  • normas e certificações adotadas: compromissos assumidos voluntariamente ou exigidos por clientes;
  • políticas internas: regras aprovadas pela própria organização;
  • decisões de governança: limites de risco, princípios e requisitos para o uso de tecnologia.
Mapa de seis fontes de requisitos convergindo para um inventário de obrigações de tecnologia
A origem define autoridade, escopo e consequência. O inventário precisa registrar a fonte específica, e não apenas o tema geral.

Uma prática importante é manter, para cada requisito, a referência exata, a interpretação aprovada, o escopo, o responsável, a data de vigência e o gatilho de revisão. “Cumprir a LGPD” é amplo demais para orientar uma equipe; um requisito precisa ser decomposto sem perder o vínculo com o texto oficial.

A Lei Geral de Proteção de Dados Pessoais oferece um exemplo brasileiro. Entre seus princípios está a responsabilização e prestação de contas, definida como demonstração de medidas eficazes capazes de comprovar observância e cumprimento das normas de proteção de dados. A lei também prevê medidas técnicas e administrativas de segurança. Isso ilustra como tecnologia, processo, responsabilidade e evidência se conectam, mas a LGPD é apenas uma das possíveis fontes de requisitos.

Do requisito ao risco

Copiar uma obrigação diretamente para uma política raramente basta. Primeiro é necessário entender:

  1. a quais processos, sistemas, dados, pessoas e fornecedores ela se aplica;
  2. quais eventos poderiam causar descumprimento;
  3. quais impactos atingiriam titulares, usuários, organização e outras partes;
  4. quais controles já existem e onde há lacunas;
  5. quem possui autoridade para aceitar, reduzir, transferir ou evitar o risco.

Risco ajuda a tornar o controle proporcional. A Controladoria-Geral da União, em sua orientação sobre gestão de riscos, destaca controles internos proporcionais ao risco e atentos à relação custo-benefício. Embora a referência tenha contexto público, o princípio evita dois extremos: controle insuficiente para uma exposição relevante e burocracia excessiva para um risco pequeno.

Como desenhar um controle

Controle é uma medida que modifica um risco ou ajuda a cumprir um requisito. Ele pode envolver pessoas, processo ou tecnologia e precisa ser descrito de forma executável.

Um controle bem definido responde:

  • objetivo: qual risco ou requisito ele atende?
  • atividade: o que será feito e com quais critérios?
  • responsável: quem executa e quem supervisiona?
  • frequência ou evento: quando ocorre?
  • escopo: quais sistemas, dados ou unidades estão incluídos?
  • evidência: qual registro demonstra a execução e o resultado?
  • exceção: como desvios são aprovados, limitados e revisados?
  • avaliação: como verificar desenho e funcionamento?

Controles também podem ser classificados pelo momento em que atuam:

  • preventivos: procuram impedir o evento, como segregação de funções ou validação antes de uma mudança;
  • detectivos: identificam ocorrência ou desvio, como alertas, conciliações e revisão de logs;
  • corretivos: restauram condições ou reduzem impactos, como revogação emergencial, correção e recuperação;
  • diretivos: orientam comportamento, como políticas, padrões e treinamento.

Essas categorias são complementares. Uma política sem mecanismo de prevenção e detecção pode não mudar a prática; um bloqueio automático sem procedimento de exceção pode interromper uma atividade legítima.

Fluxo circular que relaciona requisito, risco, controle, operação, evidência, avaliação e melhoria
Conformidade é um ciclo. A avaliação da evidência pode revelar falhas no desenho, na execução ou no próprio entendimento do requisito.

Evidência não é documento acumulado

Evidência é informação que permite verificar uma afirmação. Ela pode incluir registro de aprovação, configuração exportada, log, chamado, relatório de teste, ata, confirmação de treinamento ou resultado de monitoramento. Seu formato depende do controle e do que precisa ser demonstrado.

Uma evidência útil deve ser:

  • relevante: demonstra o requisito ou controle específico;
  • confiável: tem origem e integridade conhecidas;
  • completa: cobre escopo e período esperados;
  • rastreável: conecta fonte, responsável, execução e resultado;
  • atual: corresponde ao período avaliado;
  • protegida: possui acesso, retenção e descarte adequados.

Uma captura de tela isolada pode mostrar uma configuração em um instante, mas talvez não demonstre que o controle funcionou durante todo o período. Da mesma forma, possuir uma política aprovada não prova que as atividades previstas foram executadas.

O NIST SP 800-53 e sua publicação de avaliação, SP 800-53A, distinguem seleção de controles e procedimentos para avaliar se eles estão implementados corretamente, operam como esperado e produzem o resultado desejado. Embora focadas em segurança e privacidade, essas referências reforçam uma ideia aplicável ao compliance: desenho, implementação e efetividade são perguntas diferentes.

Pilha de evidências ligando requisito e controle a política, configuração, registro de execução, teste e resultado
Evidências complementares contam uma história verificável: o controle foi definido, configurado, executado, testado e gerou o resultado esperado.

Um exemplo completo: revisão de acessos

Considere um sistema que contém informações sensíveis e possui requisito interno de revisão trimestral de acessos.

Requisito e risco

Somente pessoas autorizadas devem manter permissões compatíveis com suas funções. O risco inclui acesso indevido por mudança de cargo, desligamento, acumulação de privilégios ou conta esquecida.

Controle

A cada trimestre, o proprietário do sistema recebe uma relação completa de usuários e permissões, compara com funções atuais, solicita correções e aprova formalmente o resultado. A equipe técnica executa as alterações; exceções recebem justificativa, prazo e aprovação.

Evidências

Podem ser necessários o relatório extraído diretamente do sistema, a identificação do período e escopo, as decisões do proprietário, os chamados de alteração, a confirmação das correções e a lista de exceções em aberto.

Avaliação

O avaliador verifica se todas as contas entraram na revisão, se o responsável possuía conhecimento e autoridade, se correções foram tempestivas e se exceções permanecem justificadas. Uma assinatura sem análise real não demonstra efetividade.

Responsabilidades e independência

Compliance em TI é transversal. Áreas jurídicas e de compliance ajudam a interpretar obrigações; responsáveis de negócio conhecem processos e impactos; TI implementa e opera parte dos controles; segurança e privacidade oferecem especialização; auditoria avalia com independência conforme seu mandato.

Uma separação saudável evita que a mesma pessoa desenhe, execute, aprove e avalie o próprio controle sem revisão. Isso não significa duplicar equipes. Em organizações menores, supervisão proporcional, revisão por pares ou validação periódica independente podem reduzir conflitos.

A Governança de TI define autoridades e supervisão. O COBIT pode ajudar a conectar objetivos, processos e componentes. Nenhum deles substitui a identificação e interpretação do requisito aplicável.

Monitoramento e mudança

Conformidade não é um projeto com data de encerramento. Requisitos, serviços, fornecedores, sistemas e riscos mudam. Um processo de monitoramento deve acompanhar:

  • novas leis, regulamentos, decisões e orientações;
  • alterações contratuais e compromissos assumidos;
  • mudanças em sistemas, dados, integrações e fornecedores;
  • falhas, incidentes, reclamações e exceções;
  • resultados de testes, auditorias e avaliações;
  • controles redundantes, ineficazes ou desproporcionais.

Quando um requisito muda, é necessário analisar impacto, atualizar interpretação, controles, documentação, treinamento e evidências esperadas. A simples alteração da política deixa uma lacuna se sistemas e rotinas continuarem iguais.

O guia de segurança da informação da ANPD para agentes de tratamento de pequeno porte ilustra a proporcionalidade ao recomendar medidas de segurança considerando realidade e limitações desses agentes. Ainda assim, flexibilização não significa ausência de responsabilidade: a Resolução CD/ANPD nº 2/2022 mantém obrigações e exige medidas administrativas e técnicas essenciais conforme risco à privacidade e realidade do agente.

Erros comuns

  • adotar uma lista pronta sem confirmar quais requisitos se aplicam;
  • tratar compliance como responsabilidade exclusiva de TI ou do jurídico;
  • confundir política publicada com controle em funcionamento;
  • guardar evidências sem integridade, contexto ou prazo de retenção;
  • testar apenas existência, sem avaliar efetividade;
  • ignorar fornecedores e serviços em nuvem no escopo;
  • manter controles depois que requisito, risco ou processo mudou;
  • usar certificação ou framework como prova automática de conformidade legal.

O que você deve guardar

Compliance em TI transforma fontes de obrigação em práticas verificáveis. O caminho passa por identificar requisitos, compreender escopo e risco, desenhar controles proporcionais, operar responsabilidades, produzir evidências confiáveis e revisar continuamente mudanças e resultados.

O próximo módulo muda o foco da direção e controle para a entrega contínua de serviços. A primeira aula apresentará o ITIL.

Referências