2026-07-21 · GUIA · A equipe da Offensive Technology

Com que frequência você deve realizar um teste de intrusão?

Resposta curta: pelo menos uma vez a cada 12 meses e novamente após qualquer alteração significativa nos sistemas no escopo. Essa regra em duas partes, calendário mais alteração, é o piso prático em todos os frameworks que um comprador encontra. Apenas o PCI DSS a estabelece como um requisito rígido. O SOC 2 e a ISO 27001 não definem uma frequência; eles são baseados em risco, e a cadência anual tornou-se simplesmente a expectativa dos auditores. Se o seu ambiente publica código toda semana ou lida com dados de alto valor, uma vez por ano é um piso a ser superado, não uma meta a ser atingida.

A pergunta surge porque "anual" parece uma regra vinda de algum órgão oficial. Para um padrão, realmente é. Para os outros, é uma convenção que surgiu em torno de uma linguagem baseada em risco, e saber qual é qual evita que você compre demais ou seja pego desprevenido em uma auditoria. Aqui está o que cada um realmente diz.

A versão curta, por framework

Quatro coisas levam a maioria dos compradores a um teste: uma processadora de cartões, um relatório SOC 2, um certificado ISO ou um formulário de seguro. Apenas um deles prescreve um número.

A regra em duas partes: calendário mais alteração

Toda resposta credível sobre frequência consiste em duas regras combinadas, e ignorar qualquer uma delas deixa uma brecha.

A parte do calendário existe porque um teste de intrusão é um exercício pontual. Ele descreve os sistemas no escopo, durante a janela de teste, em relação às técnicas nas regras de engajamento. Novas classes de vulnerabilidades são descobertas, novos exploits são publicados e sua equipe continua lançando código. Um teste anual reinicia esse relógio antes que o cenário fique defasado demais.

A parte da alteração existe porque o calendário não sabe quando você reconstruiu seu fluxo de autenticação ou expôs uma nova API. Um teste de março não diz nada sobre o serviço lançado em junho. É por isso que todo framework sério combina "pelo menos a cada 12 meses" com "e após qualquer alteração significativa", e é essa a metade que os compradores mais ignoram.

O que conta como uma alteração significativa

O PCI DSS deixa a definição de "significativa" para cada organização definir e defender, mas os exemplos do setor são consistentes. Considere qualquer um destes itens como um gatilho para testar o escopo afetado, independentemente de quando o último teste anual foi realizado:

• Um lançamento principal de aplicação ou a reescrita de um componente relevante para a segurança.
• Um novo serviço, subdomínio ou API voltado para a internet que amplia o alcance de um atacante.
• Uma migração para a nuvem, ou uma alteração material na arquitetura de nuvem ou IAM.
• Uma alteração na autenticação, single sign-on ou gerenciamento de sessão.
• Uma alteração na segmentação de rede, regras de firewall ou no modo como os ambientes são isolados.
• Uma aquisição ou uma nova integração com terceiros que incorpora a superfície de outro ambiente ao seu.

O ponto em comum é a exposição. Se a alteração modifica o que é acessível externamente, como a identidade é comprovada ou onde fica a fronteira de confiança, o último teste já não reflete a realidade.

O que cada framework realmente diz

O PCI DSS v4.0 é o prescritivo. O Requisito 11.4 exige testes de intrusão internos e externos pelo menos uma vez a cada 12 meses e após qualquer atualização ou alteração significativa de infraestrutura ou aplicação, seguindo uma metodologia documentada baseada em uma abordagem aceita pelo setor, como a NIST SP 800-115. Quando a segmentação é usada para manter sistemas fora do ambiente de dados de portadores de cartão, essa segmentação é testada pelo menos a cada 12 meses para comerciantes e pelo menos a cada 6 meses para provedores de serviços, e as descobertas são retestadas após a remediação. Esta é a resposta mais clara sobre "com que frequência" que qualquer um dos frameworks fornece.

O SOC 2 não especifica frequência. Os AICPA Trust Services Criteria são formulados como objetivos, não como cronogramas, portanto não há uma linha exigindo um teste anual. Na prática, os auditores esperam pelo menos um teste por ano, planejado para ocorrer dentro da janela de observação do Type 2. Escrevemos em detalhes quais critérios apontam para testes em o SOC 2 exige um teste de intrusão?

A ISO/IEC 27001 é explicitamente baseada em risco. Ela exige o gerenciamento de vulnerabilidades técnicas e a verificação de controles, vinculando a frequência à sua própria avaliação de risco e plano de tratamento, em vez de a um calendário fixo. Organizações certificadas convergem para testes anuais como a linha de base defensável, com ativos de maior risco sendo testados com mais frequência. A justificativa do número cabe a você, não é uma constante imposta.

O seguro cibernético depende da seguradora. Algumas apólices perguntam se você realiza testes regularmente e tratam "anualmente" como a resposta esperada; outras nem perguntam. A atitude correta é ler o formulário de proposta específico em vez de presumir, que é o tema de preciso de um pentest para o seguro cibernético?

Quando uma vez por ano não é suficiente

Anual é o piso, e alguns ambientes superam essa necessidade rapidamente. Teste com mais frequência quando:

• Você faz implantações contínuas. Se a produção muda semanalmente, um teste anual fica defasado durante onze meses do ano. Equipes nessa situação passam a adotar testes por versão em fluxos críticos ou um modelo de testes contínuos, mantendo o teste anual completo como âncora.
• Você armazena dados de alto valor. Pagamentos, registros de saúde e grandes volumes de dados pessoais aumentam o custo de um erro, o que justifica testes mais frequentes nos sistemas que lidam com eles.
• Você acabou de passar por um susto. Após um incidente, um quase incidente ou uma vulnerabilidade crítica em um componente do qual você depende, retestar a área afetada é mais barato do que presumir que a correção foi limpa.

Nada disso substitui o teste anual. Tudo isso se soma a ele, pois um trabalho completo e escopado por profissionais seniores tem uma profundidade diferente do que um reteste direcionado de uma única alteração.

O erro: tratar a data como o entregável

A forma mais comum de errar na frequência é tratar o pentest como um certificado com data de validade, executá-lo no último dia válido e não alterar nada do que foi aprendido. Um teste contratado apenas para cumprir requisitos costuma ter um escopo reduzido para passar e ser superficial a ponto de não notar como um atacante realmente invadiria. A data no relatório satisfaz o auditor; ela não torna o seu ambiente mais difícil de ser comprometido.

Entre os testes programados, sua exposição continua mudando, quer você observe ou não: um subdomínio esquecido, um serviço que nunca deveria ter sido público, uma credencial em um vazamento. Conhecer sua superfície de ataque externa de forma contínua é o complemento acessível para a profundidade periódica, e não é o mesmo tipo de contratação que um pentest. Se você ainda está tentando entender de qual serviço realmente precisa em primeiro lugar, verificação, varredura ou pentest completo? define as diferenças.

Com que frequência você deve realizar um teste de intrusão? Respostas rápidas

Com que frequência você deve realizar um teste de intrusão?

Pelo menos uma vez a cada 12 meses e novamente após qualquer alteração significativa nos sistemas no escopo. Essa regra em duas partes é o piso prático entre os padrões com os quais os compradores se preocupam. Ambientes dinâmicos ou com dados de alto valor devem realizar testes com mais frequência, até mesmo por versão ou de forma contínua.

O PCI DSS exige teste de intrusão anual?

Sim. O Requisito 11.4 do PCI DSS v4.0 exige testes de intrusão internos e externos pelo menos uma vez a cada 12 meses e após qualquer alteração significativa de infraestrutura ou aplicação. Onde a segmentação isola o ambiente de dados de portadores de cartão, a segmentação é testada pelo menos a cada 12 meses para comerciantes e pelo menos a cada 6 meses para provedores de serviços.

Com que frequência o SOC 2 e a ISO 27001 exigem um pentest?

Nenhum dos dois especifica uma frequência fixa. Ambos são baseados em risco: o SOC 2 deixa as evidências a critério do seu auditor, e a ISO 27001 vincula os testes à sua avaliação de risco. Na prática, a frequência anual tornou-se a cadência aceita e esperada pelos auditores, planejada para ocorrer dentro da janela de observação do SOC 2 Type 2.

Quando você deve realizar testes fora do ciclo anual?

Após qualquer alteração significativa: um lançamento principal, um novo serviço ou subdomínio voltado para a internet, uma migração para a nuvem, uma alteração de autenticação ou SSO, uma alteração de rede ou segmentação, ou uma aquisição. O último teste descrevia apenas o ambiente como ele estava naquele dia.

Fontes

• PCI Security Standards Council, PCI DSS v4.0 Requisito 11.4 (metodologia de teste de intrusão, frequência e teste de segmentação).
• AICPA Trust Services Criteria (SOC 2), redigidos como objetivos baseados em risco, sem frequência de teste fixa.
• ISO/IEC 27001, gerenciamento de vulnerabilidades técnicas baseado em risco e verificação de controles.
• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, citado como uma metodologia aceita.

Leitura relacionada

• O SOC 2 exige um teste de intrusão?
• Preciso de um pentest para o seguro cibernético?
• Quanto custa um teste de intrusão?