Fusões e aquisições podem reunir organizações com arquiteturas, sistemas, bases de dados, controles de segurança e práticas operacionais muito diferentes. Em empresas intensivas em tecnologia, essas condições influenciam a continuidade dos serviços, a possibilidade de integração, a dependência de fornecedores e os recursos necessários para manter ou transformar o ambiente após a transação.
A due diligence tecnológica consiste no exame estruturado desses elementos por métodos técnicos e fontes rastreáveis. Seu propósito é descrever o ambiente observado, identificar dependências e limitações, testar informações relevantes e produzir parâmetros que possam ser utilizados pelas equipes responsáveis pela operação.
O trabalho não determina se uma aquisição deve ou não ocorrer, não fixa o preço da transação e não realiza valuation societário. Também não substitui due diligence jurídica, contábil, tributária ou trabalhista. Quando houver repercussões econômicas associadas às condições tecnológicas, elas podem ser examinadas em parcela própria do trabalho, com premissas e responsabilidades metodológicas distintas.
O objeto da due diligence tecnológica
O objeto pode compreender sistemas corporativos, aplicações desenvolvidas internamente, infraestrutura local, serviços em nuvem, redes, ambientes industriais conectados, dispositivos, bancos de dados, integrações, APIs, ferramentas de desenvolvimento e processos de operação e suporte.
A análise também pode abranger segurança cibernética, continuidade, recuperação de desastres, gestão de identidades, dependências de terceiros, licenciamento, qualidade de software, governança de dados e capacidade de integração entre os ambientes tecnológicos envolvidos.
Nem todos esses componentes precisam integrar todo trabalho. O escopo decorre das questões formuladas, da natureza da organização, do estágio da transação, do acesso permitido e da relevância técnica dos sistemas para a continuidade das operações.
Delimitação das questões técnicas
O planejamento pode decompor o objeto em perguntas verificáveis. Em lugar de uma questão ampla sobre a “qualidade da tecnologia”, podem ser formuladas questões sobre capacidade, disponibilidade, obsolescência, segurança, documentação, escalabilidade, cobertura de testes, dependência de pessoas ou fornecedores e possibilidade técnica de integração.
Uma matriz de escopo pode relacionar cada questão às fontes previstas, aos procedimentos aplicáveis, aos ambientes envolvidos, aos responsáveis pelo exame e às limitações conhecidas. Essa organização reduz o risco de conclusões genéricas e permite acompanhar quais perguntas foram efetivamente respondidas.
O marco temporal também deve ser definido. Ambientes tecnológicos mudam continuamente, e uma configuração observada em determinada data pode não representar períodos anteriores ou posteriores. Alterações ocorridas durante o trabalho precisam ser registradas quando afetarem os resultados.
Fontes de evidência
As fontes podem incluir diagramas de arquitetura, inventários, configurações, catálogos de serviços, bases de gestão de ativos, relatórios de disponibilidade, registros de chamados, planos de continuidade, resultados de testes de recuperação, políticas internas e documentação de projetos.
Outras fontes possíveis são repositórios de código, históricos de versões, pipelines de integração e entrega, catálogos de APIs, documentação de bancos de dados, listas de componentes de software, registros de vulnerabilidades, logs, alertas, relatórios de incidentes e evidências de correções executadas.
Contratos, anexos, propostas e documentos de licenciamento podem fornecer especificações, níveis de serviço e requisitos técnicos. Nesse uso, funcionam como fontes documentais. O exame técnico pode comparar os requisitos expressamente registrados com os componentes encontrados, sem interpretar juridicamente as cláusulas, definir sua validade ou concluir sobre direitos e obrigações.
Informações obtidas em entrevistas e demonstrações técnicas também podem ser relevantes, mas devem ser distinguidas de evidências diretamente observadas. Sempre que possível, declarações são confrontadas com registros, configurações ou documentos contemporâneos aos fatos examinados.
Organização, integridade e rastreabilidade
A documentação recebida pode apresentar versões divergentes, lacunas, duplicidades ou referências a ambientes já modificados. Por isso, o trabalho pode começar pela catalogação das fontes, identificação de versões, registro de datas, normalização de formatos e análise de consistência entre documentos.
Arquivos relevantes podem ser preservados com identificação de origem e cálculo de funções de resumo criptográfico quando pertinente. Transformações realizadas para leitura, correlação ou análise precisam ser documentadas, especialmente quando envolvem extração de logs, conversão de bases ou tratamento automatizado.
A rastreabilidade liga cada achado às fontes e aos procedimentos que o sustentam. Ela também permite separar condições observadas, informações declaradas, estimativas e inferências. Essa distinção é essencial em trabalhos submetidos a revisão técnica ou destinados a contextos litigiosos.
Mapeamento da arquitetura e das dependências
O mapeamento técnico procura compreender como aplicações, infraestrutura, dados, identidades, redes e serviços externos se relacionam. Diagramas existentes podem ser comparados com configurações e inventários para identificar componentes não documentados ou representações desatualizadas.
Dependências críticas podem ocorrer entre sistemas, fornecedores, bibliotecas, profissionais, credenciais, chaves, ambientes ou localidades. O exame pode registrar a função de cada dependência, sua evidência, o grau de concentração e os mecanismos técnicos disponíveis para substituição, contingência ou recuperação.
A análise não pressupõe que arquiteturas centralizadas, distribuídas, locais ou em nuvem sejam melhores por natureza. Cada configuração é examinada segundo requisitos, escala, carga, disponibilidade, segurança, custo e condições operacionais documentadas.
Infraestrutura, capacidade e desempenho
O exame da infraestrutura pode abranger servidores, armazenamento, redes, serviços gerenciados, recursos em nuvem, ambientes de contingência e ferramentas de observabilidade. Os procedimentos podem considerar inventários, métricas, capacidade contratada, utilização, disponibilidade, latência e crescimento histórico.
Testes diretos nem sempre são possíveis ou apropriados durante uma transação. Quando o acesso é restrito, podem ser examinadas séries de monitoramento, relatórios técnicos, configurações exportadas e amostras de registros. A conclusão deve indicar o grau de acesso e as fontes utilizadas.
Capacidade ociosa ou utilização elevada não constitui, isoladamente, falha. A interpretação depende de picos, sazonalidade, requisitos de recuperação, margens de segurança e projeções de demanda. Esses elementos devem ser explicitados antes de qualquer inferência sobre dimensionamento.
Sistemas, software e processos de desenvolvimento
Aplicações podem ser examinadas sob aspectos como arquitetura, modularidade, manutenibilidade, confiabilidade, segurança, compatibilidade, desempenho e capacidade de evolução. Modelos de qualidade, como os da família SQuaRE, podem fornecer vocabulário e critérios, desde que adaptados ao objeto e às evidências disponíveis.
Repositórios e processos de desenvolvimento podem revelar histórico de alterações, frequência de entregas, concentração de contribuições, cobertura de testes, tratamento de vulnerabilidades e dependência de componentes externos. Análises estáticas ou dinâmicas podem ser utilizadas quando o acesso, o ambiente e o escopo permitirem.
Métricas de código não devem ser interpretadas isoladamente. Complexidade, cobertura, quantidade de defeitos e velocidade de entrega dependem da linguagem, da arquitetura, do estágio do produto e dos procedimentos adotados. Os parâmetros de comparação e suas limitações precisam acompanhar os resultados.
Cibersegurança e controles técnicos de proteção de dados
A análise de segurança pode considerar gestão de identidades, privilégios, segmentação, proteção de endpoints, registros, monitoramento, tratamento de vulnerabilidades, resposta a incidentes, backups e recuperação. Estruturas como o NIST Cybersecurity Framework e a família ISO/IEC 27000 podem auxiliar na organização dos procedimentos.
O uso de uma referência não significa certificação ou conclusão automática de conformidade. É necessário indicar quais critérios foram utilizados, quais evidências estavam disponíveis e quais controles foram efetivamente examinados.
Quando o objeto envolver dados pessoais ou informações reguladas, o trabalho técnico pode examinar controles de acesso, criptografia, retenção, segregação, rastreabilidade, descarte e mecanismos de resposta. Não compete a essa parcela declarar conformidade jurídica, interpretar normas ou definir consequências legais.
Histórico de incidentes e vulnerabilidades
Registros de incidentes podem ser examinados para reconstruir eventos, identificar sistemas afetados, compreender a resposta adotada e verificar a existência de evidências de correção. Logs, alertas, chamados, imagens forenses, relatórios técnicos e registros de mudanças podem integrar essa análise.
A ausência de incidentes registrados não demonstra, por si só, ausência de incidentes. O resultado depende da cobertura de monitoramento, do período de retenção, da qualidade dos registros e dos critérios utilizados para classificar eventos.
Vulnerabilidades também precisam ser contextualizadas. Pontuação, explorabilidade, exposição, controles compensatórios, criticidade do ativo e estado da correção podem produzir avaliações diferentes. O relatório deve indicar o critério aplicado, sem transformar uma lista de ferramentas em conclusão autossuficiente.
Dados, migração e interoperabilidade
O exame dos dados pode considerar estrutura, completude, consistência, duplicidade, procedência, documentação, controles de acesso e mecanismos de integração. Amostragens e testes podem ser utilizados para caracterizar as bases sem pressupor que todas as ocorrências tenham sido examinadas.
Em cenários de integração, podem ser analisadas diferenças entre modelos de dados, identificadores, taxonomias, formatos, interfaces e regras de transformação. Essas diferenças ajudam a dimensionar tecnicamente a migração, mas não determinam, isoladamente, seu custo ou prazo.
Resultados de testes, volumes, taxas de erro, dependências e requisitos de preservação podem fornecer parâmetros para modelos econômicos de transição. Dados incompletos ou não comparáveis devem ser tratados como limitações, e não substituídos por presunções silenciosas.
Ativos de TI, licenças e componentes de terceiros
O inventário técnico pode relacionar hardware, software, serviços em nuvem, domínios, certificados, repositórios, bibliotecas, APIs, bancos de dados e outros recursos necessários à operação. Referências de gestão de ativos de TI podem auxiliar na estruturação do levantamento.
Documentos e registros podem ser examinados para identificar versões, quantidades, usuários, datas, fornecedores e condições técnicas informadas. Componentes de código aberto e bibliotecas de terceiros podem ser relacionados a repositórios, versões e listas de materiais de software quando disponíveis.
Esse exame descreve ativos, dependências e documentos encontrados. Não emite conclusão jurídica sobre titularidade, validade de licenças, cessão de direitos, infração de propriedade intelectual ou consequências contratuais.
Continuidade e capacidade de recuperação
Planos de continuidade e recuperação podem ser confrontados com a arquitetura observada, os recursos disponíveis e os resultados de testes realizados. O exame pode considerar objetivos de recuperação, replicação, cópias de segurança, dependência de localidades, procedimentos de restauração e pessoas necessárias à retomada.
A existência de um documento não demonstra que a recuperação seja tecnicamente viável. Da mesma forma, a ausência de teste recente não permite presumir que a recuperação falhará. O relatório deve distinguir desenho, implementação, evidência de teste e resultado efetivamente observado.
Maturidade e referências comparativas
Modelos de maturidade podem organizar práticas em níveis ou dimensões e facilitar comparações internas. Seu uso exige identificar a versão do modelo, os critérios, as fontes e o método de pontuação.
Uma classificação de maturidade não equivale a julgamento absoluto sobre a organização. Estruturas distintas podem ser adequadas a portes, setores, ciclos de produto e exposições diferentes. O resultado deve ser interpretado no contexto do objeto e não como selo de qualidade.
Referências externas e benchmarks também requerem comparabilidade quanto a setor, escala, tecnologia, período e método de coleta. Diferenças não controladas reduzem o alcance das conclusões.
Interface com TCO e análise econômica
Constatações tecnológicas podem gerar parâmetros para o exame econômico de aquisição, operação, integração, migração, correção, expansão ou desativação. O custo total de propriedade, ou TCO, pode organizar esses componentes ao longo de um horizonte definido.
A parcela tecnológica identifica componentes, volumes, dependências, eventos, capacidade e procedimentos necessários. A parcela econômica estrutura preços, fluxos, períodos, cenários e testes de sensibilidade. Essa divisão preserva a responsabilidade metodológica de cada especialidade.
Os modelos podem distinguir valores documentados, estimativas e projeções. Também podem comparar cenários, como manutenção temporária de ambientes separados, integração gradual, migração ou substituição de componentes. Nenhuma dessas alternativas deve ser tratada como universalmente preferível.
Estimativas de integração ou correção não constituem passivos contábeis nem contingências reconhecidas. Tampouco determinam o valor da empresa, dos ativos ou da transação. São resultados econômicos condicionados ao perímetro, ao horizonte, às fontes e às premissas explicitadas.
Integração multidisciplinar
A due diligence tecnológica pode integrar um procedimento mais amplo conduzido por diferentes especialidades. A integração ocorre pela troca controlada de parâmetros e pela identificação da origem de cada conclusão, sem que uma disciplina assuma atribuições pertencentes a outra.
Uma matriz de interface pode registrar o achado tecnológico, a evidência correspondente, a possível variável econômica associada, as premissas adicionais necessárias e o responsável por cada análise. Questões jurídicas ou contábeis identificadas como dependências são encaminhadas às respectivas equipes, sem antecipação de conclusões.
Essa estrutura permite que o relatório técnico seja utilizado por empresas, consultores, investidores, financiadores e bancas jurídicas como uma das fontes de informação da operação, preservada a autonomia das decisões e das demais análises profissionais.
Apresentação dos achados
Os achados podem ser organizados por domínio, sistema, evidência, período ou questão técnica. Para cada item, convém indicar a condição observada, a fonte, o procedimento utilizado, a repercussão técnica possível, as limitações e os elementos necessários para confirmação adicional.
Classificações de criticidade podem auxiliar a leitura, desde que os critérios sejam previamente definidos. Probabilidade, impacto, urgência e esforço de tratamento representam dimensões distintas e não devem ser condensados em uma única nota sem explicação.
O relatório pode conter mapas de arquitetura, inventários, matrizes de dependência, linhas do tempo, tabelas de vulnerabilidades, resultados de testes e anexos metodológicos. Informações sensíveis devem ser tratadas de acordo com o regime de acesso estabelecido para o trabalho.
Limitações do exame
Due diligences frequentemente são realizadas em prazo reduzido, com acesso controlado e sem possibilidade de testes intrusivos. Ambientes críticos podem não admitir coleta direta, e determinadas informações podem estar sujeitas a restrições de confidencialidade ou disponibilidade.
Outras limitações incluem inventários incompletos, retenção curta de logs, ausência de documentação histórica, mudanças ocorridas durante o exame, amostras reduzidas e dependência de informações declaradas.
As limitações precisam ser associadas aos achados afetados. Quando não houver evidência suficiente, o relatório pode registrar a indeterminação, os procedimentos realizados e os elementos adicionais necessários, em vez de substituir dados ausentes por conclusões categóricas.
Produto técnico e alcance das conclusões
O produto pode assumir a forma de relatório, parecer técnico ou documento pericial, conforme a finalidade e o escopo. A metodologia, as fontes, as premissas, os resultados e as limitações devem permanecer identificáveis.
As conclusões descrevem condições tecnológicas e, quando previsto, parâmetros econômicos associados. Não compreendem recomendação de investimento, decisão sobre compra ou venda, valuation societário, avaliação contábil de ativos ou passivos, auditoria de demonstrações financeiras, interpretação contratual, certificação de conformidade legal ou aconselhamento jurídico.
Proposta técnica
A proposta para uma due diligence tecnológica pode delimitar os ambientes, as questões técnicas, o período, as fontes previstas, os acessos necessários, os procedimentos permitidos, as especialidades envolvidas e os produtos esperados.
Nota editorial: Este artigo possui caráter técnico e informativo. Os métodos apresentados não constituem indicação de procedimento universalmente preferível. Sua seleção depende do objeto, das questões formuladas, das evidências disponíveis, das restrições de acesso e das habilitações profissionais aplicáveis. O texto não oferece serviços contábeis ou jurídicos nem substitui as equipes responsáveis por essas áreas ou pela decisão sobre a transação.
Referências técnicas indicativas
- NIST. The NIST Cybersecurity Framework 2.0.
- ISO. ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection — Information security management systems — Requirements.
- ISO. ISO/IEC 27002:2022. Information security, cybersecurity and privacy protection — Information security controls.
- ISO. ISO/IEC 25010:2023. Systems and software engineering — Product quality model.
- ISO. ISO/IEC 19770-1:2017. Information technology — IT asset management systems — Requirements, com a alteração vigente.
- ISO. ISO/IEC/IEEE 15288:2023. Systems and software engineering — System life cycle processes.
Proposta Técnica
Solicitar informações ou proposta técnica sobre este serviço.