O pentest para ISO 27001 avalia se vulnerabilidades em aplicações, APIs, redes ou ambientes de cloud podem ser exploradas. Dentro do Sistema de Gestão de Segurança da Informação (SGSI), os resultados ajudam a avaliar controles técnicos, priorizar o tratamento de riscos e demonstrar o que foi feito após a identificação das falhas.
A ISO/IEC 27001:2022 não exige um pentest isolado nem define uma frequência anual universal. A necessidade dos testes depende da avaliação de riscos, dos controles selecionados, das políticas e dos contratos da organização.
Este guia mostra como planejar o pentest para ISO 27001: definir o escopo, preparar acessos, escolher o fornecedor e organizar os resultados para a auditoria. Para entender as exigências da norma em mais detalhe, consulte o artigo sobre requisitos de pentest e frequência na ISO 27001.
Pentest para ISO 27001: respostas rápidas
- É obrigatório? Não existe uma obrigação universal de pentest. O teste pode ser necessário pelo plano de tratamento de riscos, pelas políticas ou por compromissos contratuais.
- Quais controles ele apoia? Principalmente A.8.8, sobre gestão de vulnerabilidades técnicas, e A.8.29, sobre testes de segurança no desenvolvimento e na aceitação.
- O que testar? Os sistemas, fluxos de dados e limites de acesso relacionados aos riscos incluídos no escopo do SGSI.
- Quando realizar? Conforme o risco e os compromissos da organização, com novas avaliações após mudanças relevantes quando necessário.
- O que guardar? Escopo, datas, metodologia, relatório, registros de correção, decisões sobre risco e resultados do reteste.
O que é um pentest voltado à ISO 27001?
É uma avaliação de segurança autorizada, com sistemas e objetivos definidos para investigar riscos relevantes ao SGSI. A equipe testa cenários de abuso, confirma a explorabilidade das vulnerabilidades e documenta impacto e recomendações de correção.
Em um SaaS, isso pode incluir verificar se um cliente consegue baixar documentos de outro, se uma conta de suporte pode executar funções administrativas ou se uma credencial de serviço permite acessar dados de outros sistemas. O objetivo é testar afirmações concretas sobre os controles de segurança.
A ISO/IEC 27001 estabelece requisitos para o SGSI; a ISO/IEC 27002 oferece orientações sobre controles. O organismo certificador avalia o sistema de gestão e decide sobre a certificação. Um relatório de pentest não é um certificado ISO 27001.
Como relacionar o teste aos controles e ao tratamento de riscos?
A Declaração de Aplicabilidade registra os controles necessários, a justificativa para sua inclusão, o estado de implementação e as exclusões justificadas do Anexo A. O escopo do teste deve se conectar às questões que esses controles precisam responder.
| Controle ou atividade | Contribuição do teste | Evidências |
|---|---|---|
| A.8.8 — Gestão de vulnerabilidades técnicas | Identificar e validar vulnerabilidades exploráveis nos sistemas em uso. | Achados associados a ativos, priorização, tratamento e reteste. |
| A.8.29 — Testes de segurança no desenvolvimento e na aceitação | Investigar o comportamento de segurança de sistemas novos ou alterados. | Objetivos, versão avaliada, acessos, resultados e decisões de aceitação. |
| Avaliação e tratamento de riscos | Usar caminhos de ataque demonstrados para revisar impacto e tratamento. | Referência ao registro de riscos, responsáveis e decisões aprovadas. |
A sequência útil é risco → controle → teste → achado → tratamento → verificação. Se o risco é o acesso indevido entre clientes, o teste deve investigar o isolamento entre eles. Se houver uma falha, os registros precisam conectar a evidência à correção ou à decisão de tratamento e ao resultado da validação.
Qual versão da norma usar?
O prazo de transição da certificação acreditada da edição de 2013 para a de 2022 terminou em 31 de outubro de 2025. Use as referências da edição de 2022 nos novos mapeamentos. A.12.6.1 e A.14.2.8 são numerações da edição anterior.
A emenda de 2024 acrescentou considerações climáticas ao contexto da organização e às necessidades das partes interessadas. Ela não criou uma periodicidade universal para pentests.
Como definir o escopo do pentest para ISO 27001?
Comece pelo escopo do SGSI e pelos riscos que precisam ser investigados. Depois, determine os ativos, os perfis de acesso, os ambientes e os cenários necessários. A organização é responsável pela decisão, com apoio das equipes de segurança, engenharia, compliance e do fornecedor.
Um teste do site institucional não demonstra o isolamento entre clientes de uma plataforma SaaS. Da mesma forma, uma avaliação externa de IPs não responde se uma conta de funcionário consegue alcançar servidores internos sensíveis.
- Aplicações web e SaaS: autenticação, autorização, isolamento entre clientes, painéis administrativos, exportações, arquivos e fluxos sensíveis.
- APIs e integrações: grupos de endpoints, perfis, tokens, webhooks, contas de serviço e intercâmbio de dados com terceiros.
- Infraestrutura externa: IPs, domínios, serviços expostos, acesso remoto e responsabilidade pelos ativos.
- Redes internas e identidade: Active Directory, privilégios, segmentação e caminhos de uma conta comum até sistemas críticos, quando aplicável.
- Cloud: separe o pentest da aplicação da revisão de configuração e permissões de AWS, Azure ou Google Cloud. Uma atividade não inclui automaticamente a outra.
- Aplicativos mobile: plataformas, armazenamento local, autenticação e APIs de backend, com inclusões e exclusões explícitas.
Registre também o que ficará fora do teste e quais riscos não serão avaliados. Sistemas de fornecedores exigem autorização adequada; ser cliente de uma integração não permite testar livremente a infraestrutura de terceiros.
Black box, gray box ou white box?
O black box oferece pouca informação prévia. O gray box fornece documentação e contas selecionadas. O white box acrescenta informações acordadas, como código-fonte, arquitetura e configurações. Escolha a abordagem conforme as perguntas do teste.
Para avaliar controles de uma aplicação, a Blaze geralmente recomenda gray box autenticado. Forneça perfis representativos e, em produtos multitenant, ao menos dois ambientes de cliente para investigar o isolamento. O acesso ao código pode ampliar a profundidade quando fizer parte do escopo.
É possível testar em homologação?
Um ambiente de homologação representativo pode reduzir a interrupção operacional. Documente diferenças de versões, identidade, permissões de cloud, integrações e fluxos de dados. Um teste em homologação não comprova a segurança de controles exclusivos de produção que não foram avaliados.
Antes da execução, combine alvos autorizados, janelas, técnicas permitidas, contatos de emergência, tratamento das evidências e condições de interrupção.
O scanner de vulnerabilidades substitui o pentest?
São atividades complementares. O scanner identifica falhas conhecidas e problemas de configuração em escala. O pentest manual investiga explorabilidade, autorização, lógica de negócio e caminhos de ataque.
Um scanner pode apontar um componente desatualizado, mas não necessariamente descobrir que a troca de um identificador na API permite baixar a fatura de outro cliente. Se sua política ou contrato exige pentest manual, um relatório de scanner não substitui esse compromisso.
Combine varreduras, verificações de desenvolvimento, revisão de configuração e pentest conforme os riscos do SGSI. Nenhuma dessas atividades substitui, por si só, a auditoria interna do sistema de gestão.
Como definir a frequência e o cronograma?
A ISO 27001 não determina um pentest anual para todas as organizações. O teste anual pode ser um ponto de partida, mas a periodicidade deve refletir riscos, mudanças, políticas e contratos.
Considere avaliações adicionais após mudanças relevantes em autenticação, autorização, isolamento entre clientes, APIs expostas, arquitetura de cloud ou fluxos de dados sensíveis. Um novo painel administrativo pode introduzir caminhos que o relatório anterior nunca cobriu.
Planeje de trás para frente a partir da data de entrega das evidências. Reserve tempo para preparar acessos, executar o teste, receber o relatório, implementar correções e realizar a validação. Alinhe com o organismo certificador quais evidências serão necessárias na etapa da auditoria.
- Confirme os objetivos, ativos, perfis, exclusões, entregáveis e datas.
- Prepare contas funcionais, dados de teste representativos e documentação das APIs.
- Defina como os achados graves serão comunicados durante a execução.
- Atribua responsáveis, prazos e medidas provisórias para cada achado.
- Valide as correções e retenha o histórico do resultado original até o reteste.
Achados em aberto impedem automaticamente a certificação?
Um achado isolado não determina automaticamente o resultado da certificação. O organismo certificador considera o contexto do SGSI, os requisitos aplicáveis e os controles implementados. Uma vulnerabilidade técnica não é sinônimo automático de uma não conformidade do sistema de gestão.
Mantenha severidade, impacto, responsável, prazo, mitigação, aprovação e estado do reteste. Uma falha vencida pode revelar que o processo de gestão de vulnerabilidades não foi seguido. A aceitação de risco deve respeitar a governança e não elimina uma obrigação legal ou contratual.
Quais evidências guardar para a auditoria?
- Escopo e autorização: ativos, ambiente, perfis, exclusões, objetivos e regras do teste.
- Execução: datas, metodologia, condições de acesso, cobertura, limitações e áreas não testadas.
- Resultados: ativos afetados, severidade, impacto no negócio, passos de reprodução e orientação de correção.
- Tratamento: chamados, responsáveis, prazos, mudanças, mitigações e exceções aprovadas.
- Validação: datas e resultados que diferenciem correções confirmadas, parciais, pendentes e não verificadas.
Uma carta de atestação pode resumir a avaliação para clientes, mas não substitui o relatório detalhado quando o auditor precisa examiná-lo. Compartilhe evidências sensíveis pelo canal seguro acordado.
Use os resultados para revisar riscos e causas comuns. Falhas de autorização repetidas em vários endpoints podem indicar um problema de arquitetura; corrigir somente as URLs listadas pode deixar a mesma falha em outros pontos. Veja também nossa análise de achados de pentests relacionados à ISO 27001.
Como escolher um fornecedor e solicitar a avaliação?
Peça um relatório anonimizado e uma proposta que explique os testes previstos. Compare cobertura, profundidade manual, acessos, limitações, suporte e condições de reteste para o mesmo escopo. Não existe um pacote universal de avaliação definido apenas pelo rótulo “pentest ISO 27001”.
Para aplicações web e APIs, pergunte como o fornecedor utiliza o OWASP Web Security Testing Guide e requisitos de verificação adequados. O OWASP Top 10 é uma lista de conscientização, não uma metodologia completa. O NIST SP 800-115 oferece orientações mais amplas sobre avaliações técnicas.
Confirme experiência com a tecnologia e o modelo de permissões, independência, qualidade das evidências, comunicação antecipada de achados graves e validação das correções. O número de dias, sozinho, não demonstra a qualidade da avaliação.
A Blaze realiza testes manuais, com IA onde ela ajuda na análise e na investigação. Envie a arquitetura, as aplicações, os perfis de acesso, os ambientes e o prazo da auditoria para definir os objetivos e entregáveis. Combine também os limites e a janela do reteste; a validação de achados anteriores não inclui automaticamente novas funcionalidades.
