A maioria das empresas que tenta se alinhar a SOC 2 ou ISO 27001 começa pelos controles — e aí as coisas desandam. Este guia explica como estruturar um programa de segurança que funciona de verdade, começando pelo contexto da sua empresa, não pelo checklist do framework.
A maioria das empresas que tenta estruturar um programa de segurança alinhado a SOC 2 ou ISO 27001 começa da forma errada. Pega o framework, abre a lista de controles, e tenta implementar tudo de cima para baixo, como se seguir uma lista de requisitos fosse suficiente para construir um programa que funciona.
Não é.
Frameworks de compliance são estruturas de referência — eles dizem o que um programa maduro de segurança precisa incluir, não como construí-lo para o seu contexto específico. Uma startup de 30 pessoas com infraestrutura toda em cloud tem riscos, capacidade operacional e superfície de ataque completamente diferentes de uma empresa com 300 pessoas e infraestrutura híbrida. Aplicar os mesmos controles da mesma forma para os dois contextos é, na melhor das hipóteses, ineficiente.
Este artigo é sobre como estruturar um programa de segurança que funciona de verdade — começando pelo seu contexto, não pelo checklist do framework.
Antes de qualquer framework: entenda onde você está
O primeiro passo é um mapeamento honesto da situação atual. Não para criar um relatório bonito — para entender o que realmente existe e o que não existe.
Quais sistemas críticos você opera? Onde estão hospedados? Quem tem acesso a eles, e esses acessos são gerenciados de forma estruturada ou foram sendo concedidos informalmente ao longo do tempo? Você sabe quais dados pessoais processa e onde estão armazenados? Tem backups testados? Tem logs de autenticação dos últimos 30 dias?
Esse mapeamento geralmente produz surpresas. Sistemas que “certamente existem” mas ninguém sabe exatamente onde estão. Acessos que foram concedidos há dois anos e nunca revisados. Ferramentas SaaS que o time adotou sem avaliação formal e que têm acesso a dados de clientes.
Essa visibilidade é o pré-requisito para qualquer coisa que venha depois. Não tem como estruturar controles de segurança sem saber o que você está protegendo.
Escolha o framework pelo mercado onde você está vendendo
SOC 2 e ISO 27001 são os dois frameworks mais relevantes para startups e fintechs brasileiras. Eles não são excludentes — muitas empresas eventualmente precisam dos dois — mas começar pelo correto economiza esforço significativo.
ISO 27001 é o padrão internacional de gestão de segurança da informação. No Brasil, é amplamente reconhecido por clientes enterprise, pelo governo, e por auditorias regulatórias. Se sua base de clientes é predominantemente brasileira e você está vendendo para empresas de médio e grande porte, ISO 27001 provavelmente é o caminho natural.
SOC 2 é um relatório de auditoria americano, desenvolvido pelo AICPA. Tem forte reconhecimento nos Estados Unidos e em empresas globais com operações americanas. Se você está expandindo para o mercado americano, tem clientes que operam em contexto americano, ou seu produto processa dados de usuários em países onde SOC 2 é o padrão esperado, esse é o ponto de partida.
A boa notícia é que os dois frameworks têm sobreposição significativa. Controles de gestão de acessos, gestão de incidentes, gestão de mudanças, e continuidade de negócios aparecem nos dois. Quem começa com ISO 27001 tem uma parte considerável do caminho para SOC 2 já percorrida.
Construa a camada de governança antes de implementar controles
Esse é o ponto onde mais vejo programas fracassarem. Empresas pulam direto para a implementação técnica de controles — configuram MFA em todos os sistemas, configuram alertas de segurança, constroem pipelines de CI/CD com verificações automatizadas — e deixam a governança para depois.
A governança é o que torna o programa sustentável. Sem ela, você tem um conjunto de configurações técnicas que ninguém é responsável por manter, que não estão documentadas de forma que um auditor consiga entender, e que vão drift ao longo do tempo sem que ninguém perceba.
Governança, nesse contexto, significa:
Responsabilidades claras. Quem é responsável por cada área de segurança? Quem aprova mudanças em sistemas críticos? Quem decide sobre riscos que excedem um certo limite? Quem coordena a resposta a um incidente? Em empresas maiores, essas responsabilidades se distribuem entre múltiplas pessoas e áreas. Em startups menores, frequentemente recaem sobre o CTO ou head de engenharia — o que também é válido, desde que esteja explicitado.
Cadências de revisão. Com que frequência as políticas de segurança são revisadas? Quem conduz revisões de acesso, e quando? Como incidentes são analisados e documentados? Quando esses processos existem como rotinas — não como projetos pontuais — eles geram evidências naturalmente.
Mecanismo de tomada de decisão sobre riscos. Quando um risco é identificado, quem decide como ele será tratado? Isso precisa ser documentado — não porque auditores gostam de papelada, mas porque registros de decisões formais sobre riscos são evidências de que o programa é gerenciado de forma estruturada.
Use gestão de riscos como bússola para priorização
ISO 27001 exige formalmente um processo de gestão de riscos. SOC 2 não exige da mesma forma, mas auditores esperam que a empresa consiga justificar por que implementou os controles que implementou.
A forma mais prática de abordar isso é começar pelo registro de ativos críticos — os sistemas, dados e processos que, se comprometidos, causariam o maior impacto para o negócio. Para cada ativo crítico, você identifica as ameaças mais relevantes e as vulnerabilidades existentes.
A partir desse mapeamento, fica muito mais fácil priorizar controles. Em vez de tentar implementar tudo de uma vez, você investe primeiro nos controles que reduzem os riscos com maior impacto potencial. Isso torna o programa mais eficiente e cria uma narrativa coerente durante auditorias: cada controle existe por uma razão explícita, associada a um risco documentado.
Revisões periódicas do registro de riscos — pelo menos anuais, idealmente mais frequentes em ambientes que mudam rápido — mantêm o programa atualizado conforme a empresa evolui.
Configure a coleta de evidências como parte da operação
O erro mais comum na implementação de controles é tratar evidências como um produto separado — algo que você cria quando precisa demonstrar compliance, não algo que surge naturalmente da operação dos controles.
Evidências deveriam ser um subproduto dos controles em operação. Quando revisões de acesso acontecem, deveriam gerar registros automaticamente. Quando mudanças em produção são aprovadas, o histórico de aprovações já é a evidência. Quando treinamentos são realizados, as confirmações de participação são coletadas e armazenadas.
Na prática, isso exige integração entre os processos de segurança e as ferramentas que a empresa já usa. Git e sistemas de CI/CD para evidências de gestão de mudanças. Ferramentas de IAM para evidências de controle de acesso. Logs de cloud para evidências de monitoramento. Quando essas integrações estão configuradas, a preparação para auditorias deixa de ser um projeto de semanas e passa a ser uma revisão de registros que já existem.
A diferença entre compliance no papel e programa que funciona
Existe um teste simples para saber se um programa de segurança funciona de verdade: se um auditor chegasse amanhã sem aviso, você conseguiria demonstrar, com evidências reais, que seus controles operam de forma consistente?
Se a resposta depende de você passar os próximos dias reconstruindo documentação e coletando registros dispersos, o programa existe no papel, não na operação.
Programas que funcionam de verdade têm algumas características em comum: as responsabilidades são claras e conhecidas pelas pessoas certas, as evidências são coletadas continuamente como parte da operação normal, os riscos são revisados com regularidade, e quando algo muda — novo sistema, novo fornecedor, nova equipe — o programa se ajusta de forma estruturada.
Isso não é o estado inicial. É o estado que se constrói ao longo de meses de operação consistente. O ponto de partida é simples: governança clara, riscos mapeados, evidências coletadas de forma sistemática. O resto vem da disciplina de manter isso operando, não de um projeto que acontece uma vez e é esquecido.