Due Diligence de TI: Guia para Empresas

Aprenda a conduzir due diligence de TI em aquisições e investimentos, avaliando sistemas, segurança, dados, contratos, custos, dependências e integração.

O que é due diligence de TI?

Due diligence de TI é a investigação estruturada dos ativos, dependências, custos e riscos tecnológicos de uma empresa antes de uma aquisição, investimento ou integração relevante. Ela ajuda quem decide a entender o que sustenta a operação, quais premissas ainda não foram comprovadas e quanto trabalho pode existir depois da transação.

O resultado não deveria ser um selo genérico de “aprovado”. Uma boa diligência conecta evidências técnicas às decisões do negócio: o sistema comporta o crescimento previsto? Há licenças transferíveis? Dados e integrações podem ser separados? A continuidade depende de uma única pessoa? Existem compromissos de nuvem, segurança ou privacidade que alteram custo, prazo ou estrutura do negócio?

Esse trabalho complementa, mas não substitui, análises jurídicas, financeiras, contábeis ou trabalhistas. Achados sobre contrato, propriedade intelectual ou proteção de dados devem ser avaliados pelos especialistas responsáveis. A função da frente tecnológica é tornar o cenário verificável e mostrar suas consequências operacionais.

Due diligence de TI não é um assessment comum

Um assessment de TI normalmente procura melhorar uma organização que continuará operando sob o mesmo contexto. Na diligência de uma transação, há prazo restrito, acesso controlado a informações e uma decisão concreta: comprar, investir, ajustar condições, planejar separação ou preparar integração.

O escopo também muda conforme a tese do negócio. Se o valor está na base de clientes, a continuidade dos canais, dos dados e dos contratos tecnológicos pode ser central. Se está em um produto digital, arquitetura, código, equipe, propriedade intelectual e capacidade de entrega ganham peso. Em uma compra de ativos, é preciso identificar o que realmente pode ser transferido. Em uma fusão, compatibilidade e duplicidade entre ambientes importam mais.

Por isso, a primeira pergunta não é “qual checklist usar?”, mas “qual hipótese da transação depende de tecnologia?”. A consultoria de TI pode organizar essa investigação, enquanto a assessoria jurídica e financeira trata seus respectivos domínios.

Defina a tese, o perímetro e o nível de acesso

Comece documentando o objetivo do negócio, as entidades incluídas, países, unidades, produtos, dados e serviços compartilhados. Defina também o horizonte: decisão prévia, preparação para o primeiro dia, plano de 100 dias ou integração completa. Sem esse perímetro, a equipe pode aprofundar um repositório pouco relevante e ignorar uma integração que paralisa o faturamento.

Acesso deve seguir necessidade e estágio da transação. Informações competitivamente sensíveis, dados pessoais e detalhes de vulnerabilidades exigem regras próprias, registro de acesso e coordenação com responsáveis jurídicos e de segurança. Quando o material não pode ser compartilhado diretamente, considere evidência intermediária: demonstração controlada, relatório independente, amostra anonimizada ou confirmação contratual.

Monte um pedido inicial de documentos enxuto e explique a decisão atendida por cada item. Solicitar “toda a documentação de TI” produz volume, não clareza. Um inventário de aplicações com dono, finalidade, criticidade, custo e fornecedor costuma ser mais útil que dezenas de apresentações sem vínculo com a operação.

O que avaliar em uma due diligence de TI

Aplicações e arquitetura

Mapeie sistemas críticos, integrações, dependências externas e fluxos que sustentam receita, atendimento, entrega e obrigações regulatórias. Verifique tecnologias, versões, capacidade de suporte, ambientes, documentação e pontos únicos de falha. Em software próprio, avalie modularidade, testes, processo de liberação, observabilidade e dívida técnica que tenha impacto demonstrável.

Evite usar quantidade de linhas de código ou cobertura de testes como nota isolada. Essas métricas podem orientar perguntas, mas não mostram sozinhas se o produto é sustentável. Evidências mais fortes incluem frequência e segurança das mudanças, incidentes, tempo de recuperação, dependências sem manutenção e a facilidade de alterar capacidades importantes.

Infraestrutura, nuvem e continuidade

Identifique contas de nuvem, datacenters, redes, dispositivos, identidades privilegiadas, backups e mecanismos de recuperação. Compare faturas e compromissos contratuais com a arquitetura apresentada. Teste se planos de continuidade têm evidência recente; um documento sem exercício não prova que a restauração funciona.

Calcule custos atuais e custos de transição separadamente. Duplicar ambientes durante uma migração, manter licenças até o término contratual ou reconstruir conectividade pode criar uma curva temporária maior que o custo operacional informado. Registre premissas, moedas, períodos e itens excluídos em vez de apresentar um número excessivamente preciso.

Segurança e cadeia de fornecedores

A avaliação deve combinar governança, controles, incidentes conhecidos, vulnerabilidades abertas e dependências. O guia de due diligence do NIST SP 1326, publicado em julho de 2026, organiza a análise de fornecedores de tecnologia em temas como proveniência, resiliência, práticas fundamentais de segurança e camadas da cadeia. Ele não é um roteiro específico para fusões e aquisições, mas oferece critérios úteis para investigar produtos e terceiros críticos.

Verifique gestão de identidades, autenticação administrativa, inventário, correções, resposta a incidentes, testes e monitoramento. Para serviços essenciais, avalie subcontratados e concentração. O NIST SP 1305 recomenda definir requisitos de fornecedores e manter uma capacidade de gestão de riscos da cadeia, útil tanto antes quanto depois da transação.

Não confunda ausência de relato com ausência de incidente. Peça evidências compatíveis com o risco: registros de exercícios, relatórios, planos de correção e histórico de eventos relevantes. Descobertas críticas precisam de canal restrito e tratamento coordenado; não devem circular em planilhas amplamente acessíveis.

Dados, privacidade e separação

Mapeie categorias de dados, finalidades, locais de armazenamento, retenção, transferências, responsáveis e sistemas consumidores. Pergunte quais conjuntos pertencem ao perímetro da transação e se podem ser tecnicamente separados. Bases compartilhadas entre empresas, ambientes ou clientes podem transformar uma migração aparentemente simples em projeto de engenharia e governança.

A LGPD se aplica ao tratamento de dados pessoais nos meios digitais e deve entrar na análise com apoio jurídico e de privacidade. A diligência técnica pode verificar controles, fluxos e capacidade de atender decisões, mas não deve emitir conclusão jurídica improvisada.

Analise também qualidade, linhagem, chaves de integração, duplicidades e dependência de relatórios manuais. Quando dados são parte do valor esperado, confirme se podem ser utilizados para a finalidade pretendida e se a arquitetura permite extração, migração e reconciliação.

Software, componentes e propriedade intelectual

Para produtos próprios, identifique repositórios, histórico, autores, processos de revisão, artefatos de build e componentes de terceiros. Confirme com a área jurídica contratos de trabalho, cessões, licenças e restrições de uso. A equipe técnica deve fornecer inventário e evidência; a interpretação dos direitos pertence ao especialista jurídico.

Uma SBOM pode ajudar a identificar componentes e licenças, mas não é prova completa de segurança ou titularidade. O projeto SPDX mantém uma especificação para representar uma Software Bill of Materials e uma lista padronizada de licenças. Verifique cobertura, atualização e correspondência entre a SBOM e o software entregue, em vez de apenas confirmar que existe um arquivo.

O Software Acquisition Guide da CISA inclui perguntas sobre proveniência de componentes, SBOM e práticas do fornecedor. Embora tenha sido preparado para consumidores governamentais, suas perguntas podem inspirar verificações proporcionais em aquisições de software.

Pessoas, operação e conhecimento

Mapeie papéis críticos, cobertura de suporte, responsabilidades, rotatividade e concentração de conhecimento. “A equipe conhece o sistema” não é suficiente: observe quem aprova mudanças, responde incidentes, administra contas e mantém integrações. Se uma única pessoa concentra acesso e conhecimento, o risco afeta continuidade e plano de retenção.

Avalie capacidade, não apenas organograma. Compare backlog, incidentes, ritmo de entrega e compromissos assumidos. Entenda quais serviços são terceirizados e quais contratos dependem de pessoas específicas. A análise deve respeitar confidencialidade e legislação trabalhista; seu objetivo é planejar continuidade, não fazer avaliação individual sem contexto.

Evidências que sustentam as conclusões

Classifique cada conclusão como confirmada, parcialmente confirmada ou não verificada. Vincule-a à evidência: contrato, configuração demonstrada, relatório, repositório, fatura, teste de restauração ou entrevista corroborada. Uma política escrita demonstra intenção; um registro de execução demonstra prática. Os dois são úteis, mas não equivalentes.

Amostragem é legítima quando o prazo é curto, desde que seja declarada. Escolha itens por criticidade e risco, não apenas por conveniência. Se cinco serviços foram examinados em um universo de cinquenta, não generalize silenciosamente. Registre limitações, dependências e perguntas pendentes no relatório.

Organize achados em uma estrutura simples:

fato observado e fonte;
impacto provável para a tese;
cenário em que o risco se materializa;
opção de tratamento;
responsável pela decisão;
prazo: antes da assinatura, antes do fechamento, primeiro dia ou pós-fechamento.

Essa estrutura é mais útil que uma lista extensa de “boas práticas” desconectadas do negócio.

Como priorizar riscos sem falsa precisão

Use escalas qualitativas com critérios claros. Impacto pode considerar interrupção, perda financeira, exposição de dados, obrigação contratual e inviabilidade de integração. Probabilidade precisa refletir evidência disponível, não um percentual inventado. Destaque incerteza quando o acesso foi insuficiente.

Separe quatro tipos de resposta: condição para avançar, proteção contratual a discutir, ação anterior ao fechamento e ação posterior. A decisão sobre preço, garantias ou cláusulas não é técnica; a equipe de TI fornece insumos verificáveis para quem tem essa responsabilidade.

Evite somar todos os achados em uma única nota. Um ambiente pode ter boa operação diária e, ainda assim, conter um risco crítico de licença ou separação. Mantenha visíveis os itens que podem alterar a tese, o prazo ou o custo da transação.

Planeje o primeiro dia e os primeiros 100 dias

A diligência deve alimentar uma transição executável. Para o primeiro dia, priorize continuidade de acessos, pagamentos, atendimento, conectividade, suporte, comunicação de incidentes e responsabilidades. Não faça integração de redes ou identidades sem avaliar segurança; conectividade apressada pode ampliar o impacto de uma conta comprometida.

Para os primeiros 100 dias, transforme achados em frentes com dependências, donos, estimativas e critérios de conclusão. Inclua correções urgentes, contratos a renegociar, inventário a completar, integrações temporárias e decisões de arquitetura. A governança e compliance ajuda a manter riscos e obrigações visíveis durante essa mudança.

Defina também o que permanecerá separado. Nem toda aquisição exige unificação imediata de ferramentas ou infraestrutura. A opção mais segura pode ser manter fronteiras até que dados, identidades e controles estejam prontos.

Checklist de due diligence de TI

A tese da transação e o perímetro tecnológico estão documentados?
Sistemas críticos, integrações, dados e fornecedores têm donos identificados?
Custos recorrentes e custos de transição foram separados?
Backups e recuperação têm evidência de teste?
Incidentes, vulnerabilidades e planos de correção foram examinados?
Contratos, licenças e componentes de software foram encaminhados à análise jurídica?
Dados do perímetro podem ser separados, migrados e reconciliados?
Dependências de pessoas e terceiros têm plano de continuidade?
Cada achado informa evidência, limitação, impacto e prazo?
Há plano para o primeiro dia e para os primeiros 100 dias?

Conclusão

A due diligence de TI reduz incerteza quando conecta tecnologia à tese da transação. O trabalho começa pelo perímetro, busca evidências proporcionais ao risco e termina em decisões e planos de transição — não em uma pontuação abstrata. Sistemas, dados, contratos, segurança, custos e pessoas precisam ser analisados como partes da mesma operação.

Se sua empresa precisa estruturar uma avaliação independente antes de uma aquisição ou investimento, a Mattos Tech Solutions pode conversar sobre o escopo técnico, respeitando as fronteiras das análises jurídica e financeira.