Cyber Resilience Act · 2026/2027

Resposta a incidentes CRA: proprietários, prazos e evidências de relatórios

Autor: Piotr AdamskiRevisão operacional e de segurança: Brillnet C-Team

Conteúdo informativo. Não substitui aconselhamento jurídico individual nem avaliação de conformidade.

Verifique o âmbito do CRA e descarregue a avaliação

Desde 11 de setembro de 2026, os fabricantes abrangidos pelo CRA têm de notificar vulnerabilidades ativamente exploradas e incidentes graves que tenham impacto na segurança dos produtos com elementos digitais. O alerta precoce deve ser apresentado no prazo de 24 horas após a tomada de conhecimento e a notificação completa no prazo de 72 horas.

O principal risco operacional não é a falta de um formulário. É a falta de um T0 acordado, de um responsável pela decisão, de cobertura de substituição, de fontes de informação fiáveis e de um registo que explique por que motivo o evento foi classificado de determinada forma.

Calendário de notificação

Etapa Prazo O que controlar
Tomada de conhecimento T0 data e hora, fonte da informação e pessoa que a recebe
Alerta precoce no prazo de 24 h informação exigida pelo CRA/SRP nesta etapa
Notificação completa no prazo de 72 h informação adicional sobre o evento e o impacto
Relatório final — vulnerabilidade ativamente explorada o mais tardar 14 dias após a disponibilização de uma medida corretiva correção e resultado do tratamento
Relatório final — incidente grave no prazo de 1 mês após a notificação de 72 horas evolução do incidente, impacto, ações e resultado

Verifique sempre as instruções atuais da plataforma única de notificação do CRA. As orientações operacionais e o portal podem evoluir mais depressa do que o próprio regulamento.

Nem todas as vulnerabilidades desencadeiam uma notificação ao abrigo do artigo 14

O CRA refere-se a uma vulnerabilidade ativamente explorada, e não a todas as deteções produzidas por uma ferramenta de análise. Da mesma forma, «incidente grave» é um conceito regulamentar, e não um sinónimo de qualquer pedido de segurança marcado como prioritário.

Um bom fluxo de trabalho separa:

  1. deteção ou receção da informação;
  2. triagem técnica;
  3. avaliação dos critérios regulamentares;
  4. decisão por uma pessoa responsável;
  5. preparação da notificação;
  6. apresentação pelo canal adequado;
  7. correção, acompanhamento e relatório final.

Classificar automaticamente uma deteção como «sujeita a notificação CRA» sem aprovação humana cria tanto o risco de falsos positivos como o de omissão de notificações.

Defina a responsabilidade antes de começar a contagem

Uma função chamada «Equipa de segurança» não basta. Para cada produto, identifique:

  • quem recebe informação sobre vulnerabilidades ou incidentes;
  • quem faz a triagem técnica;
  • o responsável pelo produto;
  • quem aprova a classificação regulamentar;
  • quem apresenta a notificação através da SRP;
  • um substituto para cada função com prazos críticos;
  • qualquer via de escalonamento fora do horário de trabalho exigida pelo produto e pelo modelo operacional.

Se uma pessoa acumula várias funções, registe-o explicitamente. As equipas pequenas podem funcionar; a responsabilidade ambígua não.

O que registar no T0

Crie o primeiro registo antes de a discussão se centrar em saber se o evento é «realmente grave». Conserve, no mínimo:

  • a hora exata da tomada de conhecimento;
  • a fonte da informação;
  • o produto e a versão;
  • o notificante ou sistema de deteção;
  • uma descrição sucinta do que foi observado;
  • a pessoa que recebeu a informação;
  • uma ligação ao artefacto de origem ou às provas.

Sem esse registo, várias horas depois a organização poderá não conseguir determinar quando começou efetivamente a contagem do prazo legal.

Uma sequência operacional prática

1. Registar

Abra um processo e conserve a comunicação original. Não substitua a fonte à medida que a compreensão do evento evolui.

2. Fazer a triagem

Confirme o produto afetado, a versão, o âmbito técnico, os efeitos conhecidos e as provas disponíveis. Separe factos confirmados de hipóteses.

3. Classificar

Registe os argumentos a favor e contra a obrigação de notificação. A decisão deve identificar quem a aprovou e a hora da aprovação.

4. Apresentar o alerta de 24 horas

Prepare o alerta precoce com a informação disponível nesse momento. Não espere pela conclusão de uma análise da causa raiz quando o prazo legal já está a decorrer.

5. Apresentar a notificação de 72 horas

Complete a informação exigida pelo processo atual da SRP.

6. Corrigir e comunicar

Ligue o trabalho de engenharia, as versões, as atualizações de segurança e a comunicação com os clientes ao mesmo processo.

7. Concluir o relatório final

Encerre o fluxo apenas quando o resultado, as ações, as provas de verificação e o relatório final exigido estiverem registados.

Exercite o processo antes de um evento real

Utilize um cenário realista, mas hipotético, e verifique:

  • se a equipa sabe onde criar o registo;
  • se é possível identificar o T0;
  • se é conhecida a pessoa que aprova;
  • se existe cobertura de substituição;
  • se os dados do produto e dos registos técnicos podem ser recolhidos rapidamente;
  • se a pessoa que apresenta a notificação tem acesso funcional à SRP;
  • se o exercício deixa um registo de decisão e ações de melhoria.

O papel do Pulsar GRC

O Pulsar pode ligar o incidente ou a vulnerabilidade a riscos, ações, responsáveis, documentos, provas, relatórios e histórico de decisões. Os riscos, tarefas, documentos, provas e relatórios conservam o contexto das respostas e das decisões.

A sua organização avalia se o artigo 14 se aplica, aprova a notificação e apresenta-a à SRP pelo canal adequado. Preparar registos no Pulsar não substitui a apresentação de uma notificação.

Veja o Pulsar GRC num fluxo operacional

Orientações relacionadas

Exercício proposto: um aviso chega durante uma ausência

Imagine um fabricante de um dispositivo de controlo com uma aplicação associada. Um investigador envia informação sobre possível acesso não autorizado numa sexta-feira. A pessoa que costuma verificar o endereço publicado está de férias. Engenharia encontra a mensagem apenas na segunda-feira. O cenário é hipotético e serve para testar receção e substituição; não determina, por si só, se existe uma obrigação de notificação.

Comece por conservar a mensagem e os registos de receção. Distinga a hora de chegada, a hora de leitura e o momento de tomada de conhecimento relevante para a avaliação jurídica. Não assuma que o momento de criação de uma tarefa representa automaticamente esse início. A pessoa competente regista o fundamento e as incertezas. Utilize uma referência temporal comum e preserve informação suficiente para reconstruir a sequência.

O substituto identifica produto e versão. Se o aviso mencionar uma biblioteca utilizada em vários produtos, ligue a fonte comum a avaliações específicas. A mesma vulnerabilidade pode ter efeitos diferentes conforme funções, configuração e componente distribuído. Essa diferença exige evidência técnica. Copiar a conclusão do primeiro produto para os restantes pode ocultar exposição real ou gerar classificações erradas.

Objetivos internos e prazos legais têm funções diferentes

Os prazos legais acima exigem um processo capaz de atuar a tempo. A organização pode definir objetivos internos mais curtos para confirmar receção, reunir responsáveis e resolver dúvidas sobre o canal. São decisões operacionais propostas, não novos prazos CRA. Registe essa distinção para que a equipa não confunda uma meta interna com uma obrigação do regulamento.

Evite uma regra que obrigue a esperar por toda a informação antes de decidir. Num evento real haverá perguntas abertas. O registo separa factos confirmados, estimativas e hipóteses. Quem aprova verifica se o texto reflete o conhecimento disponível e o que falta esclarecer. A falta de um dado não deve transformar-se automaticamente numa razão para atrasar uma comunicação exigida.

Também separe vocabulário técnico e classificação normativa. Uma vulnerabilidade pode ter elevada gravidade sem haver evidência de exploração ativa. Uma prioridade alta numa ferramenta interna não demonstra um incidente grave na aceção jurídica. Conserve a informação que sustenta cada conclusão, incluindo limitações. Um rumor ou uma pontuação isolada não deve converter-se numa afirmação definitiva por aparecer num resumo bem escrito.

Um dossier que o substituto consiga utilizar

Para cada produto, mantenha identificação do fabricante, responsáveis autorizados, contactos de engenharia e procedimentos de publicação. A ficha tem data de verificação e indica quem substitui cada função crítica. Teste acesso e disponibilidade através de meios permitidos, sem enviar notificações fictícias para um canal oficial de produção. Uma conta criada anteriormente não prova que hoje permite apresentar informação.

Identifique documentos necessários para compreender o evento: descrição do produto, versões suportadas, arquitetura pertinente e política de vulnerabilidades. Pode utilizar referências estáveis em vez de duplicar todo o material. A pessoa autorizada deve conseguir abrir a fonte certa e perceber a sua relação com o caso. Um link para uma pasta sem versão não garante essa capacidade.

Para informação sensível, conserve acesso adequado e prepare comunicações revistas. Detalhes que facilitem exploração não devem seguir inadvertidamente para uma lista comercial. A revisão deve considerar destinatário, finalidade e conteúdo necessário. Preserve relação entre o original e qualquer versão destinada a partilha.

Notificação oficial e comunicação ao utilizador

Os dois percursos podem ter conteúdo, responsáveis e canais distintos. Ligue-os ao mesmo caso para detetar contradições, mas não considere que uma mensagem ao cliente substitui a apresentação oficial. Registe o que foi comunicado, quando, por quem e a quem. Uma atualização deve permitir localizar a comunicação anterior a que se refere.

Quando surge uma correção, engenharia confirma versão e ensaios. Produto verifica instruções e utilizadores afetados. A função competente avalia informação adicional e seguimento exigido. Fechar a tarefa técnica não encerra automaticamente o dossier regulatório. A decisão de fecho identifica o que se verificou e o que ainda permanece aberto.

Critérios de aceitação do procedimento

Teste receção incompleta, ausência do titular e revisão de uma classificação inicial. Inclua um problema de acesso ao canal, conservando evidência de tentativas e consultando orientações oficiais aplicáveis. Não invente uma via alternativa nem assuma que enviar por qualquer endereço satisfaz a obrigação. O exercício deve revelar onde a organização precisa de preparar contactos ou decisões.

Peça a uma pessoa que não redigiu o procedimento reconstruir o caso. Deve localizar fonte, cronologia, decisão, evidência de apresentação quando aplicável e próxima ação. Se depender de instruções verbais, identifique a informação em falta e atribua uma melhoria. O objetivo é encontrar fragilidades antes do evento real, não produzir uma simulação confortável.

Assistência de IA com revisão humana

Uma ferramenta de IA pode ajudar a ordenar a cronologia ou preparar um rascunho com fontes fornecidas. A pessoa que revê confirma produto, versão, horas, classificação e destinatários. Uma inferência apresentada com confiança continua a ser uma inferência. O rascunho não decide autonomamente tomada de conhecimento, exploração ativa nem apresentação externa.

Conserve aprovação e alterações materiais quando ajudam a explicar a decisão. O Pulsar organiza documentação, riscos, ações e historial; o fabricante mantém avaliação e apresentação pelo canal oficial. O exercício fica concluído quando outra pessoa consegue compreender o percurso com os registos disponíveis. Essa capacidade é verificável; uma política assinada, isoladamente, não a demonstra.

Ensaie um incidente sem fazer um registo real

Escolha um produto fictício que seu exercício pressupõe estar dentro do escopo do CRA. Se o exemplo incluir SaaS ou back-end, documente por que isso é relevante para esse produto; não presuma que todos os serviços somente de navegador se enquadram no CRA. Use uma notificação sintética recebida fora do horário comercial, uma constatação técnica e uma decisão que precise de um revisor autorizado.

Registre quando os participantes do exercício tomarem conhecimento dos fatos e distinguir esse ponto da abertura de um ticket. Designe o investigador, o responsável pela decisão e o substituto. Acompanhe quais fatos estão apurados e quais permanecem sob análise. Os prazos do artigo 14.º referem-se às condições aplicáveis de tomada de conhecimento e notificação e não apenas ao momento em que um gestor abre o registo.

Mantenha o ramo de vulnerabilidade ativamente explorado separado do ramo de incidente grave. As condições do relatório final são diferentes: o relatório de vulnerabilidade inclui um prazo ligado à disponibilidade de uma medida corretiva ou mitigadora, enquanto o ramo de incidentes graves tem o seu próprio cronograma de relatório final. Use o texto legal atual e as orientações oficiais para relatórios do caso identificado.

No Pulsar, prepare as ações do exercício, proprietários, prazos e evidências sintéticas. Registre uma decisão do revisor e qualquer informação faltante. Verifique o estado final após salvar. O resultado útil é um ensaio documentado que expõe a falta de um substituto ou de uma exigência de evidência antes que um evento real ocorra.

Não envie um exercício à ENISA, a um CSIRT ou a um cliente real. O registo da Pulsar não é um recibo oficial e o período de teste público não promete reporte automático às autoridades. Mantenha um envio real, seu canal oficial e recebimento como ações separadas em um incidente real. Revise a forma de pagamento e os termos de cancelamento do teste de 14 dias antes de se registrar.

Fontes

CRA para SaaS: escopo, ações próprias e evidências

Vulnerabilidades de componentes IoT: fornecedores, decisões e correções

KSC/NIS2 polaco para fornecedores de TI: avaliação e registo de ações