Guia de preparação para a comunicação de vulnerabilidades ao abrigo do CRA da UE em 2026

São 08:17 de uma segunda-feira de setembro de 2026. Anna, CISO de uma empresa europeia de SaaS em rápido crescimento, continua a pensar na reunião do conselho de administração da semana anterior. O CEO tinha colocado a pergunta que todos os responsáveis de segurança estão agora a ouvir: “Se já nos preparámos para a NIS2 e os nossos clientes fintech continuam a pedir-nos informação sobre DORA, o que muda com o Cyber Resilience Act?”

Depois, a resposta chega-lhe à caixa de entrada.

Um investigador independente comunica uma vulnerabilidade explorável remotamente num componente de atualização de firmware utilizado por um dos produtos conectados da empresa. A mensagem inclui uma prova de conceito, o nome de uma dependência e um aviso de que foi observada exploração semelhante em ambiente real.

Em poucos minutos, todos querem uma resposta diferente. O CTO pergunta se a vulnerabilidade é real. O departamento jurídico pergunta se foi desencadeada uma obrigação de comunicação ao abrigo do Cyber Resilience Act da UE. A equipa de produto pergunta que versões são afetadas. A CISO pergunta se a dependência consta de alguma SBOM. A equipa comercial pergunta se os clientes do setor financeiro precisam de evidência para DORA. O gestor de conformidade abre o Registo de Riscos da ISO 27001 e encontra um processo de gestão de vulnerabilidades, mas nenhum caminho claro de decisão para a comunicação de vulnerabilidades de produto.

Este é o verdadeiro problema da preparação para o CRA. A maioria das organizações não parte do zero. Já possui políticas de resposta a incidentes, rotinas de gestão de patches, práticas de desenvolvimento seguro, revisões de fornecedores, ferramentas de análise de vulnerabilidades e evidência ISO 27001. Mas o CRA não recompensa documentos isolados. Exige um fluxo de trabalho rápido e defensável, capaz de responder simultaneamente a cinco perguntas:

1. Trata-se de uma vulnerabilidade explorada ativamente ou de um incidente grave que afeta a segurança do produto?
2. Que produtos, versões, clientes, dependências e fornecedores são afetados?
3. Que autoridade, cliente ou destinatário contratual deve ser notificado, e quando?
4. Que evidência demonstra que a triagem, a mitigação e a divulgação foram controladas?
5. Como se alinha isto com a ISO/IEC 27001:2022, NIS2, DORA, RGPD da UE, NIST CSF e as expectativas de auditoria?

A resposta não é uma “pasta CRA” separada. A resposta é integrar a comunicação de vulnerabilidades do CRA no SGSI, no processo de Divulgação Coordenada de Vulnerabilidades, na disciplina de SBOM, na governação de fornecedores e na cadeia de evidência de resposta a incidentes de que já necessita para uma governação madura da cibersegurança.

Porque é que o Cyber Resilience Act da UE altera o modelo de comunicação

O Cyber Resilience Act da UE, Regulamento (UE) 2024/2847, coloca a segurança dos produtos no centro da conformidade. Aplica-se a produtos com elementos digitais colocados no mercado da UE, o que pode incluir dispositivos conectados, software, firmware, sistemas incorporados e produtos de software empresarial.

A mudança operacional mais relevante para CISO, responsáveis de segurança de produto e equipas de conformidade começa em 11 de setembro de 2026. O Article 14 do CRA exige comunicação faseada para vulnerabilidades exploradas ativamente e incidentes graves que afetem a segurança de produtos com elementos digitais. Em termos práticos, os fabricantes devem estar preparados para:

A avaliação jurídica exata deve ser sempre realizada por assessoria qualificada, mas a lição operacional é clara. As primeiras 24 a 72 horas só serão tão boas quanto a preparação concluída nos meses anteriores.

Se as suas SBOM estiverem incompletas, se a caixa de entrada de CVD for monitorizada informalmente, se os contratos com fornecedores não exigirem notificação de vulnerabilidades, ou se a sua Política de Resposta a Incidentes não distinguir a comunicação de vulnerabilidades de produto de incidentes de privacidade ou operacionais, o relógio legal avançará mais depressa do que o seu processo de evidência.

Use a ISO/IEC 27001:2022 como estrutura de base para a preparação para o CRA

A ISO/IEC 27001:2022 não substitui o cumprimento legal do CRA, mas é a melhor estrutura de sistema de gestão para integrar as obrigações do CRA na governação diária.

As cláusulas 4.1 a 4.4 exigem que a organização compreenda o contexto interno e externo, as partes interessadas, os requisitos, as interfaces com outras organizações e o âmbito do SGSI ISO/IEC 27001:2022. Para a preparação para o CRA, isto significa que o âmbito do SGSI deve identificar produtos com elementos digitais, responsabilidades do ciclo de vida do produto, componentes alojados, pipelines de compilação, dependências open source, fornecedores, utilizadores, importadores, distribuidores, clientes regulados e autoridades relevantes.

As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos e tratamento de riscos, incluindo proprietários do risco, consequências, probabilidade, decisões de tratamento, Declaração de Aplicabilidade e aceitação do risco residual. A comunicação ao abrigo do CRA deve ser tratada como um cenário de risco de segurança do produto dentro desse processo, e não como um exercício de interpretação jurídica de emergência.

A ISO/IEC 27002:2022 ISO/IEC 27002:2022 fornece depois a estrutura prática de controlos. Os controlos mais importantes para a comunicação de vulnerabilidades do CRA são:

Em Zenith Controls: The Cross-Compliance Guide, a Clarysec mapeia o controlo 8.8 da ISO/IEC 27002:2022, Gestão de vulnerabilidades técnicas, como um controlo preventivo que apoia a confidencialidade, integridade e disponibilidade. Os seus atributos alinham-se com os conceitos de cibersegurança Identificar e Proteger, tendo a gestão de ameaças e vulnerabilidades como capacidade operacional.

Este enquadramento é importante. A comunicação do CRA não se limita a notificar autoridades. Trata-se de provar que existia uma capacidade preventiva de gestão de vulnerabilidades antes de a necessidade de comunicação surgir.

Construa o modelo operacional em torno de CVD, SBOM e do relógio de comunicação

Um fluxo credível de vulnerabilidades CRA começa antes de qualquer investigador contactar a organização. Começa com a capacidade de receber comunicações de vulnerabilidades, validá-las, identificar componentes afetados, avaliar a exploração, coordenar a mitigação, comunicar com utilizadores e preservar evidência.

O primeiro bloco de construção é um canal público de comunicação de vulnerabilidades. A Política de Divulgação Coordenada de Vulnerabilidades da Clarysec, cláusula 6.1 dos Requisitos de implementação, estabelece:

Canais de divulgação pública: A organização deve manter um canal claro para comunicação de vulnerabilidades, como um endereço de correio eletrónico dedicado para contacto de segurança (por exemplo, security@company.com) ou um formulário web. Esta informação deve ser publicada na página de segurança do website da empresa, juntamente com a chave pública PGP da organização, para permitir submissões cifradas.

Isto resolve uma falha comum em auditoria. Muitas empresas afirmam aceitar comunicações de vulnerabilidades, mas o caminho de comunicação está escondido, não é gerido ou é encaminhado através de uma fila geral de suporte. Em contexto CRA, o canal de comunicação torna-se o ponto que desencadeia a tomada de conhecimento jurídico, a avaliação de severidade e a captura de evidência.

O segundo bloco de construção é a triagem. A Política de Divulgação Coordenada de Vulnerabilidades, cláusula 6.4 dos Requisitos de implementação, estabelece:

Triagem e confirmação de receção: Após receção de uma comunicação, a ERV deve registá-la e enviar uma confirmação ao autor da comunicação no prazo de 2 dias úteis, atribuindo uma referência de rastreio. A ERV deve realizar uma avaliação preliminar de severidade, por exemplo usando pontuação CVSS, e validar a questão, incluindo com apoio das equipas de TI e desenvolvimento quando necessário, no prazo-alvo de 5 dias úteis. Vulnerabilidades críticas, como as que permitem execução remota de código ou uma violação de dados de maior impacto, devem ser aceleradas.

Para a preparação para o CRA, esse registo de triagem deve ser alargado com campos que sustentem a decisão jurídica de comunicação:

O terceiro bloco de construção é a disciplina de SBOM. A Política de Desenvolvimento Seguro da Clarysec, cláusula 5.4 dos Requisitos de governação, estabelece:

A utilização de código open source ou de terceiros deve ser aprovada, acompanhada e validada através de: 5.4.1 Análise da composição de software (SCA) 5.4.2 Revisão de licenças (GPL, MIT, BSD, etc.) 5.4.3 Análise de vulnerabilidades conhecidas (CVE, OSS Index, etc.)

Para organizações mais pequenas, a Política de Requisitos de Segurança das Aplicações - PME da Clarysec, cláusula 6.4.2 dos Requisitos de implementação da política, define a mesma expectativa em termos práticos:

Deve ser mantido pelo programador ou prestador de TI um registo de cada componente externo utilizado, incluindo:

Esse registo de componentes torna-se o conjunto mínimo de evidência para resposta a vulnerabilidades orientada por SBOM. Deve ligar o nome do componente, versão, origem, fornecedor ou repositório, licença, versão do produto, data de compilação e estado da análise de vulnerabilidades. Quando chega um CVE, uma comunicação de investigador ou um aviso de fornecedor, a sua equipa deve conseguir responder em poucas horas: “Que produtos disponibilizados contêm este componente?”

Mapeie CRA, NIS2, DORA e RGPD da UE numa única matriz de decisão de notificação

O Cyber Resilience Act não funcionará isoladamente. Uma única vulnerabilidade de produto pode desencadear comunicação CRA, avaliação de incidente NIS2, obrigações de evidência para clientes DORA, avaliação de violação ao abrigo do RGPD da UE e deveres contratuais de notificação.

O Article 21 da NIS2 exige que entidades essenciais e importantes implementem medidas técnicas, operacionais e organizativas adequadas. Essas medidas incluem análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição, desenvolvimento e manutenção seguros, tratamento e divulgação de vulnerabilidades, avaliação de eficácia, higiene de cibersegurança, criptografia, segurança de recursos humanos, controlo de acesso, gestão de ativos, MFA e comunicações seguras.

O Article 23 da NIS2 estabelece um modelo faseado de comunicação de incidentes: alerta precoce no prazo de 24 horas após tomada de conhecimento, notificação de incidente no prazo de 72 horas, atualizações intermédias se solicitadas e relatório final no prazo máximo de um mês após a notificação do incidente. O Article 20 da NIS2 também cria responsabilização do órgão de gestão pela aprovação e supervisão das medidas de gestão de riscos de cibersegurança.

O DORA aplica-se desde 17 de janeiro de 2025 e cria um quadro uniforme de resiliência operacional digital da UE para entidades financeiras. Para prestadores SaaS, fornecedores de software e fornecedores de TIC, o DORA surge frequentemente através dos contratos com clientes. O seu cliente do setor financeiro pode ser a entidade regulada pelo DORA, mas o seu tratamento de vulnerabilidades, evidência de SBOM, apoio a incidentes, direitos de auditoria e compromissos de notificação podem ser necessários para esse cliente cumprir as suas próprias obrigações.

O RGPD da UE acrescenta outro ramo. Se a vulnerabilidade ou incidente causar destruição, perda, alteração, divulgação não autorizada ou acesso, acidentais ou ilícitos, a dados pessoais, é necessária uma avaliação de violação de dados pessoais. O Article 5 do RGPD da UE também inclui integridade, confidencialidade e responsabilização, o que significa que a organização deve conseguir demonstrar a sua tomada de decisão.

A Política de Resposta a Incidentes da Clarysec, cláusula 6.4.1 dos Requisitos de implementação da política, já apoia esta avaliação multirregime:

Se um incidente resultar em exposição confirmada ou provável de dados pessoais ou outros dados regulados, o Jurídico e o EPD devem avaliar a aplicabilidade de: 6.4.1.1 RGPD da UE Article 33 (notificação à autoridade de controlo no prazo de 72 horas) 6.4.1.2 RGPD da UE Article 34 (notificação aos titulares dos dados, quando exista risco elevado) 6.4.1.3 NIS2 Article 23 (notificação no prazo de 24 horas após tomada de conhecimento do incidente) 6.4.1.4 DORA Article 17 (comunicação de incidentes graves relacionados com TIC)

Para a preparação para o CRA, alargue este playbook para incluir a avaliação de comunicação prevista no CRA Article 14 para vulnerabilidades exploradas ativamente e incidentes graves que afetem a segurança do produto.

Uma matriz de decisão unificada impede que as equipas executem playbooks de comunicação separados e inconsistentes:

Para PME, a Política de Resposta a Incidentes - PME da Clarysec, cláusula 5.3.2 dos Requisitos de governação, expressa o mesmo princípio de forma mais simples:

Os prazos de resposta, incluindo recuperação de dados e obrigações de notificação, devem ser documentados e alinhados com os requisitos legais, como a obrigação de notificação de violação de dados pessoais no prazo de 72 horas prevista no RGPD da UE.

A preparação para o CRA apenas alarga esse princípio da notificação de violação de dados pessoais para a comunicação de vulnerabilidades de produto e incidentes de segurança do produto.

A evidência de fornecedores é agora evidência de segurança do produto

Muitas vulnerabilidades relevantes para o CRA terão origem fora da sua base de código. Podem vir de pacotes open source, módulos de firmware, SDK, interfaces de programação de aplicações alojadas, ferramentas de compilação, serviços na nuvem, componentes subcontratados ou bibliotecas a montante. Isto torna a governação de fornecedores central para a preparação para o CRA.

A cláusula 8.1 da ISO 27001:2022 exige que as organizações controlem processos, produtos ou serviços fornecidos externamente e relevantes para o SGSI. O controlo 5.21 da ISO/IEC 27002:2022, Gestão da segurança da informação na cadeia de fornecimento das TIC, fornece a âncora de controlo.

Em Zenith Controls, a Clarysec mapeia o controlo 5.21 como um controlo preventivo que apoia a confidencialidade, integridade e disponibilidade. A sua capacidade operacional é a segurança das relações com fornecedores, e os seus domínios incluem governação, ecossistema e proteção. O ponto é simples: controlos de fornecedores não são burocracia de aquisição. São controlos de proteção do ecossistema.

A Política de Segurança de Terceiros e Fornecedores - PME da Clarysec, cláusula 5.3 dos Requisitos de governação, define a base contratual:

Os contratos devem incluir cláusulas obrigatórias que cubram:

Para programas empresariais, o Zenith Blueprint: An Auditor’s 30-Step Roadmap, fase Controls in Action, Step 23, Organizational controls 5.19 a 5.37, explica o controlo 5.20 da ISO/IEC 27002:2022, Tratamento da segurança da informação em acordos com fornecedores:

A confiança, quando se trata de fornecedores, não pode assentar em pressupostos. Deve ser codificada.

Para a preparação para o CRA, os acordos com fornecedores devem incluir cláusulas de segurança do produto que apoiem uma resposta rápida a vulnerabilidades:

O DORA reforça a mesma direção. As entidades financeiras devem gerir o risco de terceiros TIC, manter registos de contratos de serviços TIC, avaliar criticidade, realizar diligência prévia, gerir risco de concentração, definir salvaguardas contratuais, assegurar direitos de auditoria e planear saídas. Se vende software ou serviços TIC a entidades financeiras, espere que os clientes perguntem se o seu processo de comunicação de vulnerabilidades e SBOM consegue apoiar as suas necessidades de evidência DORA em matéria de incidentes, resiliência e terceiros.

O fluxo de preparação CRA da Clarysec

A Clarysec ajuda os clientes a operacionalizar a comunicação CRA dentro de um SGSI alinhado com a ISO 27001:2022 através de um fluxo de trabalho prático.

1. Adicione as obrigações CRA ao registo de requisitos do SGSI

Comece pelas cláusulas 4.1 a 4.4 da ISO 27001:2022. Atualize o contexto organizacional, as partes interessadas e o âmbito para incluir produtos com elementos digitais, exposição ao mercado da UE, utilizadores, importadores, distribuidores, reguladores, CSIRT, fornecedores e clientes regulados.

Crie entradas no registo de requisitos para comunicação de vulnerabilidades CRA, comunicação CRA de incidentes graves de segurança do produto, notificação de incidentes NIS2, obrigações de apoio a clientes DORA, avaliação de violação de dados pessoais ao abrigo do RGPD da UE, notificação contratual de incidentes, compromissos CVD e comunicações com investigadores.

Isto dá aos auditores um caminho rastreável desde a obrigação externa até ao controlo interno.

2. Crie um formulário de receção de vulnerabilidades de produto

Baseie o formulário de receção na Política de Divulgação Coordenada de Vulnerabilidades. Deve capturar identidade do autor da comunicação, dados de contacto seguros, versão do produto, módulo, ambiente, prova de conceito, passos de reprodução, estado de exploração, potencial exposição de dados, impacto no serviço, correspondência de componente na SBOM, CVSS ou severidade equivalente, proprietário, referência de rastreio e ponto de verificação regulamentar.

O formulário deve criar automaticamente um ticket na fila de resposta a vulnerabilidades. Deve também iniciar um temporizador para decisão de notificação, mesmo que a resposta final seja “não comunicável”.

3. Ligue dados de SBOM a versões disponibilizadas

Para cada versão de produto disponibilizada, mantenha uma SBOM ou inventário equivalente de componentes. A evidência mínima útil inclui nome do componente, versão, origem, licença, fornecedor ou repositório, versão do produto, data de compilação e estado da análise de vulnerabilidades.

A Política de Desenvolvimento Seguro e a Política de Requisitos de Segurança das Aplicações - PME fornecem a base de política para SCA, revisão de componentes e registos de componentes externos.

4. Preserve evidência desde o primeiro dia

Cada ticket de vulnerabilidade relevante para o CRA deve reter:

• Comunicação original
• Carimbo temporal de confirmação de receção
• Notas de triagem
• Fundamentação da severidade CVSS ou equivalente
• Resultados de correspondência na SBOM
• Avaliação de exploração
• Registos, indicadores e snapshots forenses
• Comunicações com fornecedores
• Aceitação do risco, se a mitigação for adiada
• Plano de patch, notas de versão e evidência de testes
• Decisões de notificação a clientes e autoridades
• Entradas para relatório final e lições aprendidas

Isto alinha-se com a cláusula 8.1 da ISO 27001:2022, que exige informação documentada suficiente para evidenciar que os processos funcionaram conforme planeado, e com as cláusulas 8.2 e 8.3, que exigem resultados documentados da avaliação de riscos e do tratamento de riscos.

5. Teste com um cenário realista de dependência

Realize um exercício de simulação em mesa usando uma vulnerabilidade simulada de dependência explorada ativamente. Inclua engenharia, segurança, jurídico, privacidade, produto, comunicações, gestão de fornecedores e equipas orientadas para o cliente. O teste deve demonstrar que a sua organização consegue identificar versões afetadas, avaliar exploração, tomar uma decisão de notificação, contactar fornecedores, preparar orientações para utilizadores e preservar evidência.

Como os auditores irão testar a preparação para a comunicação de vulnerabilidades CRA

Uma revisão de preparação para o CRA raramente se limitará a uma checklist CRA. Auditores diferentes irão testar a mesma evidência através de diferentes referenciais.

Em Zenith Controls, a Clarysec mapeia o controlo 5.24 da ISO/IEC 27002:2022, Planeamento e preparação da gestão de incidentes de segurança da informação, como um controlo corretivo que apoia a confidencialidade, integridade e disponibilidade. Alinha-se com Responder e Recuperar, tendo a governação e a gestão de eventos de segurança da informação como capacidades operacionais.

Esse controlo é a ponte entre a descoberta de vulnerabilidades e a comunicação regulamentar.

O NIST CSF 2.0 é especialmente útil como camada de comunicação ao nível do conselho de administração. As suas funções GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND e RECOVER ajudam a explicar como a comunicação de vulnerabilidades de produto se integra na governação empresarial da cibersegurança, em vez de ficar como uma exceção de engenharia.

Falhas comuns de preparação para o CRA a corrigir antes de 2026

A Clarysec observa repetidamente as mesmas lacunas.

A primeira é CVD sem comunicação operacionalizada. A empresa tem um endereço de correio eletrónico de segurança ou ficheiro security.txt, mas não tem um caminho interno entre a comunicação de investigador e a avaliação jurídica de notificação.

A segunda é SBOM sem propriedade. A engenharia consegue gerar uma SBOM durante a compilação, mas ninguém é responsável pela exatidão dos produtos disponibilizados nem explica como as constatações da SBOM alimentam a resposta a vulnerabilidades.

A terceira é um certificado ISO sem âmbito de produto. O SGSI cobre a TI corporativa e as operações SaaS, mas não software incorporado, firmware, infraestrutura de atualização de produto, pipelines de compilação ou divulgação de vulnerabilidades.

A quarta são contratos de fornecedores sem cláusulas de vulnerabilidades. A aquisição exige confidencialidade e proteção de dados, mas não notificação de vulnerabilidades, transparência de componentes, assistência em incidentes, divulgação coordenada ou evidência de auditoria.

A quinta é resposta a incidentes sem lógica de vulnerabilidade de produto. O plano de incidentes cobre ransomware, phishing e violações de dados pessoais, mas não vulnerabilidades de produto exploradas ativamente em que os sistemas dos clientes podem estar em risco antes de o ambiente do próprio fabricante ser comprometido.

A sexta é evidência DORA para clientes tratada manualmente. Vendas ou sucesso do cliente respondem a questionários do setor financeiro caso a caso, enquanto a segurança não dispõe de um pacote de evidência padrão que demonstre tratamento de vulnerabilidades, governação de SBOM, apoio a incidentes e controlos de fornecedores.

Cada lacuna é corrigível. Cada uma se torna cara se for descoberta durante uma vulnerabilidade ativa.

Checklist de 90 dias para preparação da comunicação de vulnerabilidades CRA

Use os próximos 90 dias para estabelecer uma base defensável:

• Identificar produtos com elementos digitais colocados ou disponibilizados no mercado da UE.
• Atualizar o âmbito do SGSI e a análise de partes interessadas para incluir partes interessadas do CRA.
• Adicionar a avaliação de comunicação do CRA Article 14 ao registo de requisitos legais e regulamentares.
• Publicar e monitorizar um canal seguro de comunicação de vulnerabilidades.
• Criar uma Equipa de Resposta a Vulnerabilidades com papéis jurídicos, de produto, engenharia, segurança e comunicações.
• Manter SBOM ou inventários de componentes para versões de produto disponibilizadas.
• Ligar resultados de SCA a tickets de vulnerabilidade e versões de produto disponibilizadas.
• Adicionar critérios de exploração ativa e incidente grave de produto aos formulários de triagem.
• Criar uma matriz combinada de decisão de notificação para CRA, NIS2, DORA, RGPD da UE e contratos.
• Atualizar contratos de fornecedores com cláusulas de aviso de vulnerabilidade, SBOM, assistência em incidentes e coordenação de divulgação.
• Manter registos de patches e evidência de remediação.
• Testar o fluxo de trabalho com uma vulnerabilidade simulada de dependência explorada ativamente.
• Apresentar resultados à gestão com lacunas, riscos residuais e proprietários de remediação.
• Adicionar o pacote de evidência à auditoria interna e à revisão pela gestão.

A Política de Gestão de Vulnerabilidades e Patches - PME da Clarysec, cláusula 6.2.1 dos Requisitos de implementação da política, apoia a base de monitorização:

A função de TI deve monitorizar vulnerabilidades usando:

A mesma política, cláusula 5.4.1 dos Requisitos de governação, acrescenta o trilho de auditoria:

Deve ser mantido um registo de patches e revisto durante auditorias e atividades de resposta a incidentes

Esse registo de patches pode tornar-se um dos artefactos mais importantes num relatório final CRA. Demonstra descoberta, priorização, remediação, testes e encerramento.

Torne setembro de 2026 aborrecido

O melhor evento de comunicação CRA não é fácil porque a vulnerabilidade é simples. É fácil porque a organização já ensaiou o fluxo de trabalho.

Antes de setembro de 2026, a Clarysec pode ajudá-lo a transformar a comunicação de vulnerabilidades num sistema preparado para auditoria, mapeando o seu SGSI ISO 27001:2022 atual, processo CVD, capacidade SBOM, cláusulas de fornecedores e playbooks de resposta a incidentes face às expectativas do CRA, NIS2, DORA, RGPD da UE e NIST CSF.

Comece com uma avaliação focada de preparação para a comunicação de vulnerabilidades CRA. A Clarysec irá rever as suas políticas, evidência de SBOM, contratos de fornecedores, tickets de vulnerabilidade, playbooks de incidentes e trilho de auditoria. Depois, usaremos Zenith Blueprint e Zenith Controls para construir um roteiro prático de remediação, não um dossier teórico de conformidade.

Se já utiliza políticas Clarysec, iremos ajustá-las para a comunicação CRA. Se não utiliza, podemos ajudar a implementar o conjunto certo de políticas, incluindo a Política de Divulgação Coordenada de Vulnerabilidades, Política de Desenvolvimento Seguro, Política de Resposta a Incidentes, Política de Gestão de Vulnerabilidades e Patches - PME, Política de Requisitos de Segurança das Aplicações - PME e Política de Segurança de Terceiros e Fornecedores - PME, quando adequado.

Setembro de 2026 está suficientemente próximo para planear e suficientemente distante para uma preparação disciplinada. As organizações que atuarem agora não estarão a perguntar “Quem é responsável por esta vulnerabilidade?” durante as primeiras 24 horas. Já terão a resposta, a evidência e o caminho de comunicação.

Contacte a Clarysec para agendar uma avaliação de preparação para a comunicação de vulnerabilidades CRA e transformar a complexidade regulamentar numa vantagem defensável de segurança do produto.