SOC 2, ISO 27001

SOC 2 e ISO 27001 são os dois frameworks de compliance de segurança que mais aparecem em exigências de clientes corporativos e contratos B2B, e eles respondem a perguntas diferentes com instrumentos diferentes. O SOC 2 é um relatório de atestação, emitido por escritório de auditoria, sobre a eficácia dos controles de uma organização de serviço em um período; a ISO 27001 é uma certificação internacional, emitida por organismo acreditado, sobre a existência e maturidade de um sistema de gestão de segurança da informação, o SGSI. Em produção, os dois se materializam da mesma forma: políticas escritas, controle de acesso com trilha, gestão de mudanças, resposta a incidente e evidências coletadas continuamente. Entender a diferença de propósito, público e custo evita executar o programa errado para a necessidade do negócio. Este arquivo cobre a estrutura de cada padrão, a comparação entre eles, os requisitos comuns, o custo real e como a arquitetura reduz o esforço de auditoria.

SOC 2: critérios de confiança e estrutura do relatório

O SOC 2, definido pelo AICPA, avalia controles de uma organização de serviço contra os Trust Services Criteria. O critério de segurança, o common criteria, é obrigatório e cobre a base: controle de acesso lógico e físico, operações, gestão de mudanças e mitigação de risco. Os demais critérios são opcionais e escolhidos conforme o serviço: disponibilidade, integridade de processamento, confidencialidade e privacidade. A escolha dos critérios define o escopo do relatório, e escopo inflado, com critérios que o serviço não precisa, aumenta o trabalho de auditoria sem valor para o cliente.

O relatório tem estrutura definida: opinião do auditor, asserção da administração, descrição do sistema, que é escrita pela empresa e auditada, e os testes dos controles com resultados. A descrição do sistema é o documento que mais trabalho dá a times técnicos, porque precisa descrever com precisão infraestrutura, software, pessoas e processos relevantes para os critérios, e precisa refletir a realidade que o auditor vai encontrar. Divergência entre o que está escrito e o que existe é motivo direto de qualificação na opinião, o pior resultado comercial possível.

O common criteria organiza os controles em categorias que qualquer time técnico reconhece: governança e compromisso, avaliação e monitoramento de risco, lógica e física de acesso, operações e gestão de mudanças. O auditor testa amostra de cada categoria no período, então o padrão de verdadeiro é controles operando com rastro durante meses, e não políticas aprovadas na véspera. Essa é a diferença estrutural do SOC 2 frente a checklists de autoavaliação: alguém independente olhou a operação e assinou uma opinião sobre ela.

Type 1 e Type 2

A diferença entre os dois tipos de relatório é temporal e é a decisão mais importante do início do programa.

A sequência usual é executar Type 1 como preparação, corrigir o que o readiness revelar, e entrar no período de observação do Type 2 com controles já maduros. Organizações que tentam Type 2 direto costumam descobrir quebrado no meio da janela o que deveriam ter corrigido antes, e a janela precisa ser refeita. A janela de observação é o motivo do longo prazo do SOC 2: não existe atalho para provar operação contínua por meses.

ISO 27001: SGSI, escopo e gestão de riscos

A ISO 27001 certifica um sistema de gestão, o SGSI, e não um conjunto técnico de controles isolados. O ciclo do SGSI segue o PDCA: definir escopo e política, avaliar riscos, escolher e implementar controles, operar, medir e melhorar. O documento central é a Statement of Applicability, a SoA, que mapeia os controles do Anexo A, 93 controles na edição 2022, para o tratamento de risco declarado, com justificativa de aplicabilidade e de exclusão. A certificação é concedida por organismo acreditado, com ciclo de três anos e auditorias de vigilância anuais, e exige auditoria interna e revisão pela direção antes de cada ciclo.

O escopo é decisão estratégica e a fonte clássica de problema: um SGSI de empresa inteira custa muito mais que um SGSI da plataforma de produto, com fronteira clara entre sistemas dentro e fora do escopo. Escopo bem desenhado cobre o que o cliente compra, com dependências explícitas, e evita arrastar áreas sem relação com o serviço avaliado. A gestão de risco é o coração do padrão: a metodologia precisa existir, os riscos precisam estar registrados em registro vivo, e cada risco residual aceito precisa de dono e justificativa, que é o que o auditor cobra na prática.

Além da SoA, o padrão exige conjunto documental mínimo que inclui política de segurança, metodologia de avaliação de risco, plano de tratamento, registro de riscos, relatórios de auditoria interna e ata de revisão pela direção. A exigência documental é o que mais diferencia a ISO do SOC 2 na prática: a certificação avalia se o sistema de gestão funciona, com entrada, saída, medição e melhoria, e documentos sem ciclo de vida real não sobrevivem à auditoria interna, que é obrigatória e independente da externa.

Comparação de propósito e público

Os dois padrões se sobrepõem em controles, mas servem a propósitos distintos, e a escolha depende de quem exige o documento.

Para empresa vendendo SaaS para clientes corporativos, o SOC 2 Type 2 é normalmente a primeira exigência, porque é o que o questionário de vendor risk pede. A ISO 27001 entra com força em contratos internacionais, setores regulados e licitações, onde a certificação com escopo declarado simplifica a aceitação. Organizações com os dois programas descobrem que a ISO dá o sistema de gestão e o SOC 2 prova a operação, e os programas se complementam em vez de competir.

Requisitos comuns e controles que os dois cobram

Apesar de estruturas diferentes, a espinha dorsal de controles é praticamente a mesma, o que permite construir uma vez e evidenciar duas vezes.

• Políticas de segurança da informação aprovadas, revisadas em cadência e comunicadas aos envolvidos, com rastro de aceite.
• Controle de acesso com provisionamento por papel, revisão periódica de acessos, MFA obrigatório e desligamento imediato.
• Gestão de ativos com inventário de sistemas e responsáveis, incluindo fornecedores e serviços em nuvem.
• Gestão de mudanças com revisão, teste, aprovação e rastro, o que em produção moderna é o fluxo de pull request.
• Trilha de auditoria de eventos relevantes, com proteção contra alteração e retenção definida.
• Resposta a incidente com plano, contatos, simulação e registro de aprendizados.
• Continuidade e recuperação, com backups testados e plano de recuperação exercitado.
• Gestão de vulnerabilidades com escaneamento, correção priorizada e prazos definidos por severidade.
• Gestão de fornecedores com avaliação de risco e contratos com cláusulas de segurança.

A lista é o núcleo do readiness de qualquer um dos dois programas. Times técnicos reconhecem nela o que já fazem em engenharia bem operada, e o esforço real está em transformar prática em evidência documentada e revisada em cadência, não em inventar controles novos.

A tradução para controles técnicos segue direto, e a coleta de evidência via API é o que separa programa manual de programa sustentável. Os comandos abaixo são exemplos reais de coleta usada em preparação e em amostragem de auditoria.

# Evidência de política de senha e relatório de credenciais da conta
aws iam get-account-password-policy
aws iam generate-credential-report && aws iam get-credential-report

# Evidência de trilha de auditoria ativa e multirregião
aws cloudtrail describe-trails --trail-name-list auditoria-principal

# Evidência de grupos de log sem retenção definida, achado típico
aws logs describe-log-groups \
    --query 'logGroups[?retentionInDays==null].logGroupName'

# Evidência de política de organização que exige volume EBS cifrado
aws organizations describe-policy --policy-id p-ebs-encrypted-exemplo

Cada comando vira linha de evidência com data, execução e resultado, e a mesma coleta roda mensalmente na esteira interna. O objetivo é que a véspera da auditoria seja consulta, não corrida.

Custo real de cada programa

O custo do SOC 2 tem três componentes: preparação, o readiness, que expõe e corrige lacunas; a auditoria em si, que varia com escopo, critérios e tamanho do sistema; e a operação contínua de coletar evidência durante a janela e manter controles funcionando. O item mais subestimado é o tempo de engenharia: responder evidência manualmente consome dias por semana em auditoria, e plataformas de automação de compliance existem exatamente para conectar controles às fontes de evidência, como IAM, CI-CD, ticketing e cloud. Mesmo com automação, o custo de manter políticas vivas e revisões em dia permanece.

O custo da ISO 27001 soma consultoria de implementação, se usada, taxas do organismo de certificação, auditorias internas com recurso próprio ou terceirizado e o ciclo de vigilância anual. O padrão exige documentos formais, e a burocracia documental é maior que no SOC 2, onde o relatório estrutura a saída. Em ambos os casos o custo maior é interno, em horas de time, e a decisão de escopo, enxuto e alinhado ao que o cliente compra, é a maior alavanca de economia disponível.

Há ainda o custo de oportunidade de escopo mal planejado, que se paga duas vezes: na implementação, com controles estendidos a áreas sem valor comercial, e na manutenção, com evidência permanente sobre sistemas que nenhum cliente pediu. Orçamento realista inclui ferramentas de automação de compliance quando o número de controles justificar, e reserva de tempo de engenharia para a janela de auditoria, que continua existindo mesmo com plataforma madura.

Como a arquitetura reduz o esforço de auditoria

Cada controle com implementação nativa na plataforma gera evidência automaticamente, e cada controle implementado por processo manual gera trabalho recorrente. A tabela mapeia os requisitos comuns para implementações arquiteturais que produzem evidência por si mesmas.

O princípio por trás da tabela é que auditoria cobra operação demonstrável, e operação demonstrável é subproduto de plataforma bem construída. Auditor que pode consultar log de acesso, histórico de mudança e registro de teste de backup sai do ciclo em menos tempo, e o relatório fica melhor porque a evidência é contínua, não reconstruída.

O ciclo anual e o papel da automação

Depois do primeiro certificado ou relatório, o programa vira cadência: revisão de políticas, revisão de acessos, testes de backup, simulação de incidente, varredura de vulnerabilidades, tudo em calendário que precisa acontecer para a próxima auditoria encontrar período íntegro. A automação substitui o lembrete por workflow: revisões agendadas com dono e prazo, coleta de evidência por integração e dashboard de prontidão que mostra o que está atrasado. O time de engenharia sente a diferença entre programa manual, que consome sprints, e programa automatizado, que consome horas pontuais.

A armadilha da automação é evidência sem controle real: coletar o log não substitui o controle funcionar. Plataformas aceleram coleta e organização, mas a eficácia dos controles é julgada pelo auditor sobre a operação, e atalho documental aparece na amostragem.

Erros comuns

• Tratar o programa como projeto de documento, não de operação: política escrita sem prática correspondente é qualificação garantida.
• Definir escopo inflado, cobrindo áreas sem relação com o serviço vendido e multiplicando trabalho de evidência.
• Entrar em Type 2 sem readiness: a janela de observação registra também os meses com controle quebrado.
• Deixar revisões de acesso e testes de backup para o mês antes da auditoria: a amostragem pega o intervalo vazio.
• Copiar políticas de template sem adaptar: descrição de sistema genérica diverge da realidade técnica que o auditor testa.
• Subestimar o tempo de engenharia em coleta de evidência manual e descobrir o custo no meio da janela.
• Prometer ao cliente critérios ou controles que o sistema não sustenta, criando compromisso de relatório que não fecha.

Boas práticas

• Escolher escopo enxuto e critérios alinhados ao que o cliente realmente compra, com dependências declaradas.
• Fazer readiness honesto antes do Type 2, transformando lacunas em roadmap com prazo, e não em trabalho paralelo.
• Implementar controles como plataforma, com evidência nativa de logging, CI-CD, IAM e backup automatizado.
• Automatizar revisões periódicas de acesso, política e backup, com dono, prazo e registro centralizado.
• Manter a descrição do sistema sincronizada com a realidade, revisando-a em cada mudança arquitetural relevante.
• Reusar o mesmo núcleo de controles entre SOC 2, ISO 27001 e frameworks setoriais, mapeando cada controle na matriz comum.
• Tratar o programa de compliance como parte do ciclo de engenharia, com dono técnico e métricas de prontidão visíveis ao time.