Vou te contar uma cena que se repete toda semana no mercado de software. O Ricardo, CEO de uma software house de 40 pessoas, está em negociação avançada com um grande player. Banco, seguradora, multinacional, empresa de saúde. O contrato vale R$ 800 mil, talvez R$ 2 milhões. O produto é bom. O preço é justo. O time está pronto.

Aí chega a fase de due diligence. O jurídico do grande player manda um questionário de 120 perguntas sobre segurança da informação. O Ricardo responde o que dá. O time de segurança do grande player analisa. Devolvem com uma frase educada e definitiva: "Infelizmente, neste momento, não podemos seguir com a contratação."

O contrato não foi para o concorrente porque o produto era melhor. Foi porque o concorrente tinha ISO 27001. E o Ricardo não.

Se essa cena te parece familiar, você não está sozinho. Due diligence de segurança virou o principal filtro de grandes players na hora de escolher fornecedor de software. E a ISO 27001 é a resposta que eles esperam receber.

Este artigo explica o que é due diligence de segurança, o que exatamente eles avaliam, como a ISO 27001 responde cada ponto e o que sua software house precisa fazer para passar nesse filtro. Sem teoria. Sem enrolação. Com o que eu vejo na prática.

O que é due diligence de segurança (e por que todo grande player faz)

Due diligence é uma investigação. Quando um grande player contrata um fornecedor crítico, ele não olha só preço e qualidade do produto. Ele investiga se esse fornecedor vai trazer risco para o negócio dele. É uma auditoria pré-contrato.

No caso de software houses, a due diligence foca em segurança da informação e privacidade. Porque o grande player sabe que, se ele integrar seu software ao ambiente dele, a segurança dele passa a depender da sua. Um vazamento no seu sistema vira um vazamento no sistema dele. Uma falha sua vira uma multa LGPD dele.

A regra do mercado: o grande player não contrata fornecedor de software sem due diligence de segurança. Se ele não te investigou, ele não confia em você. E se ele não confia, ele não assina.

Isso vale para bancos, fintechs, seguradoras, empresas de saúde, varejo grande, indústria, governo. Qualquer setor regulado ou que lide com dados sensíveis faz due diligence de fornecedor. E essa lista só cresce, porque a LGPD e as normas setoriais estão apertando a responsabilidade sobre toda a cadeia.

O que eles avaliam na due diligence

Aqui está o que ninguém te conta: o questionário de due diligence não é aleatório. Ele segue um padrão. A maioria das empresas usa frameworks reconhecidos (SIG, CSA STAR, questionários setoriais), e as perguntas caem sempre nos mesmos blocos.

Depois de acompanhar dezenas desses processos, os pontos que mais travam software houses são:

1. Política de segurança da informação documentada

A primeira pergunta é quase sempre: "Vocês têm uma política de segurança da informação formal, aprovada pela diretoria e comunicada a todos os colaboradores?"

Se a resposta é "a gente se organiza" ou "cada um faz o que acha certo", você já começou mal. Política documentada é o mínimo. É a prova de que segurança não é improviso na sua empresa.

2. Análise de risco formal

"Vocês fazem análise de risco de segurança antes de aceitar contratos grandes? Como vocês identificam e tratam riscos?"

Software houses em crescimento tendem a pular essa etapa. Aceitam contrato, entregam, resolvem os problemas no caminho. Funciona até o dia em que o grande player pergunta como você gerencia risco. Se você não tem processo formal, a resposta é "não gerenciamos formalmente". E isso é eliminatório.

3. Controle de acesso documentado

"Como vocês controlam acesso a ambientes de produção? Quem tem acesso ao quê? Como vocês revisam esses acessos?"

Aqui o grande player quer saber se você tem princípio do menor privilégio, revisão periódica de acessos, segregação de funções e controle de acesso de administradores. Se seu dev sênior tem acesso a tudo, inclusive produção, sem registro, você tem um problema.

4. Criptografia e proteção de dados

"Vocês criptografam dados em trânsito e em repouso? Quais algoritmos? Como gerenciam chaves?"

Essa pergunta é técnica, mas o avaliador não quer detalhes de implementação. Ele quer saber se existe política, se é seguida e se é auditável. Se você usa HTTPS mas não tem política de criptografia documentada, a resposta fica fraca.

5. Gestão de incidentes

"Vocês têm processo de resposta a incidentes de segurança? Já tiveram algum? Como foi tratado?"

Toda empresa tem ou vai ter incidente. O que diferencia uma empresa madura de uma amadora é ter processo de resposta. Se você não tem, o grande player entende que, no dia em que acontecer um incidente, você vai demorar para reagir. E o prejuízo vai cair na cadeia dele.

6. Backup e recuperação de desastres

"Vocês fazem backup? Testam a recuperação? Qual o RPO e RTO?"

Fazer backup todo mundo faz. Testar a recuperação é outra história. O grande player quer saber se você já testou, quanto tempo leva para recuperar e se tem plano de continuidade. Se você não sabe responder RPO e RTO, você não tem plano de recuperação. Você tem esperança.

7. Treinamento de segurança

"Vocês treinam colaboradores em segurança da informação? Com que frequência?"

O maior vetor de incidente ainda é o humano. Phishing, engenharia social, erro de configuração. O grande player quer saber se você investe em conscientização. Se a resposta é "mandamos um e-mail uma vez por ano", não conta.

8. Segurança no desenvolvimento

"Vocês seguem práticas de desenvolvimento seguro? Fazem revisão de código, testes de penetração, análise de vulnerabilidade em dependências?"

Para software house, essa é específica. O grande player quer saber se segurança está no ciclo de desenvolvimento, não só na infraestrutura. Se você não faz code review com foco em segurança, não testa vulnerabilidades em bibliotecas de terceiros e não tem pipeline seguro, você é risco.

9. Due diligence com seus próprios fornecedores

"Vocês avaliam a segurança dos seus fornecedores? Cloud, SaaS que vocês usam, parceiros?"

Essa é a pergunta que pega muita gente. O grande player quer saber se você estende a mesma exigência para sua cadeia. Se você usa AWS, Azure, Google, mas não tem contrato com cláusulas de segurança, não avalia a segurança deles, você tem um ponto fraco.

10. Certificações e conformidade

"Vocês têm certificação ISO 27001, SOC 2 ou equivalente? Se não, qual o plano para obter?"

Aqui está o ponto. Ter certificação não é obrigatório em todos os casos. Mas é o atalho mais reconhecido. Se você tem ISO 27001, o questionário de due diligence encolhe de 120 perguntas para 20. Porque o certificado prova que um terceiro independente já auditou seu sistema. Se você não tem, o grande player vai auditar você. E isso é mais lento, mais caro e mais invasivo.

Como a ISO 27001 responde cada ponto da due diligence

Agora a parte que importa. A ISO 27001 não é um checklist. É um sistema de gestão. Mas quando você implementa a ISO 27001 de verdade, cada ponto da due diligence tem resposta documentada, processo definido e evidência auditável.

Ponto da due diligence Como a ISO 27001 responde
Política de segurança Requisito 5.2 da norma. Política formal, aprovada pela direção, comunicada e revisada.
Análise de risco Cláusula 6.1.2. Metodologia formal de análise de risco, com critérios de aceitação definidos.
Controle de acesso Anexo A.5 e A.9. Controles de identificação, autenticação, privilégios e revisão.
Criptografia Anexo A.10. Controles de proteção criptográfica com política definida.
Gestão de incidentes Anexo A.16. Processo de reporte, avaliação, resposta e lições aprendidas.
Backup e recuperação Anexo A.12 e A.17. Backup com política definida e plano de continuidade de negócio.
Treinamento Cláusula 7.2 e 7.3. Competência e conscientização obrigatórias para todos.
Segurança no desenvolvimento Anexo A.14. Requisitos de segurança na aquisição, desenvolvimento e manutenção.
Due diligence com fornecedores Anexo A.15. Gestão de segurança na relação com fornecedores.
Certificação O próprio certificado ISO 27001, emitido por organismo acreditado.

Perceba o padrão: não é que a ISO 27001 "cobre" cada ponto. É que ela obriga você a ter processo, documentação e evidência para cada um. E é exatamente isso que o grande player quer ver.

O atalho da ISO 27001: com o certificado, você não responde 120 perguntas do zero. Você mostra o certificado, entrega o escopo e a declaração de aplicabilidade (SoA), e responde só o que é específico do contrato. O tempo de due diligence cai de semanas para dias.

O que acontece quando você não tem ISO 27001 na due diligence

Vou ser direto sobre o que acontece, porque muita gente acha que "a gente resolve na conversa". Não resolve. O que acontece na prática:

Cenário 1: você perde o contrato

O mais comum. O grande player tem política interna que exige certificação de fornecedores críticos. Sem ISO 27001 (ou equivalente), você não passa no filtro. Não é negociação. É política.

Cenário 2: você ganha, mas com condições pesadas

O grande player aceita, mas impõe cláusulas específicas, auditorias trimestrais às suas custas, multas contratuais pesadas em caso de incidente e direito de rescisão se você não cumprir certos marcos de segurança. O contrato sai mais caro e mais arriscado do que seria com certificação.

Cenário 3: você ganha, mas demora meses

O grande player aceita fazer a due diligence sem certificado, mas o processo leva 3 a 6 meses. Porque ele vai auditar você no lugar de confiar num terceiro. Enquanto isso, o concorrente certificado fecha outros contratos. Você perde tempo e oportunidade.

Cenário 4: você nem chega a saber que perdeu

O mais silencioso e mais comum. Você participa da RFP, responde o questionário, manda a proposta. Nunca recebe feedback. O contrato foi para o concorrente certificado, e você nem sabe que o motivo foi segurança. Você acha que foi preço. Não foi.

O custo invisível: o maior prejuízo de não ter ISO 27001 não é o contrato que você perdeu. É o contrato que você nem sabe que perdeu. Porque ninguém te conta.

Quanto tempo leva para estar pronto para due diligence

Aqui tem uma confusão comum. Muita gente acha que implementar ISO 27001 leva 18 meses. Não precisa. Com método certo e foco em software house, o prazo realista é de 9 meses para estar certificado.

Dividindo em fases:

Depois disso, você tem o certificado. E a partir do certificado, toda due diligence vira conversa rápida, não investigação profunda.

Se você ainda não tem nada, 9 meses é o prazo realista. Se você já tem processos informais, pode ser menos. Se você acha que vai fazer em 3 meses, está subestimando. E vai travar no meio do caminho.

Checklist: sua software house passa na due diligence?

Antes de qualquer coisa, faça esse diagnóstico honesto. Se você não consegue responder "sim" para pelo menos 7 dos 10 pontos abaixo, sua software house não passa em due diligence de grande player:

  1. Você tem política de segurança da informação documentada e aprovada pela diretoria?
  2. Você faz análise de risco formal antes de aceitar contratos grandes?
  3. Você tem controle de acesso documentado, com revisão periódica?
  4. Você tem política de criptografia para dados em trânsito e em repouso?
  5. Você tem processo formal de resposta a incidentes?
  6. Você faz backup e testa recuperação periodicamente?
  7. Você treina o time em segurança com frequência (não só uma vez por ano)?
  8. Você aplica práticas de desenvolvimento seguro no ciclo de vida?
  9. Você avalia a segurança dos seus próprios fornecedores?
  10. Você tem certificação ISO 27001 ou equivalente reconhecido?

Se você respondeu "não" para mais de 3, você está exposto. E não é questão de tempo até um grande player perceber. É questão de quando.

O argumento que fecha a decisão

Vamos falar de números, porque decisão de CEO se toma com números.

Um contrato com grande player vale, em média, entre R$ 500 mil e R$ 2 milhões. Uma multa LGPD pode chegar a 2% do faturamento, limitada a R$ 50 milhões por infração. Um incidente de segurança custa, em média, entre R$ 4 milhões e R$ 10 milhões somando resposta, multas, perda de clientes e dano reputacional.

Implementar ISO 27001 em 9 meses custa uma fração disso. E o retorno não é só evitar perda. É destravar receita. É participar de licitações que hoje você não participa. É entrar em negociações que hoje travam na due diligence.

A conta não é "quanto custa ISO 27001". A conta é "quanto custa não ter ISO 27001". E essa conta, cedo ou tarde, chega.

Próximos passos

Due diligence de segurança não é mais diferencial. É requisito. Grandes players não contratam software house sem investigar segurança. E a ISO 27001 é o atalho mais reconhecido para passar nessa investigação com confiança.

Se você quer saber exatamente onde sua software house está hoje em relação ao que o grande player espera, o primeiro passo é um diagnóstico gratuito. Em 24 horas, você recebe:

Sem compromisso. Sem venda agressiva. Só clareza sobre onde você está e o que falta para destravar os contratos que você quer.