Guia CRA • documentação técnica

Documentação técnica do CRA: índice prático do Anexo VII

Como organizar a documentação técnica exigida pelo Cyber Resilience Act: produto, arquitetura, risco, vulnerabilidades, testes, suporte e declaração de conformidade.

Responsável editorial: Cícero Grangeiro da SilvaRevisado em 2 set. 2026Fontes oficiais verificáveisLeitura: 11 minutos
Distribuição responsável

Compartilhe este guia com a equipe.

Os links preservam a fonte e identificam o canal de origem. Para Instagram e TikTok, use o compartilhamento do celular.

LinkedInWhatsAppFacebookX

01 • arquitetura da prova

Documento sem vínculo com produto e versão é evidência fraca

O fabricante deve preparar a documentação técnica antes de colocar o produto no mercado. Para ser útil, cada item precisa indicar o produto, a versão, a decisão que sustenta, o responsável, a aprovação e o evento que exige revisão.

Não centralize segredos em uma planilha.Crie um índice com localização autorizada e controle de acesso. A preparação comercial não precisa copiar código-fonte, credenciais ou relatórios confidenciais.

02 • Anexo VII

Oito blocos formam a espinha dorsal

BlocoConteúdo operacionalPergunta de controle
1. ProdutoFinalidade, versões relevantes, imagens de hardware e instruções ao usuário.Qual versão esta pasta representa?
2. Construção e processosArquitetura, componentes, produção, monitoramento e tratamento de vulnerabilidades.Como os componentes formam o produto?
3. RiscoAvaliação de risco e aplicação dos requisitos essenciais.Qual decisão deriva de cada risco?
4. SuporteInformações usadas para determinar o período de suporte.A duração tem fundamento verificável?
5. EspecificaçõesNormas, especificações comuns, esquemas ou soluções técnicas adotadas.Quais partes foram realmente aplicadas?
6. TestesRelatórios que verificam produto e processos de vulnerabilidade.O resultado corresponde à versão?
7. DeclaraçãoCópia da declaração UE de conformidade.Assinatura e escopo estão coerentes?
8. SBOMQuando aplicável, a lista pode ser fornecida mediante pedido fundamentado da autoridade.É possível gerar uma versão confiável?

03 • governança

Um índice resolve a busca; a governança resolve a confiança

Identidade

Família, modelo, versão, mercado e configuração cobertos.

Proveniência

Autor, aprovador, sistema de origem e histórico de revisão.

Integridade

Estado aprovado, hash ou controle de versão quando necessário.

Disponibilidade

Responsável e suplente conseguem localizar a evidência no prazo.

O regulamento exige manter documentação e declaração à disposição das autoridades. A retenção e o acesso devem ser alinhados ao período aplicável, sem transformar a pasta em um repositório público.

04 • operação

Uma rotina mínima evita a “documentação de emergência”

  1. 01
    Nomeie um proprietário do índice

    Ele coordena, mas cada área continua responsável pelo conteúdo que produz.

  2. 02
    Defina eventos de revisão

    Release, mudança de arquitetura, novo componente, vulnerabilidade relevante e alteração de suporte.

  3. 03
    Faça amostragem mensal

    Escolha uma evidência crítica e teste se versão, aprovação e localização continuam válidas.

  4. 04
    Simule uma solicitação

    Meça quanto tempo a equipe leva para montar o pacote sem expor dados indevidos.

05 • recurso público

Comece com um índice leve e portátil

O modelo gratuito inclui produto, versão, bloco do Anexo VII, evidência, localização, responsável, aprovação, validade e lacuna. Abra em Excel, Planilhas Google ou qualquer editor compatível com CSV.

Modelo de índice de evidências CRAArquivo CSV sem macros, cadastro ou upload.
Baixar modelo gratuito ↓

06 • verificação

Fontes oficiais

Regulamento (UE) 2024/2847artigo 31 e Anexo VII ↗Comissão — resumo legislativodocumentação, risco e suporte ↗Comissão — obrigações do fabricanteantes, durante e depois do mercado ↗Guia Ponte Segura — SBOMcomponentes, qualidade e acesso →

Modelo de organização inicial. Não substitui a documentação técnica exigível nem a avaliação de conformidade do produto.