Período de apoio CRA: definição, registo e gestão

O Regulamento Ciber-Resiliência exige que os fabricantes determinem um período de apoio para os produtos com elementos digitais. Não se trata de um campo «EOL» preenchido depois dos factos. A decisão determina, entre outros aspetos, durante quanto tempo tem de continuar o tratamento eficaz de vulnerabilidades, e a fundamentação tem de constar da documentação técnica.

Regra geral, o período de apoio é de pelo menos cinco anos. Quando se prevê que um produto seja utilizado durante menos de cinco anos, o período de apoio corresponde a esse tempo de utilização previsto.

Critérios estabelecidos no CRA

O fabricante tem de ter em conta, em especial:

as expectativas razoáveis dos utilizadores;
a natureza do produto;
a sua finalidade prevista;
a legislação pertinente da UE que determina a vida útil do produto.

O CRA também permite considerar:

os períodos de apoio de produtos com funções semelhantes;
a disponibilidade do ambiente de funcionamento;
os períodos de apoio dos componentes integrados de terceiros que asseguram funções essenciais;
as orientações pertinentes da Comissão e do ADCO.

Os critérios têm de ser aplicados de forma proporcionada.

Não comece pela data

Um processo fraco começa assim:

«Vamos indicar cinco anos porque é isso que o CRA estabelece.»

Um processo mais sólido começa pelos pressupostos:

Durante quanto tempo é razoável que os utilizadores esperem utilizar o produto?
Durante quanto tempo podem ser apoiadas as dependências essenciais?
Qual é o ciclo de vida do hardware ou do ambiente de funcionamento?
O produto é utilizado num ambiente industrial ou noutro contexto em que a vida útil prática é mais longa?
Que compromissos decorrem dos contratos e de outra legislação aplicável?
É realisticamente possível manter o processo de atualização de segurança durante o período escolhido?

Aprove a data de fim apenas depois de considerar estas questões.

Provas da decisão

Um registo mínimo pode incluir:

Campo	Exemplo de conteúdo
Produto / versão	identificação única
Data da decisão	quando foi aprovado o período de apoio
Data de fim	pelo menos mês e ano
Tempo de utilização previsto	pressuposto + fonte
Expectativas dos utilizadores	contratos, dados do produto, provas do mercado
Dependências essenciais	períodos de apoio de terceiros
Ambiente de funcionamento	sistemas/plataformas necessários
Fundamento jurídico/orientações	fontes utilizadas na decisão
Aprovador	pessoa/função responsável
Data da revisão	quando os pressupostos voltam a ser verificados

Os utilizadores precisam de uma data de fim do apoio clara

O artigo 13 exige que a data de fim do período de apoio — pelo menos o mês e o ano — seja indicada de forma clara e compreensível no momento da compra, de maneira facilmente acessível e, quando aplicável, no produto, na embalagem ou em formato digital.

Isso liga uma decisão interna sobre o ciclo de vida à comunicação do produto. Se a data na documentação técnica, nos preços, na interface e no contrato difere, o problema surgirá na relação normal com os clientes muito antes de uma auditoria.

O período de apoio é um compromisso operacional, e não apenas uma data

Durante o período de apoio, o fabricante tem de tratar as vulnerabilidades de forma eficaz de acordo com os requisitos CRA. Por isso, o registo do período de apoio deve estar ligado a:

política de divulgação coordenada de vulnerabilidades;
triagem e correção de vulnerabilidades;
versões de segurança;
componentes de terceiros;
comunicação com os utilizadores;
monitorização do fim do apoio.

O CRA também contém requisitos sobre a disponibilidade continuada das atualizações de segurança emitidas e sobre a conservação da documentação por períodos definidos. A gestão do ciclo de vida não pode ser reduzida a um campo num CRM ou catálogo de produtos.

Como o Pulsar pode gerir a decisão

O Pulsar pode conservar a decisão, a fundamentação, as pessoas responsáveis, as ações e as provas, ligando-as a riscos e documentação. Numa revisão posterior, a equipa consegue ver o que mudou desde a decisão anterior, em vez de reconstruir a fundamentação original.

Isso não significa que o Pulsar decida autonomamente o período de apoio correto. Os pressupostos e a aprovação permanecem sob a responsabilidade do fabricante.

Veja o Pulsar GRC num ciclo de vida de decisão

Orientações relacionadas

Método proposto: justificar suporte antes de anunciar a data

Imagine um fabricante de equipamento conectado para instalações industriais. A área comercial quer anunciar cinco anos de suporte. Engenharia identifica uma dependência essencial com manutenção mais curta, enquanto clientes utilizam equipamentos semelhantes durante períodos superiores. O dossier precisa de resolver essa diferença antes de publicar um compromisso. Este cenário hipotético serve para rever pressupostos, não para determinar a duração juridicamente correta de um produto.

Descreva utilização prevista, quem instala, frequência de substituição e funções. Utilize contratos, informação do produto e experiências documentadas quando existam. Distinga dados de uma estimativa comercial. Se o produto é novo, reconheça incerteza e defina como será revista. Não invente uma vida de utilização para justificar a data mais conveniente para o orçamento.

Construa depois um mapa de dependências essenciais. Registe responsável de manutenção, período anunciado, fonte e data de verificação. Uma dependência insuficiente exige uma decisão técnica ou de fornecimento. Pode implicar substituição, manutenção própria permitida ou alteração do produto. Colocar uma nota em condições gerais não resolve automaticamente essa incompatibilidade.

Separe conceitos e marcos de início

Utilização prevista, período de suporte, disponibilidade de atualizações emitidas e conservação documental têm relações, mas não são um único campo. A pessoa competente contrasta cada obrigação com o regulamento vigente e orientações pertinentes. No registo, identifique o evento que inicia cada período e a fonte que fundamenta a interpretação.

Se uma ferramenta comercial aceita apenas uma data final, mantenha o detalhe no dossier e defina como a informação chega ao utilizador. Simplificar uma interface não simplifica a obrigação. Verifique que a data apresentada corresponde à variante e às condições efetivamente fornecidas, sem esconder diferenças relevantes entre versões.

Uma versão nova não apaga compromissos relativos a versões ainda utilizadas. O inventário identifica ramos suportados, canais de correção e condições de migração. Se migrar exige outro equipamento ou altera uma função, essa dependência necessita de avaliação. Não assuma que publicar uma atualização significa que todos os utilizadores passaram a utilizá-la.

Capacidade de manutenção precisa de evidência

Estime atividades: receção de avisos, triagem, análise de componentes, correção, ensaios, publicação e comunicação. Identifique responsáveis e substitutos. As estimativas são previsões internas, não garantias de custo. Direção deve conhecer pressupostos e o efeito de crescimento de utilizadores ou de versões mantidas.

Inclua condições que permitem trabalhar sobre versões antigas: ambiente de compilação, dispositivos de teste, processos de assinatura e pessoas capazes de manter o código. Se apenas uma pessoa sabe publicar uma correção, existe risco de continuidade. O tratamento pode combinar documentação, formação e exercício de substituição. Uma data no catálogo não demonstra capacidade de cumprir o compromisso.

Reveja contratos de serviços remotos necessários para funções. Um contrato que termina antes do período comprometido pode exigir alternativa e transição. Registe viabilidade, esforço e aprovador. Quando não houver resposta suficiente, eleve o problema antes de continuar a comercializar com pressupostos incompatíveis.

Coerência da informação ao utilizador

Compare dossier, página comercial, instruções, contrato e canal de apoio. Todos devem referir o produto pertinente e apresentar informação compreensível. Guarde revisão, data e responsável. Uma captura sem contexto pode mostrar um texto, mas não a sua correspondência com a variante comercializada.

Quando muda o fundamento ou a data, identifique comunicações afetadas e conserve versões anteriores. Não substitua silenciosamente uma promessa e considere o assunto resolvido. O efeito em contratos e obrigações necessita de avaliação. O historial permite explicar o que se anunciou em cada momento e por que se alterou.

Um exercício simples pede à equipa de apoio responder até quando haverá suporte de segurança para um produto específico. A resposta utiliza fonte vigente, distingue variante quando necessário e indica quando escalar dúvidas. Se depende sempre de perguntar ao programador original, falta um processo acessível.

Revisão quando os pressupostos mudam

Pode haver novo sistema operativo, componente abandonado, alteração de hardware ou informação sobre uso real. Registe o desencadeante e a parte da decisão afetada. Uma alteração limitada não exige reconstruir todo o dossier sem motivo; exige demonstrar que o alcance foi revisto. A conclusão deve identificar factos novos e ações necessárias.

As ações têm saída verificável. «Falar com fornecedor» descreve atividade. «Obter e rever a política de manutenção da versão utilizada» permite avaliar conclusão. Conserve ligação entre resposta, decisão e risco. Um prazo de seguimento não deve transformar uma evidência ainda pendente em fundamento aprovado.

Critérios de aceitação do dossier

Outra pessoa deve identificar produto, fundamento da duração, dependências, data comunicada e capacidade de manutenção. Deve localizar fontes e perceber quais estavam vigentes quando se decidiu. Se faltam dados sobre expectativas de uso, a lacuna permanece visível. Um campo preenchido não elimina incerteza.

Verificar uma dependência antes de renovar uma oferta

Escolha um componente essencial e confirme a fonte atual de manutenção. Identifique versão utilizada, período anunciado e condições. Se a política mudou, explique efeito no produto. Uma página genérica do fornecedor pode não cobrir a edição instalada. Preserve a fonte pertinente e data, evitando utilizar promessa de outra versão como fundamento.

Depois, peça a engenharia identificar tratamento viável. Pode precisar de mudança técnica, negociação ou plano de substituição. Registe recursos e prazo como estimativas, com pressupostos. A decisão de direção deve conhecer consequência de não executar, sem transformar uma previsão conveniente em capacidade comprovada.

O exercício termina quando uma pessoa autorizada explica ligação entre dependência, compromisso e ação. Se o fornecedor ainda não respondeu, a lacuna continua aberta. Não marque concluído apenas por enviar um pedido. O critério deve referir informação obtida, revisão e resultado. Assim o acompanhamento mantém efeito operacional em vez de se reduzir a um calendário de lembretes.

O Pulsar pode organizar o dossier e ações; o fabricante conserva decisão e aprovação. A IA ajuda a comparar material autorizado, mas não determina autonomamente duração nem transforma falta de orçamento numa exceção legal. O resultado útil é uma decisão explicada antes de surgir um incidente, com responsáveis e fontes que permitem rever as suas consequências.

Fontes

Fontes verificadas: 12 de setembro de 2026.

Pulsar GRC — acesso, isolamento de dados e exportação (polaco)