Documentação técnica CRA: preparação e manutenção

A documentação técnica CRA não é um documento pontual preparado para uma auditoria. O artigo 31 exige que seja elaborada antes de o produto com elementos digitais ser colocado no mercado e atualizada conforme necessário, pelo menos durante o período de apoio.

Se a arquitetura, as decisões e os resultados dos testes têm de ser reconstruídos a partir de e-mails, pedidos de trabalho e da memória da equipa, o problema não é a falta de um modelo de documento. É a ausência de um modelo de produto e provas mantido ao longo do tempo.

O que abrange o anexo VII

O conteúdo exato depende do produto, mas o anexo VII identifica, pelo menos, estes grupos de informação.

1. Descrição geral do produto

Inclui a finalidade prevista, as versões de software que afetam a conformidade com os requisitos essenciais de cibersegurança e a informação e instruções fornecidas aos utilizadores.

2. Conceção, desenvolvimento, produção e tratamento de vulnerabilidades

A documentação deve conter informação suficiente para compreender a conceção e a arquitetura, as relações entre componentes e os processos de tratamento de vulnerabilidades do fabricante.

O CRA refere aqui expressamente a SBOM, a política de divulgação coordenada de vulnerabilidades, a prova da existência de um endereço de contacto para comunicar vulnerabilidades e as soluções técnicas utilizadas na distribuição segura de atualizações.

3. Avaliação dos riscos de cibersegurança

O registo deve mostrar os riscos face aos quais o produto é concebido, desenvolvido, produzido, fornecido e mantido, e como se aplicam os requisitos do anexo I.

4. Fundamento do período de apoio

A documentação exige mais do que uma data de fim. Deve conservar a informação utilizada pelo fabricante para determinar esse período.

5. Normas e soluções técnicas utilizadas

Quando são utilizadas normas harmonizadas pertinentes, especificações comuns ou sistemas de certificação da cibersegurança, a documentação identifica-os e indica as partes aplicadas. Quando não são utilizados, o fabricante tem de documentar as soluções adotadas para cumprir os requisitos aplicáveis.

6. Relatórios de ensaio

Provas dos testes realizados para verificar o produto e os processos de tratamento de vulnerabilidades face aos requisitos aplicáveis.

7. Declaração UE de conformidade

Uma cópia da declaração relativa ao produto.

8. SBOM quando exigida por uma autoridade de fiscalização do mercado

O anexo VII prevê a disponibilização da SBOM pertinente após um pedido fundamentado, quando necessária para a autoridade verificar a conformidade.

Utilize um índice, e não um PDF gigantesco

Um modelo prático é um índice de documentação ligado a uma versão do produto.

Área	Artefacto de origem	Responsável	Versão / data	Prova de revisão
finalidade prevista	registo do produto	Responsável pelo produto	v3.4	aprovação
arquitetura	diagrama + descrição	Engenharia	v3.4	revisão
avaliação do risco	registo de riscos	Segurança/Produto	v3.4	decisões
SBOM	artefacto de compilação/versão	Engenharia	versão 3.4.2	hash / registo técnico
testes	relatórios	Garantia da qualidade/Segurança	versão 3.4.2	resultado
CVD	política	Segurança	rev. 5	aprovação
período de apoio	registo da decisão	Produto/Gestão	2026-09	fundamentação

A documentação técnica pode consistir em vários artefactos. O que importa é conseguir identificar que artefacto se aplica a cada versão e quem confirmou que estava atualizado.

Quatro padrões que criam custos desnecessários

«Temos uma política, por isso está coberto»

Uma política descreve como a organização pretende trabalhar. Não prova que uma versão concreta do produto tenha sido avaliada e testada.

«A arquitetura está no repositório; todos sabem onde»

Após uma mudança de equipa ou dezoito meses, «todos sabem» deixa de ser uma fonte de prova utilizável.

«A SBOM é gerada no pipeline»

Ótimo — mas a documentação continua a ter de ligar esse artefacto ao produto, à versão e ao processo de tratamento de vulnerabilidades.

«Exportaremos tudo antes da auditoria»

Se os registos de origem são inconsistentes, uma exportação apenas expõe essa inconsistência mais depressa.

Como o Pulsar pode organizar o percurso documental

Os documentos, provas, riscos, controlos e relatórios no Pulsar conservam o contexto das avaliações. Isso permite que a documentação funcione como registos ligados entre si, em vez de uma pasta que contém apenas ficheiros finais.

O registo pretendido deve responder:

a que produto e versão pertence um artefacto;
que requisito ou risco apoia;
quem o criou e aprovou;
quando estava atualizado;
que ação ou decisão prova;
o que mudou desde a revisão anterior.

O Pulsar não fornece conteúdo protegido de normas nem substitui a documentação técnica produzida pelo fabricante. Ajuda a manter a estrutura, a atribuição de responsabilidades e a rastreabilidade.

Veja documentos e provas no Pulsar GRC

Orientações relacionadas

Método proposto: índice por versão com responsáveis

Imagine uma publicação que modifica autenticação, acrescenta uma dependência e muda distribuição de atualizações. A descrição geral pouco muda, mas risco, inventário e provas precisam de revisão. Se apenas se atualizar um PDF principal, outros artefactos podem continuar a descrever a versão anterior. Este cenário hipotético testa coerência, sem representar uma avaliação completa de conformidade.

Prepare índice com identificação de produto e versão. Cada entrada indica artefacto, responsável, revisão e decisão que apoia. Pode referir documento, relatório de ensaio ou registo aprovado. Defina que referências permitem conservar rastreabilidade durante o suporte. Um índice precisa de identificar conteúdo, não apenas apontar para uma pasta onde pode existir.

Separe versão do produto e revisão documental. Um procedimento de vulnerabilidades pode aplicar-se a várias versões. Um resultado de ensaio corresponde a uma execução. Relacione ambos com o dossier sem aparentar ciclos de vida idênticos. Se o âmbito é parcial, a entrada deve mostrar essa limitação.

Critérios de aceitação das evidências

Para arquitetura, verifique produto, limites e relações. Para risco, confirme contexto, decisões e medidas. Para ensaios, identifique versão, ambiente, cenário e resultado. Estes são critérios operacionais propostos; o conteúdo exigido deve contrastar-se com CRA e o caso concreto.

Uma evidência recente pode ser de outra variante ou função. Registe o propósito e quem confirmou pertinência. Se reutilizar um ensaio anterior, explique por que continua aplicável após a mudança. Essa conclusão precisa de fundamento técnico, não de uma decisão tomada apenas para evitar trabalho.

Mantenha trabalho previsto separado de resultado. Um ensaio agendado não demonstra proteção. Um rascunho não equivale a política aprovada. Estados claros permitem identificar lacunas antes de publicar e evitam transformar campos completos numa falsa prova de cumprimento.

Referências estáveis e acessíveis

Um link para «última versão» pode perder o contexto de uma entrega anterior. Defina identificação, versões ou cópias autorizadas pertinentes. O método ajusta-se a ferramentas e obrigações de conservação. Não duplique tudo sem motivo, mas também não dependa de ficheiros sobrescritos quando precisa de reconstruir decisões passadas.

Teste permissões com uma pessoa autorizada que não criou o dossier. Deve localizar material sem pedir que o autor o envie novamente. Se falta acesso, atribua o acesso adequado; não abra toda a documentação indiscriminadamente. Um índice aparentemente completo pode falhar apenas porque as fontes ficaram inacessíveis após uma mudança de equipa.

Para material sensível, defina revisão de divulgação. O original e a versão preparada para partilhar conservam relação. A remoção de detalhe irrelevante não deve esconder informação necessária a uma autoridade ou obrigação aplicável. O destinatário e o propósito ajudam a determinar tratamento, mas não eliminam requisitos de fornecimento.

Revisão após uma alteração

Utilize o registo de mudança para identificar áreas afetadas. Autenticação pode exigir rever acesso e ensaios; dependência afeta inventário e vulnerabilidades; distribuição afeta verificação de atualizações. Atribua cada revisão e conserve resultado. Não repita provas sem razão, mas justifique a cobertura do que mudou.

Ao fechar a revisão, confirme correspondência com a compilação entregue. Questões abertas têm consequências e responsáveis. A aprovação identifica versão e condições. Não deve aparecer depois como certificação da empresa nem autorização automática de publicações futuras. O âmbito de uma decisão precisa de permanecer compreensível.

Uma correção editorial distingue-se de uma alteração técnica. Corrigir uma palavra não executa um novo ensaio. Mudar a conclusão de risco não é apenas atualizar apresentação. Essa distinção determina revisão adequada e ajuda a manter historial sem excesso de aprovações irrelevantes.

Exercício de reconstrução

Selecione uma versão anterior e peça explicar uma proteção. A pessoa deve localizar risco, requisito, decisão, ensaio e resultado. Compare também instruções e período de suporte aplicáveis. O exercício deteta problemas que um controlo de campos vazios não revela.

Classifique falhas observadas. Um link quebrado é conservação. Um ensaio sem versão é identificação. Uma prova que não cobre o controlo é cobertura técnica. Uma aprovação inexistente é responsabilidade. Cada problema precisa de ação própria; acrescentar um procedimento geral não resolve todos.

Defina saída verificável para as ações. Uma tarefa «melhorar documentação» não esclarece o que precisa de acontecer. «Associar relatório à compilação pertinente e obter revisão» permite avaliar resultado. Quando o responsável muda, preserve contexto e critérios para não reiniciar o trabalho sem fundamento.

Assistência de IA e origem das provas

A IA pode preparar um índice ou resumir material autorizado. Uma pessoa confirma nomes, versões, resultados e referências. Não aceite ensaios inventados nem conclusão que a fonte não sustenta. Uma ausência deve produzir uma lacuna e ação, em vez de uma frase que parece resolver tudo.

Transferir o dossier sem perder o fundamento

Quando muda o responsável, a pessoa nova verifica acesso, índice e questões abertas. Peça que explique uma decisão utilizando fontes, sem receber explicação privada do autor. Se falta contexto, identifique e corrija o registo. Uma entrega com ficheiros, mas sem relações, pode preservar conteúdo e perder o raciocínio aprovado.

Conserve critérios de aceitação durante a transferência. Alterar responsável não modifica automaticamente o que deve demonstrar-se. Se há razão para mudar critério, registe facto novo e aprovação. A história deve permitir distinguir aprendizagem técnica de ajuste feito apenas para fechar pendências.

O resultado da verificação indica versão testada, limitações e ações. Não precisa de reproduzir todas as conversas. Precisa de evidência suficiente para outra pessoa localizar fundamento e tomar a próxima decisão. Essa medida mantém continuidade e reduz dependência de quem criou o primeiro índice, sem atribuir ao software uma avaliação autónoma.

O Pulsar organiza documentos, riscos e decisões fornecidos. Engenharia executa ensaios e gera artefactos. O fabricante conserva documentação e avaliação de conformidade. O resultado útil permite mostrar o que se fez, em que versão e com que resultado. Muitos ficheiros sem relações apenas mudam o local onde a equipa procura informação.

Fontes

Fontes verificadas: 12 de setembro de 2026.

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