La documentation technique CRA : ce que contient chaque section (détail de l'Annexe VII)

La documentation technique est votre dossier de preuves pour la conformité CRA. Les autorités de surveillance du marché la demanderont. Les Organismes Notifiés l'examineront. Sans documentation technique complète, vous ne pouvez pas légalement mettre votre produit sur le marché de l'UE.

Ce guide détaille l'Annexe VII section par section, expliquant ce que chacune exige et comment la préparer.

Qu'est-ce que la documentation technique ?

La documentation technique (aussi appelée « dossier technique ») est le dossier complet de preuves démontrant que votre produit est conforme aux exigences du CRA.

Ce n'est pas :

• De la documentation marketing
• Uniquement des manuels utilisateur
• Un exercice de cases à cocher

C'est :

• Des preuves techniques complètes
• Une documentation vivante (mise à jour tout au long de la vie du produit)
• Votre défense dans les enquêtes de surveillance du marché
• Requis pour l'évaluation de conformité

Important : La documentation technique doit être préparée AVANT la mise sur le marché et conservée pendant 10 ans après la dernière unité mise sur le marché. Les autorités peuvent la demander à tout moment.

Aperçu de la structure de l'annexe VII

L'Annexe VII du CRA spécifie les exigences de documentation technique :

STRUCTURE DOCUMENTATION TECHNIQUE (Annexe VII)

1. DESCRIPTION GÉNÉRALE
   └── Identification du produit et usage prévu

2. CONCEPTION ET DÉVELOPPEMENT
   └── Comment la sécurité a été intégrée

3. ÉVALUATION DES RISQUES CYBERSÉCURITÉ
   └── Risques identifiés et traités

4. EXIGENCES ESSENTIELLES
   └── Comment les exigences de l'Annexe I sont satisfaites

5. NORMES APPLIQUÉES
   └── Normes utilisées et déviations

6. NOMENCLATURE DES COMPOSANTS LOGICIELS
   └── Composants et dépendances

7. RÉSULTATS DES TESTS
   └── Preuves de vérification

8. DÉCLARATION UE DE CONFORMITÉ
   └── Ou copie de celle-ci

9. GESTION DES VULNÉRABILITÉS
   └── Processus de sécurité post-marché

Section 1 : description générale

Objectif : Établir ce qu'est le produit et à quoi il sert.

Contenu requis

LISTE DE CONTRÔLE DESCRIPTION GÉNÉRALE

Identification du Produit :
[ ] Nom et numéro de modèle du produit
[ ] Version(s) matérielle(s)
[ ] Version(s) logicielle/firmware
[ ] Format ou plage de numéros de série
[ ] Identifiant unique du produit

Usage Prévu :
[ ] Description de la fonction principale
[ ] Utilisateurs/environnement cibles
[ ] Cas d'usage prévus
[ ] Usages non prévus (exclusions)

Catégorie du Produit :
[ ] Classification CRA (Par défaut/Important/Critique)
[ ] Justification de la classification
[ ] Réglementations produit connexes (le cas échéant)

Informations Marché :
[ ] Date de première mise sur le marché UE
[ ] États membres cibles
[ ] Canaux de distribution

Exemple

DESCRIPTION GÉNÉRALE

Nom du Produit : SmartSense Pro Capteur Industriel
Numéro de Modèle : SSP-3000
Version Matérielle : Rév C (PCB v3.2)
Version Firmware : 2.4.1

USAGE PRÉVU :
Le SmartSense Pro est un capteur environnemental industriel
conçu pour la surveillance des installations de fabrication.
Il mesure la température, l'humidité et la qualité de l'air,
transmettant les données via WiFi vers le cloud ou des serveurs locaux.

UTILISATEURS CIBLES :
- Responsables d'installations
- Intégrateurs d'automatisation industrielle
- Responsables conformité environnementale

ENVIRONNEMENT PRÉVU :
- Installations industrielles intérieures
- Température de fonctionnement : -10°C à +60°C
- Réseau : WiFi 802.11 b/g/n

NON PRÉVU POUR :
- Applications médicales ou de sécurité des personnes
- Installation extérieure
- Atmosphères explosives
- Usage consommateur/résidentiel

CLASSIFICATION CRA :
Produit par défaut. Non listé dans l'Annexe III ou IV.
Justification : Capteur à usage général sans fonctions
de sécurité ni application d'infrastructure critique.

MISE SUR LE MARCHÉ UE :
Première mise sur le marché : 15 mars 2027
Marchés cibles : Tous les États membres de l'UE
Distribution : Ventes directes et distributeurs autorisés

Section 2 : conception et développement

Objectif : Documenter comment la sécurité a été intégrée dans la conception du produit.

Contenu requis

LISTE DE CONTRÔLE DOCUMENTATION CONCEPTION

Architecture :
[ ] Diagramme d'architecture système
[ ] Diagramme d'interaction des composants
[ ] Diagramme de flux de données
[ ] Frontières de confiance identifiées

Conception Sécurité :
[ ] Description de l'architecture de sécurité
[ ] Implémentations cryptographiques
[ ] Mécanismes d'authentification
[ ] Modèle d'autorisation
[ ] Protocoles de communication sécurisée
[ ] Mesures de protection des données

Processus de Développement :
[ ] Description du cycle de développement sécurisé
[ ] Traçabilité des exigences de sécurité
[ ] Procédures de revue de code
[ ] Tests de sécurité en développement
[ ] Gestion de configuration

Gestion des Changements :
[ ] Procédures de contrôle de version
[ ] Évaluation d'impact des changements
[ ] Revue de sécurité pour les changements

À quoi ressemble une documentation « sécurité dès la conception »

APERÇU DE L'ARCHITECTURE DE SÉCURITÉ

1. FRONTIÈRES DE CONFIANCE
   +-----------------------------------------+
   |            Backend Cloud                 |
   |  (Authentification, stockage de données) |
   \---------------+-------------------------+
                   | TLS 1.3
   +---------------+-------------------------+
   |         Firmware de l'appareil           |
   |  +---------------------------------+    |
   |  |    Couche applicative           |    |
   |  +---------------------------------+    |
   |  |    Services de sécurité         |    |
   |  |  (Crypto, auth, démarrage sûr)  |    |
   |  +---------------------------------+    |
   |  |    Sécurité matérielle          |    |
   |  |  (Élément sécurisé, RNG)        |    |
   |  \---------------------------------+    |
   \-----------------------------------------+

2. AUTHENTIFICATION
   - Appareil vers cloud : TLS mutuel avec certificats d'appareil
   - Utilisateur vers appareil : l'API locale exige un jeton d'authentification
   - Provisionnement de certificats : provisionné en usine, unique par appareil

3. PROTECTION DES DONNÉES
   - Données au repos : chiffrement AES-256-GCM
   - Données en transit : TLS 1.3 avec épinglage de certificat
   - Données sensibles : stockées dans l'élément sécurisé

4. MÉCANISME DE MISE À JOUR
   - Mises à jour firmware signées (ECDSA P-256)
   - Vérification de signature avant installation
   - Protection anti-rollback via compteur de version
   - Vérifications automatiques des mises à jour (configurables par l'utilisateur)

Section 3 : évaluation des risques cybersécurité

Objectif : Documenter les risques identifiés et comment ils sont traités.

Contenu requis

LISTE DE CONTRÔLE ÉVALUATION DES RISQUES

Méthodologie :
[ ] Méthodologie d'évaluation des risques décrite
[ ] Définition du périmètre
[ ] Identification des actifs
[ ] Approche d'identification des menaces

Analyse des risques :
[ ] Menaces énumérées
[ ] Vulnérabilités considérées
[ ] Évaluation d'impact
[ ] Évaluation de probabilité
[ ] Notations de risque

Traitement des risques :
[ ] Décisions de traitement pour chaque risque
[ ] Contrôles de sécurité cartographiés sur les risques
[ ] Évaluation du risque résiduel
[ ] Critères d'acceptation du risque

Format d'évaluation des risques

ÉVALUATION DES RISQUES CYBERSÉCURITÉ

Produit : SmartSense Pro (SSP-3000)
Version : 2.4.1
Date d'Évaluation : Janvier 2027
Évaluateur : [Nom, Équipe Sécurité]

MÉTHODOLOGIE :
Basée sur ISO 27005 adaptée pour la sécurité produit.
Risque = Probabilité × Impact
Échelle : Faible (1-4), Moyen (5-9), Élevé (10-16), Critique (17-25)

─────────────────────────────────────────────────────────────
ID RISQUE : R-001
MENACE : Modification non autorisée du firmware
VULNÉRABILITÉ : Un firmware non signé pourrait être installé
IMPACT : Élevé (5) - Compromission appareil, fuite de données
PROBABILITÉ : Moyenne (3) - Nécessite accès physique
RISQUE INHÉRENT : 15 (Élevé)

CONTRÔLE : Vérification de signature du firmware
IMPLÉMENTATION : Signature ECDSA P-256 vérifiée avant installation
RISQUE RÉSIDUEL : 3 (Faible) - Attaque cryptographique improbable

STATUT : Atténué
─────────────────────────────────────────────────────────────

RÉSUMÉ DES RISQUES :
Total risques identifiés : 23
Critique : 0
Élevé : 3 (tous atténués à Faible/Moyen)
Moyen : 8 (tous atténués à Faible)
Faible : 12 (acceptés ou atténués)

ACCEPTATION DU RISQUE RÉSIDUEL :
Tous les risques résiduels sont dans la tolérance acceptable.
Signé : [Responsable Sécurité], [Date]

Section 4 : cartographie des exigences essentielles

Objectif : Démontrer comment chaque exigence de l'Annexe I est satisfaite.

Exigences annexe I, partie I

MATRICE DE CONFORMITÉ EXIGENCES ESSENTIELLES

ANNEXE I, PARTIE I - EXIGENCES DE SÉCURITÉ
═══════════════════════════════════════════════════════════

1. CONÇU SANS VULNÉRABILITÉS EXPLOITABLES CONNUES
   Statut : CONFORME
   Preuves :
   - Rapport de scan de vulnérabilités (Trivy) : 0 critique/élevé
   - Analyse des dépendances : Tous les composants aux dernières versions sécurisées
   - Rapport de test de pénétration : Aucune vulnérabilité exploitable trouvée
   Référence : Rapport de Test TR-2027-001, pages 15-23

2. CONFIGURATION SÉCURISÉE PAR DÉFAUT
   Statut : CONFORME
   Preuves :
   - Document de revue de configuration par défaut
   - Pas de mots de passe par défaut (identifiants uniques requis à l'installation)
   - Services non nécessaires désactivés par défaut
   - Protocoles sécurisés activés par défaut (TLS, pas HTTP)
   Référence : Document de Conception DD-004, Section 3.2

[Continuer pour toutes les exigences Annexe I...]

Exigences annexe I, partie II

ANNEXE I, PARTIE II - GESTION DES VULNÉRABILITÉS
═══════════════════════════════════════════════════════════

1. IDENTIFIER ET DOCUMENTER LES VULNÉRABILITÉS
   Statut : CONFORME
   Preuves :
   - Système de suivi des vulnérabilités (projet JIRA VULN)
   - Document du processus de veille CVE
   - Suivi des dépendances basé sur le SBOM
   Référence : Document de processus PD-VULN-001

2. TRAITER LES VULNÉRABILITÉS SANS RETARD
   Statut : CONFORME
   Preuves :
   - Document SLA de réponse aux vulnérabilités
   - Métriques historiques de temps de réponse
   - Processus de développement de correctifs
   Référence : Document de processus PD-VULN-002

3. APPLIQUER DES TESTS RÉGULIERS ET EFFICACES
   Statut : CONFORME
   Preuves :
   - Calendrier des tests de sécurité
   - Rapports de scans automatisés (hebdomadaires)
   - Rapports de tests d'intrusion annuels
   Référence : Plan de test TP-SEC-001

[Continuer pour toutes les exigences de la partie II...]

Section 5 : normes appliquées

Objectif : Documenter quelles normes ont été utilisées et comment.

Contenu requis

LISTE DE CONTRÔLE APPLICATION DES NORMES

Liste des normes :
[ ] Toutes les normes appliquées listées avec numéros de version
[ ] Normes harmonisées identifiées séparément
[ ] Référence à la publication au Journal officiel (si harmonisée)

Preuves d'application :
[ ] Comment chaque norme a été appliquée
[ ] Quels articles/sections s'appliquent
[ ] Toute déviation ou application partielle

Gestion des déviations :
[ ] Déviations documentées avec justification
[ ] Mesures alternatives pour les exigences en déviation
[ ] Évaluation des risques pour les déviations

Format documentation des normes

NORMES APPLIQUÉES

NORMES HARMONISÉES (présomption de conformité) :
─────────────────────────────────────────────────────────────
Norme : EN 303 645 (quand harmonisée pour le CRA)
Titre : Cybersécurité pour l'IoT Grand Public
Statut : Appliquée intégralement
Publication : JOUE [référence quand publiée]
Preuves : Rapport de Conformité aux Normes SCR-001
─────────────────────────────────────────────────────────────

AUTRES NORMES APPLIQUÉES :
─────────────────────────────────────────────────────────────
Norme : IEC 62443-4-1:2018
Titre : Sécurité pour l'Automatisation Industrielle - Développement Sécurisé
Statut : Appliquée (exigences sélectionnées)
Articles Appliqués : 5, 6, 7, 8, 10
Preuves : Documentation SDL SLD-001
─────────────────────────────────────────────────────────────

DÉVIATIONS :
─────────────────────────────────────────────────────────────
Norme : EN 303 645
Article : 5.3-2 (Identifiants uniques par appareil)
Déviation : Identifiants uniques par appareil mais non pré-provisionnés
Justification : L'appareil nécessite une configuration utilisateur ;
               identifiants créés lors de la première configuration
Mesure Alternative : Exigences de mot de passe fort appliquées,
                    verrouillage du compte après échecs de tentatives
Évaluation du Risque : Risque résiduel acceptable (voir R-015)
─────────────────────────────────────────────────────────────

Conseil : Automatisez la génération de votre SBOM dans CI/CD. La création manuelle de SBOM est sujette aux erreurs et ne passe pas à l'échelle sur les versions du produit.

Section 6 : nomenclature des logiciels

Objectif : Fournir la transparence sur les composants pour le suivi des vulnérabilités.

Contenu requis

LISTE DE CONTRÔLE DES EXIGENCES SBOM

Format :
[ ] Format lisible par machine (CycloneDX ou SPDX)
[ ] Résumé lisible par l'humain

Contenu :
[ ] Tous les composants logiciels listés
[ ] Versions des composants précisées
[ ] Informations sur le fournisseur incluses
[ ] Informations de licence incluses
[ ] Vulnérabilités connues à la date de l'évaluation

Périmètre :
[ ] Dépendances directes
[ ] Dépendances transitives
[ ] Composants du système d'exploitation (le cas échéant)
[ ] Bibliothèques tierces

Documentation SBOM

NOMENCLATURE DES COMPOSANTS LOGICIELS

Produit : SmartSense Pro (SSP-3000)
Version Firmware : 2.4.1
Format SBOM : CycloneDX 1.5
Généré : 2027-01-15
Outil : Trivy + syft

FICHIER SBOM :
sbom-ssp3000-v2.4.1.json (joint)

RÉSUMÉ DES COMPOSANTS :
─────────────────────────────────────────────────────────────
Total Composants : 127
  Dépendances Directes : 23
  Dépendances Transitives : 104

Par Type :
  Bibliothèques : 98
  Frameworks : 12
  Système d'Exploitation : 1 (FreeRTOS)
  Modules Firmware : 16

Par Licence :
  MIT : 45
  Apache 2.0 : 38
  BSD : 15
  LGPL : 8
  Propriétaire : 21 (composants internes)
─────────────────────────────────────────────────────────────

STATUT DES VULNÉRABILITÉS À L'ÉVALUATION :
─────────────────────────────────────────────────────────────
Date du Scan : 2027-01-15
Scanner : Trivy v0.48.0

Critique : 0
Élevé : 0
Moyen : 2 (acceptés - voir ci-dessous)
Faible : 5 (acceptés)

VULNÉRABILITÉS ACCEPTÉES :
CVE-2026-XXXXX (Moyen) : Composant xyz v1.2.3
  Statut : Non exploitable dans notre configuration
  Justification : Fonctionnalité non activée, chemin de code non accessible
  Date de Revue : 2027-04-15
─────────────────────────────────────────────────────────────

ENGAGEMENT MISE À JOUR SBOM :
Le SBOM sera mis à jour avec chaque version du firmware et mis
à disposition des clients sur demande.

Section 7 : résultats des tests

Objectif : Fournir la preuve que les exigences sont effectivement satisfaites.

Contenu requis

LISTE DE CONTRÔLE DOCUMENTATION DES TESTS

Planification des tests :
[ ] Plan de test avec périmètre et objectifs
[ ] Cas de test cartographiés sur les exigences
[ ] Description de l'environnement de test
[ ] Critères de réussite/échec

Exécution des tests :
[ ] Enregistrements d'exécution des tests
[ ] Résumé des résultats de tests
[ ] Tests échoués et résolution
[ ] Preuves de tests répétés

Types de tests :
[ ] Tests fonctionnels de sécurité
[ ] Scan de vulnérabilités
[ ] Tests d'intrusion (le cas échéant)
[ ] Tests par fuzzing (le cas échéant)
[ ] Revue de configuration

Format des résultats de tests

RÉSUMÉ DES RÉSULTATS DE TESTS

Produit : SmartSense Pro (SSP-3000) v2.4.1
Période de Test : Décembre 2026 - Janvier 2027
Responsable de Test : [Nom]

═══════════════════════════════════════════════════════════
CAMPAGNE DE TEST : TC-2027-001
═══════════════════════════════════════════════════════════

1. TESTS FONCTIONNELS DE SÉCURITÉ
   Périmètre : Authentification, autorisation, chiffrement, démarrage sécurisé
   Cas de Test : 85
   Réussis : 85
   Échoués : 0
   Référence : Rapport de Test TR-FUNC-001

2. SCAN DE VULNÉRABILITÉS
   Outil : Trivy v0.48.0 + Nessus Professional
   Périmètre : Firmware, services réseau, interface web
   Résultats :
     Critique : 0
     Élevé : 0
     Moyen : 2 (acceptés avec justification)
     Faible : 5 (acceptés)
   Référence : Rapport de Scan SR-VULN-001

3. TEST DE PÉNÉTRATION
   Prestataire : [Nom de la société tierce]
   Périmètre : Test en boîte noire de l'appareil déployé
   Durée : 5 jours
   Résultats :
     Critique : 0
     Élevé : 0
     Moyen : 1 (remédié avant publication)
     Faible : 3 (acceptés)
   Référence : Rapport Pentest PT-2027-001

═══════════════════════════════════════════════════════════
ÉVALUATION GLOBALE : RÉUSSI
Tous les résultats critiques et élevés remédiés.
Résultats Moyen/Faible acceptés avec justification documentée.
═══════════════════════════════════════════════════════════

Section 8 : déclaration UE de conformité

Objectif : Inclure la déclaration formelle ou une référence à celle-ci.

Contenu requis

La documentation technique doit inclure une copie de la déclaration UE de conformité (point 7 de l'annexe VII du règlement sur la cyberrésilience) ou, à défaut, une référence précise vers l'endroit où elle peut être obtenue. La déclaration UE de conformité accompagne chaque produit comportant des éléments numériques mis sur le marché de l'UE.

DÉCLARATION UE DE CONFORMITÉ

(Voir document DoC séparé ou inclure une copie dans la documentation technique)

Référence : DoC-SSP3000-2027-001
Date : 1er mars 2027
Emplacement : Documentation technique, annexe A

La déclaration UE de conformité accompagne chaque produit
et est disponible en téléchargement à l'adresse :
https://entreprise.com/support/ssp3000/doc

Section 9 : procédures de gestion des vulnérabilités

Objectif : Documenter les processus de sécurité post-marché.

Contenu requis

LISTE DE CONTRÔLE GESTION DES VULNÉRABILITÉS

Réception :
[ ] Méthodes de contact documentées (e-mail, formulaire web, security.txt)
[ ] Politique CVD publiée
[ ] Procédures de communication avec les chercheurs

Processus :
[ ] Procédures de triage
[ ] Méthodologie d'évaluation de la sévérité
[ ] Voies d'escalade
[ ] Processus de développement de correctifs
[ ] Procédures de test des correctifs

Communication :
[ ] Procédures de notification client
[ ] Processus de publication d'avis
[ ] Intégration du signalement ENISA (en cas d'exploitation active)

Surveillance :
[ ] Veille sur les vulnérabilités de dépendances
[ ] Veille sur la base de données CVE
[ ] Sources de renseignement sur les menaces

Documentation gestion des vulnérabilités

PROCÉDURES DE GESTION DES VULNÉRABILITÉS

1. MÉTHODES DE CONTACT
   Principal : security@entreprise.com
   Formulaire Web : https://entreprise.com/securite/signaler
   security.txt : https://entreprise.com/.well-known/security.txt
   Politique CVD : https://entreprise.com/securite/politique-divulgation

2. ENGAGEMENTS DE RÉPONSE
   Accusé de réception : Sous 3 jours ouvrés
   Évaluation Initiale : Sous 10 jours ouvrés
   Mises à jour de statut : Tous les 14 jours
   Objectif de Résolution : 90 jours (critique : 7 jours)

3. REPORTING ENISA
   Déclencheur : Exploitation active détectée
   Délai : Alerte précoce 24h, rapport détaillé 72h
   Responsable : Responsable Équipe Sécurité
   Processus : Voir PD-ENISA-001

4. HISTORIQUE
   Vulnérabilités traitées (24 derniers mois) : 3
   Temps de résolution moyen : 45 jours
   Rapports ENISA déposés : 0

Remarque : « 10 ans après la dernière unité mise sur le marché » signifie que si vous vendez des produits jusqu'en 2030, la conservation s'étend jusqu'en 2040. Planifiez votre stockage de documents en conséquence.

Quand faut-il mettre à jour la documentation technique ?

Documentation vivante

La documentation technique n'est pas statique :

DÉCLENCHEURS DE MISE À JOUR DE LA DOCUMENTATION TECHNIQUE

MISES À JOUR OBLIGATOIRES :
- Nouvelle version firmware/logicielle
- Publication d'un correctif de sécurité
- Vulnérabilité découverte et traitée
- Changement de conception affectant la sécurité
- Mise à jour de normes (si les normes appliquées changent)
- Changements de SBOM (composants nouveaux ou mis à jour)

REVUES PÉRIODIQUES :
- Trimestrielle : SBOM et statut des vulnérabilités
- Annuelle : revue complète de la documentation technique
- Avant la fin de la période d'assistance : gel final de la documentation

CONTRÔLE DE VERSION :
- Tous les documents sous contrôle de version
- Historique des changements maintenu
- Versions antérieures archivées

Exigences de conservation

CONSERVATION DE LA DOCUMENTATION

Durée de conservation : 10 ans à compter de la dernière unité mise sur le marché

Exemple de calendrier :
- Produit mis sur le marché pour la première fois : mars 2027
- Dernière unité mise sur le marché : décembre 2030
- Conservation de la documentation jusqu'à : décembre 2040

Exigences de stockage :
- Stockage sécurisé et accessible
- Procédures de sauvegarde
- Protection de l'intégrité
- Disponible dans [48 heures] suivant la demande des autorités

Erreurs courantes

Avertissement : Une documentation technique qui ne décrit que la version 1.0 alors que votre produit est en version 2.3 est considérée comme non conforme. Mettez à jour la documentation à chaque version.

Évaluation des risques incomplète

Problème : Évaluation des risques qui ne couvre pas toutes les menaces ou manque de détails sur le traitement.

Correction : Utiliser une méthodologie structurée. Mapper chaque risque identifié à un contrôle ou une décision d'acceptation.

SBOM manquant

Problème : Pas de SBOM ou SBOM qui n'inclut pas les dépendances transitives.

Correction : Générer le SBOM avec des outils appropriés. Inclure l'arbre de dépendances complet.

Documentation obsolète

Problème : La documentation technique décrit la version 1.0 mais le produit est en version 2.3.

Correction : Mettre à jour la documentation à chaque version. Suivre les versions explicitement.

Pas de traçabilité des exigences

Problème : Prétend la conformité mais ne montre pas comment chaque exigence est satisfaite.

Correction : Créer une cartographie explicite de chaque exigence de l'Annexe I vers les preuves.

Tests sans preuves

Problème : Affirme que des tests ont été réalisés sans que les rapports soient disponibles.

Correction : Conservez tous les rapports de test. Incluez-les dans la documentation technique ou référencez-les clairement.

Liste de contrôle de la documentation technique

LISTE DE CONTRÔLE DE COMPLÉTUDE DE LA DOCUMENTATION TECHNIQUE

SECTION 1 - DESCRIPTION GÉNÉRALE :
[ ] Identification du produit complète
[ ] Usage prévu documenté
[ ] Classification CRA indiquée avec justification
[ ] Informations de mise sur le marché

SECTION 2 - CONCEPTION :
[ ] Diagrammes d'architecture
[ ] Documentation de conception de sécurité
[ ] Description du processus de développement
[ ] Procédures de gestion des changements

SECTION 3 - ÉVALUATION DES RISQUES :
[ ] Méthodologie documentée
[ ] Tous les risques identifiés
[ ] Décisions de traitement pour chaque risque
[ ] Évaluation du risque résiduel

SECTION 4 - EXIGENCES ESSENTIELLES :
[ ] Cartographie Annexe I partie I complète
[ ] Cartographie Annexe I partie II complète
[ ] Preuves référencées pour chaque exigence

SECTION 5 - NORMES :
[ ] Toutes les normes appliquées listées
[ ] Preuves d'application fournies
[ ] Déviations documentées et justifiées

SECTION 6 - SBOM :
[ ] SBOM lisible par machine joint
[ ] Tous les composants inclus
[ ] Statut des vulnérabilités documenté

SECTION 7 - RÉSULTATS DE TESTS :
[ ] Plan de test documenté
[ ] Rapports de test joints
[ ] Tous les résultats traités

SECTION 8 - DoC :
[ ] Déclaration UE de conformité incluse/référencée

SECTION 9 - GESTION DES VULNÉRABILITÉS :
[ ] Méthodes de contact documentées
[ ] Processus documenté
[ ] Procédures ENISA en place

MAINTENANCE :
[ ] Contrôle de version établi
[ ] Procédures de mise à jour documentées
[ ] Plan de conservation en place

Prochaines étapes

Gérer la conformité CRA pour plusieurs produits ? CRA Evidence suit les preuves de votre dossier technique, les mises à jour SBOM et le mapping des exigences de l'Annexe I pour chaque version de produit.

Une fois votre évaluation des risques et vos documents de conception en place, complétez la Section 6 avec notre guide des exigences SBOM. Consultez le guide d'évaluation de conformité pour confirmer quel module s'applique avant de finaliser votre Déclaration de conformité.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil juridique. Pour des conseils de conformité spécifiques, consultez un conseiller juridique qualifié.