Workspace ISO 27001 ISMS: do escopo à prontidão para certificação em 22 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 22 skills especializadas e mais de 60 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 22 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 22 passos
O template de workspace instala 22 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 (16 tipos de documentos) |
| 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 | Critical Supplier Register | Acesso a dados de fornecedores, limiares de SLA, dependências BCP, programação de avaliações, referências cruzadas com BCP e registro de riscos |
| Do | 11 | Legal Requirements Register | Rastreamento de obrigações legais/regulatórias, mapeamento de controles, análise de gaps de cobertura |
| Do | 12 | Confidentiality/NDA Agreements | Validação de cláusulas NDA, cobertura por categoria de pessoal, registro de acompanhamento |
| Do | 13 | HR & Personnel Security | Completude de cláusulas de emprego, cobertura de procedimentos de desligamento |
| Do | 14 | Privacy & PII Protection Program | Completude do ROPA, validação de base legal, prazos de notificação de violações |
| Do | 15 | Operating Procedures (SOPs) | Validação de completude de SOPs, análise de cobertura controle–SOP |
| Do | 16 | Secure Architecture Principles | Cobertura de categorias de arquitetura, validação de guia de implementação |
| Do | 17 | Awareness & Training Plan | Cobertura de públicos de treinamento, completude de módulos, métricas de efetividade |
| Check | 18 | Monitoring & Evaluation | Registro de Objetivos de SI, geração de KPI, completude de CAPA, rastreamento de ações corretivas, reconciliação NC de auditoria–CAPA |
| Do | 19 | Business Continuity Plan | Validação BIA RTO/RPO, cobertura de procedimentos DR, completude de registros de exercícios |
| Check | 20 | Internal Audit Report | Imparcialidade do auditor, completude de achados, classificação de severidade |
| Act | 21 | Management Review | Cobertura de insumos obrigatórios, compilação de “input pack”, completude de ações |
| Act | 22 | Executive Readiness Report | Resumo executivo para liderança, scoring de prontidão, priorização de gaps |
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, adaptadas ao contexto da organização. Ela 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 16 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 skill agora produz até 16 tipos de documentos, incluindo a Política de Segurança da Informação central, Política de Gestão de Riscos, Política de Controle de Acesso e adições mais recentes para classificação e manuseio, controles criptográficos, ciclo de vida de desenvolvimento seguro, gestão de vulnerabilidades, trabalho remoto e backup e recuperação. Cada política é adaptada ao contexto da organização e referenciada contra outros artefatos do workspace.
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.
Também validei os controles de segurança fora do escritório (A.7.9) — criptografia de dispositivos, requisitos de VPN e cadastro em MDM estão todos cobertos para a força de trabalho remota.
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: Critical Supplier Register — evidência operacional da cadeia de fornecedores
A Supplier Security Policy (Passo 9) define requisitos. O Critical Supplier Register captura as evidências operacionais que os auditores esperam conforme a Cláusula 7.5.1(b) e os Controles A.5.19–A.5.22: quais fornecedores acessam quais dados, seus limiares de SLA, dependências de BCP, histórico de avaliações de segurança e ownership interno.
Você: Construa o registro de fornecedores críticos com base na política de segurança de fornecedores e no perfil da organização.
Agente: Identifiquei 8 fornecedores críticos a partir do perfil da organização e os mapeei contra a política de fornecedores por tier. Vou validar o registro.
Verificação de completude do registro de fornecedores: PASS. Todos os 8 fornecedores possuem: classificação de acesso a dados, limiares de SLA (uptime, resposta a incidentes), rating de dependência BCP (Crítico/Importante/Padrão), data da última avaliação de segurança, data da próxima avaliação e owner interno nomeado.
Verificação de referência cruzada com BCP: WARNING. Dois fornecedores Tier 1 (GCP e Okta) estão sinalizados como pontos únicos de falha no mapeamento de dependências BCP, mas o Plano de Continuidade de Negócios ainda não foi redigido. Registrei para validação cruzada quando o BCP for produzido no Passo 19.
Verificação de programação de avaliações: PASS. Todos os fornecedores Tier 1 têm ciclos de avaliação anuais. Fornecedores Tier 2 têm ciclos bienais. Nenhuma avaliação está vencida.
Passo 11: Legal Requirements Register — rastreando obrigações
A skill Legal Requirements Register identifica e cataloga obrigações legais, estatutárias, regulatórias e contratuais relevantes ao ISMS conforme o controle A.5.31 do Anexo A. Ela lê o perfil da organização e o escopo para identificar requisitos aplicáveis, mapeia cada obrigação a controles específicos e verifica gaps de cobertura.
Você: Construa o registro de requisitos legais para a CloudSync Solutions.
Agente: Com base no perfil da organização, identifiquei 12 obrigações legais e contratuais. Vou validar o registro.
O analisador de cobertura regulatória encontrou obrigações em três categorias: estatutárias (proteção de dados LGPD, Marco Civil da Internet), regulatórias (requisitos de cibersegurança do BACEN de clientes do setor financeiro) e contratuais (cláusulas de DPA em contratos enterprise, compromissos de SLA). Todas as 12 entradas possuem controles do Anexo A mapeados.
Verificação de completude de requisitos legais: PASS. Cada obrigação possui referência de fonte, justificativa de aplicabilidade, owner responsável, frequência de revisão e controles mapeados. Um aviso: a entrada da LGPD referencia “processamento baseado em consentimento”, mas o perfil da organização indica legítimo interesse como base legal principal — considere alinhar esses dados.
Passo 12: Confidentiality/NDA Agreements — protegendo informações via contratos
A skill Confidentiality/NDA Agreements cria templates de NDA e um registro de acompanhamento conforme o controle A.6.6 do Anexo A. Ela gera modelos de acordo adaptados a diferentes categorias de pessoal — empregados, terceirizados e parceiros — e valida que as cláusulas obrigatórias estejam presentes.
Você: Crie templates de NDA e um registro de acompanhamento para a CloudSync Solutions.
Agente: Redigi templates de NDA para três categorias de pessoal: empregados, terceirizados e parceiros. Cada template é adaptado ao contexto da CloudSync — referenciando as obrigações da LGPD, as classificações de ativos Confidenciais do inventário e cenários específicos de manuseio de dados da plataforma SaaS. Vou validar.
Validador de cláusulas NDA: PASS. Todos os três templates incluem as 9 cláusulas obrigatórias — definição de informação confidencial, obrigações da parte receptora, divulgações permitidas, prazo e sobrevivência, devolução/destruição de informações, remédios para violação, lei aplicável, jurisdição e divisibilidade.
Verificação de completude do registro NDA: WARNING. O registro de acompanhamento cobre 42 de 45 pessoas. Três contratações recentes de terceirizados (iniciadas em fevereiro de 2026) ainda não possuem NDAs assinados registrados. Sinalizei para acompanhamento imediato com o RH.
Passo 13: HR & Personnel Security — protegendo o ciclo de vida do emprego
A skill HR & Personnel Security cria a estrutura documental de controles de segurança ao longo de todo o ciclo de vida do emprego — da triagem pré-contratação até o desligamento e além. Ela cobre os controles ISO 27001 A.6.1 (Triagem), A.6.2 (Termos e condições de emprego), A.6.4 (Processo disciplinar), A.6.5 (Responsabilidades pós-desligamento) e A.5.4 (Responsabilidades da gestão).
Você: Crie a documentação de segurança de RH para a CloudSync Solutions. Precisamos de procedimentos de triagem para novas contratações de engenharia, cláusulas de segurança em contratos de trabalho e um procedimento completo de saída para quando colaboradores deixam a empresa — incluindo revogação de acesso em todos os nossos sistemas.
Agente: Redigi 4 documentos de segurança de RH com base no perfil da organização. Vou rodar as ferramentas de validação.
Verificador de completude de cláusulas de RH: PASS. O template de cláusulas de segurança de emprego inclui todos os 5 elementos obrigatórios — referência a NDA/confidencialidade, política de uso aceitável, cláusula de cessão de PI, consequências disciplinares para violações de segurança e obrigações pós-desligamento. Ele também referencia as obrigações de proteção de dados da LGPD e requisitos de devolução de ativos.
Validador de cobertura de procedimento de saída: PASS. O procedimento de segurança de desligamento cobre revogação de acesso para todos os 4 sistemas identificados no perfil da organização — Okta (SSO), GCP (infraestrutura), GitHub (código-fonte) e Google Workspace (email/docs). O procedimento inclui checklist de devolução de ativos, plano de transferência de conhecimento, lembrete de NDA e entrevista de desligamento. Um aviso: considere adicionar um período de monitoramento pós-saída para detentores de contas privilegiadas.
Passo 14: Privacy & PII Protection Program — construindo um framework abrangente de privacidade
A skill Privacy & PII Protection Program cria o conjunto completo de documentação de privacidade alinhado ao controle A.5.34 da ISO 27001 e às principais regulamentações de privacidade. Ela produz cinco documentos centrais adaptados à jurisdição da organização e suas atividades de processamento de dados.
Você: Construa o programa de privacidade para a CloudSync Solutions. Estamos sujeitos à LGPD e temos clientes enterprise na UE sob o GDPR. Crie o conjunto completo — política de privacidade, ROPA, template de DPIA, procedimento de direitos de titulares e procedimento de notificação de violações.
Agente: Redigi 5 documentos do programa de privacidade com base no perfil da organização e no registro de requisitos legais. Vou validar.
Verificador de completude do ROPA: PASS. Todas as 5 atividades de processamento (armazenamento de dados de clientes, autenticação de usuários, processamento de pagamentos, comunicações por email, analytics) possuem entradas completas — finalidade, base legal, categorias de dados, destinatários, período de retenção e status de transferência internacional documentados para cada uma.
Validador de base legal: PASS com 1 aviso. 4 de 5 atividades de processamento usam legítimo interesse ou necessidade contratual como base legal. O processamento de analytics usa consentimento — a ferramenta sinalizou para consideração de DPIA, já que processamento baseado em consentimento de dados pessoais pode requerer uma Avaliação de Impacto à Proteção de Dados conforme o Artigo 35 do GDPR e o Artigo 38 da LGPD.
Validador de prazos de notificação de violações: PASS. O procedimento de notificação de violações inclui tanto o requisito de “prazo razoável” da LGPD com notificação à ANPD quanto a notificação de 72 horas à autoridade supervisora do GDPR para titulares de dados da UE. Matriz de classificação de severidade, etapas de contenção e revisão pós-violação estão todos documentados.
Passo 15: Operating Procedures (SOPs) — documentando como os controles funcionam na prática
A skill Operating Procedures cria procedimentos operacionais padronizados passo a passo conforme o controle A.5.37 do Anexo A. Os SOPs traduzem políticas de alto nível em instruções acionáveis que os operadores seguem no dia a dia. A skill identifica quais controles requerem SOPs, cria um índice e valida cada procedimento quanto à completude.
Você: Crie os procedimentos operacionais para os controles que precisam deles.
Agente: Rodei o analisador de cobertura de SOPs contra a Declaração de Aplicabilidade. Dos 78 controles aplicáveis, 24 requerem procedimentos operacionais documentados. 10 já estão cobertos por políticas existentes. Vou criar os 14 SOPs restantes. Começarei pelos de maior prioridade.
Redigi SOP-001 (Provisionamento e Desprovisionamento de Acesso), SOP-002 (Execução de Resposta a Incidentes) e SOP-003 (Backup e Restauração). Rodando a validação de cada um…
Verificador de completude de SOPs: SOP-001 PASS — inclui finalidade, escopo, papéis, procedimento passo a passo, critérios de escalação e controles relacionados (A.5.15, A.5.18). SOP-002 PASS — cobre todos os níveis de severidade de incidentes com árvores de decisão. SOP-003 WARNING — os passos de restauração referenciam “procedimento do Console GCP” sem especificar caminhos de navegação exatos. Expandi os passos com comandos específicos do GCP e caminhos no console. Re-verificação: PASS.
O índice de SOPs agora rastreia todos os 24 procedimentos requeridos com status de conclusão e datas de última revisão.
Passo 16: Secure Architecture Principles — incorporando segurança na engenharia
A skill Secure Architecture Principles documenta os princípios de engenharia segura da organização conforme o controle A.8.27 do Anexo A. Ela produz um catálogo de princípios adaptado ao stack tecnológico da organização, cobrindo todas as 10 categorias de arquitetura definidas no framework ISO 27001.
Você: Documente nossos princípios de arquitetura segura com base no stack tecnológico da CloudSync.
Agente: Redigi um catálogo de princípios de arquitetura segura adaptado à plataforma SaaS da CloudSync baseada em GCP. O catálogo cobre 10 categorias: segmentação de rede, autenticação e controle de acesso, proteção de dados em repouso e em trânsito, design seguro de APIs, logging e monitoramento, gestão de segredos, segurança de containers, infraestrutura como código, resiliência e integridade da cadeia de fornecedores. Vou validar.
Verificação de cobertura de princípios de arquitetura: PASS. Todas as 10 categorias possuem princípios documentados com orientação de implementação específica para o seu stack — por exemplo, segmentação de rede referencia design de VPC do GCP com acesso privado a serviços, e gestão de segredos referencia a integração existente de Okta + GCP Secret Manager do perfil da organização.
Cada princípio está referenciado aos controles aplicáveis do Anexo A e às políticas relevantes geradas no Passo 7.
Passo 17: Awareness & Training Plan — construindo uma cultura de segurança
A skill Awareness & Training Plan define requisitos de treinamento, segmentos de público, conteúdo de módulos e critérios de medição de efetividade. Ela garante que todas as categorias de pessoal — de executivos a desenvolvedores e terceirizados — tenham cobertura adequada de conscientização em segurança, com módulos de treinamento mapeados a controles específicos do ISMS e riscos organizacionais.
Passo 18: Monitoring & Evaluation — medindo o que importa
A skill Monitoring & Evaluation gera um Registro de Objetivos de SI (Cláusula 6.2), KPIs alinhados aos objetivos do ISMS, rastreia ações corretivas de achados de auditoria e garante que o processo de CAPA (Ação Corretiva e Preventiva) esteja completo.
Você: Configure o framework de monitoramento e avaliação do nosso ISMS.
Agente: Construí o Registro de Objetivos de SI conforme a Cláusula 6.2, com 6 objetivos de segurança mensuráveis, cada um vinculado a políticas específicas do ISMS e decisões de tratamento de riscos. Vou validar.
Verificador de completude de objetivos: PASS. Todos os 6 objetivos possuem métricas, metas, métodos de medição, prazos e owners responsáveis definidos. Exemplo: “Reduzir tempo médio de correção de vulnerabilidades críticas para menos de 72 horas até o 3T/2026” — métrica: MTTP, meta: <72h, fonte: alertas de segurança do GitHub, owner: João Silva.
Também gerei 8 KPIs alinhados aos objetivos do ISMS. 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).
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 19: Business Continuity Plan — preparação para o pior cenário
A skill Business Continuity Plan cria documentos operacionalmente detalhados de BCP e recuperação de desastres conforme os controles A.5.29 e A.5.30 do Anexo A. Ela começa com uma Análise de Impacto no Negócio (BIA), deriva metas de RTO/RPO e produz procedimentos de recuperação e registros de exercícios.
Você: Crie o plano de continuidade de negócios para a CloudSync Solutions.
Agente: Realizei uma Análise de Impacto no Negócio com base no inventário de ativos e no perfil da organização. A BIA identificou 5 processos de negócio críticos: disponibilidade da plataforma SaaS, processamento de dados de clientes, processamento de pagamentos (Stripe), serviços de autenticação (Okta) e comunicações internas (Google Workspace). Vou construir o BCP e validar.
Redigi o BCP com procedimentos de recuperação para cada processo crítico, mais um Plano de Recuperação de Desastres separado para a infraestrutura GCP. Rodando a validação…
Validador de RTO/RPO do BCP: PASS. Todos os 5 processos críticos possuem metas de RTO e RPO definidas, consistentes com os SLAs contratuais. Plataforma SaaS: RTO 4 horas, RPO 1 hora. Processamento de pagamentos: RTO 2 horas, RPO 0 (replicação em tempo real via Stripe). Um aviso: o plano de DR referencia failover multi-região, mas o perfil da organização lista apenas uma única região GCP — considere documentar a região secundária planejada.
Verificador de registros de exercícios: WARNING. O template de registro de exercícios está completo, mas nenhum exercício foi conduzido ainda. Criei um cronograma para o primeiro exercício tabletop (2T/2026) e um teste completo de DR (3T/2026), ambos com critérios de sucesso definidos e listas de participantes.
Passo 20: 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 21: Management Review — fechando o ciclo PDCA
A skill Management Review 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 22: Executive Readiness Report — a visão para a liderança
A skill Executive Readiness Report gera um resumo de conformidade pronto para a diretoria, que condensa todo o ISMS em um scorecard conciso de prontidão. Ela agrega dados de todos os artefatos anteriores — achados do gap assessment, cobertura de tratamento de riscos, ratings de maturidade por cláusula, resultados de auditoria e status de CAPA — em um documento único adequado para revisão executiva e tomada de decisão sobre certificação. O relatório inclui um score geral de prontidão, lista priorizada de gaps e próximas ações recomendadas.
Executive Readiness Report — resumo de conformidade pronto para a diretoria com scores de prontidão por área, progresso de implementação PDCA e gaps críticos que requerem atenção.
Abrir o Executive Readiness Report completo →
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 22 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): 16 políticas, SOPs, registro legal, NDAs, BCP e princípios de arquitetura encontrados
- Fase Check (Cláusula 9): 2/2 documentos completos
- Fase Act (Cláusula 10): 3/3 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: 18/22 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 “25/30 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 22 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 22 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 22 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 22 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 22 skills cobrem todo o ciclo PDCA, e as mais de 60 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