Preparação para Auditoria: ISO 27001, SOC 2, Cyber Essentials
Um guia prático do que auditores realmente verificam em ISO 27001, SOC 2 e Cyber Essentials, e como se preparar sem pânico.
A maioria das equipes trata uma auditoria de conformidade como um simulado que aparece uma vez por ano. Não precisa ser assim, e os próprios frameworks não são tão misteriosos quanto os fornecedores fazem parecer. Aqui está o que realmente importa quando você está se preparando para ISO 27001, SOC 2 ou Cyber Essentials.
Saiba qual framework você está sendo realmente solicitado
Estes três são frequentemente agrupados, mas estão resolvendo problemas diferentes. ISO 27001 é um padrão de sistema de gestão — certifica que você tem um Sistema de Gestão de Segurança da Informação (ISMS) funcionando com avaliações de risco, políticas e melhoria contínua integradas. SOC 2 é um relatório de atestação, geralmente Tipo II, cobrindo um período de tempo (comumente 6-12 meses) contra os Critérios de Serviços Confiáveis: segurança, disponibilidade, integridade de processamento, confidencialidade, privacidade. Cyber Essentials é um esquema apoiado pelo governo do Reino Unido focado em cinco controles técnicos básicos: firewalls, configuração segura, controle de acesso, proteção contra malware e gerenciamento de patches.
Se um cliente diz "precisamos que você seja compatível com SOC 2", pergunte qual tipo e quais critérios eles realmente se importam. A maioria dos negócios B2B SaaS requer apenas Segurança e Disponibilidade, não os cinco critérios completos.
Construa o rastro de evidências antes do auditor pedir
Auditores não aceitam sua palavra — eles querem artefatos. Para ISO 27001, isso significa uma Declaração de Aplicabilidade mapeando todos os 93 controles no Anexo A (revisão 2022) para o que você implementou ou excluiu, com justificativa. Para SOC 2, significa screenshots, logs e tickets comprovando que os controles operaram consistentemente ao longo da janela de auditoria, não apenas no dia em que alguém se lembrou de configurar.
Configure a coleta de evidências como um processo contínuo, não uma correria:
# Exemplo: extrair evidências de revisão de acesso IAM mensalmente via AWS CLI
aws iam generate-credential-report
aws iam get-credential-report --output text --query 'Content' | base64 -d > access-report-$(date +%Y%m).csv
Armazene estes com timestamps em um repositório de evidências dedicado (pasta Google Drive, Vanta, Drata — o que você usar) organizado por ID de controle, não por mês. Auditores fazem amostragem ao longo do período; você precisa provar que o controle estava ativo em março e outubro, não apenas quando você se lembrou.
Os controles que causam problemas toda vez
Revisões de acesso são a descoberta número um. Se você não consegue mostrar uma revisão trimestral de quem tem acesso aos sistemas de produção, com evidência de que alguém realmente removeu contas antigas, espere uma descoberta independentemente do framework. Execute isso como uma tarefa de calendário recorrente, não como um favor ad hoc.
Gestão de risco de fornecedor é a segunda grande lacuna. ISO 27001 cláusula A.5.19-A.5.23 e os critérios de gestão de fornecedor da SOC 2 esperam que você avalie subprocessadores — provedores de nuvem, processadores de pagamento, qualquer coisa tocando dados de clientes. Um questionário de risco de fornecedor de uma página por fornecedor crítico, revisado anualmente, cobre a maioria disso.
Planos de resposta a incidentes que existem apenas como um documento que ninguém testou são uma descoberta comum também. Execute um exercício de mesa redonda pelo menos uma vez antes de sua janela de auditoria fechar e guarde as anotações da reunião. Auditores especificamente perguntam por evidência de que o plano foi exercitado, não apenas escrito.
Para Cyber Essentials, as questões de escopo técnico importam mais do que as pessoas esperam. Você precisa descrever com precisão seu limite — cada dispositivo, serviço de nuvem e política de BYOD no escopo — porque misrepresentar o escopo é motivo para falhar mesmo se os controles técnicos forem adequados. Gerenciamento de patches é verificado literalmente: patches de severidade crítica e alta devem ser aplicados dentro de 14 dias após o lançamento para serviços expostos à internet.
Executando um cronograma interno realista
Para SOC 2 Tipo II, reserve 3-6 meses de coleta de evidências antes da janela de auditoria começar, pois Tipo II requer provar que os controles operaram durante a janela de observação, não apenas em um ponto no tempo. Certificação ISO 27001 normalmente leva 6-12 meses desde a avaliação de lacunas até o certificado, incluindo uma revisão de documentação da Etapa 1 e avaliação da Etapa 2 no local (ou remota) pelo organismo certificador. Cyber Essentials é mais rápido — questionários de auto-avaliação podem ser concluídos em semanas se seus fundamentos já estiverem em ordem, com Cyber Essentials Plus adicionando uma verificação técnica externa.
Não deixe que a auditoria seja a única vez que você verifica seu próprio trabalho
Execute uma avaliação interna de prontidão contra a lista de controles reais 60-90 dias antes da auditoria real. Trate descobertas dessa passagem interna da mesma forma que trataria descobertas do auditor — remedie, documente a correção e mantenha o rastro de papel. Essa passagem interna é geralmente onde as equipes descobrem lacunas de revisão de acesso e contratos de fornecedor antigos antes que alguém externo faça isso, com um relatório anexado à renovação do contrato do cliente em jogo.
Se você quer aprofundar nos controles técnicos por trás desses frameworks — design de controle de acesso, logging, resposta a incidentes — confira as trilhas Blue Team e Certifications no Korra Studio.
Escrito com assistência de IA, revisado e publicado por Michal Pilch (CISSP), Korra Studio.
Esta é uma anotação da base de conhecimento da Korra Studio — a plataforma associa cada tema com mentoria 1-para-1.
Começar gratuitamentearrow_forward