Pentest para SOC 2: o que auditores exigem em 2026

Resumo:

• O AICPA aponta o pentest para SOC 2 como o principal exemplo de avaliação no critério CC4.1. Por isso, o teste se tornou o padrão adotado pelo mercado para comprovar que os controles realmente funcionam.
• No SOC Tipo 2, o pentest precisa ter sido realizado dentro do período de auditoria. Um relatório de pentest fora da janela de auditoria não conta como evidência válida.
• O scan automatizado não substitui o pentest no SOC 2. Auditores rejeitam avaliações baseadas apenas em ferramentas automatizadas, incluindo plataformas de IA. O critério CC4.1 requer testes adversariais com validação humana.
• O relatório precisa conter elementos específicos para ser aceito: sumário executivo, achados com CVSS scores, evidência de exploração, mapeamento para os Trust Services Criteria e laudo de reteste com correções validadas.

A certificação SOC 2 tecnicamente não exige pentest. Por isso, algumas empresas chegam à auditoria sem um e, por isso, precisam demonstrar, de outra forma, que seus controles de segurança funcionam corretamente.

Em 2026, o pentest se tornou a forma mais aceita e reconhecida de demonstrar que os controles de segurança funcionam efetivamente. O AICPA o cita como principal exemplo de avaliação separada no CC4.1, o que o posicionou como padrão do mercado.

Este artigo explica o que o SOC 2 realmente exige, por que o pentest virou o padrão do mercado, como ele mapeia para cada critério e o que o relatório precisa conter para o auditor aceitar.

O que é SOC 2?

SOC 2 (Service Organization Control 2) é um framework de auditoria desenvolvido pelo AICPA (American Institute of Certified Public Accountants) para avaliar se organizações de serviços gerenciam dados de clientes de forma segura. Diferentemente de certificações como ISO 27001, o SOC 2 é um relatório de auditoria emitido por uma firma auditora independente, que atesta como os controles de segurança da organização funcionaram em um período específico.

O Report on Controls é o relatório que clientes enterprise americanos pedem antes de contratar qualquer fornecedor que processe seus dados.

Quem precisa de SOC 2?

O SOC 2 é praticamente obrigatório para qualquer empresa que venda software ou serviços para clientes enterprise nos Estados Unidos, isso inclui:

• SaaS B2B com clientes americanos. A maioria das empresas de médio e grande porte nos EUA exige SOC 2 de seus fornecedores de software.
• Fintechs e healthtechs com parceiros americanos, especialmente quando há Business Associate Agreement (BAA) ou processamento de dados financeiros.
• Empresas brasileiras em expansão internacional  que precisam do relatório para competir em processos de avaliação de fornecedores nos EUA e na Europa.
• Qualquer empresa que processe, armazene e/ou transmita dados de clientes em infraestrutura própria ou terceirizada.

Para startups brasileiras, o SOC 2 costuma ser o primeiro obstáculo em contratos enterprise nos EUA, e o pentest é frequentemente o documento mais solicitado no processo.

Os 5 Trust Service Criteria 

O SOC 2 é estruturado em torno de cinco Trust Service Criteria (TSC). A maioria das organizações começa com Security, que é obrigatório. Os outros quatro são opcionais, a empresa escolhe quais incluir no escopo conforme o que for relevante para seus clientes.

Para o pentest, o critério que sempre se aplica é o Security (série CC). Os demais critérios podem ser reforçados dependendo do escopo, mas é no Security que o auditor busca evidência do teste ofensivo.

SOC 2 Tipo 1 vs. Tipo 2: o que muda para o pentest

A diferença entre Tipo 1 e Tipo 2 é fundamental para entender o papel do pentest em cada auditoria:

Atenção para o Tipo 2: o pentest precisa ter sido realizado dentro do período de auditoria. Um relatório de pentest produzido fora da janela, mesmo que recente, não conta como evidência válida para SOC Tipo 2. Se o período de auditoria cobre janeiro a dezembro, o pentest precisa ter acontecido nesse intervalo, com remediação e reteste concluídos antes do fechamento da janela.

Pentest para SOC 2 é obrigatório?

O AICPA não menciona o nome pentest nos Trust Services Criteria. O que o CC4.1 diz é que a gestão deve usar “avaliações contínuas e separadas variadas, incluindo testes de intrusão”. O pentest é o primeiro exemplo dessa lista, e isso muda como o auditor avalia a evidência. 

O CC4.1 é interpretado como o critério que exige evidência de que a empresa identificou seus riscos ativamente, testou se os controles resistem e respondeu aos achados. O pentest é a forma mais direta e reconhecida de produzir essa evidência. 

Sem ele, a empresa precisa demonstrar, por outros meios, que satisfaz o critério, o que costuma exigir uma documentação mais elaborada.

Quando a evidência apresentada não é suficiente, o auditor pode emitir uma opinião qualificada: um registro de exceção que ficará visível para todo cliente que revisar o relatório. A maioria das empresas prefere o custo do pentest ao custo de explicar o que aconteceu para um time de aquisições com quem está negociando.

Há três razões pelas quais o pentest é o padrão aceito:

• Você identificou seus riscos ativamente: um pentest com escopo alinhado ao limite do sistema demonstra que a empresa tentou encontrar todas as vulnerabilidades exploráveis.
• Você testou se os controles funcionam: firewalls, autenticação, controles de acesso e criptografia só são significativos se resistirem a tentativas reais de ataque. O pentest valida isso.
• Você respondeu aos achados: auditores querem ver que vulnerabilidades foram corrigidas e retestadas. Um relatório com achados críticos em aberto e sem laudo de reteste é um sinal de alerta.

Como o pentest mapeia para os Trust Services Criteria

Relatórios de pentest com um anexo de mapeamento para os Trust Services Criteria reduzem bastante o trabalho interpretativo do auditor. Sem esse mapeamento, é o auditor quem precisa fazer essa conexão sozinho.

O que o relatório de pentest precisa conter para o auditor aceitar

Nem todo relatório de pentest satisfaz auditores de SOC 2. Para que isso aconteça, o relatório precisa incluir:

Sumário executivo

Visão geral do escopo, metodologia, nível de risco geral e principais achados em linguagem acessível para não-técnicos. O auditor usa esse sumário para entender o contexto antes de avaliar os detalhes técnicos.

Escopo alinhado ao limite do sistema

O escopo do pentest deve corresponder ao limite do sistema descrito no relatório SOC 2. Se o relatório cobre uma aplicação SaaS específica, suas APIs e a conta AWS associada, é exatamente isso que precisa ser testado. Auditores verificam alinhamento entre os dois documentos.

Achados com CVSS scores e evidência de exploração

Cada achado precisa de: título, classificação de criticidade baseada em CVSS, evidência técnica de exploração, impacto de negócio e recomendação específica de correção. Sem evidência de exploração, o auditor não consegue distinguir achados validados de saída de scanner.

Mapeamento para Trust Services Criteria

Um anexo que conecta cada achado ao critério correspondente (CC4.1, CC6.1, CC7.1, etc.). Auditores de SOC 2 trabalham com a linguagem dos critérios e relatórios que falam essa linguagem reduzem o trabalho de interpretação e aceleram o processo.

Relatório de reteste com status de cada achado

Documento separado confirmando, após as correções, que cada vulnerabilidade foi de fato resolvida. Auditores querem ver evidência de que os achados foram remediados antes do fechamento da janela de auditoria.

Carta de atestado do fornecedor

Documento formal identificando o fornecedor, o profissional que executou o teste, as certificações relevantes e o período de cobertura. Auditores verificam que o teste foi conduzido por profissional independente e qualificado.

Sinais de alerta que auditores observam

Um relatório de pentest com achados críticos em aberto e sem relatório de reteste é uma das situações mais problemáticas em uma auditoria de SOC 2. O auditor não pode atestar que os controles funcionaram se vulnerabilidades críticas foram identificadas e não há evidência de que foram corrigidas.

Scan automatizado não substitui pentest no SOC 2

Ferramentas de scan automatizado, incluindo plataformas de IA de pentest, identificam padrões de vulnerabilidades conhecidas. São úteis para monitoramento contínuo entre os ciclos de pentest, mas não satisfazem o CC4.1 como evidência primária.

O CC4.1 requer testes que validem se os controles resistem a tentativas reais de ataque. Scanners não encadeiam vulnerabilidades, não identificam falhas de lógica de negócio e não geram a evidência de exploração que os auditores precisam para atestar que os controles funcionam.

Frequência e timing do pentest para SOC 2

O AICPA não especifica frequência mínima de pentest. O padrão de mercado estabelecido é anual, com pentest adicional após mudanças significativas no ambiente ou no produto. Para SOC 2 Tipo 2, o timing é crítico:

• O pentest precisa estar dentro da janela de auditoria, tipicamente de 6 a 12 meses. Um relatório produzido antes do início do período não conta.
• A remediação e o reteste precisam estar concluídos antes do fechamento da janela. Achados críticos abertos no final do período são um sinal de alerta.
• A recomendação é realizar o pentest no início do período de auditoria. Isso deixa tempo para corrigir, retestar e documentar antes que o auditor comece a coletar evidências.
• Alguns auditores aceitam um pentest que cobre parte do período, mas o ideal é que a cobertura se estenda por todo a auditoria.

Um erro frequente: empresas que percebem, semanas antes do fechamento da auditoria, que não possuem um pentest válido para o período avaliado. 

Com apenas 30 dias para contratar um fornecedor, executar o teste, corrigir os achados e documentar tudo, o tempo disponível para conduzir esse trabalho é escasso. Já a empresa que realiza o pentest no início do período chega ao encerramento com evidências organizadas.

Quando scan de vulnerabilidades é relevante no contexto SOC 2

Embora não substitua o pentest, o scan automatizado tem seu papel no programa de segurança de uma empresa com SOC 2. Auditores frequentemente buscam evidência de gestão contínua de vulnerabilidades, que é diferente de pentest periódico.

• CC7.1 exige um processo para detectar vulnerabilidades introduzidas no sistema. O scan contínuo ou mensal evidencia esse processo de monitoramento.
• A combinação de scan contínuo + pentest anual cobre tanto o monitoramento periódico quanto a validação adversarial profunda.
• Logs de scan com evidência de triagem e remediação das vulnerabilidades identificadas reforçam a evidência de CC7.1.

Ou seja, o scan mostra que você monitora e o pentest comprova que os controles resistem quando testados.

Auditoria sem achados com o Pentest para SOC 2 da Vantico 

Com a Vantico, você tem um pentest pensado para SOC 2 desde o escopo, garantindo uma cobertura orientada àquilo que o auditor irá buscar.

Entregamos um relatório com evidência técnica de exploração por achado, mapeamento explícito para os Trust Services Criteria, relatório de reteste e carta de atestado. Além disso, garantimos o reteste sem custo adicional e ilimitado por 90 dias.

Se sua janela de auditoria já está aberta, o momento de iniciar é agora. Clique para conhecer o pentest da Vantico.

FAQ: Perguntas frequentes

Pentest para SOC 2 é obrigatório?

Não diretamente. O SOC 2 não usa a palavra pentest em nenhum critério. O AICPA cita testes de intrusão como o principal exemplo de avaliação separada no CC4.1, tornando o pentest a forma mais eficiente e reconhecida de evidenciar que os controles funcionam. Empresas sem pentest podem ser aprovadas, mas precisam demonstrar por outros meios que seus controles operaram de forma efetiva durante o período.

Qual a diferença entre SOC 2 Tipo 1 e Tipo 2 para o pentest?

No Tipo 1, o auditor avalia se os controles estão desenhados e implementados em um momento específico. O pentest é útil, mas menos crítico, e serve para provar que o controle existe. Já no Tipo 2, o auditor avalia se os controles funcionaram efetivamente durante um período de 6 a 12 meses. Aqui o pentest é a forma mais eficiente de evidenciar isso e precisa ter sido realizado dentro da janela de auditoria, com remediação e reteste concluídos antes do fechamento do período.

O pentest precisa ser realizado dentro do período de auditoria SOC 2?

Sim, especialmente para Tipo 2. Um relatório de pentest produzido antes do início do período de auditoria não conta como evidência válida para cobrir aquele período. Assim como o pentest, o reteste que confirma as correções precisa também estar concluído antes do fechamento da janela. A recomendação é realizar o pentest no início do período.

O que o relatório de pentest precisa conter para o auditor de SOC 2 aceitar?

Sumário executivo com metodologia e nível de risco geral, escopo alinhado ao limite do sistema do SOC 2 report, achados com CVSS scores e evidência técnica de exploração por achado, mapeamento explícito dos achados para os Trust Services Criteria relevantes (CC4.1, CC6.1, CC7.1, etc.), relatório de reteste confirmando que os achados foram remediados, e carta de atestado identificando o fornecedor e o profissional que executou o teste. Sem esses elementos, o auditor pode solicitar evidências complementares.

Com que frequência devo fazer pentest para manter o SOC 2?

Anual é o mínimo aceito pelo mercado. Para SOC Tipo 2, o pentest precisa estar dentro de cada período de auditoria. Além do ciclo anual, um pentest adicional é recomendado após mudanças significativas no ambiente: novos módulos, migrações de infraestrutura ou mudanças de arquitetura. Empresas com múltiplos clientes enterprise que fazem avaliação de fornecedores de modo frequente podem considerar o pentest semestral para ter sempre um relatório recente disponível.

O pentest para SOC 2 precisa ser diferente de um pentest regular?

Existem diferenças no escopo, na documentação e no mapeamento. O escopo precisa ser alinhado ao limite do sistema do SOC 2, o relatório precisa conter mapeamento para Trust Services Criteria e a aplicação precisa estar dentro da janela de auditoria. Um pentest bem executado com esses elementos satisfaz tanto os requisitos de compliance quanto os objetivos de segurança. Fornecedores com experiência em SOC 2 estruturam o relatório para facilitar o trabalho do auditor desde o início.