O problema do duplo esforço
A história se repete em SaaS B2B que cresce: a primeira certificação foi ISO 27001 (exigência de cliente europeu) e meses depois veio o SOC 2 (exigência de cliente americano). Em vez de aproveitar o trabalho, a empresa monta um segundo programa de compliance — outra planilha de controles, outro repositório de evidências, outro auditor.
O custo cresce, a equipe se exaure e os controles começam a divergir. Em pouco tempo, a auditoria ISO encontra evidências que a auditoria SOC não vê — e vice-versa.
O que ISO 27001 e SOC 2 têm em comum
Apesar de pertencerem a famílias diferentes (ISO/IEC vs AICPA), os dois frameworks compartilham conceitos fundamentais:
- Gestão de riscos. Ambos exigem identificação, avaliação e tratamento de riscos.
- Controle de acesso. Mínimo privilégio, separação de funções, revisão periódica.
- Continuidade de negócios. Plano testado, evidência de exercício.
- Gestão de fornecedores. Due diligence, contratos, monitoramento.
- Gestão de incidentes. Procedimento, comunicação, lições aprendidas.
- Trilha de auditoria. Logs, retenção, capacidade de reconstruir eventos.
Estima-se que entre 60% e 75% dos controles de uma certificação podem ser reutilizados na outra — desde que estruturados corretamente.
O método: uma biblioteca, vários mapeamentos
Em vez de manter dois conjuntos de controles, monte uma biblioteca única e crie mapeamentos entre cada controle e os requisitos de cada framework.
Passo 1: extrair os requisitos
Liste todos os requisitos da ISO/IEC 27001:2022 (Anexo A) e dos Trust Services Criteria do SOC 2 (CC1 a CC9, mais critérios opcionais). São aproximadamente 93 + 64 requisitos.
Passo 2: criar controles atômicos
Em vez de "controle de acesso lógico" como um único item, crie:
- CTRL-001: política de senhas com mínimo de 12 caracteres
- CTRL-002: MFA obrigatório para acessos administrativos
- CTRL-003: revisão trimestral de acessos por gestor
- CTRL-004: revogação automática em até 24h após desligamento
Cada controle deve ser verificável — se você não consegue produzir uma evidência objetiva, ele está mal formulado.
Passo 3: mapear N:N
Para cada controle, marque quais requisitos ele satisfaz em cada framework. O CTRL-002 (MFA) por exemplo atende ISO A.5.16 (gerenciamento de identidades), A.8.2 (privilégios), e SOC CC6.1 (controles lógicos e físicos), CC6.6 (autenticação).
Passo 4: evidência por controle
Cada controle tem evidência (relatório, screenshot, log, política). A mesma evidência cobre todos os requisitos mapeados. Atualizou o controle? A evidência precisa ser atualizada também — e o sistema deve notificar os auditores.
Como medir maturidade
Use uma escala simples por controle:
- Nível 0: não existe
- Nível 1: definido mas não documentado
- Nível 2: documentado e implantado, mas sem monitoramento
- Nível 3: implantado com monitoramento periódico
- Nível 4: automatizado com métricas e melhoria contínua
Auditores não esperam todos os controles em nível 4 — esperam coerência entre o nível declarado e a evidência apresentada.
Erros comuns
- Mapear no nível dos requisitos em vez de no nível dos controles. Resultado: o mesmo controle aparece duplicado por aparecer em vários requisitos.
- Tratar evidência como "anexo de documento". Evidência precisa ter validade temporal — um log de 18 meses atrás não prova nada hoje.
- Confundir política com controle. Política diz o que deve ser feito; controle é a atividade que faz acontecer.