Dossiê de Segurança do Produto CRA 2026 com ISO 27001

Um fabricante de dispositivos conectados chama a sua CISO, Maria, para uma reunião numa sexta-feira à tarde. A área comercial acabou de fechar um acordo de distribuição europeu. O departamento jurídico pergunta se a empresa consegue sustentar a conformidade com o Cyber Resilience Act. A engenharia afirma que o desenvolvimento seguro está “praticamente coberto”, porque existem revisão de código, SAST e aplicação de patches. A equipa de compras diz que os fornecedores estão “abrangidos por acordos de confidencialidade”. As equipas de produto têm dependências de firmware numa ferramenta, inventários de interfaces de programação de aplicações na nuvem noutra, e tickets de vulnerabilidades no Jira. A conformidade dispõe de evidência da certificação ISO/IEC 27001:2022, mas essa evidência está organizada em torno do SGSI corporativo, não em torno de cada produto colocado no mercado da UE.

Depois surge a pergunta desconfortável: “Se uma autoridade da UE, um cliente, um organismo notificado ou um grande distribuidor pedir o Dossiê de Segurança do Produto em 2026, conseguimos produzi-lo numa semana?”

Para muitos fornecedores de software, fabricantes de dispositivos inteligentes e prestadores de serviços conectados, a resposta honesta é não. Não porque não tenham controlos de segurança, mas porque a sua evidência de segurança do produto está dispersa. Os registos de desenvolvimento seguro ficam com a engenharia. Os SBOM são gerados por compilação, mas não são governados. A divulgação coordenada de vulnerabilidades existe como página web, mas nem sempre está ligada à triagem, às correções, aos avisos de segurança e à monitorização pós-colocação no mercado. A segurança de fornecedores está enterrada em contratos de compras. A notificação de incidentes pertence às operações de segurança, enquanto a documentação de conformidade pertence à conformidade de produto.

O Cyber Resilience Act da UE altera o modelo operacional. A cibersegurança do produto deixa de ser apenas uma boa prática ou uma promessa contratual. Passa a ser uma obrigação suportada por evidência ao longo do ciclo de vida. As organizações devem conseguir demonstrar como os requisitos de cibersegurança são incorporados na conceção, no desenvolvimento, no lançamento, no tratamento de vulnerabilidades, nas atualizações e na monitorização após a entrada do produto no mercado.

É aqui que a ISO/IEC 27001:2022 se torna poderosa, se for usada corretamente. Não é, por si só, um esquema de certificação de produto, mas os seus controlos de SGSI, risco, ativos, fornecedores, desenvolvimento seguro, vulnerabilidades e incidentes podem fornecer a base de um Dossiê de Segurança do Produto CRA. O objetivo não é criar outro silo de conformidade. O objetivo é converter o SGSI existente num sistema de evidência ao nível do produto.

Como o Zenith Blueprint: An Auditor’s 30-Step Roadmap da Clarysec afirma na Fase 2, Etapa 8, Arquitetura de Evidência:

“A evidência não deve ser recolhida no fim do ciclo de auditoria. Deve ser desenhada no próprio controlo, atribuída a um proprietário, marcada temporalmente pelo processo e reutilizável em todas as obrigações que fazem a mesma pergunta em linguagem diferente.”

Esta frase capta o núcleo da preparação para o CRA. A pergunta não é apenas: “Temos desenvolvimento seguro?” A pergunta é: “Conseguimos comprovar o desenvolvimento seguro, o conhecimento dos componentes, o tratamento de vulnerabilidades e a monitorização pós-colocação no mercado para este produto, esta versão, este lançamento e este mercado?”

O Dossiê de Segurança do Produto CRA é um sistema vivo de evidência

Um Dossiê de Segurança do Produto CRA não deve ser tratado como um PDF estático, produzido uma vez antes do lançamento e depois esquecido. Deve ser um dossiê estruturado que conta a história de segurança do produto desde o conceito até ao fim do suporte.

Um dossiê útil explica:

1. O que é o produto e como se destina a ser utilizado.
2. Que software, firmware, serviços na nuvem e dependências de terceiros inclui.
3. Que riscos de cibersegurança foram avaliados.
4. Que requisitos de segurança foram aplicados.
5. Como foi realizado o desenvolvimento seguro.
6. Como as vulnerabilidades são recebidas, triadas, corrigidas e divulgadas.
7. Como são entregues as atualizações seguras.
8. Como são controlados os fornecedores e os componentes de código aberto.
9. Como são escalados os incidentes e as vulnerabilidades exploradas ativamente.
10. Como o produto é monitorizado após a sua colocação no mercado.

Para um CISO, este é um desafio de evidência do SGSI. Para um gestor de conformidade de produto, é documentação técnica. Para a engenharia, é DevSecOps e governação de lançamentos. Para os executivos, é acesso ao mercado e controlo de responsabilidade.

O erro é tratar estes temas como fluxos de trabalho separados. O melhor modelo é criar um ficheiro de evidência ao nível do produto que mapeie para os controlos ISO/IEC 27001:2022 e ISO/IEC 27002:2022 e, em seguida, fazer o mapeamento cruzado da mesma evidência para NIS2, DORA, RGPD da UE, NIST e COBIT 2019, quando relevante.

O Zenith Controls: The Cross-Compliance Guide da Clarysec descreve isto como uma cadeia de controlo-para-evidência-para-auditor:

“Um ficheiro de evidência de conformidade cruzada deve mapear cada obrigação para o controlo operacional, o objeto de evidência recorrente, o proprietário responsável e a perspetiva de auditoria que será usada para o questionar.”

É esta a disciplina de que a preparação para o CRA necessita. O Dossiê de Segurança do Produto não é apenas uma pasta. É a camada de tradução entre a engenharia de produto, a governação da segurança, a avaliação da conformidade e a garantia para clientes.

Construa primeiro a base de evidência do produto

O dossiê precisa de uma estrutura consistente antes de as equipas começarem a carregar registos. Sem uma base clara, a evidência transforma-se num conjunto de capturas de ecrã, exportações e PDFs de políticas que nenhum auditor consegue seguir.

Em workshops de preparação para o CRA, a Clarysec recomenda normalmente a seguinte estrutura de Dossiê de Segurança do Produto para organizações que já operam um SGSI ISO/IEC 27001:2022.

Esta tabela não substitui as obrigações legais de documentação técnica. Dá ao negócio um modelo operacional para as comprovar.

No Zenith Blueprint, a Fase 1, Etapa 3 centra-se na definição de âmbito e fronteiras. Para o CRA, essa etapa torna-se específica do produto. Defina a família de produto, as versões de software, os pressupostos de implementação, as funções de utilizador, os serviços conectados, os canais de atualização e o período de suporte. Se o âmbito do SGSI for “Corporate SaaS and device management platform”, o dossiê CRA deve ainda responder a uma pergunta mais restrita: “Que produto com elementos digitais está a ser colocado no mercado da UE e o que está incluído nesse produto?”

Mapeie o desenvolvimento seguro para registos ao nível do produto

O núcleo do Dossiê de Segurança do Produto é a evidência de segurança desde a conceção. A ISO/IEC 27001:2022 fornece o sistema de governação. A ISO/IEC 27002:2022 fornece orientações de implementação através de controlos como A.8.25 Ciclo de vida de desenvolvimento seguro, A.8.27 Arquitetura segura de sistemas e princípios de engenharia, A.8.28 Programação segura e A.8.29 Testes de segurança no desenvolvimento e aceitação.

A mudança importante é passar de declarações genéricas de desenvolvimento seguro para registos específicos por lançamento. “Fazemos revisão de código” não é suficiente. O dossiê deve mostrar que lançamento foi revisto, que riscos foram considerados, que testes de segurança foram aprovados, que vulnerabilidades foram aceites ou remediadas e quem aprovou o lançamento.

A Secure development policy Enterprise da Clarysec foi concebida para impor esse trilho de evidência. Na cláusula 6.1, Requisitos do ciclo de vida de desenvolvimento seguro, estabelece:

“Cada lançamento de produto ou serviço deve manter evidência documentada dos requisitos de segurança, revisão de conceção, atividades de programação segura, testes de segurança, decisões de remediação de vulnerabilidades e aprovação de lançamento antes da implementação em produção.”

Esta cláusula é útil para o CRA porque transforma o desenvolvimento seguro num padrão de evidência repetível. Um auditor não precisa de inferir que o desenvolvimento seguro aconteceu. Pode inspecionar o registo de lançamento.

Para um termóstato inteligente, dispositivo médico IoT, sensor industrial ou produto conectado a SaaS, a evidência de desenvolvimento seguro deve incluir:

• Requisitos de segurança do produto mapeados para os riscos identificados.
• Modelo de ameaças ou análise de casos de abuso para o produto e os serviços conectados.
• Revisão de arquitetura, incluindo limites de confiança e interfaces externas.
• Norma de programação segura e evidência de confirmação ou formação dos programadores.
• SAST, DAST, análise da composição de software, deteção de segredos e análise de firmware, quando aplicável.
• Tickets de remediação para constatações de alto risco.
• Registos de aceitação do risco com aprovação do negócio e da segurança.
• Lista de verificação do ponto de controlo de lançamento que demonstre o cumprimento dos critérios de segurança.
• Evidência de assinatura criptográfica e integridade das atualizações.
• Pressupostos sobre o período de suporte e o fim de vida útil.

Outras normas ajudam a reforçar o método. A ISO/IEC 27005 suporta a abordagem de risco por trás destes registos. A ISO/IEC 27017 é útil quando os serviços na nuvem fazem parte do ecossistema do produto. A ISO/IEC 27035 suporta o tratamento de incidentes. A ISO/IEC 29147 e a ISO/IEC 30111 são especialmente relevantes para a divulgação de vulnerabilidades e o tratamento de vulnerabilidades. A ISO/IEC 27036 suporta a segurança de fornecedores, o que é importante quando o produto inclui software externalizado, módulos incorporados, serviços geridos na nuvem ou bibliotecas de terceiros.

No Zenith Controls, a evidência de desenvolvimento seguro para o CRA é normalmente mapeada em torno de temas de controlo da ISO/IEC 27002:2022, como segurança da informação na gestão de projetos, ciclo de vida de desenvolvimento seguro, programação segura, testes de segurança, gestão de alterações e gestão de vulnerabilidades técnicas. O guia também liga estes temas ao inventário de ativos e aos controlos de fornecedores, porque nenhum processo de desenvolvimento seguro está completo se a organização não conseguir identificar os componentes que entrega.

Trate o SBOM como evidência regulada do produto

A Software Bill of Materials é frequentemente tratada como um artefacto técnico. Para a preparação para o CRA, deve ser tratada como evidência de produto.

Um SBOM útil indica que componentes estão no produto, que versões são utilizadas, de onde vieram, que licenças se aplicam, que vulnerabilidades os afetam e que lançamentos os contêm. Para firmware e produtos incorporados, isto pode incluir pacotes do sistema operativo, bootloaders, bibliotecas, controladores, contentores, módulos de terceiros e dependências do lado da nuvem necessárias à operação do produto.

O problema é que muitas organizações geram SBOM, mas não os governam. Uma pipeline de compilação pode produzir um ficheiro SPDX ou CycloneDX, mas ninguém valida a completude. As ferramentas de segurança podem sinalizar vulnerabilidades, mas os resultados não estão ligados às versões do produto. A equipa de compras pode aprovar um fornecedor, mas a lista de componentes desse fornecedor não é reconciliada com o produto lançado.

A Asset management policy Enterprise da Clarysec aborda esta lacuna de governação na cláusula 5.2, Inventário de informação e ativos associados:

“Os ativos de informação e os componentes tecnológicos associados devem ser identificados, atribuídos a um proprietário, classificados quando aplicável e mantidos num inventário que suporte a avaliação de riscos, a gestão de vulnerabilidades, o controlo de alterações e a evidência de auditoria.”

Para o CRA, essa cláusula torna-se específica do produto. O SBOM faz parte do inventário de componentes tecnológicos associados. Precisa de um proprietário, uma regra de retenção, um processo de validação e uma ligação à gestão de vulnerabilidades.

Uma regra prática de evidência SBOM é simples: cada versão de produto lançada deve ter um inventário de componentes aprovado que possa ser associado ao artefacto de lançamento. Se a organização não conseguir ligar o SBOM à imagem exata de firmware, ao pacote aplicacional, ao digest do contentor ou ao lançamento SaaS, o SBOM é evidência fraca.

Se mais de duas linhas falharem, o problema normalmente não é a ferramenta SBOM. É governação. O Dossiê de Segurança do Produto deve registar uma ação corretiva no SGSI, porque a fragilidade da evidência CRA é também um problema de eficácia dos controlos ISO/IEC 27001:2022.

Ligue a CVD ao tratamento de vulnerabilidades e à governação de lançamentos

A divulgação coordenada de vulnerabilidades é uma das áreas mais visíveis da preparação para o CRA, porque investigadores externos, clientes e autoridades podem testá-la diretamente. Publicar uma página de divulgação de vulnerabilidades ou um ficheiro security.txt é útil, mas é apenas a porta de entrada. O Dossiê de Segurança do Produto deve provar que a retaguarda operacional funciona.

Um conjunto defensável de evidência de CVD e tratamento de vulnerabilidades deve incluir:

• Canal público de divulgação e instruções de submissão.
• Processo de confirmação ao investigador.
• Critérios de triagem, incluindo avaliação de severidade e explorabilidade.
• Análise de impacto no produto.
• Propriedade da remediação e prazos-alvo.
• Modelos de aviso ao cliente e comunicação de atualização.
• Evidência de desenvolvimento e teste seguro de patches.
• Registos de publicação coordenada, quando aplicável.
• Lições aprendidas e análise de tendências de vulnerabilidades recorrentes.

A Vulnerability management policy Enterprise da Clarysec, cláusula 6.3, Receção, triagem e remediação de vulnerabilidades, estabelece:

“As vulnerabilidades comunicadas devem ser registadas, avaliadas quanto aos ativos e produtos afetados, priorizadas de acordo com o risco e a explorabilidade, atribuídas a um proprietário responsável e acompanhadas até à remediação, verificação, comunicação e encerramento.”

Esta cláusula liga a CVD ao SBOM, ao inventário de ativos, aos tickets de engenharia, à gestão de lançamentos e à monitorização pós-colocação no mercado. É também a cláusula que os auditores testarão naturalmente: mostre o registo de receção, mostre os produtos afetados, mostre a triagem, mostre a correção, mostre a comunicação ao cliente, mostre o encerramento.

A sua Information Security Incident Management Policy existente também deve ser alargada para cobrir vulnerabilidades de produto que se transformem em incidentes ou exijam notificação externa. A ISO/IEC 27002:2022 A.5.24 cobre o planeamento e preparação da gestão de incidentes, A.5.25 cobre a avaliação e decisão sobre eventos de segurança da informação, A.5.26 cobre a resposta a incidentes de segurança da informação e A.5.27 cobre a aprendizagem com incidentes.

No Zenith Controls, a gestão de vulnerabilidades é tratada como preventiva e corretiva. A vertente preventiva inclui inventário, desenvolvimento seguro, monitorização de fornecedores e configuração segura. A vertente corretiva inclui deteção, triagem, aplicação de patches, comunicação e escalonamento de incidentes. Esta distinção é importante porque o tratamento de vulnerabilidades pós-colocação no mercado faz parte da obrigação de ciclo de vida do produto, não é uma reflexão posterior.

A evidência de fornecedores é a fraqueza escondida

O Dossiê de Segurança do Produto será muitas vezes questionado com maior rigor quando o fabricante depende de terceiros. Isto inclui módulos incorporados, desenvolvimento externalizado de firmware, componentes de marca branca, alojamento na nuvem, SDKs móveis, serviços de pagamento, bibliotecas criptográficas e prestadores de serviços geridos.

O padrão comum de falha é a abstração contratual. O fabricante diz: “O nosso fornecedor é responsável por isso.” Sob escrutínio de segurança do produto, isto não é suficiente. A organização deve demonstrar que o risco de fornecedor é identificado, que os requisitos de segurança são comunicados, que a evidência é recolhida, que as vulnerabilidades são coordenadas e que as alterações são controladas.

A Third-party and supplier security policy Enterprise da Clarysec, cláusula 7.1, Requisitos de segurança de fornecedores, estabelece:

“Os fornecedores que desenvolvem, operam, tratam, suportam ou afetam materialmente sistemas de informação, produtos ou serviços devem ser avaliados de acordo com o risco e estar sujeitos a requisitos de segurança que cubram acesso, gestão de vulnerabilidades, notificação de incidentes, subcontratação, continuidade e fornecimento de evidência.”

Para o CRA, a expressão “afetam materialmente produtos” é crítica. Se um componente de fornecedor puder introduzir uma vulnerabilidade, interromper atualizações, expor dados de clientes ou comprometer a integridade do dispositivo, deve constar do Dossiê de Segurança do Produto.

A mesma política também pode suportar a contratação de SBOM. A cláusula 7.3 estabelece:

“Para todos os componentes de software de terceiros, bibliotecas ou sistemas operativos a integrar em ‘Produtos com Elementos Digitais’ da empresa, o fornecedor deve disponibilizar, mediante pedido, uma Software Bill of Materials (SBOM) legível por máquina num formato normalizado, como SPDX ou CycloneDX. Este requisito deve ser incorporado em todos os contratos de compras e de fornecedores.”

Um pacote robusto de evidência de fornecedores deve incluir classificação de fornecedores por impacto no produto, requisitos de segurança nos contratos, evidência de desenvolvimento seguro do fornecedor para componentes críticos, compromissos de divulgação de vulnerabilidades pelo fornecedor, SBOM ou declarações de componentes quando viável, suporte de patches e prazos de fim de vida útil, registos de revisão periódica e vias de escalonamento para vulnerabilidades originadas em fornecedores.

A ISO/IEC 27002:2022 A.5.19, A.5.20 e A.5.21 fornecem os principais temas de controlo de fornecedores. A ISO/IEC 27036 acrescenta profundidade à segurança das relações com fornecedores. Em termos de conformidade cruzada, a NIS2 enfatiza a cadeia de fornecimento e o tratamento de vulnerabilidades. A DORA enfatiza o risco de terceiros de TIC para entidades financeiras. O RGPD da UE torna-se relevante quando o produto ou os seus serviços na nuvem tratam dados pessoais. O COBIT 2019 enquadra a governação de fornecedores como uma questão de governação empresarial da tecnologia, não apenas como uma questão de operações de segurança.

A monitorização pós-colocação no mercado transforma evidência em operações

As organizações mais maduras em segurança de produto pensam para além do lançamento. Perguntam: “Como saberemos que este produto se tornou arriscado depois de estar no terreno?”

A monitorização pós-colocação no mercado deve captar sinais de feeds de vulnerabilidades, informações sobre exploração, apoio ao cliente, telemetria, programas de recompensa por vulnerabilidades ou comunicações de investigadores, notificações de fornecedores, registos na nuvem, registos de incidentes e dados de desempenho em campo. Deve também incluir revisão periódica do risco do produto quando as condições de ameaça mudam.

A Logging and monitoring policy Enterprise da Clarysec, cláusula 5.4, Monitorização e revisão de segurança, estabelece:

“Os eventos relevantes para a segurança devem ser recolhidos, revistos, escalados e retidos de forma a suportar a deteção atempada, a investigação, a resposta a incidentes, o reporte de conformidade e a melhoria contínua.”

Para produtos conectados, isto deve ser interpretado com cuidado. A monitorização deve respeitar a privacidade, a minimização de dados e as restrições legais, especialmente quando a telemetria inclui dados pessoais ou dados operacionais de clientes. O mapeamento para o RGPD da UE é importante. As equipas de segurança de produto devem trabalhar com as equipas de privacidade para definir que telemetria é necessária para segurança, como é minimizada, durante quanto tempo é retida e como os clientes são informados.

A evidência de monitorização pós-colocação no mercado deve incluir um plano de monitorização de segurança do produto, fontes de informação sobre vulnerabilidades, canais de receção de relatórios de clientes, canais de notificação de fornecedores, âmbito de revisão de telemetria ou registos, atas de revisão periódica do risco do produto, acompanhamento da adoção de patches, análise de tendências de incidentes e entradas para revisão pela gestão.

No Zenith Blueprint, a Fase 5, Etapa 30 centra-se na melhoria contínua e na preparação para auditorias de acompanhamento. Para o CRA, é aqui que o Dossiê de Segurança do Produto se torna um ficheiro vivo. Cada lançamento de produto, vulnerabilidade, alteração de fornecedor e sinal de campo deve atualizar o registo de evidência.

Um ficheiro de evidência, muitas perguntas de conformidade

Um Dossiê de Segurança do Produto CRA bem concebido reduz duplicações, porque a mesma evidência responde a várias perguntas de conformidade. A linguagem muda, mas a realidade dos controlos é frequentemente semelhante.

O Zenith Controls foi concebido para esta reutilização. Mapeia temas de controlo da ISO/IEC 27002:2022 para atributos como finalidade preventiva, de deteção e corretiva do controlo, conceitos de cibersegurança, capacidades operacionais e propriedades de segurança. Para o CRA, isto ajuda um CISO a explicar por que motivo um único objeto de evidência, como uma revisão de segurança de lançamento, suporta desenvolvimento seguro, tratamento de riscos, controlo de alterações, gestão de vulnerabilidades e preparação para auditoria.

Prepare-se para diferentes perspetivas de auditoria

Um Dossiê de Segurança do Produto CRA pode ser questionado por um auditor ISO, uma equipa de auditoria interna, uma equipa de garantia para clientes, um revisor de conformidade de produto, uma entidade reguladora, um avaliador baseado em NIST ou um auditor COBIT formado pela ISACA. Cada um fará perguntas semelhantes através de uma perspetiva diferente.

O mesmo ponto fraco será exposto de forma diferente. Se os SBOM forem gerados mas não retidos, o auditor ISO vê um problema de controlo de registos e de controlo operacional. O avaliador NIST vê uma fragilidade de gestão de ativos e vulnerabilidades. O auditor COBIT vê governação fraca sobre ativos de informação. O revisor de produto vê documentação técnica insuficiente.

Um roteiro de 30 etapas, adaptado à preparação para o CRA

O Zenith Blueprint impede que as equipas de conformidade saltem diretamente para a recolha de documentos. Para o CRA, o roteiro de 30 etapas torna-se um programa de evidência de segurança do produto.

A Fase 1 começa com o mapeamento de obrigações e âmbito. Identifique que produtos, versões, componentes, serviços na nuvem e processos de suporte estão no âmbito. Confirme a utilização prevista, as categorias de utilizadores, os mercados e o período de suporte de segurança.

A Fase 2 constrói a arquitetura de evidência. Defina o índice do Dossiê de Segurança do Produto, os proprietários de evidência, os requisitos de retenção, a estrutura do repositório e o fluxo de trabalho de aprovação. Alinhe com sistemas de engenharia em vez de impor carregamentos manuais.

A Fase 3 implementa controlos operacionais. Desenvolvimento seguro, geração de SBOM, tratamento de vulnerabilidades, evidência de fornecedores, pontos de controlo de lançamento, atualizações seguras e escalonamento de incidentes devem operar como processos reais.

A Fase 4 testa a preparação para auditoria. Selecione um lançamento de produto e execute uma auditoria simulada. A equipa consegue recuperar o SBOM? Consegue comprovar testes de segurança? Consegue mostrar como uma vulnerabilidade foi triada? Consegue ligar a evidência de fornecedor aos componentes do produto?

A Fase 5 incorpora supervisão e melhoria. A monitorização pós-colocação no mercado, a análise de tendências de vulnerabilidades, as revisões de fornecedores e as entradas para revisão pela gestão mantêm o dossiê atualizado.

Este sprint costuma revelar rapidamente a realidade. As organizações raramente falham por não terem quaisquer controlos. Falham porque os controlos não estão conectados ao nível do produto.

Lacunas comuns de preparação para o CRA antes de 2026

Entre fornecedores de software, fabricantes de dispositivos e prestadores de serviços conectados, as lacunas recorrentes são consistentes.

Primeiro, o âmbito do SGSI é demasiado corporativo. Cobre a organização, mas não inclui detalhe suficiente sobre o ciclo de vida do produto. A correção é criar anexos e ficheiros de evidência ao nível do produto.

Segundo, os SBOM existem, mas não são confiáveis. São gerados por ferramentas, mas não são revistos, aprovados, retidos ou ligados a decisões sobre vulnerabilidades. A correção é a governação de SBOM, não apenas a produção de SBOM.

Terceiro, a CVD é visível ao público, mas não é operacionalmente madura. As comunicações chegam, mas os critérios de triagem, as metas de resposta, as aprovações de avisos e a evidência de encerramento são inconsistentes. A correção é integrar a CVD com a gestão de vulnerabilidades, a gestão de incidentes e a gestão de lançamentos.

Quarto, a evidência de fornecedores é superficial. Fornecedores críticos são aprovados comercialmente, mas não avaliados quanto ao impacto na segurança do produto. A correção é classificar fornecedores por risco de produto e exigir evidência obrigatória para componentes críticos.

Quinto, a monitorização pós-colocação no mercado é reativa. As equipas respondem a vulnerabilidades urgentes, mas não executam revisões periódicas de risco do produto. A correção é uma revisão de segurança pós-colocação no mercado programada e ligada ao reporte à gestão.

Sexto, a evidência de auditoria é demasiado manual. As equipas de conformidade perseguem capturas de ecrã. A correção é evidência por conceção, usando sistemas de engenharia, fluxos de tickets e repositórios como fontes autoritativas.

Construa o ficheiro de evidência antes de o prazo o construir por si

O Cyber Resilience Act recompensa organizações que conseguem comprovar a segurança do produto como disciplina operacional. Cria risco para organizações que tratam a evidência como um exercício de conformidade de última hora.

Comece por um produto. Construa um Dossiê de Segurança do Produto. Mapeie-o para ISO/IEC 27001:2022 e ISO/IEC 27002:2022. Anexe evidência de desenvolvimento seguro, SBOM, registos de CVD, garantia de fornecedores e monitorização pós-colocação no mercado. Execute uma simulação de auditoria antes que alguém externo o faça por si.

A Clarysec pode ajudá-lo a acelerar esta jornada com o Zenith Blueprint, o Zenith Controls, a Secure development policy Enterprise, a Vulnerability management policy, a Asset management policy, a Third-party and supplier security policy, a Logging and monitoring policy e a Information Security Incident Management Policy.

A sua pergunta mais importante sobre o CRA 2026 não é: “Temos controlos de segurança?”

É: “Conseguimos comprovar a segurança do produto, lançamento a lançamento, componente a componente, vulnerabilidade a vulnerabilidade, depois de o produto já estar no mercado?”

Construa agora o ficheiro de evidência, ligue-o ao seu SGSI e torne cada futuro lançamento de produto preparado para auditoria desde a conceção.