← Artigos

De quanto em quanto tempo fazer pentest

Publicado em 24 de abril de 2026 · 10 min de leitura

1. Resposta curta: mínimo anual, mais frequente sob pressão externa

No Brasil, a cadência de pentest depende de três forças. O piso é anual: auditoria externa e contrato genérico assumem esse mínimo sem texto explícito pedindo mais. A segunda força é exigência externa — cliente enterprise, auditor SOC 2, regulador setorial. A terceira são eventos técnicos fora do calendário: nova superfície pública, mudança de arquitetura, módulo crítico novo.

Os dois modos precisam coexistir. Pentest anual sem atenção aos eventos da aplicação vira ritual de conformidade: o relatório chega, o certificado renova, a aplicação mudou e ninguém testou o que mudou. Pentest só por evento, sem calendário fixo, deixa risco silencioso acumular: nada dispara o teste, o atestado envelhece, a auditoria chega com documento de 18 meses. A cadência certa combina os dois.

Uma ressalva antes de continuar: continuous testing e PTaaS fazem sentido para organização com time interno de segurança dedicado. Este artigo não trata disso. O foco é em quem compra pentest de fornecedor externo em ciclos discretos, que é o padrão do mercado brasileiro.

As próximas seções tratam cada eixo em separado. A seção 2 explica por que anual é o piso. A seção 3 lista as cinco situações que sobem pra semestral. A seção 4 cobre os eventos técnicos fora do ciclo. A seção 5 separa reteste de novo pentest. O artigo fecha com um checklist de oito perguntas.

2. Por que "anual" é o piso defensável

A palavra "anual" não aparece na LGPD nem em nenhuma lei brasileira como número fixo para pentest. É uma cadência que três referências de mercado convergem a tratar como mínimo, e é isso que a torna o piso defensável.

A primeira referência é a ISO 27001:2022. O Anexo A traz o controle A.8.8 (Management of technical vulnerabilities, que substitui o A.12.6.1 da versão 2013) e o A.8.29 (Security testing in development and acceptance, que unifica A.14.2.8 e A.14.2.9 da versão 2013). Auditores de ISO 27001 aceitam pentest externo anual como evidência de cumprimento desses controles em organizações de porte médio. Uma nota direta: ISO 27001 é norma voluntária no Brasil, não lei. Vale como referência de mercado e exigência de contrato, mas não como obrigação legal automática.

A segunda referência são os SOC 2 Trust Services Criteria. Os critérios CC4.1 (monitoring activities) e CC7.1 (vulnerability management) exigem evidência de que a organização identifica vulnerabilidades com cadência. Pentest externo anual é a forma padrão de atender. Relatórios acima de 12 meses são rotineiramente recusados em vendor security review: o auditor pede evidência recente e um documento de 15 meses não passa.

A terceira referência é a prática de mercado em vendor security questionnaires. Grandes compradores enterprise mantêm formulário padronizado que pergunta a data do último pentest. Fornecedor com documento acima de 12 meses leva "não satisfatório" na resposta. Virou fato de mercado, mesmo sem norma escrita exigindo.

Ciclo acima de 12 meses tem três efeitos práticos. Vulnerabilidades se acumulam porque a superfície muda: novas libs, novas integrações, novos endpoints. O relatório perde valor contratual: cláusula de MSA que pede "atestado vigente" não aceita documento com 14 meses. E o próximo pentest custa mais trabalho: o pentester re-enumera quase do zero em vez de partir de linha de base documentada.

Anual é o piso. A seção seguinte trata dos casos onde esse piso sobe para semestral.

3. Quando a cadência precisa ser semestral

No Brasil, quem exige pentest semestral raramente é a lei. É o contrato ou o regulador setorial. Cinco situações concretas explicam quando o piso anual sobe.

1. Cliente enterprise brasileiro com cláusula no MSA. Grandes clientes B2B no Brasil — bancos, seguradoras, varejistas de grande porte, operadoras de telefonia — mantêm programa de vendor risk. Para fornecedor classificado como crítico, o MSA inclui cláusula de pentest. Quando o fornecedor é SaaS processando dado sensível do cliente, o texto costuma ser explícito: pentest externo a cada 6 meses, conduzido por terceiro independente, com entrega de atestado formal e sumário executivo ao contratante em até 30 dias da conclusão. Quem não leu o MSA antes de assinar descobre essa exigência no segundo semestre do contrato, quando o orçamento já foi fechado como anual.

2. Cliente enterprise estrangeiro via SOC 2 ou vendor security questionnaire. SaaS brasileiro vendendo para o mercado americano ou europeu esbarra no vendor questionnaire do comprador. A expectativa padrão é pelo menos anual e após mudança relevante. Compradores regulados — fintech americana, hospital sob HIPAA, empresa pública com SOX — sobem para semestral. Ou a cadência se adequa ou a negociação para. O SOC 2 em si não impõe número fixo, mas o auditor do comprador define o que aceita como evidência.

3. PCI DSS. Processadora de cartão ou qualquer entidade com ambiente de dados de cartão (CDE) opera sob PCI DSS. A versão 4.0 exige pentest externo e interno pelo menos anual e após mudança ou upgrade relevante (Requirements 11.4.3 e 11.4.4). Segmentação de rede do CDE pede pentest específico de segmentação a cada 6 meses (Requirement 11.4.5; service providers seguem o Requirement 11.4.6). O que conta como "mudança significativa" é definido pela própria entidade, mas deve estar documentado. Sem documentação, qualquer mudança pode ser questionada pelo QSA.

4. Participante Open Finance ou Open Insurance. Instituições participantes do ecossistema Open Finance ou Open Insurance seguem o manual de segurança do Banco Central, que exige testes periódicos de intrusão nas APIs regulatórias. A cadência é definida pelo manual de segurança vigente. Transmissor ou receptor de dados tem obrigação direta. Quem não é participante mas fornece sistema para um participante pode herdar a exigência via contrato de prestação de serviço.

5. Cadeia de fornecedor de banco ou seguradora. Banco e seguradora no Brasil operam sob supervisão do BCB e da Susep e repassam exigências de segurança para a cadeia via contrato de terceirização. Fornecedor que toca dado de cliente de banco ou integra com core de seguradora recebe cláusula de pentest semestral como obrigação contratual, mesmo sem ser participante direto da regulação. Isso vale para SaaS de BPO, vendor de core banking, gateway de integração e qualquer serviço classificado como prestador de serviço relevante pelo banco contratante.

A cláusula típica em MSA segue este formato: "O Contratado realizará, às suas expensas, teste de intrusão semestral na aplicação, conduzido por terceiro independente, com entrega de atestado formal e sumário executivo ao Contratante em até 30 dias da conclusão." Conhecer o formato antes de assinar evita descobrir semestral no segundo ano com orçamento dimensionado como anual.

4. Eventos que disparam pentest extra fora do ciclo

O ciclo anual ou semestral parte do princípio de que a aplicação fica estável entre um pentest e o próximo. Quando muda em dimensão que afeta superfície ou arquitetura, o relatório anterior deixou de descrever o alvo atual. O ciclo programado não basta.

1. Nova superfície exposta à internet. Novo subdomínio público, nova API externa, portal antes interno que passou a ser externo, integração que começou a receber requisições de terceiro. Um SaaS que só tinha painel do cliente acessível ao público abre webhook público para integrar com parceiro. O pentest anterior não cobriu o webhook. Pentest extra com escopo restrito à nova superfície resolve sem repetir o que já foi testado.

2. Mudança de arquitetura. Monolito dividido em microsserviços, migração de nuvem, troca de banco de dados, substituição de gateway de pagamento, mudança de framework core. Cada mudança dessas introduz classes de risco novas. Migração de Heroku para Kubernetes na AWS é o caso mais comum: herda configuração de rede, IAM, secrets management e controle de acesso entre serviços que o Heroku abstraía. O pentest feito no Heroku testou um alvo que não existe mais.

3. Novo módulo crítico. Área administrativa nova, portal de cliente novo, processo antes atendido manualmente que foi convertido em self-service. Novo módulo é nova superfície de ataque. Um banco digital que lança área de investimentos com fluxos próprios de autorização e integração com corretora tem endpoints que o pentest do módulo transacional original não tocou.

4. Volume de mudança grande. Várias releases sem pentest em período de desenvolvimento ativo acima de 6 meses, refactor de componente core, reescrita de camada de autenticação, adoção de lib crítica nova. O relatório virou descrição do passado. Identificar esse ponto é subjetivo, mas a heurística é prática: se o pentester precisaria re-enumerar grande parte dos endpoints do zero, faz mais sentido fazer pentest novo do que tentar aplicar o escopo do relatório anterior.

Quem fez pentest em janeiro e entrega refactor de autenticação em agosto não precisa esperar janeiro seguinte. Pentest extra em setembro, com escopo delimitado à mudança, custa menos em risco do que quatro meses de exposição sem cobertura.

5. Reteste não é novo pentest

A confusão é comum. O comprador recebeu relatório com 12 findings, corrigiu tudo, quer que o reteste valha como pentest do ano seguinte. Em auditoria, isso cria problema.

Reteste é validação das correções dos findings já reportados. O escopo é restrito à lista do relatório original: o pentester confirma que cada fix fechou a vulnerabilidade sem reintroduzir problema. No PentestAI, a janela é de 30 dias após a entrega do relatório, sem custo adicional. O resultado é um atestado atualizado com status final de cada finding.

Novo pentest é exploração completa. O pentester re-enumera endpoints, refaz reconhecimento, redescobre a aplicação no estado atual. Pode achar vulnerabilidades que o relatório anterior não mencionava: a aplicação mudou, o pentester encontrou caminhos novos, o panorama evoluiu desde o último teste.

A distinção importa em auditoria porque vendor security questionnaire e auditor SOC 2 pedem pentest da aplicação no último período. Relatório de reteste cobre só os findings originais. Se a aplicação ganhou 5 novos endpoints entre o pentest e o reteste, nenhum foi testado no reteste. Apresentar o reteste como pentest do ciclo anual é risco concreto de reprovação no vendor review.

No pacote do PentestAI por R$5.000, o ciclo é pentest, correção, validação e atestado atualizado. Reteste está incluso na janela de 30 dias. Reteste não substitui o próximo pentest anual ou semestral. São etapas diferentes.

Reteste é a última etapa do ciclo atual, não a primeira do próximo.

6. Checklist: que cadência o seu caso pede

Antes de definir cadência, responda oito perguntas. Cada uma tem resposta direta.

Cenário composto é mais comum do que parece. SaaS brasileiro vendendo para os EUA com SOC 2, ao mesmo tempo fornecedor de banco brasileiro e processando cartão, tem três exigências sobrepostas. A cadência mais restritiva prevalece. Semestral cobre anual; anual não cobre semestral.

Próximos passos

Se você chegou até aqui, provavelmente tem dois passos em aberto: mapear qual situação do seu caso exige semestral ou anual, e calibrar o orçamento anualizado de segurança de aplicação a partir disso.

O custo anualizado da cadência sai do preço do pentest avulso multiplicado pelo número de execuções no ano. Para entender como esse número se forma, o artigo quanto custa um pentest no Brasil cobre as variáveis que afetam o preço por execução. Se a pressão vem da LGPD e não do contrato do cliente, o artigo sobre pentest e LGPD cobre o recorte regulatório.

Quer ajuda para mapear qual cadência o seu contrato pede? Conte o caso para a WiserSecurity. A resposta chega em menos de um dia útil.