The SOC 2 parecia, para mim, a continuação natural de um caminho que já estava bem estruturado. Quando decidimos buscar o relatório Tipo 1, a Dattos havia conquistado a certificação ISO/IEC 27001:2022, mantinha um Sistema de Gestão de Segurança da Informação em operação e já tinha passado por uma auditoria externa.
Ainda assim, levei algumas semanas para perceber o tamanho da tradução que teríamos pela frente. A base de segurança existia, mas o vocabulário, o escopo e a lógica de asseguração pediam outro tipo de organização.
A primeira dificuldade nem foi técnica. Eu encontrava bastante conteúdo em inglês e pouco material em português que respondesse às perguntas de quem conduz o projeto por dentro. O que entra no sistema descrito? Quem afirma o quê? O que significa avaliar controles em uma data? Até onde o auditor pode orientar sem comprometer a independência?
Este artigo reúne o que eu gostaria de ter encontrado naquela época. Também organiza o que aprendemos ao sair da ISO 27001, passar pelo SOC 2 Tipo 1 e preparar a operação para o Tipo 2.
| Resposta rápida The company SOC 2 é um relatório de asseguração sobre controles de uma organização prestadora de serviços. Ele usa critérios da AICPA relacionados à segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Na nossa experiência, a ISO 27001 respondeu por algo entre 70% e 80% da preparação para o Tipo 1. Essa faixa é uma leitura do projeto da Dattos, não um parâmetro de mercado. O restante envolveu escopo, descrição do sistema, afirmação da administração e tradução das evidências para a estrutura do exame. O principal aprendizado foi perceber que um controle ganha valor quando funciona na rotina e produz evidência enquanto funciona. A auditoria observa esse processo, mas não deveria ser a razão de ele existir. |
SOC 2: o que ele avalia e por que não é uma certificação?
Na primeira conversa com uma firma de auditoria, perguntei em quanto tempo teríamos o “certificado SOC 2”. A resposta corrigiu o projeto logo no começo. Não teríamos um certificado, porque o SOC 2 resulta em um relatório com uma opinião independente.
The definição oficial da AICPA descreve o SOC 2 como um exame de controles de uma organização prestadora de serviços. Esses controles são avaliados conforme os Trust Services Criteria, que abrangem segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade.
Segurança funciona como a base dos Common Criteria. As demais categorias entram conforme o serviço, os compromissos assumidos e as necessidades de quem utilizará o relatório. Por isso, dois relatórios SOC 2 podem ter escopos diferentes sem que um esteja necessariamente mais completo do que o outro.
O relatório também carrega uma arquitetura própria. A organização descreve o sistema e apresenta uma afirmação formal; o auditor independente aplica procedimentos, avalia evidências e emite sua opinião. No Tipo 2, o documento ainda apresenta os testes dos controles e seus resultados.
The SOC 2, portanto, não é um selo genérico de que tudo está seguro. Ele oferece informação detalhada sobre um sistema delimitado, seus controles e o trabalho de asseguração realizado.
Qual é a diferença entre SOC 2 Tipo 1 e Tipo 2?
A diferença fica mais clara quando olhamos para o recorte de tempo e para a pergunta feita ao controle.
| Aspecto | SOC 2 Tipo 1 | SOC 2 Tipo 2 |
|---|---|---|
| Recorte | Uma data específica | Um período definido |
| Foco da opinião | Desenho e implementação dos controles | Desenho, implementação e efetividade operacional |
| Evidência | Demonstra a condição na data avaliada | Demonstra a execução ao longo do período |
A comparação entre fotografia e filme ajuda, desde que a gente não pare nela. No Tipo 1, o controle precisa estar desenhado e implementado na data-base. No Tipo 2, a organização precisa demonstrar que o controle continuou operando com consistência.
Por que começar o SOC 2 foi tão desconfortável?
Eu sabia razoavelmente bem o que precisava entregar, mas não encontrava uma explicação honesta sobre como chegar lá. Em inglês, havia material para um mercado que convive com o tema há décadas. Em português, boa parte do que aparecia vinha de consultorias, plataformas de compliance e checklists com prazos universais.
Esses materiais até ajudavam a organizar tarefas, porém não respondiam à pergunta que mais me interessava: “O que exatamente o auditor vai olhar e com base em quais critérios emitirá a opinião?”
O problema de uma promessa rápida começa antes do cronograma. Ela costuma pressupor que o escopo já está claro, os controles estão maduros, as responsabilidades foram definidas e as evidências existem. Quando alguma dessas condições falta, a velocidade anunciada apenas empurra a discussão para mais perto da auditoria.
Essa preocupação continua atual. Em 2026, a própria AICPA reuniu alertas sobre promessas de trabalhos SOC rápidos e fáceis, além de reforçar a necessidade de avaliar cuidadosamente os serviços, os profissionais e os padrões aplicados.
A pressa não resolve uma pergunta de escopo mal respondida. Antes de estimar o prazo, é preciso entender o serviço, os riscos, os controles e a condição real das evidências.
Foi por isso que saí da primeira conversa com a auditoria com mais dúvidas do que respostas. Ao mesmo tempo, aquele desconforto foi útil. Ele nos obrigou a parar de procurar um checklist universal e a compreender a estrutura do trabalho.
Como traduzir o SOC 2 para o vocabulário brasileiro?
O SOC nasceu no universo profissional da AICPA, nos Estados Unidos. Essa origem explica parte da confusão, especialmente quando a conversa chega ao jurídico, à auditoria interna ou a clientes acostumados com as normas brasileiras de asseguração.
No Brasil, a NBC TO 3402 aparece na relação oficial do Conselho Federal de Contabilidade como a norma para relatórios de asseguração de controles em organização prestadora de serviços. O assunto dela está diretamente ligado a controles relevantes para os relatórios financeiros das entidades usuárias, o mesmo território conceitual do SOC 1 e da ISAE 3402.
O SOC 2 segue outro objeto. A AICPA o estrutura em torno dos Trust Services Criteria e dos controles relevantes para segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Por isso, a NBC TO 3402 não deve ser apresentada como uma tradução brasileira do SOC 2.
| Referência | Assunto central | Relação que ajuda na conversa |
|---|---|---|
| SOC 1 e NBC TO 3402 | Controles do prestador relevantes para os relatórios financeiros dos clientes | São as referências mais próximas entre si |
| SOC 2 | Controles de um sistema de serviços avaliados pelos Trust Services Criteria | Usa critérios e orientação próprios da AICPA |
| Normas gerais de asseguração | Regras profissionais aplicáveis a trabalhos de asseguração conforme o objeto e a contratação | Podem compor o enquadramento profissional no Brasil |
O que destravou minhas conversas foi reconhecer a arquitetura comum dos trabalhos de asseguração. Existe uma descrição preparada pela administração, uma afirmação formal, critérios aplicáveis, controles relacionados e uma opinião independente.
A semelhança que ajudou foi estrutural, não uma equivalência automática entre as normas. Com esse cuidado, ficou mais fácil explicar o relatório sem reduzir o SOC 2 a uma sigla brasileira que trata de outro objeto.
Como a ISO 27001 simplificou o nosso SOC 2?
Se eu tivesse que apontar a decisão que mais economizou esforço, escolheria ter feito a ISO 27001 primeiro. Chegamos ao SOC 2 Tipo 1 com um SGSI em funcionamento, riscos tratados, políticas aprovadas e uma auditoria externa no retrovisor.
The ISO/IEC 27001:2022 define os requisitos para estabelecer, implementar, manter e melhorar continuamente um sistema de gestão de segurança da informação. Na prática, ela já havia organizado boa parte da governança que o novo projeto precisaria encontrar.
Também tínhamos uma base documental. Política de segurança, gestão de ativos, controle de acesso, avaliação de fornecedores, resposta a incidentes, continuidade, mudanças, auditoria interna e tratamento de não conformidades já faziam parte da rotina. Quem quiser aprofundar essa estrutura pode consultar o artigo da Dattos sobre ISO 27001 e gestão de segurança da informação.
| O que já existia com o SGSI | O que o SOC 2 ainda exigiu organizar |
|---|---|
| Método de avaliação e tratamento de riscos | Descrição do sistema segundo os critérios aplicáveis |
| Políticas, responsáveis e controles implementados | Afirmação formal da administração |
| Auditorias internas e tratamento de não conformidades | Delimitação do sistema e dos compromissos com clientes |
| Registros de revisões, aprovações e resultados | Evidências apresentadas na estrutura esperada pelo auditor |
Havia, ainda, uma correspondência prática entre os controles. A versão 2022 reorganizou 93 controles de referência em quatro temas: organizacionais, de pessoas, físicos e tecnológicos. Threat intelligence, segurança para serviços em nuvem, prontidão de TIC para continuidade, monitoramento, filtragem web e codificação segura estavam entre os pontos que conversavam diretamente com riscos avaliados no SOC 2.
A própria AICPA publicou um mapeamento entre os Trust Services Criteria e a ISO 27001. Como esse material antecede a revisão de 2022 da norma ISO, ele funciona melhor como ponto de partida do que como resposta pronta. O mapeamento atual precisa considerar o escopo real, os controles adotados e os critérios contratados.
Na Dattos, a matriz entre o Anexo A e os Trust Services Criteria se tornou uma das peças mais consultadas do projeto. Ela ajudou a localizar sobreposições, mas também mostrou onde ainda existiam lacunas de descrição, evidência ou responsabilidade.
Foi nesse momento que o apoio da Clavis se tornou decisivo. Quem constrói o ambiente conhece a intenção por trás de cada decisão e pode confundir intenção com implementação. Um olhar externo separou o que estava maduro daquilo que apenas parecia maduro no papel.
Algumas conclusões foram confortáveis e outras deram trabalho. Justamente por isso, a avaliação prévia reduziu as surpresas na data-base.
Minha estimativa é que a ISO 27001 respondeu por 70% a 80% do que usamos na preparação para o SOC 2 Tipo 1. O número descreve a nossa jornada. Outra organização pode ter um escopo, uma arquitetura e um nível de maturidade completamente diferentes.
Onde erramos ao definir o escopo do SOC 2?
A parte que mais gerou retrabalho não foi um controle técnico. Foi o escopo. O primeiro desenho que levei para discussão era largo demais e incluía sistemas que nenhum cliente contratava.
À primeira vista, incluir tudo parecia prudente. Na prática, o relatório ganharia uma superfície maior de descrição e teste sem responder melhor às perguntas de quem compra o serviço.
Voltamos atrás e começamos pelo contrato do cliente. A partir dele, fizemos perguntas que pareciam mais simples, mas organizavam a fronteira correta:
- O que exatamente entregamos ao cliente?
- Quais sistemas, pessoas e processos sustentam essa entrega?
- Que dados entram, circulam e saem do serviço?
- Quais fornecedores e subprocessadores participam do fluxo?
- Que compromissos de segurança, disponibilidade ou confidencialidade assumimos?
- Quais responsabilidades permanecem com o cliente?
O contrato mostrou onde o serviço começava, o que o cliente realmente recebia e o que não precisava entrar no relatório. A fronteira deixou de representar a infraestrutura inteira e passou a refletir o sistema que presta o serviço.
Esse cuidado também vale para os controles complementares esperados das entidades usuárias. Parte da segurança depende de o próprio cliente administrar usuários autorizados, proteger credenciais e revisar as permissões concedidas. Essas responsabilidades precisam aparecer com clareza.
Um escopo amplo demais aumenta custo e complexidade. Um escopo estreito demais produz um relatório que pode não responder à due diligence de um cliente relevante. O equilíbrio surge quando a descrição acompanha o serviço contratado e seus riscos reais.
Como o SOC 2 aparece na segurança entregue ao cliente?
Se tudo isso ficasse restrito ao exercício de conformidade, o projeto teria perdido o sentido. O teste real está no que chega ao cliente e no que continua funcionando quando ninguém está olhando para o calendário da auditoria.
A Dattos processa bases financeiras, contábeis e operacionais que sustentam conciliações, fechamentos e decisões. Esses dados são sensíveis por natureza, e a segurança dos dados financeiros precisa participar da arquitetura desde o começo.
Na prática, cada cliente opera em fronteiras próprias de dados e acesso. A criptografia em trânsito e em repouso faz parte da arquitetura. O acesso segue o mínimo necessário, passa por revisões periódicas e deixa registros que permitem reconstruir quem acessou, quando a ação ocorreu e o que mudou.
No desenvolvimento, mudanças relevantes entram com aprovação e trilha. Código passa por revisão, e as responsabilidades de desenvolver e promover são separadas. Monitoramento, resposta a incidentes e continuidade também têm papéis, prazos e testes definidos.
O mesmo raciocínio chega aos fornecedores. A cadeia que sustenta o serviço inclui terceiros e subprocessadores, portanto a avaliação precisa observar os dados envolvidos, a dependência criada e os controles que esses parceiros mantêm.
O efeito mais visível apareceu na due diligence. Conversas que antes começavam com uma reconstrução longa do ambiente passaram a contar com uma base independente para análise. O certificado ISO 27001 e o relatório SOC 2 Tipo 1 não encerram todas as perguntas, mas elevam o ponto de partida.
| “O teste real do SOC 2 aparece no que continua funcionando quando a auditoria acaba.” |
Quando a governança de segurança vira cultura?
O ganho de que mais me orgulho não aparece em relatório. Ele surgiu quando segurança da informação deixou de ser assunto de uma área e começou a entrar nas decisões cotidianas.
Essa mudança veio de práticas pouco glamourosas e muito repetidas. Criamos onboarding de segurança para quem chega, reciclagens periódicas e conteúdos diferentes conforme a função. Quem desenvolve software encontra riscos distintos de quem atende clientes ou avalia fornecedores.
Também mudamos a forma de simular phishing. Em vez de disparar uma mensagem falsa e apenas contar cliques, passamos a pedir que as pessoas classificassem a mensagem e apontassem o indício que sustentava a decisão. Um domínio alterado, um link incoerente, um anexo inesperado ou uma urgência fabricada deixavam de ser detalhes soltos e viravam parte do aprendizado.
Colocamos mensagens legítimas no exercício, porque segurança também exige reconhecer o que pode seguir. Assim, o treinamento reduziu tanto o risco do clique precipitado quanto a desconfiança generalizada que paralisa o trabalho.
O ranking mostrava quem acertava, nunca quem errava. Quem precisava de apoio era acompanhado individualmente, sem exposição. Quando a conscientização vira constrangimento, as pessoas param de participar e de reportar.
Com o tempo, o melhor sinal não foi uma queda artificial no número de incidentes comunicados. O aumento dos reportes mostrou que as pessoas estavam observando e confiavam no canal.
O comitê de segurança também ganhou uma função concreta. Riscos, incidentes, exceções e indicadores entravam na pauta, com decisões registradas e acompanhamento do que havia sido combinado. Sem decisão, um comitê vira apenas uma reunião de status.
Por fim, a segurança entrou no fluxo. Revisão de código, avaliação de risco em mudanças e checagem de fornecedores passaram a acontecer antes da execução.
O sinal mais claro apareceu nas perguntas que chegavam antes do fato: “Posso usar essa ferramenta?”, “Esse dado pode sair daqui?” e “Esse acesso ainda faz sentido?”. Auditoria nenhuma mede bem esse comportamento, embora ele proteja a empresa todos os dias.
O que muda na preparação do SOC 2 Tipo 1 para o Tipo 2?
Em 2026, nossa prioridade passou a ser sustentar. A manutenção da ISO 27001 corre ao lado da renovação do SOC 2 Tipo 1, enquanto a operação se prepara para demonstrar consistência no Tipo 2.
No Tipo 1, um controle bem desenhado e implementado pode ser demonstrado na data-base. No Tipo 2, o auditor avalia ocorrências ao longo do período e observa execução, aprovação, prazo, tratamento das exceções e retenção das evidências.
Uma revisão trimestral de acessos mostra bem a diferença. A política pode existir e a revisão pode estar configurada, mas o período contará a história de cada trimestre. Se uma execução falhar, o caso precisa ser identificado, explicado e avaliado conforme o desenho do teste e o risco envolvido.
O mesmo vale para desligamentos, mudanças e avaliações de fornecedores. O relatório não pergunta apenas se a organização sabe executar o controle. Ele observa se a operação manteve a disciplina necessária durante o período.
A preparação para o Tipo 2 virou um projeto de operação. Cinco decisões passaram a orientar esse trabalho:
- Definir com clareza o período e a data de início;
- Atribuir um responsável nominal a cada controle;
- Fazer a evidência nascer no fluxo normal da atividade;
- Rodar amostragens internas antes do exame externo;
- Remover controles decorativos que não reduzem risco e ainda consomem evidência.
Esse último ponto importa bastante. Um controle criado apenas para preencher uma matriz aumenta o trabalho e pode esconder a pergunta principal: qual risco ele reduz e qual compromisso do serviço ajuda a sustentar?
Quando a resposta não aparece, talvez o controle precise ser redesenhado ou eliminado. Automatizar uma rotina mal definida só faz a inconsistência ganhar velocidade.
Onde a inteligência artificial entra nessa governança?
Cheguei a 2026 convencido de que a próxima fronteira da governança é a inteligência artificial. Ela entra por duas portas ao mesmo tempo. Pode apoiar a operação dos controles e também precisa ser governada como uma tecnologia que cria riscos próprios.
Como a IA pode apoiar a governança?
Coletar e conferir evidências consome tempo, envolve volume e exige atenção constante. Por isso, vejo espaço para a IA apoiar tarefas nas quais a leitura e a correlação pesam mais do que o julgamento final.
- Organizar evidências e associar cada artefato ao controle correspondente;
- Identificar documentos vencidos e lacunas de periodicidade;
- Relacionar políticas, riscos, critérios e compromissos contratuais;
- Preparar rascunhos de questionários a partir de respostas aprovadas;
- Agrupar alertas semelhantes e apoiar a triagem de incidentes;
- Apontar diferenças entre o controle descrito e a evidência disponível.
Em todas essas frentes, a revisão humana continua necessária. Uma resposta a cliente, a classificação de uma exceção ou a conclusão sobre um incidente exige contexto, autoridade e responsabilização definida.
Quais riscos de IA também precisam ser governados?
O outro lado começa quando a própria adoção de IA vira objeto de controle. Um prompt pode carregar informação confidencial, uma ferramenta pode processar dados de cliente e uma saída plausível pode influenciar uma decisão sem evidência suficiente.
Por isso, estamos olhando para inventário, classificação de dados, fornecedores, acesso, propriedade intelectual, revisão humana e registros de uso. Cada ferramenta precisa ter responsáveis claros, finalidade conhecida e regras proporcionais ao impacto.
The ISO/IEC 42001:2023 oferece uma referência internacional para estabelecer e melhorar um sistema de gestão de inteligência artificial. Ela conversa com a experiência da 27001 porque organiza políticas, responsabilidades, riscos, oportunidades e melhoria contínua.
Na Dattos, uma orientação transparente de uso responsável produziu mais visibilidade do que uma proibição genérica produziria. Quando a liderança explica limites, ferramentas e dados permitidos, as pessoas conseguem perguntar antes e trazer novos casos para avaliação. O nosso conteúdo sobre ética na IA aprofunda essa discussão.
A governança melhora quando o uso deixa rastros, tem responsáveis e continua visível para quem precisa avaliá-lo. Suspeito que os clientes perguntarão sobre isso com a mesma naturalidade com que hoje perguntam sobre segurança em nuvem.
O que eu faria diferente se começasse o SOC 2 hoje?
Eu começaria aceitando que a escassez de material confiável em português é real. Depois, organizaria o projeto ao redor de perguntas sobre serviço, risco e evidência, em vez de procurar um cronograma universal.
| Se eu precisasse recomeçar 1. Iria primeiro às fontes da AICPA e às normas aplicáveis ao trabalho. 2. Usaria o contrato do cliente para desenhar a primeira versão do escopo. 3. Estruturaria o sistema de gestão antes do exame, quando essa escolha fosse possível. 4. Escolheria parceiros que explicassem o raciocínio por trás de cada teste. 5. Desenharia os controles do Tipo 1 já pensando na repetição exigida pelo Tipo 2. |
Começar pela ISO 27001 funcionou para nós porque criou método, responsáveis e um ciclo de melhoria. A evidência apareceu como consequência de uma operação mais organizada, e não como um arquivo produzido apenas para a auditoria.
Também escolheria o auditor pela qualidade da conversa antes da proposta comercial. Uma lista de pendências resolve o que está visível naquele momento. A explicação do raciocínio continua sendo útil depois que a pendência desaparece.
| “O certificado tem data de validade. O hábito de perguntar antes, não.” |
FAQ: quais são as dúvidas mais comuns sobre SOC 2?
As respostas abaixo servem como consulta rápida. O escopo final, os critérios e o enquadramento profissional de cada trabalho precisam ser alinhados com a firma responsável pelo exame.
SOC 2 é uma certificação?
Não. SOC 2 é um relatório de asseguração emitido após o exame de controles de uma organização prestadora de serviços. A administração descreve o sistema e apresenta uma afirmação; o auditor independente aplica procedimentos e emite sua opinião.
Quem pode emitir um relatório SOC 2?
O trabalho deve ser realizado por uma firma e profissionais habilitados para aplicar os padrões profissionais da AICPA. A própria AICPA recomenda que as organizações avaliem qualificação, licenciamento, independência e participação em processos de revisão de qualidade.
Quanto tempo leva para concluir um SOC 2?
Não existe um prazo universal. O tempo depende do escopo, da maturidade dos controles, da disponibilidade de evidências, do tratamento das lacunas e, no Tipo 2, do período que será examinado.
A ISO 27001 substitui o SOC 2?
Não. A ISO/IEC 27001 estrutura um sistema de gestão e pode resultar em certificação. O SOC 2 entrega um relatório detalhado sobre controles de um sistema de serviços. A sobreposição reduz esforço, mas os resultados atendem necessidades diferentes.
O que um cliente deve observar em um relatório SOC 2?
Vale conferir o sistema descrito, os serviços incluídos, os critérios avaliados, o tipo e o período do relatório, a opinião do auditor, as exceções encontradas e as responsabilidades complementares esperadas do cliente.
O que fica depois do relatório?
Quando comecei, eu via ISO 27001 e SOC 2 como projetos com linha de chegada. Hoje, penso neles como duas maneiras de observar a mesma operação. A ISO organiza o sistema de gestão; o SOC 2 exige que o serviço e seus controles sejam explicados com precisão.
O aprendizado mais importante apareceu fora dos documentos. Ele surgiu quando alguém perguntou antes de compartilhar um arquivo, quando um gestor questionou um acesso, quando um fornecedor foi avaliado antes da contratação e quando uma falha virou melhoria registrada.
Relatórios têm datas, certificados passam por novos ciclos e riscos continuam mudando. O hábito de perguntar antes, registrar decisões e tratar exceções precisa continuar no dia seguinte.
Se a sua empresa processa operações financeiras em grande escala, vale conhecer como a plataforma Dattos combina automação, rastreabilidade e governança. A tecnologia amplia a capacidade da equipe, enquanto a confiança continua dependendo do que existe por trás dela.
