Um levantamento de 2026 da Orchid Security, especializada em segurança de identidade, analisou o acesso de organizações de vários setores e chegou a um número difícil de justificar: 40% das contas encontradas pertenciam a pessoas que já não trabalham mais ali. Em alguns ambientes, esse índice passava de 60%.
O motivo não é falta de ferramenta. É que a lista de quem pode entrar em quê é, na maioria das empresas, um exercício que acontece uma vez por ano, feito à mão, e que já nasce desatualizado no dia seguinte. Cargo muda, projeto termina, fornecedor sai — e o acesso continua.
Para quem decide sobre segurança e conformidade, o dado que interessa não é só "existe conta sobrando". É que ninguém sabe, no momento em que pergunta, quantas dessas contas ainda conseguem fazer alguma coisa.
O tamanho do problema, com números
A mesma pesquisa da Orchid Security encontrou algo pior do que a simples sobra de contas: 22% das contas órfãs ainda tinham privilégio elevado — ou seja, quem já saiu continuava com poder de administrador em algum sistema. E uma fatia relevante das contas de máquina e de integração — as que um sistema usa para conversar com outro — nunca passava pelo controle central de identidade da empresa, segundo o mesmo relatório.
Esse tipo de conta é o ponto cego mais comum. Uma conta de aplicação é criada para um projeto, uma integração pontual, um teste. O projeto termina, a pessoa que criou a conta muda de time ou sai da empresa, e a credencial fica — geralmente configurada para nunca expirar, porque expirar "quebraria alguma coisa" que ninguém tem certeza do que é.
O risco de credencial válida não é hipotético. Segundo o relatório de investigação de violações de dados de 2026 da Verizon, divulgado pela Descope, o abuso de credenciais aparece em 39% das violações analisadas, em algum ponto da cadeia do ataque, e 28% dos casos tinham credenciais entre os dados comprometidos. Uma credencial válida, de uma conta que ninguém está olhando, é exatamente o tipo de porta que esse tipo de ataque procura.
Por que a revisão anual não resolve
A resposta mais comum ainda é a planilha: uma vez por ano, alguém de TI exporta a lista de usuários de cada sistema, manda para os gestores confirmarem por e-mail, e espera a resposta. Esse processo tem três problemas ao mesmo tempo.
O primeiro é a defasagem. Entre uma revisão e a próxima, pessoas mudam de função, contratos terminam, projetos são encerrados — e o acesso que fazia sentido em janeiro pode não fazer sentido nenhum em julho. O segundo é a cobertura. Contas de aplicação, de integração e de projetos encerrados raramente aparecem nessas planilhas, porque não têm um "dono" humano óbvio para confirmar ou negar.
O terceiro problema é o que auditores de conformidade chamam de falta de rastro. Não basta a revisão ter acontecido: é preciso mostrar quem revisou, quando e contra qual sistema real — não contra uma cópia da lista de meses atrás. Segundo material sobre auditoria de acesso para a norma ISO 42001, que trata da gestão de sistemas de inteligência artificial, o auditor verifica se as revisões acontecem em um ritmo constante e se cada uma mostra o revisor, a data e a decisão tomada — uma revisão sem essa trilha não conta como evidência, mesmo que tenha sido feita.
O que muda quando a revisão é contínua
A norma ISO 27001, no controle sobre direitos de acesso, pede revisão em intervalos definidos, com privilégio administrativo revisado com mais frequência que o acesso comum — a prática recomendada costuma ser trimestral para acesso privilegiado e anual para o resto. A exigência não é nova; o que muda é como ela é cumprida.
Quando o acesso é revisado continuamente, e não uma vez por ano, três coisas deixam de depender de planilha. A primeira é a origem do acesso: se ele nasce ligado à identidade corporativa da pessoa, sair da empresa já significa perder o acesso, sem esperar a próxima rodada de revisão. A segunda é a granularidade: revisar "a pessoa X tem acesso ao sistema Y" é mais fácil de fazer errado do que revisar "a pessoa X tem a função Z dentro do sistema Y" — e é essa segunda pergunta que uma revisão de verdade precisa responder.
A terceira é a conta de aplicação. Ferramentas criadas para um projeto, uma integração ou um teste específico precisam de dono, de prazo e de motivo registrado — do contrário, viram exatamente o tipo de conta órfã que o levantamento da Orchid Security encontrou aos milhares.
O que precisa existir na prática
Um ambiente de acesso bem revisado se sustenta em mecanismos concretos, não em boa vontade de quem lembra de avisar o TI.
Entrada pela identidade corporativa. O acesso à IA e às ferramentas conectadas usa o mesmo cadastro da rede da empresa — o mesmo crachá, por assim dizer. Quando alguém sai do diretório da empresa, o acesso cai junto, no mesmo instante, sem depender de uma segunda ação manual.
Acesso conforme o papel, não a pessoa. Cada função dentro de cada sistema é liberada de forma específica, para quem exerce aquele papel — não uma permissão ampla "porque foi mais rápido assim".
Prazo e dono para acesso temporário. Toda conta criada para um projeto, uma integração ou um teste tem um responsável e uma data prevista de encerramento, em vez de ficar ativa por padrão até alguém perceber.
Trilha de auditoria de quem concedeu o quê. Toda concessão, mudança ou remoção de acesso fica registrada com quem tomou a decisão e quando — o tipo de evidência que uma auditoria de conformidade pede e que uma planilha de e-mail não entrega.
É assim que a Skyller foi desenhada: identidade vinda do diretório da empresa, acesso conforme o papel de cada pessoa e trilha de auditoria por padrão, não como etapa extra de fim de ano.
O ganho para quem responde pela conformidade
Para quem prepara uma auditoria — de segurança da informação, de controles financeiros ou, cada vez mais, de uso de inteligência artificial — o valor prático de um acesso revisado continuamente aparece na hora de responder à pergunta mais simples e mais temida: "quem tem acesso a isso, e por quê?"
Normas como a que trata de controles financeiros exigem que a revisão de acesso siga o mesmo ritmo do relatório trimestral, com alguém independente confirmando que cada acesso continua fazendo sentido — e com prova de que o que foi sinalizado para remoção foi de fato removido, não apenas registrado num chamado. Um ambiente onde essa trilha já existe por construção transforma a preparação de auditoria de um projeto de semanas em uma consulta de minutos.
Há também um ganho menos falado: tempo da própria equipe de TI. Cada hora gasta perseguindo gestores para confirmar planilha de acesso é uma hora que não vai para o que realmente protege a empresa.
Um roteiro para a próxima revisão de acesso
Antes de abrir mais uma planilha anual, vale levar estas perguntas para a conversa com segurança da informação e conformidade:
- Quantas contas ativas hoje pertencem a quem já não trabalha na empresa? Se a resposta exige um levantamento manual, o número real provavelmente é maior do que qualquer um imagina.
- As contas de aplicação e de projetos encerrados têm dono e prazo registrados? Se não têm, elas não aparecem em nenhuma revisão — e são exatamente as que mais se acumulam.
- A última revisão de acesso mostra quem revisou, quando e contra qual sistema? Uma revisão sem essa trilha não resiste a uma auditoria, mesmo que tenha sido feita de boa-fé.
- O acesso está ligado à identidade corporativa ou a cadastros soltos por sistema? Sem essa ligação, desligar alguém da empresa não desliga automaticamente o acesso que essa pessoa acumulou pelo caminho.
