Apetite ao risco de TIC no DORA: guia de aprovação pelo Conselho de Administração para 2026

São 08:15 de uma terça-feira e o CISO de uma empresa de tecnologia de pagamentos de média dimensão está à porta da sala do Conselho de Administração com três documentos abertos num tablet.

O primeiro é o registo de riscos de TIC. Tem 137 linhas, classificações codificadas por cores e vários riscos elevados associados à concentração em serviços de computação em nuvem, acesso privilegiado, recuperação após ransomware, exposição de dados de clientes e resposta a incidentes de prestadores. O segundo é o rastreador de preparação para o DORA. Indica que a empresa tem políticas, procedimentos de incidentes, registos de terceiros e planos de testes de resiliência. O terceiro é o dossiê do Conselho de Administração para uma reunião regulamentar.

O presidente tem uma pergunta, e não é técnica:

“Que nível de risco de TIC acordámos efetivamente aceitar?”

A sala fica em silêncio porque a empresa tem avaliações de risco, mas não tem um apetite ao risco de TIC aprovado pelo Conselho de Administração. Tem classificações de impacto, mas não limiares de tolerância mensuráveis. Tem reuniões de escalonamento, mas nenhum critério formal que determine quando um risco cibernético passa a ser uma decisão do órgão de administração. Tem riscos residuais aceites, mas alguns são justificados como “decisões de negócio” sem uma ligação clara a critérios de risco, à proporcionalidade do artigo 32 do RGPD da UE, às expectativas de tolerância do DORA ou à responsabilização da gestão exigida pela NIS2.

Esta lacuna é cada vez mais visível em 2026. O DORA é aplicável desde 17 de janeiro de 2025 e exige que as entidades financeiras mantenham um quadro de governação e controlo para o risco de TIC, incluindo a responsabilidade do órgão de administração pelo quadro de gestão de riscos de TIC, pela estratégia de resiliência operacional digital e pela tolerância ao risco de TIC. A NIS2 leva os órgãos de administração a aprovar medidas de gestão dos riscos de cibersegurança e a supervisionar a respetiva implementação. O artigo 32 do RGPD da UE exige medidas técnicas e organizativas de segurança adequadas e baseadas no risco. A ISO/IEC 27001:2022 fornece a mecânica do sistema de gestão: contexto, partes interessadas, critérios de risco, planos de tratamento, informação documentada e revisão pela gestão.

A ponte em falta é uma declaração de apetite e tolerância ao risco de TIC que o Conselho de Administração consiga compreender, aprovar, desafiar e utilizar.

Este guia explica como construir essa ponte com o Zenith Blueprint: roteiro de 30 passos de um auditor da Clarysec, a Política de Gestão de Riscos da Clarysec, a Política de Gestão de Riscos para PME da Clarysec e o Zenith Controls: guia de conformidade transversal.

Porque os registos de riscos não são apetite ao risco

Muitas organizações confundem um registo de riscos com governação de riscos. Um registo de riscos indica que riscos existem, como são classificados, quem é o dono do risco e que tratamento está previsto. Não responde automaticamente às perguntas ao nível do Conselho de Administração que o DORA, a NIS2, o RGPD da UE e a ISO/IEC 27001:2022 esperam que os líderes abordem.

Uma declaração madura de apetite ao risco de TIC responde a perguntas como:

• Que riscos de TIC são inaceitáveis independentemente do custo?
• Que indisponibilidade operacional pode o negócio tolerar para uma função crítica ou importante?
• Que nível de perda de dados ou comprometimento da integridade dos dados está fora do apetite?
• Que risco de concentração em terceiros exige atenção do Conselho de Administração?
• Quem pode aceitar risco residual de TIC e a que nível?
• Quando deve um risco ser escalado para a gestão de topo ou para o órgão de administração?
• Como são integrados os requisitos legais, regulamentares e contratuais nos critérios de risco?

Ao abrigo do DORA, isto não é um mero aperfeiçoamento opcional da governação. O artigo 5 exige que o órgão de administração defina, aprove, supervisione e assuma responsabilidade pelo quadro de gestão de riscos de TIC, incluindo a estratégia de resiliência operacional digital e a tolerância ao risco de TIC. O artigo 6 exige um quadro de gestão de riscos de TIC documentado, revisão anual para entidades que não sejam microempresas, auditoria interna, remediação de constatações de auditoria críticas e uma estratégia de resiliência operacional digital com objetivos de TIC, tolerância ao risco, tolerância ao impacto, arquitetura, testes e estratégia de comunicação de incidentes.

A NIS2 acrescenta um modelo paralelo de responsabilização. O artigo 20 exige que os órgãos de administração das entidades essenciais e importantes aprovem medidas de gestão dos riscos de cibersegurança, supervisionem a implementação e recebam formação. O artigo 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionais, baseadas numa abordagem multirriscos, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, desenvolvimento seguro, eficácia dos controlos, formação, criptografia, segurança de recursos humanos, controlo de acessos, gestão de ativos e autenticação multifator (MFA) quando aplicável.

Para entidades financeiras, o DORA é tratado como ato jurídico setorial da União quando existam obrigações NIS2 sobrepostas. Na prática, o DORA substitui geralmente os requisitos sobrepostos de gestão de riscos e notificação de incidentes da NIS2 para entidades financeiras abrangidas pelo seu âmbito, enquanto a NIS2 continua importante para coordenação e para prestadores fora das obrigações diretas do DORA aplicáveis a entidades financeiras. Para prestadores SaaS, de serviços de computação em nuvem, de serviços geridos e de segurança gerida, a NIS2 pode aplicar-se diretamente quando as condições de âmbito estejam preenchidas.

É por isso que o apetite ao risco de TIC aprovado pelo Conselho de Administração deixou de ser um artefacto de risco financeiro. É um controlo de governação da cibersegurança.

Use a ISO/IEC 27001:2022 como sistema operativo

O DORA e a NIS2 indicam aos líderes o que deve ser governado. A ISO/IEC 27001:2022 dá às organizações um sistema operativo prático para governar esse universo.

As cláusulas 4.1 a 4.4 da ISO/IEC 27001:2022 exigem que a organização defina o contexto, as partes interessadas, os requisitos, o âmbito do SGSI e os processos do SGSI. Isto é relevante porque DORA, NIS2, RGPD da UE, contratos, expectativas das autoridades de supervisão, clientes, prestadores de serviços de computação em nuvem e acordos de externalização passam a ser requisitos que influenciam os critérios de risco.

As cláusulas 5.1 a 5.3 exigem compromisso da liderança, alinhamento de políticas, recursos, responsabilidades e reporte do desempenho do SGSI à gestão de topo. As cláusulas 6.1.1 a 6.1.3 exigem planeamento baseado no risco, um processo documentado de avaliação de riscos, critérios de aceitação do risco, critérios de avaliação consistentes, donos dos riscos, comparação com critérios de risco, planeamento do tratamento, uma Declaração de Aplicabilidade e aprovação do risco residual.

Esta é a base da tolerância ao risco de TIC no DORA.

Na fase de gestão de riscos, o passo 10 do Zenith Blueprint orienta as organizações a definir critérios de risco antes de classificar os riscos:

“Os critérios de risco são as regras e referenciais que a sua organização utiliza para avaliar a relevância de cada risco. Definir estes critérios antecipadamente garante que todos falam a mesma linguagem de risco.”

O mesmo passo alerta que o impacto regulamentar deve ser integrado nas definições de risco:

“Qualquer risco que possa conduzir ao incumprimento de leis aplicáveis (RGPD da UE, etc.) não é aceitável e deve ser mitigado.”

O Zenith Blueprint também fornece orientação prática para escalas de impacto:

“Ao definir impacto, é aconselhável relacionar os níveis com a escala específica do seu negócio. Por exemplo, ‘impacto financeiro maior = perda > 100 mil dólares’ (ajustar ao seu contexto). Considere também o impacto regulamentar: por exemplo, uma violação de dados pessoais pode ser automaticamente ‘maior’ ou ‘severa’ devido a coimas do RGPD da UE e requisitos de notificação, mesmo que a perda financeira direta seja incerta. Do mesmo modo, se estiver abrangido pela NIS2 (serviços essenciais), um incidente que cause interrupção de serviços pode ser pelo menos ‘maior’ devido a implicações legais. Inclua estas considerações nas suas definições.”

Esta orientação evita uma falha comum: classificar um risco cibernético como moderado porque a perda financeira imediata parece pequena, ignorando o impacto legal, de resiliência operacional, para os titulares dos dados ou para os clientes.

Um modelo preparado para o Conselho de Administração deve separar quatro camadas:

Esta estrutura torna o apetite ao risco auditável porque cada declaração pode ser rastreada até critérios de risco, controlos, evidência e decisões.

Uma declaração de apetite ao risco de TIC no DORA preparada para o Conselho de Administração

Uma declaração robusta de apetite ao risco de TIC deve ser suficientemente curta para ser aprovada pelo Conselho de Administração, suficientemente específica para ser aplicada pela gestão e suficientemente mensurável para ser testada por auditores. Deve evitar jargão, mas não pode ser vaga.

Uma declaração prática de alto nível poderia ser:

“A nossa empresa tem baixo apetite por riscos de TIC que possam resultar em danos materiais para clientes, interrupção de funções críticas ou importantes, divulgação ou alteração não autorizada de dados regulados, incumprimento de obrigações legais ou perda de resiliência em serviços críticos de TIC prestados por terceiros.”

Essa declaração precisa então de limiares de tolerância mensuráveis e critérios de escalonamento.

Esta tabela altera a conversa. O Conselho de Administração deixa de aprovar um slogan. Passa a aprovar limites operacionais para disponibilidade, confidencialidade, integridade, prestadores, vulnerabilidades, recuperação e conformidade.

A Política de Gestão de Riscos da Clarysec suporta este modelo de governação. A política empresarial estabelece:

“Aprova o quadro de gestão de riscos e define o apetite ao risco aceitável e os limiares de tolerância.”

A cláusula 6.2.1 torna explícito o requisito de medição:

“Os riscos devem ser avaliados quanto à probabilidade e ao impacto utilizando uma matriz de riscos padrão com escalas de pontuação claramente definidas.”

A cláusula 6.3.4 cria a regra de aceitação que os auditores esperarão:

“Os riscos aceites sem tratamento devem ser justificados por escrito, ligados ao apetite ao risco da organização e aprovados ao nível apropriado.”

Para PME, a Política de Gestão de Riscos para PME mantém o mesmo princípio de governação num formato mais leve:

“Assegurar o envolvimento da gestão na aprovação da tolerância ao risco e dos principais planos de tratamento de riscos.”

Também exige o escalonamento de riscos elevados:

“Os riscos elevados devem ser escalados para o Diretor-Geral para decisão.”

Isto é proporcionalidade em ação. O artigo 4 do DORA exige que os requisitos sejam aplicados de forma proporcional à dimensão, ao perfil de risco e à natureza, escala e complexidade dos serviços. A ISO/IEC 27001:2022 permite o mesmo princípio através do âmbito, contexto, critérios de risco e decisões de tratamento. A norma de governação não exige que todas as organizações tenham a mesma estrutura de comités. A norma de governação exige que apetite ao risco, tolerância, escalonamento e aceitação sejam definidos, aprovados, evidenciados e utilizados.

O artigo 32 do RGPD da UE muda a conversa sobre risco

O artigo 32 do RGPD da UE é frequentemente tratado como uma cláusula técnica de segurança. Em termos de governação, é também uma cláusula de apetite ao risco.

O artigo 32 exige que responsáveis pelo tratamento e subcontratantes implementem medidas técnicas e organizativas adequadas para assegurar um nível de segurança adequado ao risco. Esta abordagem baseada no risco considera o estado da técnica, os custos de implementação, a natureza, o âmbito, o contexto e as finalidades do tratamento, bem como os riscos para os direitos e liberdades das pessoas singulares.

Isto afeta o apetite ao risco de TIC de três formas.

Primeiro, o impacto sobre dados pessoais não pode ser reduzido a perda financeira. A exposição de uma pequena base de dados pode ter custo direto limitado, mas consequências graves para confidencialidade, identidade, fraude, discriminação ou direitos dos titulares. Se estiverem envolvidas categorias especiais de dados pessoais, como dados de saúde, biométricos ou genéticos, o apetite deve ser materialmente mais baixo.

Segundo, os papéis no tratamento devem ligar-se à propriedade do risco. O RGPD da UE distingue responsáveis pelo tratamento e subcontratantes. O DORA distingue entidades financeiras e prestadores terceiros de serviços de TIC. A NIS2 distingue entidades essenciais e importantes. A ISO/IEC 27001:2022 exige donos dos riscos. Uma declaração madura de apetite deve identificar quem é proprietário das decisões de risco que envolvem dados pessoais, tratamento externalizado, serviços críticos e dependências transfronteiriças.

Terceiro, a proporcionalidade do artigo 32 deve ser visível na seleção de controlos. Cifragem, pseudonimização, controlo de acessos, cópia de segurança, registo, monitorização, resposta a incidentes e resiliência não são tarefas técnicas isoladas. São medidas de tratamento selecionadas porque um risco excedeu o apetite ou a tolerância.

A Política de Gestão de Riscos da Clarysec estabelece explicitamente esta ligação:

“Artigo 32: exige uma abordagem baseada no risco às medidas de segurança, cumprida através de avaliações de risco baseadas no impacto e da seleção de controlos.”

Essa é a ligação operacional que os auditores procuram: requisito do artigo 32, avaliação de riscos, classificação de risco, plano de tratamento, seleção de controlos, risco residual e aprovação.

Como o Zenith Controls suporta evidência de conformidade transversal

Uma declaração de apetite aprovada pelo Conselho de Administração torna-se poderosa quando é mapeada para controlos. O Zenith Controls atua como guia de conformidade transversal da Clarysec, ajudando as equipas a reutilizar evidência em ISO/IEC 27001:2022, DORA, NIS2, RGPD da UE, NIST CSF e garantia baseada em COBIT.

Três áreas de controlo da ISO/IEC 27002:2022 são especialmente importantes:

Isto não é um exercício de mapeamento em papel. Altera a forma como as decisões são tomadas.

Se um responsável de negócio pedir para aceitar o adiamento da implementação de MFA para administradores, o Zenith Controls ajuda o CISO a demonstrar que isto não é apenas uma questão de controlo de acessos. Toca governação de políticas, responsabilidade da gestão, requisitos legais e regulamentares, segurança do tratamento ao abrigo do RGPD da UE, gestão de riscos de TIC no DORA, medidas de cibersegurança NIS2, impacto de incidentes e evidência de auditoria.

Se uma equipa de produto quiser lançar num novo mercado da UE utilizando um novo serviço de computação em nuvem, o controlo 5.31 da ISO/IEC 27002:2022 leva a revisão dos requisitos legais e regulamentares para dentro do âmbito do SGSI. A cláusula 4.2 da ISO/IEC 27001:2022 exige que os requisitos das partes interessadas sejam identificados, incluindo obrigações legais, regulamentares e contratuais. A cláusula 8.1 exige planeamento e controlo operacional, incluindo o controlo de processos, produtos ou serviços fornecidos externamente relevantes para o SGSI.

O objetivo é uma linguagem de risco única, não dialetos separados de conformidade.

Fluxo de aprovação: quem decide o quê

Um CISO pode propor o apetite ao risco de TIC, mas o Conselho de Administração ou o órgão de administração deve assumi-lo como seu. Essa propriedade exige um fluxo de trabalho.

Isto também se alinha com o NIST CSF 2.0. A função GOVERN, especialmente GV.RM, espera objetivos de gestão de riscos acordados, declarações de apetite ao risco e tolerância, atividades de risco integradas na gestão de riscos empresariais, opções de resposta ao risco definidas, linhas de comunicação e métodos normalizados para calcular, documentar, categorizar e priorizar riscos de cibersegurança. GV.RR espera responsabilização da liderança, papéis, autoridades e recursos alinhados com a estratégia de risco. GV.PO espera que as políticas sejam estabelecidas, comunicadas, aplicadas, revistas e atualizadas.

Profissionais de garantia baseada em COBIT e ISACA perguntarão se o apetite ao risco está integrado na governação empresarial da informação e tecnologia, e não apenas anexado a uma política de cibersegurança.

Construa um dossiê de apetite ao risco de TIC numa sessão de trabalho

Um workshop prático de apetite ao risco de TIC pode levar uma organização de registos dispersos para um dossiê auditável para o Conselho de Administração.

Passo 1: recolher os inputs certos

Prepare o registo de riscos de TIC atual, a análise de impacto no negócio, os objetivos de recuperação, a lista de funções críticas ou importantes, o inventário de ativos de TIC, o inventário de serviços de TIC, o registo de dependências de prestadores e de serviços de computação em nuvem, os critérios de classificação de incidentes, o inventário de atividades de tratamento ao abrigo do RGPD da UE, as AIPD quando relevantes, o registo de obrigações legais, as políticas, a Declaração de Aplicabilidade e a declaração existente de apetite ao risco empresarial.

Isto alinha-se com as cláusulas 4, 6 e 8 da ISO/IEC 27001:2022 e com os métodos de perfil do NIST CSF, que começam por prioridades de negócio, prioridades de risco, requisitos, salvaguardas e papéis.

Passo 2: definir escalas de impacto que incluam regulamentação

Com o passo 10 do Zenith Blueprint, defina probabilidade e impacto em linguagem de negócio. Inclua perda financeira, interrupção operacional, impacto no cliente, dano reputacional, impacto legal e regulamentar, dano para titulares dos dados e impacto em funções críticas.

Por exemplo, um impacto “maior” pode incluir uma indisponibilidade prolongada de um serviço crítico, uma violação de dados pessoais confirmada que exija notificação, incumprimento de uma obrigação de reporte de incidentes DORA ou falha de prestador que afete uma função crítica ou importante.

Passo 3: escrever o apetite por domínio

Não crie um apetite cibernético genérico único. Defina domínios como disponibilidade de serviços críticos, confidencialidade de dados pessoais, integridade dos dados, acesso privilegiado, dependência de terceiros de TIC, concentração em serviços de computação em nuvem, exposição a vulnerabilidades, preparação para reporte de incidentes, cópia de segurança e recuperação, e risco de alterações em desenvolvimento seguro.

Para cada domínio, escreva uma declaração de apetite, um ou mais limiares de tolerância e critérios de escalonamento.

Passo 4: ligar o tratamento à Declaração de Aplicabilidade

O passo 13 do Zenith Blueprint orienta as organizações a escolher opções de tratamento de riscos: mitigar, evitar, transferir ou aceitar. Também enfatiza a aprovação pela gestão:

“As decisões de tratamento de riscos e a Declaração de Aplicabilidade devem ser revistas e aprovadas pela gestão de topo.”

Para DORA e NIS2, isto é evidência de que o órgão de administração ou a liderança delegada reviu riscos-chave, tratamentos e exposição residual aceite. Para o RGPD da UE, suporta a responsabilização ao demonstrar por que razão as medidas selecionadas eram adequadas ao risco.

Passo 5: registar a aceitação com expiração e condições

Cada risco residual médio ou elevado aceite deve incluir:

• ID do risco e dono
• Fundamentação de negócio
• Referência à declaração de apetite
• Limiar de tolerância afetado
• Análise legal e regulamentar
• Controlos compensatórios
• Data de expiração ou revisão
• Aprovador
• Localização da evidência
• Critério para reabrir a decisão

A Política de Gestão de Riscos para PME estabelece:

“Qualquer decisão de aceitar ou diferir o tratamento de um risco elevado ou médio deve ser documentada no registo de riscos. Esta documentação deve incluir:”

Em ambientes empresariais, isto transforma-se num fluxo de aprovação e num dossiê do comité de risco. Em organizações mais pequenas, pode ser uma aba estruturada do registo de riscos com aprovação formal da gestão. O objetivo não é burocracia. O objetivo é defensabilidade.

Tolerância a incidentes: onde o apetite encontra o relógio

O apetite ao risco torna-se real durante incidentes.

O artigo 17 do DORA exige que as entidades financeiras estabeleçam um processo de gestão de incidentes relacionados com as TIC para detetar, gerir e notificar incidentes, registar todos os incidentes e ciberameaças significativas, identificar causas raiz, utilizar indicadores de alerta precoce, classificar incidentes por prioridade, severidade e criticidade do serviço, atribuir papéis, comunicar às partes interessadas, escalar pelo menos os incidentes maiores relacionados com as TIC para a gestão de topo e para o órgão de administração, e restaurar operações seguras em tempo útil.

O artigo 18 do DORA classifica incidentes com base em fatores como clientes afetados, duração, indisponibilidade, distribuição geográfica, perdas de dados que afetem disponibilidade, autenticidade, integridade ou confidencialidade, criticidade dos serviços afetados e impacto económico. O artigo 19 exige que incidentes maiores relacionados com as TIC sejam comunicados à autoridade competente, com informação aos clientes quando os seus interesses financeiros sejam afetados.

O artigo 23 da NIS2 prevê reporte por fases para incidentes significativos, incluindo alerta precoce sem demora injustificada e, quando aplicável, no prazo de 24 horas, notificação de incidente sem demora injustificada e, quando aplicável, no prazo de 72 horas, atualizações intermédias quando solicitadas e relatório final até um mês após a notificação do incidente. Incidentes significativos incluem os que causam interrupção operacional severa, perda financeira ou danos materiais ou imateriais a terceiros.

A declaração de apetite deve definir limiares de escalonamento antes de o incidente ocorrer.

Os controlos do Anexo A relativos a planeamento de incidentes, avaliação de eventos de segurança da informação, resposta a incidentes, aprendizagem com incidentes, recolha de evidência, manutenção da segurança da informação durante disrupções e preparação de TIC para continuidade de negócio suportam todos estes limiares. Os resultados do NIST CSF em IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER suportam o mesmo modelo operativo, incluindo cópias de segurança, monitorização, declaração de incidentes, escalonamento, análise de causa raiz, comunicação com partes interessadas e verificação da recuperação.

A tolerância a prestadores e serviços de computação em nuvem que os conselhos de administração frequentemente ignoram

O DORA torna o risco de terceiros de TIC uma obrigação central de conformidade. O artigo 28 exige que as entidades financeiras gerem o risco de terceiros de TIC como parte do quadro de gestão de riscos de TIC, mantendo a plena responsabilidade pela conformidade. Exige estratégia de risco de terceiros de TIC, registos de acordos contratuais de serviços de TIC, distinção dos serviços que suportam funções críticas ou importantes, reporte anual, notificação de acordos planeados, avaliações pré-contratuais, diligência prévia, direitos de auditoria e inspeção, direitos de cessação e estratégias de saída documentadas.

O artigo 29 acrescenta análise do risco de concentração, incluindo não substituibilidade, múltiplas dependências do mesmo prestador ou de prestadores ligados, riscos de subcontratação, subcontratantes de países terceiros, conformidade com proteção de dados, executoriedade e cadeias de subcontratação complexas. O artigo 30 exige direitos e obrigações contratuais por escrito, descrições de serviços, localizações, proteções de segurança, acesso e devolução de dados, níveis de serviço, assistência em incidentes, cooperação com autoridades, direitos de cessação, planos de contingência testados, monitorização e mecanismos de saída.

Uma declaração de tolerância a prestadores aprovada pelo Conselho de Administração poderia estabelecer:

“Temos baixo apetite por dependência de funções críticas ou importantes relativamente a um prestador terceiro de serviços de TIC quando não temos direitos contratuais de auditoria, mecanismos de saída testados, deveres de notificação de incidentes, metas de níveis de serviço, direitos de devolução de dados ou visibilidade sobre subcontratação material.”

Esta frase dá à aquisição uma regra prática. Se o contrato não cumprir o limiar, o risco não pode ser aceite discretamente pela equipa de projeto.

Como os auditores testarão o seu apetite ao risco de TIC

Uma declaração robusta de apetite é concebida tendo a auditoria em mente.

O passo 28 do Zenith Blueprint, na fase de auditoria, revisão e melhoria, reforça a camada de revisão pela gestão. Orienta as organizações a recolher inputs como alterações em questões externas e internas, desempenho do SGSI, resultados de auditoria, monitorização e medição, incidentes, não conformidades, oportunidades de melhoria e necessidades de recursos. Também indica que a revisão pela gestão deve conduzir a decisões e ações, não apenas a apresentações.

Pelo menos anualmente, e sempre que existam alterações materiais, a gestão deve rever se os limiares de tolerância continuam alinhados com o modelo de negócio, se incidentes excederam o apetite, se riscos aceites permanecem dentro dos limites aprovados, se novos requisitos DORA, NIS2, RGPD da UE ou contratuais alteraram a configuração de referência, se prestadores continuam dentro das tolerâncias de concentração e se os KRI estão a gerar escalonamento atempado.

Se a resposta for não, a declaração de apetite deve mudar, ou os controlos devem mudar.

Padrões comuns de falha nos trabalhos de preparação para 2026

Em projetos DORA, NIS2, RGPD da UE e ISO/IEC 27001:2022, as mesmas fragilidades surgem repetidamente:

• Apetite sem limiares, quando o Conselho de Administração aprova uma declaração mas ninguém consegue dizer quando foi violada.
• Limiares sem autoridade, quando existem níveis de severidade mas os donos dos riscos podem aceitar exceções sem aprovação superior.
• Risco legal fora do modelo de pontuação, quando RGPD da UE, DORA, NIS2 e contratos são listados separadamente mas não integrados nos critérios de impacto.
• Tolerância a prestadores ausente do dossiê do Conselho de Administração, mesmo quando as dependências críticas de TIC são conhecidas pela aquisição ou pela TI.
• Revisão pela gestão como teatro, quando são apresentados slides mas decisões, ações, necessidades de recursos e aceitações de risco não são documentadas.
• Fragmentação da evidência de auditoria, quando políticas, registos, KRI, relatórios de incidentes, revisões de prestadores e atas do Conselho de Administração existem em locais diferentes sem referência cruzada.

A abordagem da Clarysec foi concebida para eliminar estas lacunas. O Zenith Blueprint fornece o percurso faseado de implementação. A Política de Gestão de Riscos e a Política de Gestão de Riscos para PME fornecem cláusulas de governação ajustadas a ambientes empresariais e PME. O Zenith Controls mapeia a espinha dorsal de controlos entre política de segurança da informação, responsabilidade da gestão e requisitos legais ou regulamentares, tornando a evidência reutilizável em ISO/IEC 27001:2022, DORA, NIS2, RGPD da UE, NIST CSF e garantia baseada em COBIT.

Transforme a intenção do Conselho de Administração em governação auditável do risco de TIC

Se a sua organização tem um registo de riscos mas não consegue demonstrar um apetite ao risco de TIC aprovado pelo Conselho de Administração, limiares de tolerância mensuráveis, critérios de escalonamento e regras formais de aceitação, a lacuna não é cosmética. Afeta a governação DORA, a responsabilização da gestão NIS2, a defensabilidade do artigo 32 do RGPD da UE e a preparação para auditoria ISO/IEC 27001:2022.

Um próximo passo prático é realizar um workshop de apetite ao risco de TIC focado, utilizando o conjunto de ferramentas da Clarysec:

1. Use o Zenith Blueprint passo 10 para definir critérios de risco e escalas de impacto.
2. Use o Zenith Blueprint passo 13 para ligar opções de tratamento, risco residual e aprovação da Declaração de Aplicabilidade.
3. Use o Zenith Blueprint passo 14 para cruzar obrigações do RGPD da UE, NIS2 e DORA.
4. Use o Zenith Blueprint passo 28 para levar apetite, KRI, riscos aceites e decisões sobre recursos para a revisão pela gestão.
5. Aplique a Política de Gestão de Riscos ou a Política de Gestão de Riscos para PME para formalizar regras de aprovação e aceitação.
6. Use o Zenith Controls para mapear controlos de governação para evidência de auditoria e expectativas de conformidade transversal.

A Clarysec pode ajudá-lo a converter artefactos de risco dispersos num modelo de apetite ao risco de TIC aprovado pelo Conselho de Administração e preparado para o regulador, que as suas equipas podem utilizar quando a próxima indisponibilidade de serviços de computação em nuvem, falha de prestador, divulgação de vulnerabilidade ou incidente com dados pessoais testar a tolerância real da organização.