O Verizon DBIR 2025 traz um dado que merece atenção de qualquer fundador de startup: 88% dos breaches envolvendo pequenas e médias empresas continham um componente de ransomware, contra 39% em empresas enterprise. A mediana de pagamento de resgate no mesmo período foi de USD 115 mil. Pra uma startup no estágio seed ou Series A, esse valor pode representar meses de runway evaporando numa única transação, sem contar o custo de parada operacional e dano reputacional. Na minha avaliação, startups enfrentam risco comparável ao de empresas grandes com uma fração dos recursos pra mitigá-lo, e a resposta típica oscila entre dois extremos disfuncionais: ignorar segurança até que um incidente force a questão, ou copiar controles de playbooks enterprise que consomem tempo e dinheiro sem endereçar os riscos que importam.
O segundo extremo tem nome: security theater. O conceito, popularizado por Bruce Schneier, descreve medidas desenhadas pra criar impressão de proteção sem reduzir risco mensurável. Já auditei uma startup de 25 pessoas que havia contratado um SIEM enterprise configurado com regras padrão de fábrica, gerando centenas de alertas diários que ninguém triava. O dashboard existia. A segurança, não. O controle A.8.16 da ISO 27001:2022 exige capacidade de monitoramento, e capacidade significa pessoas, processos e tempo alocado pra responder ao que o monitoramento detecta. Outra manifestação comum é a política de segurança de 40 páginas copiada de um template online, que nenhum engenheiro leu e que descreve controles que a empresa não tem infraestrutura pra implementar. O risco permanece intacto.
A alternativa ao security theater é proporcionalidade. A ISO 27001 opera sob esse princípio, embora a percepção do mercado sugira o contrário. A cláusula 6.1.2 exige que a organização defina e aplique um processo de avaliação de riscos, e a 6.1.3 exige que selecione controles apropriados com base nessa avaliação, documentando a justificativa no Statement of Applicability. O Annex A oferece 93 controles como referência, mas a norma trata esses controles como um menu, e não como checklist obrigatória. Uma startup de SaaS B2B com 15 pessoas que processa dados financeiros tem perfil de risco diferente de uma startup de marketplace B2C do mesmo tamanho, e os controles necessários refletem essa diferença.
Na prática, o ponto de partida é a identificação dos ativos de informação que sustentam o negócio: código-fonte, dados de clientes, credenciais de acesso a serviços de terceiros, ambientes de produção. A cláusula 4.1 pede que a organização entenda seu contexto. Pra uma startup esse contexto inclui sistemas rodando em cloud pública, time pequeno o suficiente pra que a saída de uma pessoa represente perda significativa de conhecimento, e velocidade de entrega como restrição de negócio real. A avaliação identifica, pra cada ativo relevante, quais ameaças são plausíveis, qual o impacto de cada cenário e o que a empresa já faz pra mitigá-lo.
Os controles que produzem mais retorno por unidade de esforço em startups são previsíveis, até porque os vetores de ataque também são. Credenciais comprometidas representaram 22% dos vetores iniciais no DBIR 2025, e o mesmo relatório mostra que 46% dos sistemas comprometidos por infostealer malware com credenciais corporativas eram dispositivos não gerenciados. MFA em todos os serviços que suportam (A.8.5), gestão centralizada de identidades e uma política de acesso baseada no menor privilégio (A.5.15 e A.8.2) resolvem uma parcela desproporcional do risco com investimento mínimo. Backup verificado e testado (A.8.13) transforma um incidente de ransomware de crise existencial em inconveniente operacional de horas. A gestão de vulnerabilidades técnicas (A.8.8) num time pequeno pode ser tão simples quanto Dependabot, ferramenta de varredura automática de dependências do GitHub, habilitado nos repositórios com triagem semanal dos alertas.
O custo médio global de um breach atingiu USD 4,88 milhões em 2024 segundo o IBM Cost of a Data Breach Report, o maior valor já registrado, e nos Estados Unidos o custo médio chegou a USD 9,36 milhões no mesmo período. Pra startups que operam com clientes americanos ou europeus, a exposição regulatória é real e crescente. No Brasil, a LGPD prevê sanções de até 2% do faturamento, limitadas a R$ 50 milhões por infração (artigo 52), e a Resolução CD/ANPD n. 15/2024 regulamentou o prazo de notificação de incidentes em 3 dias úteis. Uma startup sem processo de resposta a incidentes (A.5.24 a A.5.28) não cumpre esse prazo, porque antes de notificar é preciso detectar, conter e avaliar o impacto.
Decisões de arquitetura tomadas nos primeiros meses de uma startup, como a forma de armazenar segredos e a estrutura das permissões de acesso, definem o modelo de log e observabilidade e determinam o custo de implementar controles depois. A ISO 27005, que complementa a 27001 com diretrizes específicas pra gestão de riscos, reconhece que o nível de detalhe da avaliação deve ser proporcional à complexidade e ao contexto da organização. Na minha experiência de auditoria, uma avaliação numa planilha com 20 linhas, revisada trimestralmente, já constitui um avanço sobre o que a grande maioria das startups tem. Pra mim, o que diferencia um controle real de security theater é a existência de um processo operacional que alguém executa com frequência definida. Saber, sem precisar conferir, que o MFA está habilitado sem exceção pro CEO e que os backups são testados e não apenas configurados. Saber que credenciais de produção não vivem num arquivo .env commitado no repositório e que existe ao menos um runbook básico de resposta a incidentes.