Revisão pela gestão ISO 27001 para NIS2 e DORA

São 08:00 de uma segunda-feira de fevereiro de 2026. Maria, CISO de uma fintech europeia em rápido crescimento, abre um e-mail do CEO com o assunto: “URGENTE: preparação para o conselho”. Em anexo está uma notícia sobre uma ação regulatória de vários milhões de euros ao abrigo da Diretiva NIS2, centrada não apenas em controlos falhados, mas também em negligência do órgão de administração.
A pergunta do CEO é curta e desconfortável:
“Conseguimos provar que o conselho de administração governa ativamente o risco de cibersegurança, e não se limita a receber atualizações de TI?”
Às 08:30, o CFO acrescentou um questionário de auditoria de cliente. O presidente do conselho quer uma visão de uma página sobre a responsabilidade em cibersegurança antes da próxima reunião do comité de risco. O CTO pergunta se um incidente de fornecedor altera o pacote de evidência DORA para os clientes da empresa. Entretanto, Maria observa quatro temas que, à superfície, parecem operacionais: uma exceção de acesso privilegiado por resolver, duas ações corretivas em atraso, uma falha num exercício de tabletop e uma lacuna contratual com um fornecedor.
Não são problemas separados. São problemas de evidência de governação.
Em 2026, as organizações expostas à NIS2, ao DORA, ao GDPR, à garantia para clientes e ao escrutínio da certificação ISO/IEC 27001:2022 enfrentam uma pergunta mais exigente do que “Temos controlos de segurança?”.
A verdadeira pergunta é:
A gestão consegue provar que reviu o risco de cibersegurança, compreendeu as implicações, tomou decisões, atribuiu ações, financiou a remediação, aceitou risco residual quando adequado e acompanhou a execução?
Essa prova não resulta apenas de um PDF de política. Resulta de uma revisão pela gestão disciplinada, nos termos da Cláusula 9.3 da ISO/IEC 27001:2022, suportada por entradas, atas, decisões, registos de aceitação de risco, ações corretivas e trilhos de evidência.
Porque a Cláusula 9.3 da ISO 27001 é agora evidência para o conselho de administração
Uma revisão pela gestão fraca é uma apresentação apressada, algumas métricas e uma assinatura. Uma revisão pela gestão robusta é um evento de governação controlado no qual as decisões da liderança se transformam em evidência.
A Cláusula 9.3 da ISO/IEC 27001:2022 exige que a gestão de topo reveja o Sistema de Gestão da Segurança da Informação em intervalos planeados, para assegurar a sua contínua adequação, suficiência e eficácia. A revisão deve considerar ações anteriores, alterações em questões internas e externas, alterações nas necessidades e expectativas das partes interessadas, feedback sobre desempenho, resultados de auditoria, desempenho dos objetivos, resultados da avaliação de riscos, estado do tratamento de riscos e oportunidades de melhoria contínua.
Essa estrutura corresponde exatamente ao que conselhos de administração, reguladores, clientes e auditores esperam atualmente da governação da cibersegurança.
Para entidades essenciais e importantes abrangidas pela NIS2, o artigo 20 exige que os órgãos de administração aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e recebam formação. O artigo 21 exige medidas técnicas, operacionais e organizacionais proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, desenvolvimento seguro, avaliação da eficácia, higiene cibernética, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos, MFA quando adequado e ações corretivas sem demora indevida.
Para entidades financeiras, o DORA coloca a governação do risco das TIC diretamente no órgão de administração. O artigo 5 do DORA exige que o órgão de administração defina, aprove, supervisione e permaneça responsável pelo quadro de gestão do risco das TIC. Isto inclui tolerância ao risco das TIC, planos de continuidade e recuperação, planos de auditoria, orçamento, formação, políticas relativas a terceiros prestadores de serviços de TIC, canais de reporte de incidentes relevantes e medidas corretivas. O artigo 6 exige um quadro de gestão do risco das TIC documentado, revisto pelo menos anualmente e após incidentes relevantes relacionados com as TIC, instruções de supervisão, testes, auditorias ou alterações materiais.
O GDPR acrescenta a camada de responsabilidade. O artigo 5(2) exige que os responsáveis pelo tratamento sejam responsáveis pelo cumprimento dos princípios de proteção de dados e sejam capazes de o demonstrar. O artigo 32(1)(d) prevê um processo para testar, apreciar e avaliar regularmente a eficácia das medidas técnicas e organizativas.
Uma revisão pela gestão corretamente concebida é o ponto onde estas obrigações convergem.
A pressão regulamentar por trás da agenda de revisão
NIS2 e DORA não utilizam linguagem idêntica. O DORA também atua como ato jurídico setorial da UE para entidades financeiras abrangidas quando estejam em causa obrigações sobrepostas de cibersegurança e reporte. Mas ambos conduzem ao mesmo resultado de governação: a liderança sénior deve aprovar, supervisionar, dotar de recursos e corrigir a gestão do risco cibernético.
A NIS2 aplica-se amplamente a entidades médias e grandes em setores abrangidos e, em alguns casos, independentemente da dimensão. O Anexo I inclui prestadores de infraestruturas digitais, como prestadores de serviços de computação em cloud, prestadores de serviços de centros de dados, prestadores de redes de distribuição de conteúdos, prestadores de serviços de confiança, prestadores de serviços públicos de comunicações eletrónicas, prestadores de serviços geridos e prestadores de serviços de segurança geridos. Os Estados-Membros tinham de estabelecer listas de entidades essenciais e importantes até 17 de abril de 2025.
As consequências de aplicação são significativas. Para incumprimentos relacionados com as medidas de gestão de riscos de cibersegurança do artigo 21 ou com o reporte de incidentes do artigo 23, as coimas administrativas máximas podem atingir pelo menos EUR 10.000.000 ou 2% do volume de negócios anual mundial para entidades essenciais, e pelo menos EUR 7.000.000 ou 1,4% do volume de negócios anual mundial para entidades importantes, consoante o valor mais elevado.
O DORA aplica-se desde 17 de janeiro de 2025 e abrange um amplo ecossistema do setor financeiro, incluindo instituições de crédito, instituições de pagamento, instituições de moeda eletrónica, empresas de investimento, prestadores de serviços de criptoativos, seguradoras, resseguradoras, plataformas de negociação, agências de notação de risco, prestadores de serviços de financiamento colaborativo, repositórios de titularização e terceiros prestadores de serviços de TIC. O DORA é proporcional, mas proporcional não significa informal. Mesmo entidades financeiras de menor dimensão precisam de registos que demonstrem que a governação do risco das TIC é escalada, intencional, documentada e revista.
É por isso que a revisão pela gestão não pode continuar a ser uma formalidade de certificação. Tornou-se um dos mecanismos de evidência mais práticos para a responsabilidade NIS2, a governação do risco das TIC no DORA, a responsabilidade GDPR e a diligência prévia de clientes.
A espinha dorsal das políticas da Clarysec para disciplinar a revisão
A Clarysec trata a revisão pela gestão como um pacote de evidência para o conselho de administração, não como uma reunião anual cerimonial.
A Política de Segurança da Informação explicita a revisão pela gestão ISO 27001:
As atividades de revisão pela gestão (nos termos da Cláusula 9.3 da ISO/IEC 27001) devem ser realizadas pelo menos anualmente e devem incluir:
Da secção “Requisitos de governação”, cláusula 5.3 da política.
A mesma política define as expectativas de evidência:
Revisão dos indicadores-chave de desempenho de segurança (KPIs), incidentes, constatações de auditoria e estado do risco
Da secção “Requisitos de governação”, cláusula 5.3.2 da política.
E liga a revisão a decisões executivas:
Decisões sobre atualizações ao âmbito, controlos e alocação de recursos
Da secção “Requisitos de governação”, cláusula 5.3.3 da política.
Este último ponto é essencial. Uma revisão pela gestão não é uma apresentação. É um fórum de decisão.
A Política de Funções e Responsabilidades de Governação acrescenta a regra de rastreabilidade:
A governação deve apoiar a integração com outras disciplinas (por exemplo, risco, jurídico, TI, RH), e as decisões do SGSI devem ser rastreáveis até à sua origem (por exemplo, registos de auditoria, registos de revisão, atas de reunião).
Da secção “Requisitos de governação”, cláusula 5.5 da política.
Também atribui responsabilidades de escalonamento:
Participa nas revisões pela gestão do SGSI e escalona decisões que exigem aprovação ao nível do conselho de administração.
Da secção “Funções e responsabilidades”, cláusula 4.1.3 da política.
Para organizações de menor dimensão, a mesma lógica de governação deve ser escalada, não ignorada. A Política de Funções e Responsabilidades de Governação para PME estabelece:
Todas as decisões de segurança significativas, exceções e escalonamentos devem ser registados e rastreáveis.
Da secção “Requisitos de governação”, cláusula 5.5 da política.
A Política de Auditoria e Monitorização da Conformidade para PME assegura que as constatações de garantia chegam à liderança:
As constatações de auditoria e as atualizações de estado devem ser incluídas no processo de revisão pela gestão do SGSI.
Da secção “Requisitos de governação”, cláusula 5.4.3 da política.
E a Política de Gestão de Riscos para PME estabelece uma cadência para riscos elevados:
Revê trimestralmente os riscos mais elevados com o Coordenador de Risco.
Da secção “Funções e responsabilidades”, cláusula 4.1.3 da política.
O resultado é um ritmo prático: revisão trimestral dos riscos mais elevados, revisão pela gestão anual ou planeada nos termos da Cláusula 9.3, e revisões desencadeadas após incidentes relevantes, auditorias, testes de resiliência, falhas de fornecedores, alterações regulamentares ou alterações significativas no negócio.
Preparar o pacote de evidência para o conselho antes da reunião
O Zenith Blueprint: roteiro de auditoria em 30 passos aborda a revisão pela gestão na fase Auditoria, revisão e melhoria, passo 28: Revisão pela gestão. Instrui as equipas a preparar as entradas obrigatórias antes da reunião:
A ISO 27001 especifica várias entradas obrigatórias para a revisão pela gestão. Prepare um breve relatório
ou apresentação que cubra estes pontos:
Da fase Auditoria, revisão e melhoria, passo 28: Revisão pela gestão.
O Blueprint enfatiza ações anteriores, alterações em questões externas e internas, desempenho e eficácia do SGSI, resultados de auditoria, resultados de monitorização e medição, objetivos de segurança, incidentes, não conformidades, oportunidades de melhoria, necessidades de recursos e acompanhamento de decisões anteriores.
Também alerta que a revisão deve resultar em ação:
Decisões e ações: isto é crucial – a revisão pela gestão não é apenas uma apresentação;
trata-se de tomar decisões.
Da fase Auditoria, revisão e melhoria, passo 28: Revisão pela gestão.
Um pacote de evidência preparado para o conselho deve ser suficientemente conciso para executivos, mas suficientemente detalhado para auditores.
| Item de evidência | Finalidade de governação | Responsável típico |
|---|---|---|
| Agenda da revisão pela gestão | Demonstra que as entradas da Cláusula 9.3 foram planeadas e abrangidas | Gestor do SGSI ou CISO |
| Registo de acompanhamento de ações anteriores | Demonstra o seguimento das decisões de gestão anteriores | Gestor do SGSI |
| Resumo do Registo de Conformidade | Demonstra alterações em obrigações NIS2, DORA, GDPR, contratuais e de clientes | Jurídico ou GRC |
| Resumo do Registo de Riscos | Demonstra riscos elevados, riscos residuais e decisões dos responsáveis pelos riscos | Coordenador de Risco ou CISO |
| Registo de alterações da Declaração de Aplicabilidade | Demonstra decisões de controlo, exclusões e estado de implementação | Gestor do SGSI |
| Painel de KPIs e objetivos | Demonstra desempenho, tendências e metas não cumpridas | Operações de Segurança ou GRC |
| Resumo de incidentes e quase-incidentes | Demonstra escalonamento, análise de causa raiz, impacto e lições aprendidas | Gestor de Incidentes |
| Relatório de risco de fornecedores e cloud | Demonstra supervisão do risco de terceiros prestadores de serviços de TIC | Gestor de Fornecedores ou Compras |
| Constatações de auditoria interna e revisão independente | Demonstra garantia objetiva e não conformidades | Auditoria Interna ou Conformidade |
| Registo de acompanhamento de ações corretivas | Demonstra responsabilidade, prazos e evidência de encerramento | Responsáveis pelos controlos |
| Registo de decisões de recursos e orçamento | Demonstra apoio da gestão e priorização | Patrocinador executivo |
| Atas aprovadas | Demonstra supervisão, decisões, responsáveis atribuídos e acompanhamento | Secretário da reunião ou Gestor do SGSI |
Transformar entradas ISO em evidência NIS2 e DORA
A fintech de Maria precisa de uma agenda única que satisfaça auditores de certificação ISO, clientes alinhados com o DORA, questões de enquadramento NIS2 e expectativas de supervisão do conselho de administração. A forma mais simples de o fazer é traduzir cada entrada da Cláusula 9.3 numa pergunta de governação.
| Item da agenda da revisão pela gestão | Preocupação de governação NIS2 e DORA | Evidência gerada |
|---|---|---|
| Estado das ações da revisão anterior | Demonstra um ciclo de supervisão e responsabilidade em funcionamento | Atas com acompanhamento e estado de encerramento |
| Alterações em questões externas e internas | Demonstra adaptação a novas ameaças, regulamentos, serviços, fornecedores e estratégia de negócio | Atualização do Registo de Conformidade e alterações ao Registo de Riscos |
| Alterações nas necessidades das partes interessadas | Demonstra que as obrigações de clientes, reguladores, fornecedores e contratos são revistas | Registo de obrigações atualizado e rastreador de garantia para clientes |
| Desempenho e objetivos do SGSI | Demonstra que a liderança monitoriza a eficácia das medidas de cibersegurança | Painel de KPIs e registo de desempenho dos objetivos |
| Não conformidades e ações corretivas | Demonstra que as fragilidades são escaladas e remediadas | Registo de ações corretivas com responsáveis e datas |
| Resultados de monitorização, medição e auditoria | Demonstra avaliação da eficácia e garantia independente | Resumo de auditoria interna e resultados de monitorização |
| Estado da avaliação de riscos e do tratamento de riscos | Demonstra que a gestão revê o progresso do tratamento e o risco residual | Plano de tratamento de riscos, atualização da SoA e registos de aceitação |
| Oportunidades de melhoria contínua | Demonstra governação proativa e melhoria da resiliência | Plano de melhoria aprovado e decisões de investimento |
| Necessidades de recursos e orçamento | Apoia as expectativas de governação do DORA e o apoio da gestão | Aprovações orçamentais, decisões de recursos e planos de formação |
A última linha não substitui as entradas obrigatórias da ISO 27001 para a revisão. É a expansão prática da Clarysec para a governação em 2026, porque DORA, NIS2 e a verdadeira responsabilidade do conselho exigem evidência de que a liderança ponderou se a segurança dispunha de pessoas, financiamento, ferramentas e autoridade suficientes.
Uma revisão pela gestão de 90 minutos para um prestador fintech SaaS
Considere a empresa de Maria: um prestador fintech SaaS com clientes na UE. Presta serviços de monitorização de transações, utiliza um grande prestador de serviços cloud, depende de um Centro de Operações de Segurança externalizado, trata dados pessoais e integrou recentemente dois novos clientes de pagamentos. Está a preparar-se para uma auditoria de acompanhamento ISO/IEC 27001:2022, uma revisão de cliente alinhada com o DORA e uma avaliação de enquadramento NIS2.
Uma revisão pela gestão focada de 90 minutos poderia funcionar assim.
1. Começar pelas obrigações e alterações de contexto
Para PME, a Política de Cumprimento Legal e Regulamentar para PME dá um ponto de partida simples:
O Diretor-Geral (GM) deve manter um Registo de Conformidade simples e estruturado que liste:
Da secção “Requisitos de governação”, cláusula 5.1.1 da política.
O pacote de revisão deve resumir se a organização está no âmbito da NIS2, se o DORA se aplica diretamente ou por via de obrigações transferidas por clientes, se o tratamento ao abrigo do GDPR mudou e se as obrigações contratuais de segurança mudaram.
Exemplos:
- Um novo contrato com um cliente da UE exige notificação de incidentes de segurança ao cliente no prazo de 72 horas.
- Um pedido de diligência prévia de cliente alinhado com o DORA solicita registos de terceiros prestadores de serviços de TIC, evidência de estratégia de saída e registos de escalonamento de incidentes.
- Uma avaliação NIS2 identifica possível risco de classificação porque um serviço suporta atividades de segurança geridas num Estado-Membro.
- Uma nova funcionalidade de analytics altera o inventário de dados GDPR porque trata identificadores online.
As decisões de gestão devem aprovar a atualização do Registo de Conformidade, atribuir ao Jurídico e ao GRC a validação da classificação NIS2 com assessoria jurídica local e exigir um pacote de evidência DORA para clientes até ao próximo trimestre.
2. Apresentar decisões de risco e da Declaração de Aplicabilidade
A fase de Gestão de Riscos do Zenith Blueprint, passo 13: Planeamento do Tratamento de Riscos e Declaração de Aplicabilidade, enfatiza a aprovação executiva:
As decisões de tratamento de riscos e a SoA devem ser revistas e aprovadas pela gestão de topo.
Da fase Gestão de Riscos, passo 13: Planeamento do Tratamento de Riscos e Declaração de Aplicabilidade.
A revisão não deve submergir o conselho de administração em todos os riscos. Deve apresentar os principais riscos, estado do tratamento, exceções, ações em atraso e riscos residuais que exigem aprovação.
| Risco | Estado atual | Decisão necessária |
|---|---|---|
| Comprometimento de conta de administrador cloud | MFA implementada, revisão de acessos privilegiados em atraso | Aprovar responsável e prazo para revisão mensal de acessos privilegiados |
| Dependência de Centro de Operações de Segurança externalizado | O contrato não contém direito de auditoria integral nem linguagem de cooperação em incidentes | Aprovar remediação contratual ou avaliação de fornecedor alternativo |
| Objetivo de recuperação de cópias de segurança não cumprido | O teste de recuperação excedeu a meta em 4 horas | Aprovar orçamento para redesenho das cópias de segurança |
| Risco de concentração em fornecedor | Dois serviços críticos dependem da mesma região cloud | Aprovar revisão da arquitetura de resiliência |
| Retenção de logs de dados pessoais | Logs de depuração contêm identificadores online por mais tempo do que o previsto | Aprovar redução da retenção e controlo de monitorização |
Isto cria uma cadeia rastreável desde a avaliação de riscos até ao tratamento e à decisão da gestão.
3. Rever incidentes, quase-incidentes e preparação para reporte
O artigo 23 da NIS2 exige reporte faseado para incidentes significativos, incluindo um alerta precoce no prazo de 24 horas, notificação no prazo de 72 horas e um relatório final no prazo de um mês após a notificação do incidente, com reporte de progresso para incidentes em curso. Os artigos 17 a 19 do DORA exigem deteção, classificação, escalonamento, comunicação, reporte, análise de causa raiz e melhoria para incidentes relacionados com as TIC.
A revisão pela gestão deve incluir incidentes significativos, quase-incidentes, resultados de classificação, causas raiz, tempo até à deteção, tempo até ao escalonamento, tempo até à recuperação, preparação para notificação a clientes, preparação para reporte a autoridades, lições aprendidas e ações corretivas.
O Zenith Blueprint, na fase Controlos em ação, passo 16: Controlos de pessoas II, explica porque o reporte por colaboradores deve alimentar a governação:
Por último, o Controlo 6.8 deve alimentar o ciclo de melhoria contínua do SGSI. Os reportes
gerados pelo pessoal devem ser revistos durante a revisão pela gestão (Cláusula 9.3) e
utilizados para identificar falhas em políticas como offboarding, devolução de ativos ou violações de NDA.
Da fase Controlos em ação, passo 16: Controlos de pessoas II.
Se uma conta de antigo colaborador permaneceu ativa após a cessação, o conselho de administração não deve tratá-la como um ticket isolado. É evidência de uma possível fragilidade em RH, TI, controlo de acesso, gestão de ativos, monitorização e ação corretiva.
4. Rever fornecedores, cloud e preparação para saída
O artigo 28 do DORA torna o risco de terceiros prestadores de serviços de TIC parte do quadro de gestão do risco das TIC. As entidades financeiras mantêm plena responsabilidade pelo cumprimento quando os serviços de TIC são contratados externamente. Devem manter um registo atualizado de acordos contratuais de TIC, distinguir funções críticas ou importantes, realizar diligência prévia, gerir risco de concentração, assegurar direitos de auditoria e inspeção, e manter estratégias de saída.
O artigo 21 da NIS2 também exige segurança da cadeia de fornecimento, incluindo segurança das relações com fornecedores, vulnerabilidades específicas de fornecedores, práticas de cibersegurança de fornecedores e medidas corretivas.
Para a revisão pela gestão, o reporte sobre fornecedores não pode ser um anexo de compras. Tem de constituir evidência para o conselho de administração.
Inclua alterações em fornecedores críticos, estado da diligência prévia, lacunas contratuais, revisão da responsabilidade partilhada cloud, risco de concentração, resultados de estratégia de saída, cooperação de fornecedores em incidentes e ações corretivas decorrentes de avaliações de fornecedores. Se a liderança aprovar a continuação da utilização de um prestador de alto risco, as atas devem registar a fundamentação, os controlos compensatórios, a data de revisão e o responsável.
O conselho de Maria recebe uma questão concreta de fornecedor: um prestador de plataforma essencial sofreu um incidente menor, não reportável. Nenhum dado de cliente foi afetado, mas o evento expôs risco de concentração. O CEO atribui ao CTO a realização de um estudo de viabilidade de fornecedor secundário até ao próximo trimestre e aloca EUR 25.000 para a avaliação. Essa única decisão documentada prova supervisão do risco da cadeia de fornecimento, alocação de recursos e acompanhamento.
Como o Zenith Controls liga a evidência
O Zenith Controls: guia de conformidade cruzada da Clarysec ajuda as equipas a explicar porque a evidência de controlos ISO é relevante em vários referenciais.
Para a revisão pela gestão, o controlo 5.4 da ISO/IEC 27002:2022, Responsabilidades da gestão, é uma âncora de governação. Apoia a direção da gestão, a responsabilidade, a dotação de recursos e a supervisão. O Zenith Controls liga o controlo 5.4 a controlos de apoio da ISO/IEC 27002:2022 que surgem frequentemente na evidência de revisão pela gestão.
| Controlo ISO/IEC 27002:2022 | Porque é relevante para a revisão pela gestão |
|---|---|
| 5.1 Políticas de segurança da informação | A gestão deve aprovar, promover, dotar de recursos e institucionalizar políticas |
| 5.2 Funções e responsabilidades de segurança da informação | A gestão deve assegurar que as funções existem, têm autoridade e são monitorizadas |
| 5.8 Segurança da informação na gestão de projetos | A gestão assegura que a segurança é integrada em projetos e alterações de negócio |
| 5.35 Revisão independente da segurança da informação | A revisão independente proporciona à gestão garantia objetiva |
| 5.36 Cumprimento de políticas, regras e normas de segurança da informação | A monitorização do cumprimento dá à gestão evidência da aplicação |
| 8.15 Registo | Os logs suportam evidência para incidentes, controlo de acesso e monitorização da conformidade |
| 8.16 Atividades de monitorização | A monitorização suporta deteção, escalonamento e reporte de desempenho |
Este conjunto de controlos dá a Maria uma narrativa de conformidade cruzada. A evidência da sua revisão pela gestão pode apoiar a certificação ISO/IEC 27001:2022, a supervisão do artigo 20 da NIS2, as medidas de gestão de riscos do artigo 21 da NIS2, a governação das TIC do artigo 5 do DORA, a revisão do quadro de gestão do risco das TIC do artigo 6 do DORA, os testes de resiliência operacional digital dos artigos 24 a 27 do DORA, o artigo 32(1)(d) do GDPR, os resultados GOVERN do NIST CSF 2.0 e os objetivos de governação do COBIT 2019.
| Tema de evidência | Âncora ISO ou de controlo | Relevância regulamentar ou de referencial |
|---|---|---|
| Responsabilidade da gestão | ISO/IEC 27002:2022 5.4 | NIS2 artigo 20, DORA artigo 5, COBIT 2019 EDM03 |
| Garantia independente | ISO/IEC 27002:2022 5.35 | GDPR artigo 32(1)(d), DORA artigos 24 a 27, NIST SP 800-53 CA-2 |
| Acompanhamento de ações corretivas | ISO/IEC 27001:2022 Cláusula 10 | NIS2 artigo 21, DORA artigo 13, NIST SP 800-53 CA-5 |
| Monitorização do cumprimento da política | ISO/IEC 27002:2022 5.36 | Responsabilidade GDPR, COBIT 2019 MEA02, COBIT 2019 MEA03 |
| Risco de terceiros prestadores de serviços de TIC | ISO/IEC 27002:2022 5.19 e 5.20 | DORA artigo 28, NIS2 artigo 21 |
| Governação de incidentes | ISO/IEC 27002:2022 5.24, 5.25, 5.26, 5.27 | NIS2 artigo 23, DORA artigos 17 a 19 |
A revisão independente e a monitorização do cumprimento merecem atenção especial. Uma revisão pela gestão sem evidência independente torna-se autorreporte. O controlo 5.35 da ISO/IEC 27002:2022 proporciona ao conselho garantia objetiva através de auditorias internas, avaliações externas, resumos de testes de intrusão, observações de auditorias de certificação e revisões da eficácia dos controlos. O controlo 5.36 transforma “temos uma política” em “sabemos se as pessoas e os sistemas seguem a política”.
Como os auditores irão testar a sua revisão pela gestão
Uma revisão pela gestão nos termos da Cláusula 9.3 é um dos primeiros pontos que os auditores analisam quando avaliam se a governação é real. Auditores diferentes colocam perguntas diferentes, mas todos procuram rastreabilidade.
| Perspetiva do auditor | O que irá procurar | Evidência útil |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Se a gestão de topo reviu as entradas obrigatórias e fez acompanhamento | Agenda, atas, pacote de KPIs, resultados de auditoria, ações corretivas, aprovações de tratamento de riscos |
| Auditor de SGSI ao estilo ISO/IEC 27007 | Se os registos de revisão demonstram supervisão contínua e itens de ação implementados | Calendário de revisão, rastreador de ações, atualizações de objetivos, decisões de alteração do SGSI |
| Auditor ao estilo ISO/IEC 19011 | Se as conclusões são suportadas por evidência objetiva e métodos de auditoria adequados | Notas de entrevista, registos, atas aprovadas, referências de evidência |
| Avaliador orientado por NIST | Se a liderança sénior aprova a estratégia de risco, funções, recursos e supervisão do programa | Plano do programa de segurança, nomeação de responsável sénior, aprovação da estratégia de risco, POA&M |
| Auditor COBIT 2019 | Se a liderança avalia, dirige e monitoriza iniciativas de risco e segurança | Relatórios ao conselho, painéis de risco, alinhamento EDM03, métricas de desempenho |
| Auditor ISACA ITAF | Se o tom no topo é visível e as respostas da gestão são tempestivas e eficazes | Respostas de auditoria interna, registos de escalonamento, trilho de governação de incidentes |
A falha comum não é a reunião não ter ocorrido. É a reunião não ter alterado nada. Os auditores querem ver decisões, responsáveis, prazos, evidência esperada e registos de encerramento.
Resultados que provam supervisão executiva
As entradas criam a revisão. Os resultados provam a governação.
No mínimo, o registo da revisão pela gestão deve incluir:
Decisões aprovadas
Exemplos incluem aprovar a preparação para certificação, atualizar o âmbito do SGSI, rever fluxos de reporte de incidentes, exigir remediação contratual de fornecedores ou aceitar risco residual até uma data definida.Ações atribuídas
Cada ação precisa de um responsável, data limite, prioridade, evidência esperada e cadência de revisão.Registos de aceitação de risco
Os riscos aceites devem identificar o responsável pelo risco, fundamentação, nível de risco residual, controlos compensatórios, data de expiração e limiar de escalonamento.Decisões de recursos
Registe orçamento, efetivo, ferramentas, formação, apoio de auditoria externa, avaliação jurídica, exercícios de tabletop ou atividades de garantia de fornecedores.Atualizações de políticas e controlos
Registe alterações a controlo de acesso, resposta a incidentes, continuidade de negócio, gestão de fornecedores, cifragem, desenvolvimento seguro, registo, gestão de vulnerabilidades ou retenção de dados.Aprovações de ações corretivas
Não conformidades e constatações de auditoria devem tornar-se ações corretivas com responsabilidade atribuída, prazos e expectativas de evidência.Mecanismo de acompanhamento
A revisão seguinte deve começar pelo estado destas decisões.
Para PME, a Política de Segurança da Informação para PME reforça a necessidade de ligar certificação, regulamentação e alteração do negócio:
Esta política deve ser revista pelo Diretor-Geral (GM) pelo menos anualmente para assegurar o cumprimento contínuo dos requisitos de certificação ISO/IEC 27001, alterações regulamentares (como GDPR, NIS2 e DORA) e necessidades de negócio em evolução.
Da secção “Requisitos de revisão e atualização”, cláusula 9.1.1 da política.
Essa frase capta a realidade de 2026. A revisão pela gestão deve ligar o SGSI, alteração regulamentar, clientes, fornecedores, incidentes, risco, recursos e estratégia de negócio num único ciclo de governação.
Falhas comuns na revisão pela gestão em 2026
As falhas mais comuns são previsíveis.
Primeiro, a revisão é demasiado técnica. Os executivos recebem contagens de vulnerabilidades e volumes de alertas, mas não risco de negócio, exposição regulamentar, impacto nos clientes ou opções de decisão.
Segundo, não existe registo de decisões. As atas dizem “risco de fornecedor discutido”, mas não registam se a gestão aceitou o risco, exigiu remediação, aprovou orçamento ou atribuiu um prazo.
Terceiro, a aceitação de risco residual é informal. Um risco permanece aberto durante meses porque “o negócio sabe”, mas não há aprovação do responsável, fundamentação, data de expiração ou desencadeador de revisão.
Quarto, as constatações de auditoria não chegam à gestão. Os relatórios de auditoria interna permanecem em pastas GRC enquanto a liderança vê apenas um resumo de estado verde.
Quinto, fornecedores e prestadores de serviços cloud são tratados separadamente do desempenho do SGSI. Ao abrigo do DORA e da NIS2, o risco de terceiros prestadores de serviços de TIC é evidência central de governação.
Sexto, os incidentes são reportados como eventos operacionais, mas não são revistos para melhoria sistémica. Causas raiz, lições aprendidas e ações corretivas devem alimentar a revisão pela gestão.
Sétimo, falta o rastreador de ações anteriores. Os auditores irão perguntar o que aconteceu às decisões do ano anterior. Se a resposta estiver dispersa por e-mails e tickets, a narrativa de governação enfraquece.
Um ciclo de governação, muitas obrigações
O modelo prático da Clarysec é simples:
Âmbito e obrigações
Utilize o âmbito do SGSI, partes interessadas, Registo de Conformidade, obrigações de clientes e dependências de fornecedores para definir o que a revisão deve abranger.Evidência de risco e controlo
Utilize o Registo de Riscos, a Declaração de Aplicabilidade, evidência de implementação de controlos, KPIs e monitorização da conformidade.Entradas de garantia
Inclua auditorias internas, revisões independentes, testes de intrusão, avaliações de fornecedores, auditorias de clientes e constatações de certificação.Entradas de resiliência operacional
Inclua incidentes, quase-incidentes, testes de continuidade de negócio, resultados de cópias de segurança, exercícios de recuperação de desastre, lições de gestão de crise e preparação para reporte.Decisões da liderança
Registe aceitação de risco, alocação de recursos, alterações de âmbito, alterações de controlos, decisões sobre fornecedores, ações corretivas e objetivos estratégicos.Preservação da evidência
Armazene atas, pacotes, aprovações, rastreadores de ações e evidência de encerramento num repositório controlado.Cadência de acompanhamento
Reveja riscos elevados trimestralmente, execute revisões pela gestão planeadas nos termos da Cláusula 9.3 e desencadeie revisões adicionais após incidentes relevantes, alterações de fornecedores, auditorias, testes ou desenvolvimentos regulamentares.
É assim que uma única revisão pela gestão pode servir a certificação ISO/IEC 27001:2022, a responsabilidade do órgão de administração NIS2, a governação do risco das TIC no DORA, a responsabilidade GDPR, a revisão GOVERN do NIST CSF, a supervisão do conselho de administração COBIT 2019 e a diligência prévia de clientes.
Torne a sua próxima revisão pela gestão preparada para auditoria
O conselho de administração de Maria não precisava de mais um painel técnico. Precisava de evidência defensável de que o risco de cibersegurança foi revisto, compreendido, decidido, financiado e melhorado.
A sua organização precisa do mesmo.
Comece este mês:
- Construa um pacote de evidência da Cláusula 9.3.
- Mapeie cada item da agenda para um risco, obrigação, KPI, constatação de auditoria, incidente, questão de fornecedor ou ação corretiva.
- Registe cada decisão com responsável, data limite, fundamentação e evidência esperada.
- Utilize o rastreador de ações anteriores como primeiro item da agenda na revisão seguinte.
- Preserve atas, aprovações, aceitações de risco e registos de encerramento num repositório controlado.
A Clarysec pode ajudá-lo a operacionalizar isto rapidamente utilizando o Zenith Blueprint, o conjunto de políticas da Clarysec e o Zenith Controls como bússola de conformidade cruzada para ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF, COBIT 2019 e preparação para auditoria.
Se a sua revisão pela gestão ainda é uma tarefa rotineira de conformidade, está na hora de a transformar num ativo estratégico de governação. Descarregue os toolkits da Clarysec, prepare o seu pacote de evidência para o conselho de administração e faça da sua próxima revisão a prova de que a liderança governa o risco de cibersegurança.
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


