ISO 27001:2022: plano de recuperação após auditoria não aprovada
O e-mail que ninguém queria receber
O e-mail chega tarde numa sexta-feira, com um assunto aparentemente inofensivo: “Resultado da auditoria de transição.”
O corpo da mensagem não é inofensivo. O organismo de certificação levantou uma não conformidade maior. O certificado ISO/IEC 27001 está suspenso ou a decisão de transição não pode ser encerrada. A observação do auditor é direta: a Declaração de Aplicabilidade não justifica os controlos excluídos, a avaliação de riscos não reflete o contexto atual e não existe evidência suficiente de que novas obrigações regulamentares tenham sido consideradas.
Em menos de uma hora, o problema deixa de ser apenas uma questão de conformidade. A equipa comercial pergunta se um concurso do setor público está agora em risco. O departamento jurídico está a rever cláusulas contratuais de clientes. O Diretor de Segurança da Informação está a explicar por que motivo a SoA não está conciliada com o plano de tratamento de riscos. O Diretor Executivo faz a única pergunta que importa: “Com que rapidez conseguimos corrigir isto?”
Para muitas organizações, a ultrapassagem do prazo de transição ISO 27001:2022 não criou uma lacuna teórica. Criou uma questão real de continuidade de negócio. Uma auditoria de transição ISO 27001:2022 não concluída ou não aprovada pode afetar a elegibilidade em concursos, a integração de fornecedores, o seguro de riscos cibernéticos, os programas de garantia para clientes, a preparação para NIS2, as expectativas DORA, a responsabilização no âmbito do RGPD da UE e a confiança do conselho de administração.
A boa notícia é que a recuperação é possível. A má notícia é que retoques documentais não funcionam. A recuperação deve ser tratada como um programa disciplinado de ações corretivas do SGSI, e não como uma reescrita apressada de políticas.
Na Clarysec, organizamos esta recuperação em torno de três ativos interligados:
- Zenith Blueprint: roteiro de 30 passos para auditores, em especial a fase de auditoria, revisão e melhoria.
- A biblioteca de políticas empresariais e para PME da Clarysec, que transforma constatações de auditoria em obrigações governadas.
- Zenith Controls: o guia de conformidade cruzada, que ajuda a ligar as expectativas dos controlos ISO/IEC 27002:2022 com NIS2, DORA, RGPD da UE, modelos de garantia ao estilo NIST e perspetivas de governação COBIT 2019.
Este é o plano prático de recuperação para CISO, gestores de conformidade, auditores, fundadores e responsáveis de negócio que perderam o prazo de transição ISO 27001:2022 ou cuja auditoria de transição não foi aprovada.
Primeiro, diagnostique o modo de falha
Antes de editar uma única política, classifique a situação. Nem todas as transições não aprovadas ou não concluídas têm o mesmo impacto no negócio ou o mesmo percurso de recuperação. As primeiras 24 horas devem concentrar-se em obter o relatório de auditoria, a decisão do organismo de certificação, a redação da não conformidade, os pedidos de evidência, os prazos e o estado atual do certificado.
| Situação | Impacto no negócio | Ação imediata |
|---|---|---|
| Auditoria de transição não aprovada com não conformidade maior | A decisão de certificação pode ficar bloqueada ou o certificado pode ser suspenso até à correção do problema | Abrir CAPA, realizar análise de causa raiz, confirmar expectativas de evidência com o organismo de certificação |
| Auditoria de transição aprovada com não conformidades menores | A certificação pode continuar se as ações corretivas forem aceites | Encerrar rapidamente as CAPA menores e atualizar o pacote de evidências do SGSI |
| Transição não concluída antes do prazo | O certificado pode deixar de ser válido ou reconhecido | Confirmar o estado com o organismo de certificação e planear o percurso de transição ou recertificação |
| Auditoria de acompanhamento revelou evidência de transição fraca | A certificação pode estar em risco no próximo ponto de decisão | Executar uma auditoria simulada e atualizar a SoA, o tratamento de riscos, a revisão pela gestão e os registos de auditoria interna |
| Cliente rejeitou o certificado ou a evidência de transição | Risco comercial, risco de concurso e impacto na confiança | Preparar um pacote de garantia para clientes com estado da auditoria, plano CAPA, datas-alvo e aprovação de governação |
O plano de recuperação depende do modo de falha. Uma decisão de certificação bloqueada exige remediação direcionada. Um certificado suspenso exige governação urgente e correção de evidências. Um certificado retirado ou expirado pode exigir um percurso de recertificação mais amplo.
Em todos os casos, mapeie cada problema para a cláusula relevante do SGSI, o controlo do Anexo A, o registo de risco, o responsável pela política, a obrigação legal ou contratual e a fonte de evidência.
É aqui que a ISO/IEC 27001:2022 importa como sistema de gestão, e não apenas como catálogo de controlos. As cláusulas 4 a 10 exigem que o SGSI compreenda o contexto, as partes interessadas, o âmbito, a liderança, o planeamento de riscos, o suporte, a operação, a avaliação de desempenho e a melhoria contínua. Se a transição não foi aprovada, uma dessas ligações do sistema de gestão está normalmente quebrada.
Porque falham as auditorias de transição ISO 27001:2022
As auditorias de transição não aprovadas tendem a agrupar-se em padrões recorrentes. Muitas não são profundamente técnicas. São falhas de governação, rastreabilidade, titularidade e evidência.
| Padrão da constatação | O que o auditor vê | O que normalmente significa |
|---|---|---|
| Declaração de Aplicabilidade não atualizada ou não justificada | Controlos marcados como aplicáveis sem fundamentação, ou excluídos sem evidência | A seleção de controlos não é rastreável ao risco, à regulamentação ou à necessidade do negócio |
| Avaliação de riscos não refletiu obrigações atuais | NIS2, DORA, RGPD da UE, contratos de clientes, dependências da nuvem ou risco de fornecedor estão em falta | O contexto e os critérios de risco não foram atualizados |
| Revisão pela gestão é superficial | Existem atas, mas não são discutidas decisões, recursos, objetivos, resultados de auditoria ou alterações de risco | A responsabilização da liderança não está a funcionar |
| Auditoria interna não testou o âmbito da transição | A lista de verificação da auditoria é genérica e não cobre controlos atualizados, fornecedores, nuvem, resiliência ou obrigações legais | A avaliação de desempenho não é suficiente |
| Controlos de fornecedores e nuvem são fracos | Não há diligência prévia, revisão contratual, planeamento de saída ou monitorização contínua | O controlo operacional sobre serviços prestados externamente está incompleto |
| Resposta a incidentes não está alinhada com reporte regulamentar | Não há lógica de escalonamento de 24 ou 72 horas, árvore de decisão DORA ou RGPD da UE, nem evidência de exercícios | A gestão de incidentes não está ligada ao reporte legal |
| Processo CAPA é fraco | As constatações são encerradas apenas com edições documentais | A causa raiz não foi eliminada |
A auditoria não aprovada é um sinal de que o SGSI não se adaptou com rapidez suficiente ao ambiente operacional real da organização.
A ISO/IEC 27005:2022 é útil na recuperação porque reforça a importância de estabelecer o contexto com base em requisitos legais, regulamentares, setoriais, contratuais, internos e de controlos existentes. Também apoia critérios de risco que tenham em conta deveres legais, fornecedores, privacidade, fatores humanos, objetivos de negócio e apetite ao risco aprovado pela gestão.
Em termos práticos, a recuperação da transição começa com contexto e critérios de risco atualizados, não com um novo número de versão num documento antigo.
Passo 1: congelar o registo de auditoria e criar um centro de comando de recuperação
O primeiro erro operacional após uma auditoria não aprovada é o caos da evidência. As equipas começam a procurar em caixas de correio, unidades partilhadas, sistemas de tickets, mensagens de chat, pastas pessoais e pacotes de auditoria antigos. Os auditores interpretam isto como sinal de que o SGSI não está controlado.
A Política de Auditoria e Monitorização da Conformidade - PME da Clarysec é explícita quanto ao controlo de evidências:
“Toda a evidência deve ser armazenada numa pasta de auditoria centralizada.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.2.1.
Essa pasta de auditoria centralizada torna-se o centro operacional da recuperação. Deve incluir:
- Relatório e correspondência do organismo de certificação.
- Confirmação do estado do certificado.
- Registo de não conformidades.
- Registo CAPA.
- Avaliação de riscos atualizada.
- Plano de tratamento de riscos atualizado.
- Declaração de Aplicabilidade atualizada.
- Relatório de auditoria interna.
- Ata de revisão pela gestão.
- Registos de aprovação de políticas.
- Evidência para cada controlo aplicável do Anexo A.
- Pacote de garantia para clientes, se compromissos comerciais forem afetados.
Para ambientes empresariais, a Política de Auditoria e Monitorização da Conformidade da Clarysec estabelece a mesma expectativa de governação:
“Todas as constatações devem resultar numa CAPA documentada que inclua:”
Da secção “Requisitos de implementação da política”, cláusula da política 6.2.1.
A redação introduz uma expectativa estruturada de ação corretiva. O ponto essencial é simples: cada constatação de auditoria deve tornar-se um item CAPA governado, não uma tarefa informal no bloco de notas de alguém.
Para PME, o envolvimento da liderança é igualmente importante:
“O Diretor-Geral deve aprovar um plano de ação corretiva e acompanhar a sua implementação.”
Da Política de Auditoria e Monitorização da Conformidade - PME, secção “Requisitos de governação”, cláusula da política 5.4.2.
Isto é relevante porque a ISO 27001:2022 não trata a liderança como simbólica. A alta direção deve estabelecer a política, alinhar objetivos com a estratégia do negócio, disponibilizar recursos, comunicar a importância da segurança da informação, atribuir responsabilidades e promover a melhoria contínua.
Se a transição não aprovada for tratada como “o problema da pessoa da conformidade”, a próxima auditoria voltará a expor uma fraca responsabilização da liderança.
Passo 2: reconstruir contexto, obrigações e risco
Uma auditoria de transição não aprovada significa frequentemente que o contexto do SGSI já não reflete a realidade da organização. O negócio pode ter migrado para plataformas na nuvem, adicionado novos fornecedores, entrado em mercados regulados, tratado mais dados pessoais ou tornado-se relevante para clientes ao abrigo da NIS2 ou da DORA. Se essas alterações não estiverem refletidas no SGSI, a avaliação de riscos e a SoA ficarão incompletas.
A Política de Cumprimento Legal e Regulamentar da Clarysec estabelece a base:
“Todas as obrigações legais e regulamentares devem ser mapeadas para políticas, controlos e proprietários específicos no Sistema de Gestão de Segurança da Informação (SGSI).”
Da secção “Requisitos de implementação da política”, cláusula da política 6.2.1.
Esta cláusula é crítica após uma falha de transição. As cláusulas 4.1 a 4.3 da ISO 27001:2022 exigem que as organizações considerem questões internas e externas, partes interessadas, requisitos, interfaces, dependências e âmbito. As obrigações legais, regulamentares e contratuais não são notas laterais. Moldam o SGSI.
O Article 21 da NIS2 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas, incluindo análise de riscos, políticas, tratamento de incidentes, cópia de segurança, recuperação de desastre, gestão de crise, segurança da cadeia de fornecimento, desenvolvimento seguro, tratamento de vulnerabilidades, avaliações de eficácia, higiene de cibersegurança, formação, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos e comunicações seguras. O Article 20 coloca a responsabilidade ao nível do órgão de gestão. O Article 23 cria reporte faseado de incidentes significativos, incluindo alerta precoce, notificação de incidente, atualizações e relatório final.
A DORA aplica-se diretamente a entidades financeiras a partir de 17 de janeiro de 2025 e abrange gestão do risco das TIC, reporte de incidentes graves, testes de resiliência, risco de terceiros de TIC, requisitos contratuais e supervisão de prestadores terceiros críticos de TIC. Para entidades financeiras abrangidas, a DORA torna-se um vetor central de governação das TIC, controlo de fornecedores, testes, classificação de incidentes e responsabilização da gestão.
O RGPD da UE acrescenta responsabilização pelos dados pessoais. O Article 5 exige tratamento lícito, leal, transparente, limitado, exato, atento à retenção e seguro, com conformidade demonstrável. O Article 4 define violação de dados pessoais de forma que afeta diretamente a classificação de incidentes. O Article 6 exige mapeamento do fundamento de licitude, e o Article 9 acrescenta requisitos reforçados para categorias especiais de dados.
Isto não significa criar universos de conformidade separados. Significa utilizar a ISO 27001:2022 como sistema de gestão integrado e mapear obrigações numa única arquitetura de riscos e controlos.
A Política de Gestão de Riscos da Clarysec liga diretamente o tratamento de riscos à seleção de controlos:
“As decisões de controlo resultantes do processo de tratamento de riscos devem refletir-se na SoA.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.5.1.
Uma auditoria não aprovada é também motivo para rever o próprio processo de gestão de riscos. A Política de Gestão de Riscos - PME da Clarysec identifica este desencadeador:
“Um incidente maior ou uma constatação de auditoria revela lacunas na gestão de riscos”
Da secção “Requisitos de revisão e atualização”, cláusula da política 9.2.1.1.
Em modo de recuperação, isto significa que o Registo de Riscos, os critérios de risco, o plano de tratamento e a SoA devem ser reconstruídos em conjunto.
Passo 3: corrigir a SoA como eixo de rastreabilidade
Na maioria das transições não aprovadas, a Declaração de Aplicabilidade é o primeiro documento a inspecionar. É também um dos primeiros documentos que os auditores amostram. Uma SoA fraca indica ao auditor que a seleção de controlos não é baseada no risco.
O Zenith Blueprint fornece uma instrução prática na fase de auditoria, revisão e melhoria, passo 24, auditoria, revisão e melhoria:
“A sua SoA deve ser consistente com o seu Registo de Riscos e com o Plano de Tratamento de Riscos. Verifique novamente se cada controlo escolhido como tratamento de risco está marcado como ‘Aplicável’ na SoA. Inversamente, se um controlo estiver marcado como ‘Aplicável’ na SoA, deve existir uma fundamentação para isso — normalmente um risco mapeado, um requisito legal/regulamentar ou uma necessidade do negócio.”
Do Zenith Blueprint: roteiro de 30 passos para auditores, fase de auditoria, revisão e melhoria, passo 24.
Esse é o princípio de recuperação. A SoA não é uma formalidade. É o eixo de rastreabilidade entre riscos, obrigações, controlos, evidência de implementação e conclusões de auditoria.
Um exercício prático de correção da SoA deve seguir esta sequência:
- Exportar a SoA atual.
- Adicionar colunas para ID de risco, obrigação regulamentar, requisito de negócio, referência de política, localização da evidência, responsável, estado de implementação e data do último teste.
- Para cada controlo aplicável, mapear pelo menos uma fundamentação defensável.
- Para cada controlo excluído, escrever uma razão de exclusão específica.
- Conciliar a SoA com o plano de tratamento de riscos.
- Conciliar a SoA com os resultados da auditoria interna.
- Fazer a pergunta difícil: se um auditor amostrar esta linha, conseguimos prová-la em cinco minutos?
Uma linha defensável da SoA deve ter este aspeto:
| Campo da SoA | Exemplo de entrada de recuperação |
|---|---|
| Fundamentação do controlo | Aplicável devido a alojamento na nuvem, processador de pagamentos, suporte externalizado e compromissos contratuais de segurança com clientes |
| Ligação ao risco | R-014 interrupção de serviço terceiro, R-021 exposição de dados por fornecedor, R-027 violação regulatória devido a falha de subcontratante |
| Ligação à obrigação | Segurança da cadeia de fornecimento NIS2, risco de terceiros de TIC DORA quando aplicável, responsabilização de subcontratantes no RGPD da UE |
| Ligação à política | Política de segurança de terceiros e fornecedores, procedimento de revisão contratual, lista de verificação de avaliação de fornecedores |
| Evidência | Registo centralizado de fornecedores, classificações de risco, questionário de diligência prévia, Acordo de Tratamento de Dados assinado, revisão de relatório SOC, plano de saída, registo de revisão anual |
| Responsável | Gestor do fornecedor, Diretor de Segurança da Informação, Jurídico |
| Testes | Amostra de auditoria interna dos cinco principais fornecedores críticos concluída, exceções registadas em CAPA |
| Estado | Implementado com duas ações corretivas abertas para atualizações contratuais |
Esta linha conta uma história de recuperação. Mostra contexto do negócio, lógica de risco, relevância regulamentar, titularidade, implementação, testes e ação remanescente.
Para exclusões, aplica-se a mesma disciplina. Por exemplo, se a organização não realiza desenvolvimento de software internamente, uma exclusão do controlo 8.25 Secure development life cycle e do controlo 8.28 Secure coding da ISO/IEC 27002:2022 pode ser defensável, mas apenas se for verdadeira, documentada e suportada por evidência de que o software é comercial pronto a usar ou totalmente externalizado, com controlos de fornecedores em vigor.
Passo 4: realizar análise de causa raiz, não retoques documentais
Uma auditoria de transição não aprovada raramente é causada por um único ficheiro em falta. Normalmente resulta de um processo quebrado.
O Zenith Blueprint, fase de auditoria, revisão e melhoria, passo 27, constatações de auditoria — análise e causa raiz, afirma:
“Para cada não conformidade identificada (maior ou menor), pense por que motivo aconteceu — isto é crítico para uma correção eficaz.”
Do Zenith Blueprint, fase de auditoria, revisão e melhoria, passo 27.
Se a constatação disser “faltam justificações da SoA”, a correção pode ser atualizar a SoA. Mas a causa raiz pode ser que os responsáveis pelos ativos não foram envolvidos na avaliação de riscos, que as obrigações legais não foram mapeadas ou que a equipa de conformidade manteve a SoA isoladamente.
Uma tabela de recuperação útil separa correções fracas de ações corretivas reais:
| Constatação de auditoria | Correção inadequada | Pergunta correta de causa raiz | Melhor ação corretiva |
|---|---|---|---|
| SoA não alinhada com tratamento de riscos | Atualizar a redação da SoA | Por que motivo a SoA não foi conciliada com o tratamento de riscos? | Adicionar conciliação trimestral SoA-risco sob responsabilidade do Gestor do SGSI |
| Sem avaliações de fornecedores | Carregar um questionário | Por que motivo os fornecedores não foram revistos? | Atribuir responsável pelo fornecedor, definir estratificação do risco, concluir revisões e monitorizar anualmente |
| Revisão pela gestão incompleta | Acrescentar retroativamente um ponto à agenda | Por que motivo a revisão pela gestão não cobriu o estado da transição? | Atualizar o modelo de revisão pela gestão e agendar revisão trimestral de governação |
| Comunicação de incidentes não testada | Editar o procedimento de incidentes | Por que motivo o reporte não foi exercitado? | Executar exercício de simulação com pontos de decisão NIS2, DORA e RGPD da UE e reter evidência |
| Auditoria interna demasiado estreita | Expandir a lista de verificação | Por que motivo o planeamento da auditoria falhou o âmbito da transição? | Aprovar um plano de auditoria baseado no risco que cubra regulamentação, fornecedores, nuvem e resiliência |
É aqui que a credibilidade regressa. Os auditores não esperam perfeição. Esperam um sistema controlado que deteta, corrige, aprende e melhora.
Passo 5: construir uma CAPA em que o auditor possa confiar
A ação corretiva e preventiva é onde muitas organizações recuperam o controlo. O registo CAPA deve tornar-se o roteiro de recuperação e a evidência principal de que a auditoria não aprovada foi tratada de forma sistemática.
O Zenith Blueprint, fase de auditoria, revisão e melhoria, passo 29, melhoria contínua, explica a estrutura:
“Garanta que cada ação corretiva é específica, atribuível e limitada no tempo. Essencialmente, está a criar um miniprojeto para cada problema.”
Do Zenith Blueprint, fase de auditoria, revisão e melhoria, passo 29.
O seu registo CAPA deve incluir:
- ID da constatação.
- Auditoria de origem.
- Referência da cláusula ou do controlo.
- Severidade.
- Descrição do problema.
- Correção imediata.
- Causa raiz.
- Ação corretiva.
- Ação preventiva, quando relevante.
- Responsável.
- Data limite.
- Evidência exigida.
- Estado.
- Verificação de eficácia.
- Aprovação pela gestão.
A Política de Auditoria e Monitorização da Conformidade - PME da Clarysec também identifica uma não conformidade maior como desencadeador de revisão:
“Uma auditoria de certificação ou auditoria de acompanhamento resulta numa não conformidade maior”
Da secção “Requisitos de revisão e atualização”, cláusula da política 9.2.2.
Se a auditoria de transição gerou uma não conformidade maior, reveja o próprio processo de auditoria e monitorização da conformidade. Por que motivo a auditoria interna não detetou primeiro o problema? Por que motivo a revisão pela gestão não o escalou? Por que motivo a SoA não revelou a lacuna de evidência?
É assim que uma auditoria não aprovada se transforma num SGSI mais forte.
Passo 6: utilizar o Zenith Controls para ligar evidência ISO à conformidade cruzada
Uma reauditoria não acontece isoladamente. Clientes, reguladores, seguradoras e equipas internas de governação podem analisar a mesma evidência sob ângulos diferentes. É aqui que o Zenith Controls é valioso como guia de conformidade cruzada. Ajuda as equipas a deixar de tratar ISO 27001, NIS2, DORA, RGPD da UE, garantias ao estilo NIST e governação COBIT 2019 como listas de verificação separadas.
Três controlos ISO/IEC 27002:2022 são especialmente relevantes na recuperação da transição.
| Controlo ISO/IEC 27002:2022 | Relevância para a recuperação | Evidência a preparar |
|---|---|---|
| 5.31 Requisitos legais, estatutários, regulamentares e contratuais | Confirma que as obrigações são identificadas, documentadas e ligadas ao SGSI | Registo legal, obrigações contratuais, mapa regulamentar, matriz de responsáveis por políticas, fundamentação da SoA |
| 5.35 Revisão independente da segurança da informação | Confirma que a atividade de revisão é objetiva, definida no âmbito, competente e que gera ações | Plano de auditoria interna, relatório de revisão independente, competência do auditor, registos CAPA, reporte à gestão |
| 5.36 Conformidade com políticas, regras e normas de segurança da informação | Confirma que as políticas não estão apenas publicadas, mas são monitorizadas e aplicadas | Atestado da política, registos de exceções, relatórios de monitorização, fluxo disciplinar, testes de conformidade |
No Zenith Controls, o controlo 5.31 da ISO/IEC 27002:2022 está diretamente ligado à privacidade e a informações pessoais identificáveis (PII):
“O 5.34 cobre a conformidade com leis de proteção de dados (por exemplo, RGPD da UE), que constitui uma categoria de requisitos legais ao abrigo do 5.31.”
Do Zenith Controls, controlo 5.31, ligações a outros controlos.
Para a recuperação, isto significa que o registo legal não pode ficar fora do SGSI. Deve orientar a SoA, o plano de tratamento de riscos, o conjunto de políticas, a titularidade dos controlos e a evidência de auditoria.
Para o controlo 5.35 da ISO/IEC 27002:2022, o Zenith Controls sublinha que a revisão independente frequentemente alcança evidência operacional:
“As revisões independentes ao abrigo do 5.35 avaliam frequentemente a adequação das atividades de registo e monitorização.”
Do Zenith Controls, controlo 5.35, ligações a outros controlos.
Isto é prático. Um auditor pode começar pela governação e depois amostrar logs, alertas, registos de monitorização, revisão de acessos, tickets de incidentes, testes de cópia de segurança, revisões de fornecedores e decisões de gestão.
Para o controlo 5.36 da ISO/IEC 27002:2022, o Zenith Controls explica a relação com a governação interna das políticas:
“O controlo 5.36 funciona como mecanismo de aplicação das regras definidas no 5.1.”
Do Zenith Controls, controlo 5.36, ligações a outros controlos.
É aqui que muitos programas de transição falham. As políticas existem, mas o cumprimento das mesmas não é monitorizado. Os procedimentos existem, mas as exceções não são capturadas. Os controlos são declarados, mas não testados.
Passo 7: preparar-se para diferentes perspetivas de auditoria
Um pacote de recuperação robusto deve resistir a mais do que uma perspetiva de auditoria. Auditores de certificação ISO, supervisores DORA, revisores NIS2, partes interessadas no RGPD da UE, equipas de garantia para clientes, avaliadores orientados por NIST e revisores de governação COBIT 2019 podem fazer perguntas diferentes sobre a mesma evidência.
| Perspetiva do auditor | Pergunta provável | Evidência que ajuda |
|---|---|---|
| Auditor ISO 27001:2022 | O SGSI é eficaz, baseado no risco, corretamente delimitado no âmbito, revisto pela liderança e sujeito a melhoria contínua? | Âmbito, contexto, partes interessadas, avaliação de riscos, SoA, plano de tratamento, auditoria interna, revisão pela gestão, CAPA |
| Avaliador orientado por NIST | As atividades de governação, identificação de riscos, proteção, deteção, resposta e recuperação funcionam de forma coerente? | Inventário de ativos, Registo de Riscos, controlos de acesso, registo de eventos, monitorização, procedimentos operacionais de resposta a incidentes, testes de recuperação |
| Auditor COBIT 2019 ou ao estilo ISACA | Os objetivos de governação, a titularidade, a monitorização de desempenho, a gestão de riscos e a garantia de conformidade estão incorporados? | RACI, objetivos aprovados, métricas, plano de auditoria, reporte à gestão, titularidade dos controlos, acompanhamento de problemas |
| Revisor de conformidade NIS2 | A gestão aprovou e supervisionou medidas proporcionadas de risco de cibersegurança e fluxos de comunicação de incidentes? | Atas do conselho de administração, medidas de risco, controlos de fornecedores, escalonamento de incidentes, formação, evidência de continuidade e crise |
| Revisor DORA | A gestão do risco das TIC está documentada, testada, atenta aos fornecedores e integrada na governação? | Quadro de risco das TIC, testes de resiliência, classificação de incidentes, registo de contratos TIC, planos de saída, direitos de auditoria |
| Revisor RGPD da UE | A organização consegue demonstrar responsabilização pela proteção de dados pessoais e pela resposta a violações? | RoPA, mapeamento de fundamento de licitude, AIPD quando necessário, contratos com subcontratantes, registos de violação, medidas técnicas e organizativas |
O objetivo não é duplicar evidência. Uma única linha da SoA para registo e monitorização pode suportar evidência ISO, expectativas de deteção ao estilo NIST, tratamento de incidentes DORA, avaliação de eficácia NIS2 e deteção de violações no RGPD da UE. Um único ficheiro de risco de fornecedor pode suportar controlos de fornecedores ISO, risco de terceiros de TIC DORA, segurança da cadeia de fornecimento NIS2 e responsabilização de subcontratantes no RGPD da UE.
Este é o valor prático da conformidade cruzada.
Passo 8: realizar uma revisão documental final e uma auditoria simulada
Antes de regressar ao organismo de certificação, execute um desafio interno rigoroso. O Zenith Blueprint, fase de auditoria, revisão e melhoria, passo 30, preparação para certificação — revisão final e auditoria simulada, recomenda verificar as cláusulas 4 a 10 da ISO 27001:2022 uma a uma e validar a evidência para cada controlo aplicável do Anexo A.
A recomendação é:
“Verifique os controlos do Anexo A: garanta que, para cada controlo marcado como ‘Aplicável’ na SoA, tem algo a apresentar.”
Do Zenith Blueprint, fase de auditoria, revisão e melhoria, passo 30.
A revisão final deve ser direta:
- Todos os controlos aplicáveis podem ser explicados?
- Todos os controlos excluídos podem ser justificados?
- A aceitação do risco residual pode ser demonstrada?
- A gestão reviu a falha de transição, recursos, objetivos, resultados de auditoria e ações corretivas?
- A auditoria interna testou a SoA e o plano de tratamento de riscos atualizados?
- Existem evidências dos controlos de fornecedores, nuvem, continuidade, incidentes, privacidade, acesso, vulnerabilidades, registo e monitorização?
- As políticas estão aprovadas, atuais, comunicadas e sujeitas a controlo de versões?
- As CAPA estão ligadas a causas raiz e verificações de eficácia?
- A evidência pode ser encontrada rapidamente na pasta de auditoria centralizada?
A Política de Segurança da Informação da Clarysec fornece a base de governação:
“A organização deve implementar e manter um Sistema de Gestão de Segurança da Informação (SGSI) em conformidade com as cláusulas 4 a 10 da ISO/IEC 27001:2022.”
Da secção “Requisitos de implementação da política”, cláusula da política 6.1.1.
Para PME, a revisão também deve acompanhar os requisitos de certificação e a alteração regulamentar. A Política de Segurança da Informação - PME da Clarysec declara:
“Esta política deve ser revista pelo Diretor-Geral (GM) pelo menos anualmente para assegurar a conformidade contínua com os requisitos de certificação ISO/IEC 27001, alterações regulamentares (como RGPD da UE, NIS2 e DORA) e necessidades de negócio em evolução.”
Da secção “Requisitos de revisão e atualização”, cláusula da política 9.1.1.
Foi exatamente isto que muitos programas de transição falharam: ISO, regulamentação e mudança do negócio evoluem em conjunto.
O que dizer aos clientes durante a recuperação
Se uma transição não aprovada ou não concluída afetar contratos de clientes, o silêncio é perigoso. Não é necessário divulgar todos os detalhes de auditoria interna, mas deve fornecer garantia controlada.
Um pacote de comunicação para clientes deve incluir:
- Estado atual da certificação confirmado pelo organismo de certificação.
- Estado da auditoria de transição e plano de remediação de alto nível.
- Confirmação de que existe um processo CAPA ativo e aprovado pela gestão.
- Datas-alvo para ações corretivas e encerramento da auditoria.
- Declaração de que o SGSI permanece operacional.
- Ponto de contacto para garantia de segurança.
- Declaração atualizada da Política de Segurança da Informação, se adequado.
- Evidência de controlos compensatórios para qualquer área de alto risco.
Evite afirmações vagas como “estamos totalmente em conformidade” enquanto a auditoria estiver por resolver. Diga o que é verdadeiro: o SGSI está a operar, a ação corretiva está aprovada, a evidência está a ser consolidada e está agendada uma revisão de encerramento ou reauditoria.
Isto é especialmente importante se os clientes dependerem de si como fornecedor em setores relevantes para a NIS2, como infraestrutura digital, nuvem, centros de dados, redes de distribuição de conteúdos, DNS, serviços de confiança, comunicações eletrónicas públicas, serviços geridos ou serviços de segurança geridos. Se o seu estado de auditoria afetar o risco da cadeia de fornecimento deles, precisam de garantia credível.
Sprint prático de recuperação em 10 dias
Os prazos variam consoante o organismo de certificação, a severidade, o âmbito e a maturidade da evidência. Mas a sequência de recuperação é fiável.
| Dia | Atividade | Resultado |
|---|---|---|
| 1 | Recolher relatório de auditoria, confirmar estado do certificado, abrir pasta de auditoria centralizada | Centro de comando de recuperação |
| 2 | Classificar constatações, atribuir responsáveis, informar a gestão | Governação de recuperação aprovada |
| 3 | Atualizar contexto, obrigações, partes interessadas e pressupostos de âmbito | Contexto e mapa de conformidade atualizados |
| 4 | Conciliar avaliação de riscos e plano de tratamento de riscos | Registo de Riscos e plano de tratamento atualizados |
| 5 | Corrigir a SoA com fundamentação, exclusões, evidência e responsáveis | SoA preparada para auditoria |
| 6 | Executar análise de causa raiz para todas as constatações | Registo de causas raiz |
| 7 | Construir plano CAPA com datas-alvo e requisitos de evidência | Registo CAPA |
| 8 | Recolher e testar evidência para controlos prioritários | Pacote de evidências |
| 9 | Realizar revisão pela gestão e aprovar riscos residuais | Ata de revisão pela gestão |
| 10 | Executar auditoria simulada e preparar resposta ao organismo de certificação | Pacote de preparação para reauditoria |
Não submeta a resposta até ela contar uma história coerente. O auditor deve conseguir seguir a cadeia da constatação à causa raiz, da causa raiz à ação corretiva, da ação corretiva à evidência e da evidência à revisão pela gestão.
O fluxo de recuperação da Clarysec
Quando a Clarysec apoia uma transição ISO 27001:2022 não concluída ou não aprovada, organizamos o trabalho num fluxo de recuperação focado.
| Fase de recuperação | Ativo Clarysec | Resultado |
|---|---|---|
| Triagem de auditoria | Zenith Blueprint passos 24, 27, 29, 30 | Classificação de constatações, mapa de evidências, plano de encerramento da auditoria |
| Reposição da governação | Política de Segurança da Informação, Política de Auditoria e Monitorização da Conformidade | Responsabilidades aprovadas, envolvimento da gestão, pasta de evidência centralizada |
| Atualização de riscos | Política de Gestão de Riscos, método ISO/IEC 27005:2022 | Contexto, critérios, Registo de Riscos e plano de tratamento atualizados |
| Correção da SoA | Zenith Blueprint passo 24, Política de Gestão de Riscos | SoA rastreável com risco, obrigação, responsável, evidência e estado |
| Mapeamento de conformidade cruzada | Zenith Controls | Alinhamento de garantia com NIS2, DORA, RGPD da UE, NIST e COBIT 2019 |
| Execução CAPA | Zenith Blueprint passo 29, políticas de auditoria | Causa raiz, ação corretiva, responsável, prazo, verificação de eficácia |
| Auditoria simulada | Zenith Blueprint passo 30 | Pacote de preparação para reauditoria e pacote de garantia para clientes |
Isto não se trata de fabricar documentação. Trata-se de restaurar a confiança de que o SGSI é governado, baseado no risco, evidenciado e está em melhoria.
Conselho final: trate a transição não aprovada como um teste de esforço
Um prazo de transição ISO 27001:2022 perdido ou uma auditoria de transição não aprovada parecem uma crise, mas são também uma oportunidade de diagnóstico. Mostram se o seu SGSI consegue absorver mudança, integrar obrigações legais, gerir fornecedores, provar a operação dos controlos e aprender com a falha.
As organizações que recuperam mais depressa fazem três coisas bem:
- Centralizam a evidência e interrompem o caos.
- Reconstróem a rastreabilidade entre risco, SoA, controlos, políticas e obrigações.
- Tratam constatações de auditoria através de CAPA disciplinada e revisão pela gestão.
As organizações que têm dificuldades tentam resolver o problema editando documentos sem corrigir titularidade, monitorização, evidência ou causa raiz.
Se perdeu o prazo ou a sua auditoria de transição não foi aprovada, o próximo passo não é entrar em pânico. É executar uma recuperação estruturada.
A Clarysec pode ajudar a executar a triagem da auditoria de transição, reconstruir a sua SoA, mapear expectativas NIS2, DORA, RGPD da UE, NIST e COBIT 2019 através do Zenith Controls, executar ações corretivas com o Zenith Blueprint e alinhar evidência de políticas utilizando a Política de Segurança da Informação, a Política de Auditoria e Monitorização da Conformidade, a Política de Gestão de Riscos e a Política de Cumprimento Legal e Regulamentar.
O problema do seu certificado pode ser corrigido. O seu SGSI pode tornar-se mais forte do que era antes da auditoria. Se a sua auditoria de transição ainda está por resolver, inicie agora a avaliação de recuperação, consolide a sua evidência e prepare um pacote de reauditoria que prove que o seu SGSI não está apenas documentado, mas funciona.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
