Ciber-resiliência: preparar produtos para o CRA

O Regulamento Ciber-Resiliência (CRA) não fica implementado quando se acrescenta um requisito a uma folha de cálculo. Uma equipa de produto tem de saber a que produto se aplica o requisito, quem é responsável pelo trabalho, qual é o prazo, por que motivo foi tomada uma decisão e onde se encontram as provas.

As obrigações de notificação do CRA aplicam-se desde 11 de setembro de 2026. A parte principal do regulamento aplicar-se-á a partir de 11 de dezembro de 2027. Por isso, uma parte do modelo operacional tem de funcionar já, enquanto a restante deve ser construída a tempo de evitar a reconstrução da documentação técnica no final.

Datas essenciais do CRA

Data	O que muda
11 de setembro de 2026	Aplicam-se as obrigações de notificação do artigo 14
11 de dezembro de 2027	Aplicam-se as principais obrigações do CRA

Para os eventos sujeitos a notificação, a contagem começa quando o fabricante toma conhecimento. A Comissão descreve um alerta precoce no prazo de 24 horas e uma notificação completa no prazo de 72 horas. O prazo do relatório final difere entre uma vulnerabilidade ativamente explorada e um incidente grave.

Consulte o fluxo prático de notificação CRA em 24/72 horas

O CRA diz respeito a um produto, e não a uma pontuação abstrata de conformidade de toda a empresa

A primeira pergunta útil é: que produto concreto com elementos digitais estamos a avaliar?

O regulamento abrange produtos de software e hardware e, em condições definidas, as suas soluções de tratamento remoto de dados. O papel da organização também é relevante: fabricante, mandatário, importador, distribuidor ou interveniente que realiza uma modificação substancial.

Comece com um registo de um produto:

nome do produto e identificador único;
versão ou família de versões;
fabricante e marca sob a qual o produto é disponibilizado;
forma como é disponibilizado no mercado da UE;
finalidade prevista e funções principais;
componentes e dependências;
serviços remotos necessários às funções do produto;
período de apoio;
pessoas responsáveis pela segurança do produto, vulnerabilidades e versões.

Veja como avaliar o âmbito de aplicação do CRA a um produto

Sete áreas que têm de estar ligadas

1. Âmbito de aplicação

Determine se o produto e o papel da organização estão abrangidos pelo CRA. Uma designação como «SaaS», «IoT» ou «software» não é uma avaliação do âmbito de aplicação.

2. Risco do produto

Os requisitos do CRA estão ligados a uma avaliação dos riscos de cibersegurança do produto. Essa avaliação deve permanecer associada a uma versão do produto e ser revista quando a arquitetura, a finalidade prevista ou o risco se alteram.

3. Segurança desde a conceção e por defeito

Um requisito tem de se transformar em trabalho de engenharia: decisão de conceção, ação, responsável, teste, revisão e prova.

Consulte a segurança desde a conceção no CRA

4. Vulnerabilidades e SBOM

O CRA exige que os fabricantes identifiquem e documentem as vulnerabilidades e os componentes dos produtos, incluindo através da elaboração de uma lista de materiais de software (SBOM) num formato de uso corrente e legível por máquina, que cubra pelo menos as dependências de nível superior.

Veja por que motivo uma SBOM é uma entrada do processo, e não o resultado final

5. Notificação

A plataforma única de notificação (SRP) do CRA está operacional desde 11 de setembro de 2026. Na prática, um fabricante precisa de mais do que acesso ao portal: um T0 claro, critérios de escalonamento, um responsável que responda pela decisão, cobertura de substituição e a informação necessária para apresentar uma notificação.

6. Documentação técnica

A documentação técnica não deve ser um arquivo de ficheiros sem ligação entre si. Tem de tornar rastreáveis o produto, a versão, a arquitetura, a avaliação do risco, o tratamento de vulnerabilidades, os testes, as decisões e o fundamento do período de apoio.

Consulte uma estrutura prática de documentação técnica CRA

7. Período de apoio

O fabricante determina um período de apoio com base na utilização prevista e nos critérios estabelecidos no CRA. Regra geral, é de pelo menos cinco anos, salvo se for previsto que o produto seja utilizado durante um período mais curto.

Veja como documentar o período de apoio

Onde se enquadra o Pulsar GRC

O inquérito CRA da ENISA às PME de 2026 ilustra a distância entre conhecimento e execução. Numa amostra voluntária de 194 respostas, 66% conheciam o CRA, enquanto 54% declararam ter conhecimentos limitados ou inexistentes sobre a avaliação da conformidade e 42% sobre a documentação exigida. O apoio à documentação técnica foi selecionado por 73% dos participantes.

O inquérito não deve ser tratado como uma estimativa representativa de todo o mercado da UE: é uma amostra pequena e voluntária. Ainda assim, é útil como sinal de que o problema não é simplesmente «saber que o CRA existe». As equipas precisam de processos operacionais repetíveis.

O Pulsar GRC liga trabalho que está frequentemente disperso por documentos, folhas de cálculo, pedidos de trabalho e e-mails:

requisito → risco → controlo ou ação → responsável → prazo → documento ou prova → revisão → histórico de decisões.

O Pulsar liga auditorias, controlos, riscos, documentos, provas, relatórios, CAPA, fornecedores e tarefas. Isso é útil para executar e demonstrar um processo sem apresentar o software como quem faz a determinação jurídica pelo cliente.

O Pulsar não certifica a conformidade com o CRA, não substitui uma avaliação jurídica nem decide autonomamente se um evento tem de ser notificado. As decisões sobre o âmbito, a classificação regulamentar e a apresentação da notificação permanecem com pessoas responsáveis.

Comece com um produto

Não comece com um programa chamado «implementar o CRA em toda a empresa». Escolha um produto real. Defina o seu âmbito, responsáveis, riscos atuais, fluxo de tratamento de vulnerabilidades, documentação e período de apoio. É aí que se tornam visíveis as lacunas que podem dar origem a ações.

Veja o Pulsar GRC num fluxo operacional

Plano de trabalho proposto: começar por um produto real

Escolha um produto conhecido pela equipa e relevante para a atividade. Um protótipo vazio pode facilitar preenchimento e não testar nenhuma dificuldade. O piloto inclui versão utilizada, responsáveis e uma alteração recente. As atividades seguintes são uma proposta organizativa; não substituem requisitos do regulamento nem uma avaliação individual.

Produto e engenharia acordam funções, componentes fornecidos, elementos remotos e distribuição. A função responsável revê papel da empresa e questões abertas. O resultado é uma ficha com factos e dúvidas específicas. «Implementar CRA» não permite atribuir uma ação concreta. «Confirmar responsabilidade de desenvolvimento do backend» permite.

Reveja depois gestão de vulnerabilidades. Localize canal publicado, quem o acompanha e o que acontece numa ausência. Prepare uma cronologia hipotética e identifique informação necessária à decisão. Não envie notificação fictícia a um canal oficial de produção. Teste contactos e registos internos por meios adequados.

Prioridade baseada em efeito e dependência

Uma lista grande de lacunas pode paralisar uma pequena equipa. Classifique cada uma por consequência e trabalho que bloqueia. Ausência de responsável de receção pode afetar um evento atual. Arquitetura desconhecida impede risco e documentação. Um índice com apresentação imperfeita pode ter prioridade menor se fontes pertinentes já se localizam e revêm.

Conserve fundamento da prioridade e atualize-o quando mudam factos. O título regulatório de uma tarefa não demonstra urgência sozinho. Uma obrigação vigente também não pode ser adiada só por ser difícil. Direção precisa de conhecer falta de capacidade e decisões materiais que exigem recurso ou mudança.

Escreva uma saída verificável para cada ação. «Preparar documentos» pode tornar-se «identificar arquitetura da versão, obter revisão de engenharia e ligar à ficha». Atribua uma pessoa responsável pelo resultado, embora várias funções contribuam. Um departamento não explica quem atua quando falta revisão ou surge contradição.

Calendário que distingue obrigações

Separe trabalho já aplicável de preparação de requisitos principais posteriores. Cada entrada indica fonte, data de aplicação e responsável. Uma previsão interna não é prazo legal. Uma data legal não é recomendação opcional. Quando uma orientação pode mudar, conserve data de consulta e o pressuposto que depende dela.

A cadência de revisão ajusta-se ao processo. Reuniões semanais podem ajudar numa preparação, enquanto outras atividades têm ritmos diferentes. Não é uma exigência universal CRA. O importante é que mudanças e eventos cheguem a quem decide. Um calendário mensal não serve de resposta a um evento com prazo curto.

Simulação: uma nova dependência numa publicação

Suponha que se acrescenta biblioteca para uma função pedida pelo cliente. Inventário, risco, provas, instruções e suporte podem precisar de revisão. Se cada área atualiza ficheiros sem referência comum, o dossier pode descrever produtos diferentes. O piloto verifica se a alteração ativa os registos pertinentes antes de publicar.

Engenharia fornece identificadores e resultados. Produto confirma finalidade e informação ao utilizador. Segurança avalia riscos e vulnerabilidades. A função responsável revê provas e lacunas. A aprovação conserva âmbito e condições. A IA pode resumir contribuições, mas uma pessoa verifica versões e distingue trabalho planeado de execução.

Após publicação, conserve índice aplicável à entrega. Não precisa de copiar todas as ferramentas para o Pulsar. Pode manter referência estável e documentos pertinentes. Um link que mostra sempre «atual» sem permitir reconstruir a versão anterior não demonstra o que se reviu naquela entrega.

Medir capacidade em vez de preenchimento

Proponha provas simples. Outra pessoa encontra decisão de âmbito? O substituto reconstrói aviso? Engenharia localiza SBOM de versão fornecida? A data anunciada coincide com suporte aprovado? Essas respostas descrevem funcionamento. Percentagem de campos completos pode ocultar dados incorretos ou antigos.

Registe lacunas de cada teste, responsável e saída. Se é difícil localizar, reveja identificadores ou acesso. Se a evidência não demonstra o controlo, procure verificação adequada. São mecanismos diferentes. Acrescentar documentos gerais não resolve automaticamente nenhum deles.

Uma prova limitada não demonstra conformidade completa nem autoriza extensão a todas as ofertas. Antes de ampliar, identifique diferenças de arquitetura, operadores e ciclo de vida. O que se observou num produto pode ser uma aprendizagem útil; precisa de confirmação onde os factos mudam.

Resultado do primeiro piloto

O piloto demonstra se a organização liga produto, requisito, decisão e prova. Também revela trabalho técnico ou jurídico que o software não executa. Conserve resultados observados e limitações. Não trate intenção de uso como capacidade comprovada nem apresente poupança sem medir o trabalho substituído.

Utilize documentos autorizados e confirme direitos sobre padrões protegidos antes do tratamento previsto. A IA prepara rascunhos sujeitos a aprovação humana. No final, compare o processo com o anterior através de ações observáveis: localizar evidência, atribuir tarefa e reconstruir aprovação. A utilidade decide-se por esses resultados e pelo esforço de manutenção, não por uma promessa genérica de eficiência.

Fontes

Fontes verificadas: 12 de setembro de 2026.