Votre checklist d’action
- 01
Nommer les responsables
Désignez un sponsor de direction et des responsables opérationnels. Identifiez les prestataires, assureurs et contacts de crise sans confondre contrat de support et capacité de réponse à incident. Pour chaque décision critique, distinguez préparation, autorisation et exécution. Conservez un titulaire et un relais joignable hors des outils habituels. Vérifiez que les contrats indiquent les horaires, limites et prérequis d’intervention avant d’en avoir besoin.
- 02
Identifier les services vitaux
Définissez les activités indispensables, leurs données et leurs fournisseurs. Faites valider des objectifs de reprise réalistes et testables par les métiers. Décrivez une chaîne complète, par exemple commande, paiement, confirmation et livraison. Une application disponible peut rester inutile si son fournisseur d’identité ou son export comptable ne fonctionne plus. Les objectifs de reprise doivent couvrir ces dépendances.
- 03
Réduire les accès et l’exposition
Revoir les accès distants, les privilèges, la messagerie et les services exposés. Supprimez les comptes dormants et les usages non approuvés de logiciels ou d’IA. Contrôlez l’arrivée et le départ d’un salarié ou d’un prestataire sur un exemple réel autorisé. Vérifiez que comptes, sessions, clés et accès partagés sont traités ensemble. Toute exception conserve une justification, une date de revue et un responsable.
- 04
Exiger des preuves des fournisseurs
Vérifiez les responsabilités partagées, les sous-traitants, l’export des données et les procédures de sortie. Demandez des éléments datés adaptés au service, au-delà d’un logo de certification. Posez une question testable : pouvez-vous récupérer vos données dans un format exploitable et redémarrer une activité ? Vérifiez le périmètre des attestations et la date des tests fournis. Un engagement commercial ne remplace pas une démonstration de réversibilité.
- 05
Exercer la continuité
Simulez une indisponibilité de messagerie ou d’un SaaS critique. Testez les contacts hors ligne, la restauration et les décisions de communication avec les équipes métiers. Annoncez un scénario et mesurez décisions, délais et obstacles, sans perturber la production. Un exercice peut montrer que les contacts ne sont plus valides ou que les moyens de paiement dépendent du même compte que la messagerie.
- 06
Suivre des mesures utiles
Suivez délais de correction, comptes privilégiés, restauration testée et alertes traitées. Présentez les risques résiduels et les décisions attendues plutôt qu’un score global sans méthode. Associez chaque indicateur à une population, une période et une décision. Distinguez sauvegardes exécutées et restaurations réussies, correctifs déployés et expositions supprimées. Évitez de comparer des pourcentages dont le dénominateur change sans explication.
Exemple pédagogique : une PME dépend d’une messagerie hébergée pour ses commandes et ses accès administratifs. Rejouez la perte du compte principal avec un contact de secours et un canal indépendant. Vérifiez l’accès aux informations nécessaires à la reprise sans utiliser le compte indisponible. Notez ensuite les dépendances circulaires, le responsable de chaque correction et la preuve attendue au prochain essai.
Références : données, usages et limites
Documentation consultée le .
| Source et objet | Donnée ou repère vérifié | Comment l’utiliser | Limite à conserver |
|---|---|---|---|
| NIST · Cybersecurity Framework Structurer les résultats attendus d’un programme de cybersécurité. |
CSF 2.0 comporte six fonctions : Govern, Identify, Protect, Detect, Respond et Recover. Le cadre ne prescrit pas une unique façon d’obtenir les résultats. | Décrivez un profil actuel et un profil cible avec preuves, écarts et responsables. Rattachez chaque priorité aux services qu’elle aide à protéger. | Une correspondance avec le cadre n’équivaut pas à une certification ni à la preuve que chaque contrôle fonctionne. |
| NIST · SP 800-61 Rev. 3 Préparer la réponse à incident dans la gestion du risque cyber. |
La révision 3 a été publiée en avril 2025 et remplace la révision 2. Elle se présente comme un profil communautaire du CSF 2.0. | Exercez décision de confinement, conservation des traces, communication et reprise. Comparez ce qui était prévu aux preuves produites pendant l’exercice. | Lire le guide ne valide pas un plan local. Les contacts, accès de secours et dépendances doivent être testés dans votre environnement. |
| NIST · Privacy Framework Examiner les risques pour les personnes liés au traitement de données. |
Le Privacy Framework est un outil volontaire de gestion des risques pour la vie privée. Il se distingue d’une liste unique d’obligations juridiques. | Décrivez le traitement réel : données, finalités, destinataires, accès et durées. Comparez documents, configurations et tests de suppression ou de récupération. | L’utilisation du cadre ne détermine pas à elle seule la conformité au droit applicable. Le contexte du traitement et la juridiction restent à examiner. |
Sécurité email : identité, alignement et transport
Messagerie d’entreprise : séparer identité et disponibilité
Une messagerie peut réussir SPF ou DKIM pour un domaine tiers tout en échouant à l’alignement du domaine From. Documentez chaque prestataire et chaque usage avant d’interpréter un indicateur global.
- Séparer les alertes critiques, les échanges humains et les campagnes.
- Associer les résultats d’authentification au domaine réellement évalué.
- Rapprocher les rapports DMARC des incidents de transport TLS ; ils n’observent pas le même phénomène.
Consulter le comparatif et le simulateur DMARC →
Références et statut consultés le · SPF · RFC 7208 DKIM · RFC 6376 DMARC · RFC 9989
Retry-After : attente, budget et décision de reprise
Une reprise peut amplifier une panne de dépendance
Le délai global et le nombre d’essais doivent traverser les couches de l’intégration. Chaque étage qui réessaie sans coordination peut augmenter le travail final.
- Identifier client, SDK, proxy et file qui peuvent chacun relancer une demande.
- Comparer délai serveur, délai local et budget restant avant de relancer.
- Séparer lecture rejouable et écriture dont l’effet doit d’abord être rapproché.
Explorer Retry-After et le modèle de reprise →
Références relues le · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS
Webhooks : signatures et rejeu
Une reprise API et une reprise webhook suivent deux contrats
Pour une notification entrante, suivez l’événement, la tentative de transport et l’effet métier séparément. La signature authentifie un message ; elle ne constitue pas une clé d’idempotence.
- Conserver les octets bruts requis et authentifier chaque nouvelle tentative.
- Préparer une reprise propre au fournisseur : Stripe peut réessayer automatiquement ; GitHub ne relivre pas automatiquement les échecs.
- Tester réponse perdue, concurrence et rapprochement après panne.
Voir les signatures, les empreintes et les dix cas webhooks →
Sources vérifiées le · Stripe · Webhooks · Stripe · Manage webhook endpoints · GitHub · Validating webhook deliveries · GitHub · Best practices for using webhooks · GitHub · Handling failed webhook deliveries
PDF : expurgation et diffusion
La revue documentaire porte sur le fichier et son partage
Un dossier de confiance numérique doit montrer quels contrôles ont porté sur quelle copie. Une grille de résultats ne remplace ni la vérification des contenus ni celle des accès et versions accessibles.
- Définir le périmètre de confidentialité et les informations nécessaires au destinataire.
- Conserver les résultats et les contrôles non réalisés sans les convertir en score rassurant.
- Faire correspondre la copie approuvée au fichier réellement diffusé.
Voir les surfaces et la matrice de revue avant partage →
Sources vérifiées le · Adobe · Redacting and sanitizing PDFs · Adobe · Redact sensitive content · Adobe · Sanitize PDFs · ICO · Avoid accidental breaches when redacting · ICO · Hidden information in documents · Microsoft · Document Inspector

