ISO/IEC 27001:2022
Guia Completo de Estudo
Todas as cláusulas, os 93 controles, metodologias de risco, terminologia oficial, casos de estudo e quiz por domínio — em português.
Distribuição do Exame por Domínio
Fundamentos da SI e da Norma
Tríade CID, família ISO 27000, Estrutura Harmonizada, PDCA e mudanças da versão 2022.
Iniciação do Projeto SGSI
Contexto, partes interessadas, escopo, liderança, política e responsabilidades.
Planejamento — Gestão de Riscos
Avaliação e tratamento de riscos, SoA, objetivos de SI e planejamento de mudanças.
Apoio — Infraestrutura Habilitadora
Recursos, competência, conscientização (3 elementos obrigatórios), comunicação e documentação.
Os 93 Controles
4 temas, 11 novos controles 2022, atributos e relação com a avaliação de riscos.
Implementação e Operação
Controle operacional, gestão de incidentes (5.24–5.28) e gestão de fornecedores.
Avaliação do Desempenho
KPIs por controle, auditoria interna com imparcialidade, revisão pela direção.
Melhoria Contínua
Tipos de NCs, ações corretivas com causa raiz e Top 10 dicas para o exame.
Navegue pelos domínios usando as abas acima. Cada domínio tem conteúdo detalhado das cláusulas, tabelas de referência, casos de estudo práticos e quiz de 10 questões comentadas. Recomendamos completar os quizzes após estudar cada domínio.
Fundamentos da Segurança da Informação e da Norma ISO 27001
Conceitos essenciais, família ISO 27000, estrutura HLS, ciclo PDCA e mudanças da versão 2022
1.1 — A Tríade CID: Pilar de Todo o SGSI
A ISO/IEC 27000 define segurança da informação como a preservação da confidencialidade, integridade e disponibilidade da informação. Essa tríade — conhecida como CID (ou CIA em inglês) — é o fundamento filosófico de cada controle, cada risco e cada decisão dentro de um SGSI.
Confidencialidade
A informação é acessível somente a pessoas, entidades e processos autorizados. Violação: credenciais de clientes expostas em repositório público.
Integridade
Salvaguardar a exatidão e completude da informação e seus métodos de processamento. Violação: ransomware que criptografa arquivos de produção.
Disponibilidade
Garantir que informação e sistemas estejam acessíveis quando necessários. Violação: ataque DDoS que derruba o e-commerce no pico de vendas.
📚 Propriedades adicionais reconhecidas pela ISO 27000
A norma reconhece outras propriedades além da CID, importantes para o exame:
Como a CID orienta decisões práticas?
Ao avaliar um risco ou selecionar um controle, o profissional de SI deve perguntar: "Qual propriedade da CID está ameaçada?". Essa pergunta direciona a resposta correta:
| Cenário | Propriedade violada | Controle mais adequado |
|---|---|---|
| Funcionário desligado continua tendo acesso ao sistema | Confidencialidade | Controle 6.5 (responsabilidades pós-desligamento) + 8.2 (acesso privilegiado) |
| Atacante altera registros contábeis sem ser detectado | Integridade | Controle 8.17 (sincronização de relógios), 8.15 (logs), controle de acesso granular |
| Sistema de home banking indisponível por 6 horas | Disponibilidade | Controle 5.30 (continuidade de TIC), 8.6 (gestão de capacidade), 8.14 (redundância) |
| Phishing usa identidade visual do banco para enganar clientes | Autenticidade | Controle 8.5 (autenticação segura), 5.7 (threat intelligence), 8.23 (filtragem web) |
| Usuário nega ter enviado transferência fraudulenta | Não-repúdio | Controle 8.15 (logging), 8.17 (timestamp), assinatura digital em transações |
1.2 — A Família ISO/IEC 27000: Normas Complementares
A ISO 27001 não existe de forma isolada. Ela é o núcleo certificável de uma família de normas que cobrem aspectos específicos da segurança da informação. Entender o papel de cada norma é frequentemente testado no exame.
| Norma | O que cobre | Papel prático no SGSI |
|---|---|---|
ISO/IEC 27000 | Vocabulário e visão geral de toda a família | Referência normativa da ISO 27001 — única referência citada na cláusula 2. Leitura obrigatória para o exame. |
ISO/IEC 27001 | Requisitos do SGSI — a norma certificável | Define o "o quê fazer". Usa "shall" para requisitos obrigatórios e "should" para recomendações. |
ISO/IEC 27002 | Guia de implementação dos controles do Anexo A | Define o "como fazer" cada controle. Referência para preencher a SoA e implementar controles. |
ISO/IEC 27003 | Orientações de implementação do SGSI | Guia prático para estruturar o projeto de implementação — útil para o Lead Implementer. |
ISO/IEC 27004 | Monitoramento, medição, análise e avaliação | Suporte técnico à cláusula 9.1 — como definir e calcular métricas de SI. |
ISO/IEC 27005 | Gestão de riscos de segurança da informação | Suporte técnico às cláusulas 6.1 e 8.2/8.3 — metodologias de avaliação e tratamento de riscos. |
ISO/IEC 27007 | Diretrizes para auditoria de SGSI | Base técnica para auditorias internas (cláusula 9.2). Usada por Lead Auditors. |
ISO/IEC 27017 | Controles de segurança para serviços em nuvem | Extensão para cloud — complementa o controle 5.23 do Anexo A. |
ISO/IEC 27018 | Proteção de PII em nuvem pública | Alinhamento com LGPD/GDPR para dados pessoais processados em cloud. |
ISO/IEC 27035 | Gestão de incidentes de segurança | Aprofundamento técnico para os controles 5.24–5.28 do Anexo A. |
A ISO 27001 usa "shall" (deve — obrigatório) para requisitos de conformidade e "should" (deveria — recomendação) para boas práticas. A ISO 27002, como guia, usa predominantemente "should". No exame: quando uma questão menciona que algo é "exigido pela norma", busque cláusulas com "shall".
1.3 — Estrutura de Alto Nível (HLS) e as 10 Cláusulas
A ISO 27001:2022 segue a Estrutura Harmonizada (HLS) — anteriormente chamada de Anexo SL — compartilhada com ISO 9001, ISO 14001, ISO 22301 e outras normas de sistemas de gestão. Isso permite que organizações integrem múltiplos sistemas sem duplicar esforços.
Organizações que já têm ISO 9001 (qualidade) ou ISO 14001 (ambiental) podem integrar o SGSI usando a mesma estrutura de documentação, revisão pela direção e auditoria interna — reduzindo significativamente o custo e o esforço de implementação. O exame pode apresentar cenários de integração de sistemas de gestão.
O que a norma cobre
Especifica requisitos para estabelecer, implementar, manter e melhorar continuamente um SGSI no contexto da organização. Aplicável a qualquer organização, independentemente de tipo, tamanho ou natureza.
ISO/IEC 27000 como único referencial
A ISO 27000 é a única referência normativa da ISO 27001 — o vocabulário oficial. Em caso de dúvida sobre um termo durante o exame ou uma implementação, a fonte oficial é a ISO 27000.
Remissão à ISO 27000
Não define termos diretamente — remete à ISO 27000. O exame explora diferenças sutis entre: ameaça × vulnerabilidade × risco, evento × incidente, controle × medida × processo.
Ponto de partida do SGSI
4.1 questões internas/externas → 4.2 partes interessadas → 4.3 escopo → 4.4 SGSI e seus processos. Sem contexto correto, todo o SGSI será inadequado à realidade da organização.
Comprometimento inegociável
5.1 comprometimento da alta direção → 5.2 política de SI → 5.3 papéis e responsabilidades. A liderança não pode ser delegada. A alta direção tem responsabilidades concretas — não apenas "apoiar".
Gestão de riscos e objetivos
6.1 ações para riscos e oportunidades → 6.1.2 avaliação de riscos → 6.1.3 tratamento e SoA → 6.2 objetivos → 6.3 planejamento de mudanças (NOVO em 2022). O coração técnico do SGSI.
Infraestrutura habilitadora
7.1 recursos → 7.2 competência → 7.3 conscientização → 7.4 comunicação → 7.5 informação documentada. O SGSI não funciona sem pessoas, conhecimento e documentação adequados.
O "Fazer" do PDCA
8.1 planejamento e controle operacional → 8.2 execução da avaliação de riscos → 8.3 execução do tratamento de riscos. É onde os planos se tornam realidade e os controles funcionam no dia a dia.
O "Verificar" do PDCA
9.1 monitoramento e medição → 9.2 auditoria interna → 9.3 revisão pela direção. Sem medição sistemática, não há como saber se o SGSI está atingindo seus objetivos.
O "Agir" do PDCA
10.1 não conformidades e ações corretivas → 10.2 melhoria contínua. O SGSI é um organismo vivo — deve evoluir continuamente em resposta ao contexto, incidentes e oportunidades.
1.4 — O Ciclo PDCA Aplicado ao SGSI
O PDCA (Plan-Do-Check-Act), também chamado de Ciclo de Deming, é o modelo de melhoria contínua que dá vida ao SGSI. Compreender o mapeamento cláusula → fase PDCA é uma fonte consistente de questões no exame.
O que acontece em PLAN (Cls. 4–7)?
- Entender o contexto e as partes interessadas
- Definir o escopo do SGSI
- Obter comprometimento da liderança
- Identificar, analisar e avaliar riscos
- Selecionar controles e elaborar a SoA
- Definir objetivos mensuráveis de SI
- Garantir competência e conscientização
O que acontece em DO, CHECK e ACT?
- DO (Cl. 8): Implementar controles, executar planos de tratamento, gerir incidentes e fornecedores
- CHECK (Cl. 9): Medir eficácia dos controles, auditar internamente, fazer revisão pela direção
- ACT (Cl. 10): Corrigir não conformidades, eliminar causas raiz, melhorar continuamente
1.5 — Mudanças ISO 27001:2013 → 2022
A versão 2022 trouxe as mais significativas mudanças desde a publicação da norma. Questões sobre diferenças entre versões são frequentes no exame PECB.
| Aspecto | Versão 2013 | Versão 2022 | Impacto prático |
|---|---|---|---|
| Controles totais | 114 controles em 14 domínios | 93 controles em 4 temas | Redução por consolidação — sem perda de cobertura |
| Novos controles | — | 11 controles totalmente novos | Cobrem lacunas em cloud, DLP, threat intelligence etc. |
| Controles fundidos | Duplicidades entre domínios | 24 controles mesclados (eliminadas redundâncias) | SoA mais simples e coerente |
| Cláusula 6.3 | Não existia | Planejamento de mudanças ao SGSI | Mudanças como fusões/migração cloud devem ser planejadas |
| Atributos dos controles | Não existiam | 5 atributos por controle (tipo, propriedades, capacidades, domínios, conceitos) | Permite filtrar e priorizar controles por perspectiva |
| Cláusula 4.4 | Vaga sobre processos do SGSI | Explicitada: organização deve determinar processos do SGSI e sua interação | Maior ênfase em abordagem de processo |
| Prazo de migração | — | Até outubro de 2025 para migrar da versão 2013 | Organizações certificadas na 2013 já deveriam ter migrado |
TechRetail — Migração estratégica da versão 2013 para 2022
Gap analysis: Mapearam controle a controle. 79 controles existentes tinham equivalente direto. Os 11 novos controles foram analisados — apenas 8 eram aplicáveis ao contexto (e-commerce SaaS, sem datacenter próprio). Custo incremental: ~20% do esforço original.
Aproveitamento dos atributos: Os novos atributos foram usados para filtrar controles pelo conceito "Detectar" — justamente a capacidade mais fraca identificada no gap. Isso revelou que os controles 8.16 (monitoramento) e 5.7 (threat intelligence) eram prioritários.
SoA revisada: A nova SoA listou 82 controles aplicáveis (11 excluídos com justificativas: todos relacionados a segurança física de datacenter — provida pelo cloud provider com SOC 2 Type II). Documentação de exclusão incluiu os relatórios de terceiros como evidência.
Resultado: Auditoria de transição concluída em 1 dia — zero NCs maiores. O auditor elogiou a qualidade das justificativas de exclusão e o uso dos atributos na SoA.
Quiz — Domínio 1: Fundamentos
Iniciação do Projeto SGSI
Contexto organizacional, partes interessadas, escopo, liderança, política e responsabilidades
2.1 — Cláusula 4.1: Compreendendo a Organização e seu Contexto
A cláusula 4.1 é o ponto de partida absoluto de qualquer SGSI. Ela exige que a organização determine as questões internas e externas que são relevantes para seu propósito e que afetam sua capacidade de alcançar os resultados pretendidos do SGSI.
🌐 Questões Externas — o que analisar?
- Legal e regulatório: LGPD, GDPR, normas setoriais (BACEN, ANS, ANVISA), leis de cibersegurança, contratos públicos
- Tecnológico: Evolução de ameaças (ransomware, APTs), adoção de cloud, IoT, IA generativa como vetor de ataque
- Mercado: Exigência de clientes por certificação, práticas do setor, competidores com brechas exploradas
- Geopolítico: Risco de espionagem industrial, conflitos que afetam fornecedores, cadeia de suprimentos de hardware
- Social: Expectativas de privacidade da sociedade, LGPD e cultura de proteção de dados
🏢 Questões Internas — o que analisar?
- Cultura organizacional: Maturidade em SI, resistência a controles, histórico de incidentes por erro humano
- Tecnologia: Legado vs. modernização, shadow IT, BYOD, débito técnico de sistemas sem suporte
- Estrutura: Governança de TI e SI, modelo de tomada de decisão, silos entre TI/negócio/jurídico
- Recursos humanos: Competências disponíveis, turnover em funções críticas, terceirização de SI
- Financeiro: Orçamento disponível para SI, histórico de cortes em TI, ROI esperado da certificação
🛠️ Ferramentas para análise de contexto
SWOT aplicado ao SGSI
| Forças (Internas+) | Fraquezas (Internas-) |
|---|---|
| Equipe de SI experiente, SOC maduro, cultura de segurança | Sistemas legados sem patches, shadow IT, baixa consciência de usuários |
| Oportunidades (Externas+) | Ameaças (Externas-) |
|---|---|
| Certificação abre mercado enterprise, clientes exigem ISO 27001, fundos para modernização | Ransomware como serviço, regulação mais rigorosa, ataques na cadeia de suprimentos |
PESTLE para SI
- Político: legislação de cibersegurança emergente, regulação de IA
- Econômico: custo de incidentes, ROI de controles, orçamento de SI
- Social: expectativas de privacidade, reputação pós-breach
- Tecnológico: cloud nativa, DevSecOps, Zero Trust, IA adversarial
- Legal: LGPD, GDPR, setoriais (PCI-DSS, HIPAA equivalente BR)
- Ecológico: continuidade em desastres naturais, datacenters verdes
2.2 — Cláusula 4.2: Necessidades e Expectativas das Partes Interessadas
A organização deve identificar as partes interessadas relevantes para o SGSI e determinar seus requisitos. "Relevante" é a palavra-chave — não é necessário mapear todas as partes interessadas da organização, apenas aquelas que têm interesse ou impacto na segurança da informação.
A norma exige identificar partes interessadas E seus requisitos relevantes para o SGSI. Simplesmente listar as partes sem documentar o que elas precisam do SGSI é uma não conformidade. Esses requisitos alimentam diretamente o escopo (4.3) e a avaliação de riscos (6.1).
| Parte interessada | Tipo | Requisitos típicos | Consequência se ignorada |
|---|---|---|---|
| Clientes corporativos | Externa | Certificação ISO 27001, relatórios de segurança, SLAs de disponibilidade, proteção de dados compartilhados | Perda de contrato, cláusula de rescisão por inadimplência de SI |
| ANPD (regulador LGPD) | Externa | Conformidade LGPD, notificação em 72h de incidentes, relatório de impacto (RIPD), encarregado de dados (DPO) | Multa até 2% do faturamento (máx R$50M/infração) |
| Reguladores setoriais | Externa | BACEN: Res. 4.658/4.893. ANS: controle de acesso a prontuários. ANVISA: integridade de dados de saúde | Sanções regulatórias, cassação de licença operacional |
| Alta direção / C-level | Interna | Integração com estratégia corporativa, ROI mensurável do SGSI, visibilidade de riscos, relatórios executivos | SGSI sem orçamento, sem autoridade e sem sustentação |
| Acionistas / Conselho | Interna | Proteção do valor da empresa, gestão de riscos reputacionais, conformidade com governança (IBGC) | Impacto no valuation, litígios de acionistas pós-incidente |
| Colaboradores | Interna | Clareza das políticas, treinamentos acessíveis, ferramentas seguras que não impedem produtividade, canal de reporte | Resistência passiva, violações não intencionais, shadow IT |
| Fornecedores críticos | Cadeia | Requisitos de SI contratuais, avaliações periódicas, notificação de incidentes que os afetam, direito a auditoria | Supply chain attack, comprometimento por terceiros |
| Parceiros de integração | Cadeia | Controle de acesso a APIs, NDAs/DPAs, revisão de segurança de integrações, gestão de credenciais de serviço | Vazamento de dados via API mal protegida |
2.3 — Cláusula 4.3: Determinando o Escopo do SGSI
O escopo é o documento que define os limites e a aplicabilidade do SGSI. É o primeiro documento verificado em qualquer auditoria de certificação ou vigilância.
Considerar as questões internas e externas (4.1)
O escopo deve refletir a realidade do contexto. Uma empresa com operações em múltiplos países deve considerar quais países/operações serão cobertos. Uma empresa com sistemas legados deve decidir se os inclui ou os documenta como exclusão justificada.
Considerar os requisitos das partes interessadas (4.2)
Se um cliente exige que seu sistema de gestão de dados esteja no escopo do SGSI, não é possível excluí-lo sem perder a conformidade contratual. Os requisitos das partes interessadas funcionam como delimitadores do escopo mínimo.
Determinar interfaces e dependências
O que está fora do escopo pode ser uma ameaça para o que está dentro. Um sistema de RH fora do escopo que se integra via API com o sistema de identidade dentro do escopo cria uma dependência que deve ser documentada e gerenciada como risco.
Documentar e manter o escopo
O escopo deve ser mantido como informação documentada. Deve ser revisado quando: mudança de negócio, expansão de mercado, aquisições, mudança significativa em tecnologia, ou quando a avaliação de riscos identificar que o escopo atual deixa riscos críticos fora da cobertura do SGSI.
📐 O escopo PODE ser parcial — mas com limites
Exemplos válidos de escopos parciais: apenas o datacenter, apenas o sistema de internet banking, apenas a área de desenvolvimento de software, apenas uma filial certificada.
O que NÃO é permitido: excluir partes do negócio de forma que o SGSI não cubra os riscos reais identificados, ou que não atenda aos requisitos das partes interessadas. Um banco que certifica apenas o sistema de caixa eletrônico mas deixa fora o internet banking (principal canal de ataque) tem um escopo indefensável.
2.4 — Cláusula 5: Liderança — A Fundação do SGSI
A cláusula 5 é frequentemente subestimada por profissionais técnicos, mas representa ~15% das questões do exame. Liderança não é apenas "suporte" — é responsabilidade ativa e inegável.
Cláusula 5.1 — Comprometimento da Alta Direção: 8 Responsabilidades Concretas
| # | Responsabilidade (cláusula 5.1) | Evidência esperada em auditoria | Falha comum |
|---|---|---|---|
| 1 | Garantir que política e objetivos de SI sejam compatíveis com a direção estratégica | Política assinada pela alta direção com referência à estratégia corporativa | Política genérica sem vínculo com objetivos de negócio |
| 2 | Garantir integração dos requisitos do SGSI aos processos de negócio | SI como critério em comitês de aprovação de novos projetos, contratações, aquisições | SI consultado apenas quando há problema, não no início |
| 3 | Garantir disponibilidade de recursos para o SGSI | Linha orçamentária aprovada, FTEs dedicados, ferramentas adquiridas | SI depende de sobra de orçamento de TI |
| 4 | Comunicar a importância do SGSI e da conformidade | Mensagem executiva em campanhas, menção em all-hands, patrocínio visível | Alta direção desconhece o SGSI ou o vê como "projeto de TI" |
| 5 | Garantir que o SGSI atinja seus resultados pretendidos | Revisão de KPIs de SI em meetings executivos, tomada de decisão baseada em métricas | Alta direção só vê o SGSI na revisão anual pela direção |
| 6 | Dirigir e apoiar pessoas para contribuir | SI incluído nos objetivos de desempenho individual de gestores | Gestores não são avaliados por seu apoio à SI |
| 7 | Promover a melhoria contínua | Participação ativa na revisão pela direção com agenda formal documentada | Revisão delegada completamente ao CISO — alta direção ausente |
| 8 | Apoiar outros gestores em suas áreas de liderança relevantes | C-level empoderam CISOs com autoridade real, não apenas responsabilidade | CISO com responsabilidade de SI mas sem autoridade para exigir mudanças |
Cláusula 5.2 — Política de Segurança da Informação
✅ O que a política DEVE conter
Propósito do SGSI alinhado ao negócio; comprometimento explícito com requisitos aplicáveis (norma, legal, contratual); comprometimento com melhoria contínua; estrutura para estabelecer objetivos mensuráveis de SI.
❌ O que a política NÃO deve ser
Um manual técnico de TI. Uma lista de controles técnicos. Um documento genérico copiado da internet. Um arquivo confidencial acessível apenas ao CISO. Deve ser compreensível a todos os colaboradores.
📢 Como comunicar
Disponível para todos os colaboradores (intranet, integração, físico em áreas comuns). Disponível para partes interessadas externas quando pertinente (versão resumida no site para clientes que solicitam certificação).
🔄 Quando atualizar
Quando há mudança significativa de contexto (nova lei, novo mercado, incidente grave), quando os objetivos estratégicos mudam, quando a revisão pela direção identifica necessidade — ou ao menos anualmente como boa prática.
Cláusula 5.3 — Papéis, Responsabilidades e Autoridades
A alta direção deve atribuir E comunicar responsabilidades e autoridades para funções relevantes do SGSI. Dois papéis são explicitamente referenciados na cláusula 5.3:
| Papel | Responsabilidade conforme ISO 27001 | Nota importante |
|---|---|---|
| Responsável pelo SGSI (CISO ou equiv.) | Garantir que o SGSI está em conformidade com os requisitos da ISO 27001; reportar o desempenho do SGSI à alta direção | Deve ter autoridade real — não apenas responsabilidade nominal. Acumular SI com TI operacional é um conflito de interesse comum. |
| Proprietários de ativos | Responsabilidade pela proteção do ativo e pelos riscos associados. Aprovam decisões de tratamento de risco dos seus ativos. | Deve ser papel de negócio, não apenas TI. O dono do sistema de CRM é o VP de Vendas, não o gerente de infraestrutura. |
| Todos os colaboradores | Seguir políticas e procedimentos de SI; reportar eventos e incidentes de segurança suspeitos | Cláusula 7.3 (conscientização) garante que todos saibam dessas responsabilidades |
HealthInsure — Mapeando partes interessadas em setor multi-regulado
Mapeamento regulatório completo: ANS (disponibilidade de sistemas de autorização, prazo máximo de resposta), ANPD (dados sensíveis de saúde = proteção máxima pela LGPD), CFM (prontuário eletrônico: integridade absoluta, histórico imutável), BACEN via PSP (pagamentos de mensalidades). Cada regulador tinha um analista designado para mapeamento.
Conflito identificado: CFM exigia que prontuários sejam mantidos por 20 anos mesmo após cancelamento. LGPD (direito de exclusão) potencialmente conflitava. A solução jurídica foi: manter dados para fins de saúde por prazo legal, anonimizando para fins comerciais. Esse conflito foi documentado formalmente e a solução aprovada pelo DPO.
Disponibilidade como prioridade #1: A ANS estabelecia disponibilidade de 99,7% para sistemas de autorização de procedimentos em UTI. Isso elevou disponibilidade ao topo da hierarquia da CID para esse ativo específico — influenciando diretamente os critérios de impacto na avaliação de riscos.
Escopo resultante: Cobriu os sistemas de core de beneficiários, portal do médico, sistema de autorização eletrônica e portal do beneficiário. Sistema de RH excluído com justificativa documentada: sem dados de saúde de clientes.
Em setores com múltiplos reguladores, o mapeamento de requisitos conflitantes é indispensável ANTES de definir o escopo. O escopo deve ser capaz de atender o mais restritivo dos reguladores.
Quiz — Domínio 2: Iniciação e Cláusulas 4 e 5
Planejamento — Gestão de Riscos e Objetivos
O coração técnico do SGSI: avaliação e tratamento de riscos, Declaração de Aplicabilidade, objetivos e planejamento de mudanças
3.1 — Cláusula 6.1.2: Avaliação de Riscos de SI
A avaliação de riscos é o processo mais extensamente testado no exame. A norma não prescreve uma metodologia específica — mas exige que o processo produza resultados consistentes, válidos e comparáveis.
Terminologia essencial — não confunda no exame
O processo de avaliação de riscos (passo a passo)
Estabelecer critérios ANTES de avaliar
Os critérios devem ser definidos antes de iniciar a avaliação — não depois. Incluem: escala de probabilidade (ex: 1 a 5), escala de impacto (1 a 5 por propriedade CID), método de cálculo do nível de risco, e o critério de aceitação de risco (qual nível é tolerável sem tratamento).
Identificar riscos: ativo → ameaça → vulnerabilidade → impacto
Para cada ativo no escopo: identificar ameaças relevantes (catálogo ISO 27005 Anexo C), identificar vulnerabilidades que essas ameaças podem explorar, determinar o impacto potencial na CID se o risco se materializar. Resulta no registro de riscos.
Analisar riscos: estimar probabilidade e impacto
Quantitativa (valores monetários — custo de um breach), qualitativa (Alto/Médio/Baixo — mais comum em PMEs) ou semi-quantitativa (escalas numéricas com significado qualitativo). Considerar controles existentes na estimativa de probabilidade — um controle de MFA reduz a probabilidade de comprometimento por credenciais.
Avaliar riscos: comparar com critérios → priorizar
Comparar cada risco com os critérios estabelecidos. Riscos acima do critério de aceitação devem ser tratados. Riscos abaixo podem ser aceitos (com documentação formal). A saída é uma lista priorizada de riscos que requer tratamento — insumo direto para a cláusula 6.1.3.
Matriz de Risco 5×5 — Exemplo com legenda
Muito baixo
Baixo
Médio
Alto
Crítico
3.2 — Cláusula 6.1.3: Tratamento de Riscos e a Declaração de Aplicabilidade (SoA)
Após a avaliação, a organização seleciona opções de tratamento para cada risco acima do critério de aceitação, e produz os dois documentos mais importantes da cláusula 6: o Plano de Tratamento de Riscos (PTR) e a Declaração de Aplicabilidade (SoA).
As 4 opções de tratamento — com lógica de seleção
| Opção | Quando usar | Exemplo prático | Resultado no risco |
|---|---|---|---|
| 🔧 Modificar (Mitigar) | Quando o custo do controle é proporcional à redução de risco. Caso mais comum. | Implementar MFA em todos os acessos remotos para reduzir risco de comprometimento de credenciais | Reduz probabilidade e/ou impacto → risco residual menor |
| 🚫 Evitar | Quando o risco é inaceitável e o benefício da atividade não justifica o risco | Descontinuar sistema legado SCADA sem suporte ao invés de tentar protegê-lo com controles compensatórios | Elimina o risco na origem — junto com a atividade |
| 🤝 Transferir/Compartilhar | Quando o impacto financeiro pode ser passado a terceiros e o custo é menor que o controle | Contratar seguro cibernético para cobertura de vazamento de dados; terceirizar processamento de pagamentos para PCI-DSS-certified provider | Risco permanece, mas impacto financeiro é compartilhado |
| ✅ Aceitar | Quando o risco está abaixo do critério de aceitação, ou quando custo de qualquer controle supera o benefício | Aceitar risco de indisponibilidade de sistema de relatório gerencial por 4h (impacto baixo, baixa probabilidade, custo de HA injustificável) | Risco permanece — deve ser monitorado e aprovado formalmente pelo proprietário |
📄 A Declaração de Aplicabilidade (SoA) — O Documento Central do SGSI
A SoA é a saída obrigatória da cláusula 6.1.3d e o documento mais verificado em qualquer auditoria de certificação. Para cada um dos 93 controles do Anexo A, a SoA deve registrar:
| Campo obrigatório na SoA | O que documentar | Exemplo |
|---|---|---|
| Aplicabilidade | O controle se aplica ao escopo do SGSI? | 5.23 (Cloud): Aplicável — organização usa AWS e Azure |
| Status de implementação | Implementado / Em implementação / Planejado | 8.12 (DLP): Em implementação — go-live previsto para T3 |
| Justificativa de inclusão | Por que é necessário: resultado de risco, requisito legal, obrigação contratual, boa prática do setor | 6.3 (Backup): Resultado de risco (ransomware, prob. 4, imp. 5 = 20 crítico) + LGPD art. 46 |
| Justificativa de exclusão | Se excluído: por que não é aplicável, demonstrando que nenhum risco ou requisito externo o exige | 7.4 (Monitor. físico): Excluído — infraestrutura hospedada em AWS (responsabilidade do provider, evidenciada por SOC 2 Type II) |
Não é possível excluir um controle se um risco que o controle mitiga foi identificado na avaliação — a menos que outro controle equivalente o cubra (controle compensatório documentado). Custo de implementação NÃO é justificativa de exclusão — é justificativa para aceitar o risco residual.
3.3 — Cláusula 6.2: Objetivos de Segurança da Informação
Os objetivos de SI são o "norte" mensurável do SGSI para um período. Devem ser documentados e atender a 7 critérios obrigatórios:
| Critério | O que exige | Exemplo de objetivo que atende | Exemplo que falha |
|---|---|---|---|
| Consistente com a política | Alinhado às intenções declaradas na política de SI | "Reduzir MTTD de 48h para 4h" — alinhado à política de "detecção ágil" | Objetivo de disponibilidade em política que não menciona disponibilidade |
| Mensurável (quando praticável) | Critério de medição definido | "95% dos patches críticos aplicados em ≤ 30 dias" | "Melhorar a gestão de vulnerabilidades" |
| Levando em conta requisitos aplicáveis | Conformidade, legal, contratual | "Zero notificações tardias à ANPD" — incorpora requisito LGPD | Objetivo sem referência a qualquer requisito externo |
| Monitorado | Indicadores e frequência de medição | KPI medido mensalmente, dashboard disponível para gestores | Objetivo sem definição de como será medido |
| Comunicado | Às pessoas relevantes | Publicado no portal de SI, comunicado em all-hands trimestral | Objetivo conhecido apenas pelo CISO |
| Atualizado | Revisado quando necessário | Revisado nas revisões pela direção e quando o contexto muda | Definido uma vez e nunca revisado |
| Documentado | Retido como informação documentada | Registrado no sistema de gestão de documentos com aprovação e versão | Definido verbalmente em reunião sem registro |
3.4 — Cláusula 6.3: Planejamento de Mudanças (NOVO em 2022)
Esta cláusula inteiramente nova responde a uma lacuna da versão 2013: mudanças no SGSI eram frequentemente feitas ad hoc, sem considerar impactos no sistema como um todo. A 6.3 exige que mudanças ao SGSI sejam planejadas e controladas.
Migração de infraestrutura para cloud; fusão ou aquisição empresarial; expansão do escopo do SGSI; mudança na metodologia de avaliação de riscos; adoção de nova tecnologia (IA, IoT, OT); reestruturação organizacional que afeta papéis do SGSI; resposta a novo requisito regulatório que exige novos controles.
LogisPrime — Avaliação de riscos em cadeia de suprimentos pós-SolarWinds
Classificação de 200 fornecedores em 3 níveis: Nível A (12 fornecedores com acesso a sistemas críticos de rastreamento em tempo real), Nível B (68 com acesso a dados não críticos), Nível C (120 sem acesso a sistemas internos — apenas recebem dados). A classificação foi baseada em: criticidade do dado acessado, privilégio de acesso, e impacto potencial de comprometimento.
Avaliação diferenciada por nível: Nível A: questionário detalhado (85 perguntas) + auditoria in loco + exigência contratual de ISO 27001 ou SOC 2 Type II. Nível B: questionário simplificado (30 perguntas) + análise documental + evidências de controles básicos. Nível C: aceite formal da política de SI da LogisPrime no contrato.
Risco crítico identificado: 3 fornecedores Nível A não tinham qualquer certificação de segurança e tinham acesso privilegiado a sistemas de rastreamento em tempo real de carga aérea. Avaliação: Prob. 4 × Impacto 5 = 20 (crítico). Risco de adulteração de dados de localização de cargas sensíveis.
Plano de tratamento: Prazo de 180 dias para implementar controles mínimos (MFA, gestão de patches, log de acesso, processo de notificação de incidentes). Acesso temporariamente movido para ambiente sandbox isolado. Contratos aditados com SLA de segurança e multas por incidente de SI.
Este caso illustra os controles 5.19 (política de relações com fornecedores), 5.20 (abordagem em acordos), 5.21 (gestão de SI na cadeia de suprimentos de TIC) e 5.22 (monitoramento e revisão de serviços de fornecedores).
Quiz — Domínio 3: Planejamento e Riscos
Apoio — A Infraestrutura Habilitadora do SGSI
Recursos, competência, conscientização, comunicação e gestão da informação documentada
4.1 — Cláusulas 7.1 e 7.2: Recursos e Competência
7.1 — Recursos
A organização deve determinar e prover os recursos necessários para o SGSI. Recursos são mais amplos do que orçamento: incluem pessoas (com tempo dedicado), tecnologia (ferramentas de SI), conhecimento especializado (consultores, treinamentos), infraestrutura física e acesso a informações relevantes (threat intelligence, benchmarks do setor).
7.2 — Competência: O ciclo completo
Determinar competências necessárias
Mapeie conhecimentos, habilidades e experiências necessárias para cada função que afeta o desempenho do SGSI. Exemplos: o gestor de riscos precisa de conhecimento em ISO 27005; desenvolvedores precisam de OWASP Top 10 e secure coding; o CISO precisa de governança e gestão executiva de SI.
Verificar se as pessoas são competentes
Verificar através de: entrevistas técnicas, avaliações de desempenho, certificações existentes, análise de histórico de incidentes causados por erro humano. Um gap de competência é um risco para o SGSI e deve ser tratado.
Tomar ações para adquirir competências
Ações possíveis: treinamento interno, certificações externas (CISSP, CEH, ISO 27001 Lead Implementer, CISM), contratação de profissional qualificado, terceirização de função específica (SOC gerenciado). A eficácia das ações deve ser avaliada após a execução.
Reter evidências documentadas
Manter: diplomas, certificados de treinamento, registros de participação, avaliações de desempenho, descrições de cargos com competências exigidas. São os documentos mais solicitados em auditorias para demonstrar conformidade com 7.2.
4.2 — Cláusula 7.3: Conscientização — Os 3 Elementos Obrigatórios
A cláusula 7.3 é bastante específica. Todas as pessoas que trabalham sob o controle da organização devem estar conscientes de exatamente 3 elementos — não mais, não menos (como mínimo obrigatório):
1️⃣ A Política de SI
Não apenas que a política existe, mas seu conteúdo e propósito. Todo colaborador deve saber o que a política diz e por que existe — não apenas assinar um aceite sem ler.
2️⃣ Sua contribuição para o SGSI
Como o trabalho de cada pessoa impacta a segurança — incluindo os benefícios de uma boa postura (redução de incidentes, proteção do emprego) e como contribuir efetivamente.
3️⃣ Consequências de não conformidade
O que acontece se as políticas não são seguidas: consequências disciplinares, impacto nos clientes e na reputação da empresa, riscos legais. O aspecto dissuasório é tão importante quanto o educativo.
Programa de Conscientização Eficaz — Do Treinamento à Mudança de Comportamento
| Método | Adequado para | Métricas de eficácia | Frequência recomendada |
|---|---|---|---|
| Simulação de phishing | Toda a organização — mede vulnerabilidade e treina comportamento no momento do erro | Taxa de cliques, taxa de reporte, tempo até reporte | Mensal (variando temas e sofisticação) |
| E-learning modular | Treinamento escalável com trilhas por perfil (TI, financeiro, RH, executivos) | % conclusão, nota no teste, retenção em reteste após 30 dias | Anual obrigatório + módulos trimestrais |
| Gamificação e desafios | Engajamento contínuo, especialmente em ambientes tech e com perfil jovem | Participação, pontuação por equipe, desafios completados | Contínuo — campanhas mensais |
| Comunicações executivas | Sinalizar compromisso da liderança — impacto na cultura de alto para baixo | Engajamento nas comunicações, pesquisa de percepção de SI | Trimestral ou em eventos de SI relevantes |
| Exercícios práticos | Resposta a incidentes, exercício de tabletop (TTX), fire drills de segurança | Tempo de resposta, identificação de gaps procedimentais | Semestral para equipes de SI; anual para gestores |
4.3 — Cláusulas 7.4 e 7.5: Comunicação e Informação Documentada
7.4 — O que comunicar sobre o SGSI?
A organização deve determinar comunicações internas e externas relativas ao SGSI, especificando 5 elementos: o quê comunicar, quando, a quem, como e quem comunica.
7.5 — Informação Documentada: Requisitos de Criação e Controle
| Requisito 7.5.2 — Criação e atualização | Requisito 7.5.3 — Controle |
|---|---|
| Identificação (título, data, autor, versão) | Disponível e adequada para uso quando e onde necessário |
| Formato e suporte adequados (papel, digital, vídeo) | Protegida adequadamente (contra perda, confidencialidade, uso indevido) |
| Análise crítica e aprovação quanto à pertinência e adequação | Distribuição, acesso, recuperação e uso controlados |
| Armazenamento e preservação (incluindo legibilidade futura) | |
| Controle de mudanças (histórico de versões) | |
| Retenção e descarte (conforme política de retenção e LGPD) |
📂 Documentos obrigatórios vs. registros obrigatórios
Documentos (prescritivos — como fazer)
- Escopo do SGSI (4.3)
- Política de SI (5.2)
- Processo de avaliação de riscos (6.1.2)
- Processo de tratamento de riscos (6.1.3)
- SoA — Declaração de Aplicabilidade (6.1.3d)
- Objetivos de SI (6.2)
- Plano de Tratamento de Riscos (6.1.3e)
Registros (evidências — o que foi feito)
- Resultados da avaliação de riscos (8.2)
- Resultados do tratamento de riscos (8.3)
- Evidências de competência (7.2)
- Resultados de monitoramento e medição (9.1)
- Programa e resultados de auditoria interna (9.2)
- Resultados da revisão pela direção (9.3)
- Não conformidades e ações corretivas (10.1)
Quiz — Domínio 4: Apoio e Cláusula 7
Os 93 Controles do Anexo A
4 temas, 11 novos controles, atributos e relação com a avaliação de riscos
5.1 — Os 4 Temas e seus Controles
🏢 Organizacional — 37 controles (5.1 – 5.37)
Políticas, papéis, responsabilidades, gestão de ativos e de acessos, criptografia, relacionamento com fornecedores, gestão de incidentes, continuidade, conformidade legal. Inclui os novos controles 5.7 (threat intelligence), 5.23 (cloud), 5.29 (SI na continuidade) e 5.30 (continuidade de TIC).
👥 Pessoas — 8 controles (6.1 – 6.8)
Ciclo completo do colaborador: triagem pré-contratação (6.1), termos de emprego (6.2), conscientização (6.3), processo disciplinar (6.4), responsabilidades pós-desligamento (6.5), acordos de confidencialidade (6.6), trabalho remoto (6.7), reporte de eventos de SI (6.8).
🏗️ Físico — 14 controles (7.1 – 7.14)
Perímetros de segurança (7.1), controle de acesso físico (7.2), segurança de escritórios (7.3), monitoramento físico/CCTV — novo! (7.4), trabalho em áreas seguras (7.5), mesa e tela limpa (7.7), remoção de ativos (7.9), descarte seguro de mídia (7.10), manutenção de equipamentos (7.13).
💻 Tecnológico — 34 controles (8.1 – 8.34)
Endpoints (8.1), acesso privilegiado (8.2), restrição de acesso (8.3), autenticação forte (8.5), criptografia (8.24), logs de eventos (8.15), gestão de vulnerabilidades (8.8), testes de intrusão (8.8), SIEM/monitoramento — novo! (8.16), DLP — novo! (8.12), mascaramento — novo! (8.11), filtragem web — novo! (8.23), código seguro — novo! (8.28).
5.2 — Os 11 Novos Controles da Versão 2022
| Controle | Tema | O que exige na prática | Motivação para criação |
|---|---|---|---|
5.7 Inteligência de ameaças | Org. | Coletar, analisar e produzir inteligência acionável sobre ameaças relevantes ao contexto da organização (não apenas receber feeds genéricos) | Aumento de APTs e ataques sofisticados exigindo postura proativa |
5.23 Segurança em cloud | Org. | Processo formal para aquisição, uso, gerenciamento e saída de serviços cloud — incluindo modelo de responsabilidade compartilhada, avaliação de provedores | Adoção massiva de cloud sem controles adequados de SI |
5.29 SI na continuidade | Org. | Planejar como manter SI durante perturbações — garantir que controles de SI sobrevivam a incidentes de continuidade de negócios | Integração explícita entre SI e BCP/DRP |
5.30 Continuidade de TIC | Org. | Preparação de TIC baseada em RTO/RPO para suportar continuidade de negócio — testes periódicos de failover e recovery | Separação entre continuidade de negócio e continuidade de TIC |
7.4 Monitoramento físico | Fís. | Monitoramento contínuo de áreas sensíveis contra acesso físico não autorizado — CCTV, sensores de movimento, alertas de acesso | Evolução das ameaças físicas e insider threats pós-pandemia |
8.9 Gestão de configuração | Tec. | Ciclo de vida de configurações seguras de hardware, software e redes — hardening, baseline de configuração, controle de desvios | Configurações incorretas como vetor principal de breaches (Verizon DBIR) |
8.10 Exclusão de informações | Tec. | Eliminação segura de informações quando não mais necessárias — alinhado à política de retenção e ao direito de exclusão da LGPD | LGPD/GDPR e direito ao esquecimento |
8.11 Mascaramento de dados | Tec. | Técnicas de mascaramento, pseudonimização ou tokenização de dados pessoais — especialmente em ambientes de desenvolvimento, teste e analytics | Proteção de PII em ambientes não produtivos |
8.12 Prevenção de vazamento | Tec. | Medidas de DLP aplicadas a sistemas, redes e dispositivos que processam dados sensíveis — monitoramento e bloqueio de exfiltração | Aumento de exfiltração de dados e insider threats |
8.16 Atividades de monitoramento | Tec. | Monitoramento contínuo de redes, sistemas e aplicações para detecção de anomalias e comportamentos suspeitos (SIEM, UEBA) | Necessidade de detecção proativa — redução de MTTD |
8.23 Filtragem web | Tec. | Gestão de acesso a websites externos para reduzir exposição a conteúdo malicioso, phishing e malware baseado em web | Web como principal vetor de infecção por malware |
8.28 Código seguro | Tec. | Aplicação de princípios de desenvolvimento seguro (OWASP, SAST/DAST, revisão de código) em todo o SDLC — interno e terceirizado | Explosão de vulnerabilidades em código customizado |
5.3 — Os 5 Atributos dos Controles (Novo em 2022)
| Atributo | Valores possíveis | Para que serve |
|---|---|---|
| #Tipo de controle | Preventivo · Detectivo · Corretivo | Classificar controles por quando agem no ciclo de ataque. Um SIEM é detectivo; um firewall é preventivo; um plano de resposta é corretivo. |
| #Propriedades de SI | Confidencialidade · Integridade · Disponibilidade | Identificar qual propriedade da CID o controle protege. Um backup protege principalmente a disponibilidade. MFA protege confidencialidade. |
| #Conceitos de cibersegurança | Identificar · Proteger · Detectar · Responder · Recuperar | Alinhamento direto com o NIST CSF. Permite comunicar postura de segurança usando linguagem reconhecida globalmente. |
| #Capacidades operacionais | Governança · Gestão de ativos · Proteção da informação · Segurança de RH · Controle de acesso · Gestão de ameaças · Continuidade etc. | Mapear controles para as equipes operacionais responsáveis pela implementação. |
| #Domínios de segurança | Governança e ecossistema · Proteção · Defesa · Resiliência | Visão estratégica de alto nível para comunicação com o conselho e a alta direção. |
Quiz — Domínio 5: Controles do Anexo A
Implementação e Operação do SGSI
Controle operacional, execução dos planos de risco, gestão de incidentes e fornecedores
6.1 — Cláusula 8.1: Planejamento e Controle Operacional
Esta cláusula é o "fazer" do ciclo PDCA. A organização deve implementar os processos planejados, estabelecer critérios de execução, evidenciar que os controles funcionam e controlar mudanças — incluindo as não planejadas.
A cláusula 8.2 exige executar a avaliação de riscos em intervalos planejados E quando mudanças significativas ocorrem. Gatilhos práticos: novo sistema crítico implantado, incidente de segurança relevante, mudança regulatória, aquisição de empresa, expansão geográfica, nova família de ameaças identificada (ex: novo ransomware ativo no setor).
6.2 — Gestão de Incidentes (Controles 5.24 – 5.28)
| Controle | O que exige | Artefato esperado |
|---|---|---|
| 5.24 — Planejamento | Definir papéis, responsabilidades e procedimentos ANTES dos incidentes ocorrerem | IRP (Incident Response Plan) aprovado, testado e com versão controlada |
| 5.25 — Avaliação e decisão | Avaliar eventos de SI para decidir se constituem incidentes — critérios de classificação documentados | Critérios de classificação (Crítico/Alto/Médio/Baixo), tabela de triagem |
| 5.26 — Resposta | Responder a incidentes conforme procedimentos documentados — containment, eradication, recovery | Playbooks específicos por tipo de incidente (ransomware, phishing, vazamento) |
| 5.27 — Aprendizado | Conduzir PIR (Post-Incident Review) — lições aprendidas devem retroalimentar o SGSI | Relatório de PIR com: timeline, causa raiz, 5 porquês, ações de melhoria |
| 5.28 — Coleta de evidências | Preservar evidências de forma forense para suporte a processos legais ou disciplinares | Procedimento de cadeia de custódia, ferramentas de forensics, logs imutáveis |
6.3 — Gestão de Fornecedores (Controles 5.19 – 5.22)
A gestão de fornecedores é uma das áreas mais críticas e mais frequentemente auditadas. Um SGSI que protege a organização mas deixa brechas abertas via fornecedores tem uma falsa sensação de segurança.
| Controle | O que exige | Falha comum identificada em auditorias |
|---|---|---|
| 5.19 — Política de segurança em relações com fornecedores | Política documentada definindo como a SI é tratada em toda a cadeia de fornecimento | Política existe mas não é aplicada na prática — fornecedores legados não revisados |
| 5.20 — Abordagem da SI em acordos com fornecedores | Contratos com fornecedores que têm acesso a ativos de informação devem incluir cláusulas explícitas de SI | Contratos antigos sem cláusulas de SI, sem direito a auditoria, sem obrigação de notificação de incidentes |
| 5.21 — Gestão de SI na cadeia de suprimentos de TIC | Controles para endereçar riscos de hardware, software e serviços TIC comprometidos antes da entrega | Sem validação de integridade de software adquirido, sem verificação de fornecedores de hardware crítico |
| 5.22 — Monitoramento, revisão e gestão de mudanças de serviços | Monitorar e revisar regularmente os serviços dos fornecedores — gestão ativa, não apenas contratual | Fornecedores contratados e nunca revisados — incidentes descobertos meses depois pela organização |
Quiz — Domínio 6: Implementação e Cláusula 8
Avaliação do Desempenho
Monitoramento e KPIs, auditoria interna com imparcialidade, revisão pela direção com entradas e saídas obrigatórias
7.1 — Cláusula 9.1: Monitoramento, Medição, Análise e Avaliação
| Controle/Processo | KPI eficaz | Meta típica | Frequência |
|---|---|---|---|
| Gestão de patches (8.8) | % sistemas com patches críticos aplicados em ≤ 30 dias | ≥ 95% | Mensal |
| Controle de acesso privilegiado (8.2) | % contas privilegiadas revisadas no trimestre | 100% | Trimestral |
| Conscientização — phishing (6.3/7.3) | Taxa de cliques em phishing simulado | ≤ 5% | Mensal |
| Gestão de incidentes (5.26) | MTTD (Mean Time to Detect) | ≤ 4 horas | Mensal |
| Backup e recuperação (8.13) | Taxa de sucesso de backups + teste de restauração realizado | 100% / mensal | Diário/Mensal |
| Controle de acesso (8.3) | Número de acessos de desligados reativos (sem automação) | Zero | Mensal |
| Gestão de vulnerabilidades (8.8) | Vulnerabilidades críticas abertas acima de 90 dias | Zero | Mensal |
7.2 — Cláusula 9.2: Auditoria Interna
Programa anual de auditorias
Definir escopo, critérios, frequência e métodos para o período inteiro. Considerar: maturidade do SGSI, mudanças recentes, áreas de alto risco, resultados de auditorias anteriores, e requisitos de partes interessadas (ex: cliente que exige auditoria semestral).
Seleção de auditores com imparcialidade
Requisito inegociável: auditores não podem auditar seu próprio trabalho. Soluções para organizações pequenas: (a) consultores externos para a auditoria interna, (b) cross-audit entre equipes distintas, (c) auditoria de segunda parte por cliente ou parceiro confiável.
Plano de auditoria individual
Para cada auditoria: escopo detalhado, checklist baseado em requisitos ISO 27001, agenda de entrevistas, lista de documentos a revisar. O auditado recebe o plano com antecedência razoável (geralmente 1–2 semanas).
Coleta de evidências objetivas
Três técnicas: entrevistas (o processo é seguido na prática?), observação direta (o controle funciona como documentado?), revisão documental (a documentação existe, está atualizada e é aplicada?). Toda NC deve ter evidência objetiva — não apenas impressão do auditor.
Relatório e encerramento
O relatório lista: conformidades (boas práticas encontradas), NCs maiores, NCs menores, observações/OFIs. É reportado à direção relevante. NCs exigem plano de ação com responsável, prazo e critério de encerramento. O auditor verifica fechamento na próxima auditoria ou via revisão documental.
7.3 — Cláusula 9.3: Revisão pela Direção (Management Review)
📥 Entradas obrigatórias (9.3.2)
- Status de ações de revisões anteriores pela direção
- Mudanças em questões externas e internas relevantes para o SGSI
- Feedback de desempenho do SGSI: NCs, ações corretivas, monitoramento, KPIs, resultados de auditorias, atendimento dos objetivos
- Feedback de partes interessadas
- Resultados da avaliação de riscos e status do plano de tratamento
- Oportunidades de melhoria contínua
📤 Saídas obrigatórias (9.3.3)
- Decisões sobre oportunidades de melhoria contínua
- Qualquer necessidade de mudanças no SGSI (incluindo escopo, política, processos)
- Necessidades de recursos (pessoal, orçamento, tecnologia, treinamento)
A revisão PELA DIREÇÃO é responsabilidade da alta direção — não pode ser delegada completamente ao CISO. O CISO prepara os insumos e apresenta, mas as decisões (saídas obrigatórias) devem ser tomadas pela alta direção. Uma revisão conduzida apenas pelo CISO, sem a alta direção presente, é uma não conformidade.
Quiz — Domínio 7: Avaliação e Cláusula 9
Melhoria Contínua e Não Conformidades
Ações corretivas com causa raiz, tipos de NCs e as 10 dicas mais importantes para o exame
8.1 — Cláusula 10.1: Não Conformidades e Ações Corretivas
| Tipo de achado | Definição | Impacto na certificação | Prazo típico |
|---|---|---|---|
| 🔴 NC Maior (Major) | Ausência de requisito inteiro, falha sistêmica e abrangente, ou situação que coloca em risco sério o SGSI | Pode impedir certificação ou exigir auditoria extra de verificação presencial | 30–60 dias para plano + verificação in loco |
| 🟡 NC Menor (Minor) | Falha isolada ou desvio pontual sem comprometimento sistêmico do SGSI | Não impede certificação — exige plano de ação com prazo | 90 dias para implementação + evidência documental |
| 💡 OFI / Observação | Oportunidade de Melhoria — sugestão do auditor, não é NC | Sem impacto na certificação — organização decide se implementa | A critério da organização |
Processo completo de ação corretiva
Reagir — conter e corrigir imediatamente
Ação imediata para controlar os efeitos da NC. Ex: revogar acessos indevidos agora, colocar sistema comprometido em quarentena, restaurar backup corrompido. A contenção não resolve a causa raiz — é apenas o primeiro passo.
Investigar — análise de causa raiz
Ferramentas: 5 Porquês (perguntar "por que" 5 vezes até a causa sistêmica), Diagrama de Ishikawa (espinha de peixe — categorias: Pessoa, Processo, Tecnologia, Ambiente). O objetivo é eliminar a CAUSA, não o SINTOMA.
Planejar e implementar ação corretiva
A ação deve ser proporcional ao impacto da NC e endereçar diretamente a causa raiz identificada. Deve ter: responsável único, prazo realista, critério de conclusão mensurável, e recursos alocados.
Verificar eficácia da ação
A verificação deve ser feita por alguém diferente de quem implementou (objetividade). Busca confirmar: a causa raiz foi eliminada? A NC pode recorrer? Os controles adjacentes foram afetados?
Documentar tudo
A cláusula 10.1f exige documentação de: natureza da NC, ações subsequentes, resultados da ação corretiva. É informação documentada obrigatória — solicitada em toda auditoria de vigilância.
8.2 — Top 10 Dicas para o Exame PECB Lead Implementer
| # | Confusão ou armadilha frequente | A resposta correta segundo a norma |
|---|---|---|
| 1 | "Custo alto justifica excluir um controle da SoA" | FALSO. Custo alto pode justificar aceitar o risco residual (com aprovação formal), mas não excluir o controle da SoA se há risco identificado que ele mitiga. |
| 2 | "O SGSI é responsabilidade exclusiva da TI" | FALSO. O SGSI é um sistema de gestão organizacional. RH (triagem, desligamento), Jurídico (conformidade), Compras (fornecedores), Operações (continuidade) têm papéis essenciais e obrigatórios. |
| 3 | "Qual é o PRIMEIRO passo na implementação de um SGSI?" | Compreender o contexto organizacional (Cláusula 4) — nunca começar pelos controles técnicos. Sem contexto, os controles serão inadequados ou excessivos para a realidade. |
| 4 | "O auditor interno pode auditar o SGSI que ele mesmo implementou" | FALSO. Conflito de interesse explícito — a cláusula 9.2 exige objetividade e imparcialidade. O mesmo profissional não pode implementar e auditar. |
| 5 | "Certificação = SGSI perfeito" | FALSO. Certificação é um ponto de verificação — confirma que o SGSI atende aos requisitos da norma no momento da auditoria. O SGSI deve ser continuamente mantido e melhorado. |
| 6 | "A Revisão pela Direção pode ser delegada ao CISO" | FALSO. A cláusula 9.3 especifica "análise crítica PELA DIREÇÃO" — a alta direção deve participar e tomar as decisões das saídas obrigatórias (3.3). O CISO prepara; a diretoria decide. |
| 7 | "Lead Implementer pode realizar a auditoria de certificação" | FALSO. Quem constrói e implementa um SGSI não pode auditar o mesmo SGSI de forma independente. Lead Implementer ≠ Lead Auditor. |
| 8 | "Todos os 93 controles do Anexo A são obrigatórios" | FALSO. Apenas controles relevantes para os riscos identificados e requisitos externos são obrigatórios. Exclusões devem ser justificadas na SoA — mas não podem excluir controles que mitiguem riscos reais. |
| 9 | "A SoA é criada uma vez durante a implementação" | FALSO. A SoA é um documento vivo — deve ser revisada e atualizada quando o contexto, riscos ou escopo mudam. Cada reavaliação de riscos pode gerar atualizações na SoA. |
| 10 | "Em questões de cenário, busque a resposta mais técnica" | FALSO para o exame PECB. Questões de cenário geralmente testam a abordagem de gestão (contexto, processo, governança) e não a solução técnica. Se duas respostas parecem corretas, escolha a que considera o contexto organizacional e os requisitos de partes interessadas. |