Workspace ISO 27001 ISMS: do escopo à prontidão para certificação em 19 passos
Guia prático para consultores GRC e times internos de segurança sobre como usar o template de workspace ISO 27001 do Rakenne para construir um conjunto completo e coerente de documentação de ISMS — com validação assistida por ferramentas em cada etapa.
Construir um ISMS compatível com a ISO 27001 exige muita documentação. Uma certificação inicial para uma empresa de porte médio costuma levar de 6 a 12 meses de trabalho de consultoria, com mais de 60 % do tempo gasto em produção de documentos, análise de risco, avaliação de gaps e cruzamento de requisitos com controles. O gargalo raramente é “escrever texto”: é traduzir operações reais, com toda a sua bagunça, em documentação auditável, coerente e alinhada por cláusula.
O template de workspace ISO 27001 ISMS do Rakenne oferece 19 skills especializadas e mais de 55 ferramentas de validação que guiam um agente LLM ao longo de todo o ciclo PDCA. Cada skill impõe um fluxo estruturado, carrega referências específicas da ISO e usa ferramentas determinísticas para checar a saída do agente — capturando os tipos de erro que uma redação genérica por LLM costuma deixar passar: cláusulas obrigatórias ausentes, scores de risco inconsistentes, controles órfãos, registros CAPA incompletos e inconsistências entre documentos onde um artefato contradiz outro.
Este guia percorre as 19 skills em sequência, mostra trechos de diálogo reais e saídas de ferramentas de uma sessão ao vivo e explica por que a documentação de ISMS assistida por ferramentas é materialmente melhor do que a redação genérica com IA.
Por que LLMs “puros” não bastam para ISO 27001
Um LLM genérico como o ChatGPT consegue redigir políticas, procedimentos e declarações de risco. Onde ele falha é na validação em nível de conformidade:
| Questão | LLM puro | Rakenne com skills ISO 27001 |
|---|---|---|
| Completude de cláusula | Pode ignorar requisitos obrigatórios | Varre o workspace em busca de artefatos obrigatórios e aponta gaps |
| Rastreabilidade risco–controle | Fraca sem estado estruturado | Obriga vínculos entre registro de risco, SoA e plano de tratamento |
| Consistência entre documentos | Contradições entre documentos passam despercebidas | 11 checagens de rastreabilidade entre documentos detectam inconsistências em todos os artefatos do ISMS — do escopo às políticas e ao log de CAPA |
| Processo repetível | A saída varia conforme o prompt | Cada skill define um fluxo fixo; os mesmos checks rodam sempre |
| Autocorreção | O modelo pode “afirmar” cobertura sem entregá‑la | As ferramentas retornam PASS/FAIL; o agente revisa até passar |
A diferença é estrutural: as skills dão ao agente uma especificação (workflow + referências + estrutura) e ferramentas (checagens determinísticas) para verificar a própria saída. É isso que transforma um rascunho em um artefato auditável.
A jornada ISMS em 19 passos
O template de workspace instala 19 skills que se alinham ao ciclo PDCA da ISO 27001:
| Fase | Passo | Skill | O que é validado |
|---|---|---|---|
| Plan | 1 | Organization Profile | Classificação de stack tecnológico, completude do perfil |
| Plan | 2 | ISMS Scope | Integridade do escopo, justificativas de exclusão, análise de impacto downstream |
| Plan | 3 | Asset Inventory | Consistência de rotulagem de ativos, responsabilidade por owner |
| Plan | 4 | Risk Assessment | Conformidade da metodologia, completude de cada registro, detecção de duplicados, mapeamento risco–controle, limiares de risco residual, cobertura ativo–risco |
| Plan | 5 | Statement of Applicability | Sugestões de inclusão de controles, auditoria de justificativas, consistência SoA–risco, validação de evidências de políticas, rastreamento de status de implementação |
| Plan | 6 | Gap Assessment | Detecção de artefatos obrigatórios, cobertura de requisitos por cláusula, rating de maturidade, priorização de remediação, dashboard de rastreabilidade do ISMS |
| Do | 7 | Policy Generator | Seleção de template, metadados de documento, cobertura de tópicos obrigatórios, rastreabilidade tratamento–política |
| Do | 8 | Physical Security Perimeter | Controles de prevenção a tailgating |
| Do | 9 | Supplier Security Policy | Cláusulas por tier de fornecedor, reforço de direito de auditoria |
| Do | 10 | Risk Treatment Plan | Consistência tratamento–SoA, completude de planos de ação, validação de prazos e owners |
| Do | 11 | Business Continuity Plan | Análise de impacto no negócio, estratégias de recuperação, validação de RTO/RPO |
| Do | 12 | Incident Response Procedure | Fluxo de escalação, categorização de severidade, checagem de notificação regulatória |
| Do | 13 | Access Control Policy | Princípio do menor privilégio, cobertura de revisão de acesso, consistência com inventário de ativos |
| Do | 14 | Awareness & Training Program | Cobertura de público-alvo, completude de conteúdo, rastreamento de cronograma |
| Check | 15 | Monitoring & Evaluation | Geração de KPIs, completude de CAPA, rastreio de ações corretivas, reconciliação NC de auditoria–CAPA, Registro de Objetivos de SI e objectives_completeness_checker |
| Check | 16 | IS Objectives & Planning | Alinhamento de objetivos com política, mensurabilidade, atribuição de recursos |
| Check | 17 | Internal Audit Report | Imparcialidade do auditor, completude de achados, classificação de severidade |
| Act | 18 | Management Review | Cobertura de insumos obrigatórios, compilação de “input pack”, completude de ações |
| Act | 19 | Continual Improvement Register | Rastreabilidade de fontes de melhoria, priorização, validação de status do ciclo PDCA |
Cada skill lê arquivos do workspace produzidos por etapas anteriores — o perfil da organização alimenta o escopo, o escopo alimenta a avaliação de riscos, a avaliação de riscos alimenta a SoA e assim por diante. A cadeia inteira é rastreável.
Passo 1: Organization Profile — a base que todo o resto lê
Todo projeto ISO 27001 começa entendendo a organização. A skill Organization Profile captura fatos estruturados — razão social, porte, localizações, stack tecnológico, obrigações regulatórias, principais responsáveis — em um arquivo de perfil reutilizável.
Você: A CloudSync Solutions é uma empresa SaaS B2B com sede em São Paulo, 45 colaboradores. Rodamos em GCP, usamos GitHub, Google Workspace, Okta para IAM, Stripe para pagamentos e SendGrid para email. Maria Santos é CISO, João Silva é CTO. Lidamos com dados de projetos de clientes e estamos sujeitos à LGPD.
Agente: Preparei o perfil da organização. Vou rodar o classificador de stack tecnológico e o verificador de completude do perfil.
O classificador identificou 8 entradas: GCP como IaaS, GitHub como SaaS (DevOps), Google Workspace como SaaS (Produtividade), Okta como SaaS (Segurança/IAM). Um alerta — AWS CloudFront aparece sem especificação de região.
Completude do perfil: PASS (92 %). Pequena lacuna: a faixa de receita é estimada — considere confirmar com finanças.
Também atualizei o dashboard do projeto para marcar o Organization Profile como concluído.
Passo 2: ISMS Scope — desenhando fronteiras defensáveis
A skill ISMS Scope define quais partes da organização, processos, localizações e sistemas estão no escopo de certificação — e, principalmente, justifica quaisquer exclusões. Ela lê o perfil da organização e produz uma declaração de escopo que o auditor consegue rastrear até a Cláusula 4.3.
Você: Defina o escopo do ISMS para a CloudSync Solutions. Nossa plataforma SaaS e a infraestrutura de suporte devem estar no escopo. Sistemas de marketing e RH ficam fora.
Agente: Redigi a declaração de escopo com base no perfil da organização. Vou rodar as checagens de integridade de escopo e de justificativas de exclusão.
Integridade das fronteiras do escopo: PASS. O escopo cobre a plataforma SaaS, infraestrutura em GCP, processamento de dados de clientes e todos os serviços de TI de suporte. As fronteiras estão claramente definidas por unidade organizacional, localização (sede em São Paulo + regiões GCP) e tecnologia.
Verificação de justificativas de exclusão: WARNING. Duas exclusões precisam de justificativas mais fortes. “Sistemas de marketing” foi aceita — não há processamento de dados de clientes. Mas “Sistemas de RH” precisa de esclarecimento: o RH mantém dados pessoais de empregados sujeitos à LGPD, e a Cláusula 4.3 exige justificar por que o tratamento de dados de RH não afeta os objetivos do ISMS. Sinalizei para revisão e sugeri adicionar uma frase explicando que os dados de RH são geridos sob um programa separado de conformidade com a LGPD.
A declaração de escopo se torna a âncora para todos os passos seguintes — a avaliação de riscos cobre apenas ativos dentro do escopo, a SoA contempla apenas controles dentro do escopo, e o gap assessment verifica cobertura em relação às fronteiras definidas.
Quando o escopo muda durante o projeto (um novo escritório é aberto, um provedor de nuvem é adicionado), o analisador de impacto de mudança de escopo varre todos os documentos downstream — inventário de ativos, registro de riscos, SoA e políticas — e sinaliza inconsistências. Por exemplo, se você exclui “escritório de Tóquio” do escopo, mas o inventário de ativos ainda lista um “Servidor de arquivos do escritório de Tóquio”, a ferramenta detecta imediatamente.
Passo 3: Asset Inventory — o que você protege precisa estar nomeado
Antes de avaliar riscos, o ISMS precisa de um inventário completo de ativos de informação. A skill Asset Inventory cataloga ativos por tipo (informação, software, hardware, serviços, pessoas), atribui owners e valida a consistência de rotulagem.
Você: Construa o inventário de ativos com base no perfil da organização e no escopo.
Agente: Identifiquei 18 ativos de informação dentro do escopo do ISMS e os classifiquei por tipo. Vou validar a rotulagem e as atribuições de ownership.
Consistência de rotulagem: PASS. Todos os 18 ativos seguem a convenção de nomenclatura (prefixo de tipo + ID sequencial). Os níveis de classificação (Confidencial, Interno, Público) estão atribuídos de forma consistente — dados de projetos de clientes e chaves de API são Confidenciais; documentação interna é Interna.
Verificação de accountability de owner: WARNING. Dois ativos têm owners em nível de equipe (“Time de Engenharia”) em vez de indivíduos nomeados. A Cláusula A.5.9 da ISO 27001 exige owners identificáveis. Sinalizei AST‑011 (Pipeline CI/CD) e AST‑014 (Dashboard de monitoramento) para reatribuição a pessoas específicas.
O inventário de ativos alimenta diretamente a avaliação de riscos — cada risco precisa referenciar um ativo específico, e ativos órfãos (sem riscos associados) são sinalizados para revisão.
Passo 4: Risk Assessment — onde a validação realmente faz diferença
A avaliação de riscos (Cláusula 6.1.2) é onde a validação assistida por ferramentas mais se destaca. Um LLM puro pode listar riscos, mas não consegue garantir de forma confiável que cada risco tenha uma cadeia ameaça–vulnerabilidade–consequência adequada, que os scores sigam a metodologia definida ou que as decisões de tratamento estejam ligadas a controles específicos do Anexo A.
A skill Risk Assessment aciona seis verificações em sequência:
- Conformidade da metodologia — valida se escalas de probabilidade/impacto, matriz de risco e critérios de aceitação estão definidos segundo a Cláusula 6.1.2.
- Completude de cada risco — verifica se todo risco tem ativo, ameaça, vulnerabilidade, consequência, scores, owner e decisão de tratamento.
- Detecção de duplicados — identifica riscos sobrepostos ou quase duplicados.
- Cobertura ativo–risco — cruza o inventário de ativos com o registro de riscos para confirmar que ativos Confidenciais e Restritos possuem entradas de risco correspondentes.
- Mapeamento risco–controle — garante que todo risco tratado esteja ligado a controles específicos do Anexo A.
- Limite de risco residual — verifica se, após tratamento, os scores caem abaixo do limiar de aceitação.
Você: Com base no perfil da organização e no escopo, avalie nossos riscos de segurança da informação.
Agente: Identifiquei 7 riscos e montei o registro de riscos com score de probabilidade × impacto. Vou rodar a suíte de validação.
O verificador de metodologia confirmou que todos os 11 requisitos da Cláusula 6.1.2 foram atendidos — escalas, matriz e limiar de aceitação 12 estão corretamente definidos.
Cada um dos 7 riscos passou na validação de completude: ativo, ameaça, vulnerabilidade, consequência, scores P×I, owner e decisão de tratamento estão presentes.
O detector de duplicados não encontrou riscos sobrepostos — todos os 7 cobrem cenários distintos.
O validador de cobertura ativo–risco cruzou o inventário de ativos: 5 dos 6 ativos Confidenciais possuem entradas de risco correspondentes. Porém, AST‑008 (Cofre de chaves de API) é classificado como Confidencial mas não tem entrada no registro — adicionei R‑08 cobrindo extração não autorizada de chaves com score 4×5=20 (Tratar, controles A.5.17, A.8.24).
O mapeador risco–controle verificou que todos os 8 riscos tratados estão ligados a controles específicos do Anexo A. E o verificador de risco residual confirmou que todos os scores pós‑tratamento ficam abaixo do limiar de aceitação 12.
Um trecho do registro de riscos gerado:
| ID | Ativo | Ameaça | P | I | Score | Tratamento | Controles |
|---|---|---|---|---|---|---|---|
| R-01 | Dados de projetos de clientes | Acesso não autorizado | 3 | 5 | 15 | Tratar | A.5.15, A.5.18 |
| R-02 | Infraestrutura em nuvem | Configuração incorreta | 4 | 4 | 16 | Tratar | A.8.20, A.8.21 |
| R-06 | Plataforma SaaS | Vulnerabilidades em APIs | 4 | 5 | 20 | Tratar | A.8.25, A.8.26 |
Sem essas ferramentas, o agente poderia produzir um registro “verossímil”, mas com scores desalinhados, tratamentos órfãos ou controles que não endereçam de fato as ameaças. As ferramentas codificam as mesmas checagens lógicas que um consultor sênior faria — de forma automática e consistente.
Passo 5: Statement of Applicability — a ponte entre riscos e controles
A Statement of Applicability (SoA) é um dos documentos mais auditados na ISO 27001. Ela lista todos os 93 controles do Anexo A e declara quais são aplicáveis, quais são excluídos e por quê. A skill SoA cruza o registro de riscos para sugerir inclusões de controles, verifica se toda justificativa é rastreável e rastreia o status de implementação de cada controle ao longo do seu ciclo de vida.
Você: Gere a Declaração de Aplicabilidade com base na nossa avaliação de riscos. Inclua rastreamento de status de implementação.
Agente: Mapeei todos os 93 controles do Anexo A contra o registro de riscos e o perfil da organização. Vou rodar a suíte de validação da SoA.
Sugestões de inclusão de controles: 78 controles marcados como aplicáveis, 15 excluídos. A ferramenta sinalizou 2 controles que podem precisar de reavaliação: A.7.4 (Monitoramento de segurança física) — marcado como excluído, mas a infraestrutura inclui um escritório com acesso a sala de servidores. E A.5.23 (Segurança da informação para serviços em nuvem) — deveria ser aplicável dada a dependência do GCP.
Auditoria de justificativas: PASS. Todas as 15 exclusões possuem justificativas documentadas referenciando fronteiras de escopo ou contexto organizacional específico. A auditoria também sinalizou 12 controles com evidências mas status de implementação ainda “Não Iniciado” — considere atualizar conforme a implementação avança.
Consistência SoA–risco: PASS. Todo risco tratado no registro de riscos está mapeado a pelo menos um controle aplicável na SoA, e nenhum controle aplicável carece de risco ou requisito de negócio correspondente.
Resumo de status de implementação: Não Iniciado: 34, Planejado: 28, Implementado: 14, Verificado: 2. O verificador de consistência agora rastreia esses dados para que você veja de relance o andamento da implementação.
Verificação de evidências de políticas: o verificador de consistência também escaneou o diretório de políticas. 3 controles incluídos referenciam arquivos de evidência que ainda não existem — A.5.24 cita “Incident-Management-Procedure.md”, mas esse arquivo não foi gerado. Registrei como lembrete para o passo do Policy Generator.
A SoA inclui uma coluna opcional de Status de implementação com quatro valores de ciclo de vida: Não Iniciado, Planejado, Implementado e Verificado. Isso dá aos auditores uma visão clara do progresso da implementação — não apenas quais controles são aplicáveis, mas em que ponto cada um se encontra. A coluna é opcional; SoAs existentes sem ela continuam funcionando. Quando preenchida, as três ferramentas de validação reportam sobre ela: a auditoria de justificativas sinaliza controles com evidências mas status desatualizado, o verificador de consistência resume a distribuição, e o índice de evidências inclui o status na tabela de saída.
A SoA se torna um documento vivo — à medida que os riscos mudam, a ferramenta pode re‑verificar se as decisões de aplicabilidade ainda se sustentam, e o status de implementação acompanha o progresso rumo à conformidade plena.
Passo 6: Gap Assessment — encontrar o que ainda falta
Depois que os cinco primeiros passos geram os artefatos de base, a skill Gap Assessment revisa o workspace inteiro para identificar o que ainda é necessário para a certificação.
Você: Avalie o estado atual do nosso ISMS em relação à ISO 27001.
Agente: Escaneei o workspace em busca de artefatos obrigatórios e atribuí um nível de maturidade para cada cláusula. Eis o que encontrei.
O scanner de artefatos obrigatórios produziu um checklist rastreável — a declaração de escopo do ISMS e o registro de riscos estão presentes, mas a Política de Segurança da Informação, a Declaração de Aplicabilidade e os resultados de Auditoria Interna ainda faltam.
Para maturidade por cláusula, atribuí nível 3 (“Definido”) à Cláusula 6 (Planejamento), com base na metodologia de risco e no registro existentes, enquanto a Cláusula 9 (Avaliação de desempenho) está em nível 0 (“Inexistente”), pois ainda não há monitoramento, auditoria ou revisão pela direção.
Com base no risco de auditoria, a priorização de remediação é:
- Imediato — Política de Segurança da Informação (Cláusula 5.2), justificativas de exclusão de escopo
- Curto prazo — Declaração de Aplicabilidade, Plano de Tratamento de Riscos, Objetivos de Segurança
- Médio prazo — Procedimentos operacionais (controle de acesso, gestão de incidentes, segurança de fornecedores)
- Prontidão para auditoria — Auditoria interna, revisão pela direção, processo de CAPA
É aqui que o PDCA ganha forma concreta: a avaliação de gaps indica exatamente quais skills subsequentes devem ser executadas e em que ordem.
Passo 7: Policy Generator — políticas sob medida com controle de documento
A skill Policy Generator cria políticas compatíveis com a ISO a partir do contexto da organização. Ela suporta 16 tipos de documento e lê o perfil da organização, o registro de riscos e a declaração de escopo para produzir políticas que referenciam sistemas, cargos e requisitos regulatórios reais — não placeholders genéricos.
Você: Gere a Política de Segurança da Informação para a CloudSync Solutions.
Agente: Redigi a POL‑001 com base no seu perfil organizacional e contexto de risco. Vou validar os metadados do documento e a cobertura de tópicos obrigatórios.
Verificação de metadados: PASS. O documento POL‑001 tem versão, owner (Maria Santos), aprovador (João Silva), data de entrada em vigor, próxima data de revisão e classificação (Interno) — todos presentes.
Verificador de tópicos obrigatórios: PASS. Todos os tópicos necessários estão cobertos — comprometimento da direção (5.1), propósito (5.2), papéis e responsabilidades (5.3), gestão de riscos (6.1), requisitos de conformidade e agenda de revisão.
Após gerar todas as 10 políticas, rodei a checagem de rastreabilidade tratamento–política. Ela cruzou as 8 decisões “Tratar” do plano de tratamento de riscos com as políticas geradas. 7 de 8 possuem cadeias completas — a política que implementa cada controle existe. Uma lacuna: R‑06 (vulnerabilidades em APIs, controles A.8.25–A.8.26) mapeia para um Procedimento de Desenvolvimento Seguro, mas ele ainda não foi gerado, já que procedimentos de desenvolvimento de software são opcionais para o seu escopo. Recomendo adicioná‑lo, considerando que a plataforma SaaS é o ativo principal.
A política gerada inclui:
- Cabeçalhos alinhados à norma (5.1 Comprometimento da direção, 5.2 Finalidade, 5.3 Papéis e responsabilidades)
- Objetivos específicos da organização (“Alcançar certificação ISO 27001 até o 4T/2026”, “Conformidade com a LGPD”)
- Atribuição nominal de papéis (“Maria Santos — CISO”, “João Silva — CTO”)
- Referências cruzadas para documentos relacionados (POL‑002 Política de Gestão de Riscos, inventário de ativos, SoA)
Um LLM genérico poderia redigir uma política “ok”. A skill garante que essa política seja coerente com todos os outros artefatos do workspace.
Passo 8: Physical Security Perimeter — controles além do digital
Mesmo organizações cloud-native têm questões de segurança física — escritórios, salas de reunião e armários de rede. A skill Physical Security Perimeter gera controles adaptados à estrutura física da organização, com foco em controle de acesso, gestão de visitantes e prevenção a tailgating.
Você: Defina controles de segurança física para o nosso escritório em São Paulo.
Agente: Com base no perfil da organização, seu escritório tem uma localização única com sala de servidores e layout open‑plan. Redigi o documento de perímetro de segurança física com controles para três zonas: entrada do prédio, andar do escritório e sala de servidores. Vou validar.
Checagem de prevenção a tailgating: PASS. Os controles incluem entrada por crachá na recepção do prédio, registro de visitantes com exigência de acompanhamento e entrada tipo mantrap para a sala de servidores com dupla autenticação (crachá + PIN).
Também fiz a referência cruzada com a SoA — A.7.1 (Perímetros de segurança física), A.7.2 (Entrada física) e A.7.4 (Monitoramento de segurança física) estão todos endereçados.
Passo 9: Supplier Security Policy — gerenciando risco de terceiros
Empresas SaaS dependem fortemente de serviços de terceiros. A skill Supplier Security Policy gera requisitos de segurança por nível de acesso a dados e criticidade de cada fornecedor, garantindo cláusulas de direito de auditoria e acordos de processamento de dados.
Você: Crie a política de segurança de fornecedores com base no stack tecnológico e na avaliação de riscos.
Agente: Classifiquei os 8 fornecedores em três tiers com base em acesso a dados e criticidade. Vou validar a política.
Classificação por tier:
- Tier 1 (Crítico): GCP (IaaS — hospeda todos os dados de clientes), Okta (IAM — controla autenticação)
- Tier 2 (Importante): GitHub (código‑fonte), Stripe (processamento de pagamentos), Google Workspace (comunicação interna)
- Tier 3 (Padrão): SendGrid (envio de email), CloudFront (CDN), ferramentas de monitoramento
Geração de cláusulas por tier: PASS. Fornecedores Tier 1 exigem relatórios SOC 2 Type II anuais, cláusula de direito de auditoria, notificação de incidentes em até 24 horas e garantias de residência de dados. Fornecedores Tier 2 exigem evidências SOC 2 ou ISO 27001 e notificação em até 48 horas. Fornecedores Tier 3 exigem questionários de segurança básicos.
Reforço de direito de auditoria: PASS. Todas as cláusulas de fornecedores Tier 1 e Tier 2 incluem direito contratual de auditoria conforme A.5.19 e A.5.21.
Passo 10: Risk Treatment Plan — traduzindo riscos em ações concretas
O registro de riscos identifica ameaças e controles, mas o Risk Treatment Plan transforma essas decisões em planos de ação executáveis — com owners, prazos, recursos necessários e métricas de sucesso. A skill valida a consistência entre o plano de tratamento e a SoA, e garante que nenhuma decisão “Tratar” fique sem plano de ação correspondente.
Você: Elabore o plano de tratamento de riscos com base no registro de riscos e na SoA.
Agente: Gerei planos de ação para os 8 riscos com decisão “Tratar”. Vou rodar as validações.
Consistência tratamento–SoA: PASS. Todos os 8 planos de ação referenciam controles marcados como aplicáveis na SoA. Nenhum controle órfão.
Completude de planos de ação: WARNING. 7 de 8 planos estão completos — owner, prazo, recursos e critério de sucesso presentes. O plano para R‑06 (vulnerabilidades em APIs) está sem estimativa de recursos. Sinalizei para revisão.
Validação de prazos: PASS. Todos os prazos estão dentro do horizonte de 12 meses para certificação, e nenhuma ação de prioridade alta tem prazo superior a 90 dias.
Passo 11: Business Continuity Plan — preparação para o pior cenário
A skill Business Continuity Plan produz uma análise de impacto no negócio (BIA), estratégias de recuperação e planos de continuidade alinhados ao Anexo A (A.5.29, A.5.30). Ela valida que os tempos de recuperação (RTO/RPO) sejam realistas para cada processo crítico.
Você: Crie o plano de continuidade de negócios para a CloudSync Solutions.
Agente: Realizei a análise de impacto no negócio e identifiquei 5 processos críticos. Vou validar as estratégias de recuperação.
Análise de impacto no negócio: PASS. Cada processo tem classificação de criticidade, impacto financeiro estimado por hora de indisponibilidade e dependências mapeadas.
Validação de RTO/RPO: WARNING. O RTO da plataforma SaaS está definido em 4 horas, mas a estratégia de recuperação depende de restauração de snapshot do GCP, que tipicamente leva 2–6 horas. Recomendo ajustar o RTO para 6 horas ou implementar failover automático para atingir 4 horas.
Estratégias de recuperação: PASS. Todos os 5 processos críticos possuem estratégias de recuperação documentadas com responsáveis, procedimentos de ativação e critérios de retorno à operação normal.
Passo 12: Incident Response Procedure — quando algo dá errado
A skill Incident Response Procedure gera procedimentos de resposta a incidentes com fluxos de escalação, categorização de severidade e checagem de requisitos de notificação regulatória (como os prazos da LGPD para comunicação à ANPD).
Você: Crie o procedimento de resposta a incidentes de segurança.
Agente: Redigi o PROC‑003 com fluxo de resposta em 5 fases: detecção, contenção, erradicação, recuperação e lições aprendidas. Vou validar.
Fluxo de escalação: PASS. Incidentes de severidade Crítica escalam para a CISO (Maria Santos) em até 30 minutos, com notificação ao CTO (João Silva) em até 1 hora.
Categorização de severidade: PASS. Quatro níveis definidos (Crítico, Alto, Médio, Baixo) com critérios claros de classificação baseados em impacto a dados de clientes, disponibilidade do serviço e obrigações regulatórias.
Checagem de notificação regulatória: PASS. O procedimento inclui prazo de 72 horas para notificação à ANPD conforme a LGPD, e notificação a clientes afetados em até 48 horas quando dados pessoais estão envolvidos. Ambos os prazos referenciam os controles A.5.24 e A.5.26 da SoA.
Passo 13: Access Control Policy — quem acessa o quê, e por quê
A skill Access Control Policy gera uma política de controle de acesso baseada no princípio do menor privilégio, com cobertura de revisão periódica e consistência com o inventário de ativos. Ela cruza os ativos do workspace para garantir que todo sistema dentro do escopo tenha controles de acesso definidos.
Você: Gere a política de controle de acesso para a CloudSync Solutions.
Agente: Redigi a POL‑003 com regras de acesso para todos os sistemas dentro do escopo. Vou validar.
Princípio do menor privilégio: PASS. Cada sistema tem perfis de acesso definidos por cargo, com justificativa documentada para acessos privilegiados. Contas administrativas do GCP e Okta exigem aprovação do CISO.
Cobertura de revisão de acesso: PASS. Revisões trimestrais programadas para todos os sistemas Tier 1 (GCP, Okta), semestrais para Tier 2 (GitHub, Stripe, Google Workspace).
Consistência com inventário de ativos: WARNING. 16 de 18 ativos possuem controles de acesso mapeados. AST‑015 (Documentação técnica interna) e AST‑017 (Ambiente de staging) ainda não possuem regras de acesso explícitas. Sinalizei para inclusão.
Passo 14: Awareness & Training Program — cultura de segurança
A skill Awareness & Training Program cria um programa de conscientização e treinamento em segurança da informação com cobertura por público-alvo, conteúdo obrigatório alinhado à ISO 27001 e cronograma de execução rastreável.
Você: Crie o programa de conscientização e treinamento em segurança da informação.
Agente: Desenhei o programa com 4 trilhas de treinamento segmentadas por público. Vou validar.
Cobertura de público-alvo: PASS. Quatro trilhas definidas: todos os colaboradores (onboarding + anual), equipe de engenharia (desenvolvimento seguro, trimestral), gestão (governança e riscos, semestral) e equipe de suporte (tratamento de dados de clientes, trimestral).
Completude de conteúdo: PASS. Todos os tópicos obrigatórios cobertos — política de segurança da informação, gestão de senhas, phishing, classificação de dados, resposta a incidentes e responsabilidades individuais sob a LGPD.
Rastreamento de cronograma: WARNING. O cronograma do 1T/2026 mostra que o treinamento de onboarding está configurado, mas o primeiro treinamento anual obrigatório ainda não tem data definida. Recomendo agendar para antes da auditoria interna.
Passo 15: Monitoring & Evaluation — medindo o que importa
A skill Monitoring & Evaluation gera KPIs alinhados aos objetivos do ISMS, rastreia ações corretivas originadas da auditoria e garante que o processo de CAPA (Ação Corretiva e Preventiva) esteja completo. Ela também mantém o Registro de Objetivos de SI e usa o objectives_completeness_checker para verificar que cada objetivo tenha métricas, metas e owners definidos.
Você: Configure o framework de monitoramento e avaliação do nosso ISMS.
Agente: Gerei 8 KPIs alinhados aos objetivos do ISMS definidos no escopo e nas políticas. Vou validar o rastreamento de CAPA.
Geração de KPIs: PASS. Cada KPI tem métrica definida, meta, frequência de medição, fonte de dados e owner responsável. Exemplos: “Porcentagem de revisões de acesso concluídas no prazo” (meta: 100 %, trimestral, fonte: logs de auditoria do Okta, owner: Maria Santos), “Tempo médio para corrigir vulnerabilidades críticas” (meta: <72h, mensal, fonte: alertas de segurança do GitHub, owner: João Silva).
Completude de CAPA: WARNING. Dois dos três achados de auditoria (Finding 01 e Finding 02) possuem registros CAPA completos — causa raiz, ação corretiva, owner, prazo e critérios de efetividade. O Finding 03 (verificação de backups) tem causa raiz e ação corretiva definidos, mas está sem critérios de verificação de efetividade. Sinalizei para completar.
Reconciliação NC–CAPA de auditoria: o reconciliador cruzou o relatório de auditoria interna com o log de CAPA. Todas as 3 NCs de auditoria (NC‑001 a NC‑003) possuem entradas CAPA correspondentes. Ele também verificou os controles reprovados no relatório de monitoramento — a métrica de revisão de acesso (72 % de conclusão vs. meta de 100 %) foi corretamente vinculada à CAPA‑001. Nenhum achado órfão.
Rastreamento de ações corretivas: PASS. Todos os CAPAs têm owners atribuídos e prazos dentro de 90 dias da data do achado.
Passo 16: IS Objectives & Planning — objetivos mensuráveis de segurança
A skill IS Objectives & Planning garante que os objetivos de segurança da informação definidos pela organização sejam mensuráveis, alinhados à política de SI, tenham recursos alocados e responsáveis definidos — conforme a Cláusula 6.2.
Você: Defina os objetivos de segurança da informação para a CloudSync Solutions.
Agente: Redigi 6 objetivos de SI alinhados à política e ao contexto de risco. Vou validar.
Alinhamento com política: PASS. Cada objetivo referencia uma seção específica da Política de Segurança da Informação (POL‑001). “Reduzir tempo médio de correção de vulnerabilidades críticas para menos de 72 horas” referencia a seção 6.1 de gestão de riscos.
Mensurabilidade: PASS. Todos os 6 objetivos possuem métricas quantificáveis, metas numéricas, frequência de medição e fonte de dados.
Atribuição de recursos: WARNING. 5 de 6 objetivos têm owner e orçamento definidos. O objetivo “Alcançar 100 % de cobertura de treinamento em SI” está sem estimativa de horas necessárias. Sinalizei para revisão.
Passo 17: Auditoria interna — imparcialidade e validação de achados
A skill Internal Audit Report produz um plano de auditoria, checklist, achados e classificação de severidade. O que a diferencia de uma simples redação:
Você: Crie o relatório de auditoria interna do nosso ISMS.
Agente: Preparei o plano de auditoria para 20–24 de março de 2026, com Carlos Mendes, do time de Qualidade, como auditor líder. Vou rodar a checagem de imparcialidade.
Validação de imparcialidade: PASS. Carlos Mendes não possui responsabilidades operacionais, de gestão ou de desenho do ISMS — independência confirmada.
Completei o checklist de auditoria para todas as cláusulas e controles do Anexo A. Foram identificados três achados:
Finding 01 (Evidências de revisão de acesso, A.5.15): Não conformidade menor. A Política de Controle de Acesso exige revisões trimestrais, mas não há registros do 1T/2026. Causa raiz: a transição para Okta foi concluída, porém os fluxos de revisão ainda não foram agendados.
Finding 02 (Procedimento de gestão de incidentes, A.5.24): Não conformidade menor. O PROC‑003 está em rascunho e não contempla passos específicos para incidentes em ambiente SaaS.
Finding 03 (Verificação de backups, A.8.13): Não conformidade maior. Existem backups em GCP, mas não há registros de testes de restauração. A suposição de que serviços gerenciados garantem integridade sem verificação manual é insuficiente.
O checklist de auditoria referencia artefatos reais do workspace:
| Ref | Requisito | Evidência | Status |
|---|---|---|---|
| 4.3 | Escopo do ISMS documentado? | isms-scope-statement.md | Pass |
| 6.1 | Registro de riscos existe? | risk-register.md | Pass |
| A.5.15 | Revisões de acesso realizadas? | Sem registros do 1T/2026 | Fail |
| A.8.13 | Backups verificados? | Backups em GCP, sem logs de teste | Fail |
Passo 18: Management Review — fechando o ciclo PDCA
A skill compila o pacote de insumos de revisão pela direção conforme a Cláusula 9.3, puxando artefatos de todas as etapas anteriores. O verificador de insumos obrigatórios garante que os 10 itens exigidos estejam cobertos:
- Status das ações de revisões anteriores
- Mudanças em questões internas/externas
- Não conformidades e ações corretivas
- Resultados de monitoramento e medição
- Resultados de auditorias
- Cumprimento de objetivos
- Feedback de partes interessadas
- Resultados de avaliações de risco
- Oportunidades de melhoria
- Necessidades de recursos
Você: Compile o pacote de insumos para a revisão pela direção.
Agente: Compilei o input pack com referências rastreáveis para todos os artefatos do workspace. O verificador de insumos obrigatórios confirmou que os 10 itens da Cláusula 9.3 estão cobertos.
Também validei que cada ação definida na revisão tem owner, prazo e critério de aceitação — todas as checagens passaram.
Passo 19: Continual Improvement Register — mantendo o ISMS vivo
A skill Continual Improvement Register fecha o ciclo PDCA ao capturar oportunidades de melhoria vindas de todas as fontes — achados de auditoria, revisão pela direção, análise de incidentes, feedback de colaboradores — e rastrear cada uma desde a identificação até a implementação e verificação de efetividade.
Você: Crie o registro de melhoria contínua do nosso ISMS.
Agente: Compilei o registro com 8 oportunidades de melhoria identificadas ao longo do ciclo. Vou validar.
Rastreabilidade de fontes: PASS. Cada oportunidade referencia sua origem — 3 vêm de achados de auditoria interna, 2 da revisão pela direção, 2 da análise de incidentes e 1 do programa de conscientização.
Priorização: PASS. Todas as oportunidades estão classificadas por impacto (Alto/Médio/Baixo) e esforço de implementação, com justificativa documentada.
Validação de status PDCA: WARNING. 6 de 8 oportunidades possuem ciclo PDCA completo — planejamento, execução, verificação e ação definidos. Duas oportunidades recentes (oriundas da revisão pela direção) ainda estão na fase “Plan” sem prazo para a fase “Do”. Sinalizei para definição de cronograma.
Rastreabilidade entre documentos: a perspectiva do auditor
Auditores ISO 27001 não avaliam documentos isoladamente — eles rastreiam cadeias. “Mostre o risco que levou a este controle. Mostre a política que o implementa. Mostre a evidência de que está funcionando.” Se um elo da cadeia se rompe, o auditor registra uma não conformidade.
As ferramentas de rastreabilidade entre documentos do Rakenne verificam automaticamente 11 desses elos. Cada ferramenta roda dentro da skill que produz o documento downstream, checando-o contra os artefatos upstream. Todos os parâmetros entre documentos são opcionais — as ferramentas descobrem automaticamente os documentos no workspace e só verificam vínculos onde ambos os extremos existem.
Veja o que acontece quando você roda o dashboard de rastreabilidade do ISMS após concluir as 19 skills:
Você: Rode o dashboard de rastreabilidade para verificar a consistência geral do ISMS.
Agente: Escaneei o workspace e verifiquei todos os 11 vínculos de rastreabilidade. Eis os resultados.
Progresso de implementação:
- Fase Plan (Cláusulas 4–6): 6/6 documentos completos
- Fase Do (Cláusulas 7–8): 10 políticas encontradas
- Fase Check (Cláusula 9): 2/2 documentos completos
- Fase Act (Cláusula 10): 2/2 documentos completos
Vínculos de rastreabilidade: 9 de 11 vínculos estão plenamente consistentes. 2 alertas encontrados:
- SoA → Políticas: 3 controles incluídos citam arquivos de evidência que foram modificados após a última atualização da SoA — talvez seja necessário atualizar a SoA para refletir o conteúdo atual das políticas.
- Tratamento de riscos → Políticas: R‑06 (vulnerabilidades em APIs) tem tratamento “Tratar” com controles A.8.25–A.8.26, mas o Procedimento de Desenvolvimento Seguro que o implementa ainda não existe.
Prontidão para auditoria: 91 % — resolva os 2 alertas antes do Stage 1.
O dashboard de rastreabilidade é sensível à fase. Se você está no meio da implementação — digamos, fase Plan concluída, mas Check e Act ainda não iniciadas —, o dashboard não penaliza pela ausência de relatórios de auditoria. Em vez disso, informa:
“Fase Plan: 6/6 completa, rastreabilidade 100 %. Fase Do: 10/14 documentos, 2 alertas. Fase Check: ainda não iniciada. Fase Act: ainda não iniciada.”
Isso dá aos consultores uma visão clara de onde o projeto está e no que trabalhar em seguida — sem o desanimador “17/21 documentos faltando” que outras ferramentas mostram.
Como a consistência é detectada e autocorrigida
O poder da validação entre documentos está no ciclo de feedback. Eis um exemplo concreto de como o agente detecta e corrige uma inconsistência entre três documentos:
Agente: Completei o registro de riscos com 8 entradas. Rodando a suíte de validação…
O validador de cobertura ativo–risco encontrou uma lacuna: AST‑008 (Cofre de chaves de API, classificado como Confidencial) aparece no inventário de ativos, mas não tem entrada correspondente no registro de riscos. Isso é um sinal vermelho para o auditor — um ativo Confidencial sem avaliação de risco sugere análise incompleta.
Adicionei o risco R‑08: “Extração não autorizada de chaves de API do cofre de segredos” (Probabilidade: 4, Impacto: 5, Score: 20, Tratamento: Tratar, Controles: A.5.17, A.8.24).
Agora rodando o verificador de consistência da SoA com o registro de riscos atualizado…
O verificador confirmou que A.5.17 (Informações de autenticação) e A.8.24 (Uso de criptografia) estão marcados como aplicáveis na SoA — consistente com a nova entrada de risco. Porém, sinalizou que o campo de evidência de implementação de A.8.24 contém “[TBD]” — um placeholder que precisa ser substituído por uma referência real de política.
Atualizei a evidência de A.8.24 para referenciar a “Seção de Controles Criptográficos” na Política de Segurança da Informação. Rodando novamente… PASS.
Nesse exemplo, uma ferramenta (cobertura ativo–risco) encontrou um risco ausente, levando o agente a adicioná-lo. Uma segunda ferramenta (consistência da SoA) verificou que o mapeamento de controles estava correto, mas detectou um placeholder no campo de evidência. O agente corrigiu e confirmou que a cadeia está limpa. Três documentos — inventário de ativos, registro de riscos e SoA — estão agora consistentes, verificados por checagens determinísticas em vez de revisão manual.
Esse tipo de autocorreção em cascata é o que torna a documentação de ISMS assistida por ferramentas fundamentalmente diferente da redação baseada em templates. As ferramentas não apenas checam — elas criam as condições para o agente corrigir problemas antes que um revisor humano sequer os veja.
Dashboard: acompanhando o progresso das 19 skills
À medida que cada skill é concluída, o agente atualiza o dashboard do projeto. O dashboard dá uma visão única do progresso do ISMS:
Dashboard após concluir as 19 skills do ISMS — documentos produzidos, riscos identificados e tratados, maturidade por cláusula avaliada.
Algumas métricas acompanhadas:
- Conclusão do ISMS — porcentagem de skills concluídas (Plan → Do → Check → Act)
- Documentos produzidos — total de artefatos de saída (políticas, procedimentos, registros, relatórios)
- Distribuição de riscos — por severidade (Crítico / Alto / Médio / Baixo)
- Cobertura de tratamento de riscos — porcentagem de riscos com plano de tratamento
- Maturidade por cláusula — rating de 0 a 5 por cláusula
- Achados de gap — achados abertos vs. fechados do gap assessment
- CAPAs — status de ações corretivas originadas da auditoria interna
- Prontidão para Stage 1/2 — estimativa de prontidão para as auditorias de certificação
O dashboard dá a consultores e gestão uma visão em tempo real de onde o projeto está e o que ainda falta.
Comparando esforço: tempo de consultoria com e sem ferramentas
Com base em distribuições típicas de esforço de consultoria ISO 27001 para certificação inicial de uma organização pequeno‑média:
| Atividade | % de esforço | Aceleração com ferramentas |
|---|---|---|
| Escopo, contexto, aplicabilidade | 8 % | Skills Organization Profile + ISMS Scope reduzem entrevistas e retrabalho |
| Avaliação de gaps | 12 % | Detecção de artefatos obrigatórios e análise de requisitos por cláusula substituem checklists manuais |
| Avaliação de riscos + SoA + tratamento | 24 % | Cinco checagens de risco + consistência da SoA aplicam a metodologia automaticamente |
| Conjunto de políticas e procedimentos | 16 % | Geração context‑aware com validação de metadados e tópicos obrigatórios |
| Auditoria interna + CAPA | 4 % | Checagem de imparcialidade e classificação de severidade organizam o processo |
| Revisão pela direção | 3 % | Validação dos 10 insumos da Cláusula 9.3 garante completude |
As atividades de documentação mais pesadas (risco, políticas, gap assessment) são justamente onde as ferramentas de validação agregam mais valor — não substituindo o julgamento do consultor, mas capturando erros mecânicos e omissões que consomem ciclos de revisão.
Como começar
- Crie um novo projeto no Rakenne e selecione o template ISO 27001 ISMS.
- Todas as 19 skills e ferramentas de validação são instaladas automaticamente.
- Comece pelo Organization Profile — forneça os detalhes do cliente e deixe o agente construir o perfil estruturado.
- Siga a sequência PDCA pelos 19 passos, ou pule para skills específicas conforme o resultado do gap assessment.
- Use o dashboard para acompanhar o progresso e enxergar o que ainda é necessário.
Cada skill é independente, mas lê artefatos dos passos anteriores. Você pode executá‑las em qualquer ordem, mas a sequência recomendada garante que cada skill tenha o contexto necessário.
Resumo
O template de workspace ISO 27001 ISMS transforma a documentação de ISMS de um exercício ad hoc de redação em um processo estruturado e validado. As 19 skills cobrem todo o ciclo PDCA, e as mais de 55 ferramentas de validação implementam as mesmas checagens que um consultor sênior de GRC faria — de forma consistente, automática e rastreável.
O que diferencia esta abordagem de qualquer outra — templates, IA genérica ou mesmo plataformas GRC dedicadas — é a teia de rastreabilidade entre documentos. Onze checagens automatizadas verificam que riscos rastreiam para controles, controles rastreiam para políticas, políticas rastreiam para evidências, achados de auditoria rastreiam para CAPAs e fronteiras de escopo são consistentes em todos os documentos downstream. Quando um elo se rompe, o agente detecta, explica o motivo e corrige — antes que um revisor humano ou auditor sequer veja a falha.
O resultado não é um conjunto de templates genéricos, e sim um conjunto de artefatos específicos da organização, coerentes entre si e alinhados por cláusula, que se referenciam mutuamente, ligam riscos a controles, procedimentos e evidências, e apontam gaps antes que o auditor o faça.
Experimente você mesmo
Abra um workspace com os skills descritos neste artigo e comece a redigir em minutos.
Comece Grátis — Sem Cadastro