Aller au contenu principal

Les 10 politiques essentielles pour tout programme GRC (modèles gratuits)

Tout programme GRC solide repose sur des politiques claires et opérationnelles. Voici les 10 politiques fondamentales dont chaque organisation a besoin ; rédigées en langage simple, alignées sur les normes ISO, NIS 2, DORA et GDPR, et prêtes à l'emploi immédiat.

Christophe MazzolaChristophe Mazzola· Practicing CISO · Founder of Cyber Academy5 min de lecture
Top 10 Essential Policies for Every GRC Program

La plupart des organisations ont des politiques ; mais très peu ont des politiques que les gens suivent réellement.

Le problème n'est pas le contenu. C'est la complexité, le jargon, et le fait que la plupart des politiques semblent avoir été rédigées par des juristes qui n'ont jamais rencontré les personnes censées les appliquer.

Un vrai programme GRC commence par des politiques claires et pratiques que les équipes comprennent, adoptent et utilisent réellement au quotidien.

Voici les 10 politiques essentielles dont chaque organisation a besoin ; sans remplissage, sans fioritures, juste ce qui fonctionne.

Vous n'avez pas besoin de 40 politiques. Vous avez besoin d'un référentiel de politiques cohérent et allégé qui couvre la gouvernance, la sécurité, les données, le risque et les opérations ; sans noyer vos équipes sous la paperasse.

Chaque politique doit répondre à trois questions :

  • Qu'est-ce qui est exigé ?
  • Qui en est responsable ?
  • Comment le prouvons-nous ?

Ces 10 politiques constituent l'épine dorsale de tout programme GRC sérieux. Passons-les en revue.

1. Politique de sécurité de l'information (la politique maîtresse)

C'est votre étoile polaire. Elle définit les objectifs de sécurité, les engagements et les attentes de l'organisation.

Elle doit :

  • définir le SMSI ou le cadre de gouvernance de la sécurité
  • attribuer les responsabilités (CISO, responsables, managers)
  • établir les principes de sécurité de haut niveau
  • donner autorité à toutes les autres politiques
  • s'aligner sur ISO 27001, NIS2, DORA

Une bonne politique de sécurité de l'information est courte, claire et directive ; pas un roman de 25 pages.

2. Politique de contrôle d'accès

C'est là que la plupart des violations se produisent, et que les régulateurs regardent en premier.

Doit inclure :

  • les modalités de création des comptes
  • les modalités de suppression des comptes
  • les exigences MFA
  • les règles d'accès privilégié
  • les revues périodiques des accès
  • le processus joiner–mover–leaver (JML)
  • les standards d'authentification

Anecdote : Dans 90 % des audits NIS2, un contrôle d'accès défaillant est le premier constat. Cette politique y remédie.

3. Politique de gestion des actifs

Vous ne pouvez pas protéger ce que vous n'avez pas identifié.

À couvrir :

  • inventaire matériel
  • inventaire logiciel
  • actifs cloud
  • classification des données
  • règles de propriété
  • systèmes tiers
  • référentiels de configuration

C'est également ici que commence l'AI Act : identifier les actifs IA avant de les gouverner.

4. Politique de gestion des risques

L'épine dorsale de tout programme GRC. Sans elle, vos contrôles n'ont aucune logique.

Doit définir :

  • la méthodologie de gestion des risques
  • les sources de menaces
  • les échelles de vraisemblance et d'impact
  • l'approbation de l'acceptation des risques
  • le lien avec les plans de traitement
  • les rôles et responsabilités
  • la fréquence de révision

Si vous ne documentez pas votre méthodologie, votre registre des risques n'est pas défendable.

5. Politique de réponse aux incidents

NIS2 et DORA rendent cette politique obligatoire ; avec des règles de notification strictes.

À inclure :

  • niveaux de gravité
  • chemins d'escalade
  • rôles (technique, juridique, direction, communication)
  • processus de notification 24h / 72h
  • règles de communication
  • préservation des preuves
  • interaction avec le CSIRT
  • revue post-incident

Une politique qui précise « comment nous gérons les jours difficiles » est non négociable.

6. Politique de continuité d'activité et de reprise après sinistre (BC/DR)

Votre plan de résilience.

À couvrir :

  • exigences du BIA
  • objectifs de reprise (RTO/RPO)
  • stratégie de sauvegarde
  • gestion de crise
  • tests de reprise (DR)
  • sites de repli
  • propriété des plans

Les régulateurs veulent la preuve que vous pouvez continuer à opérer ; même quand vos fournisseurs défaillent.

7. Politique de sécurité des fournisseurs et des tiers

L'exigence la plus sous-estimée de NIS2.

  • classification des fournisseurs (critique / important / non critique)
  • étapes de due diligence
  • clauses contractuelles de sécurité
  • surveillance continue
  • intégration et sortie (onboarding/offboarding)
  • transparence sur les sous-traitants
  • stratégie de sortie

Si vos fournisseurs ne sont pas encadrés, vous n'êtes pas conforme.

8. Politique de protection des données et de la vie privée

GDPR rend cette politique obligatoire, mais les équipes l'interprètent souvent mal.

Doit inclure :

  • la base légale du traitement
  • les droits des personnes concernées
  • les règles de conservation
  • la minimisation des données
  • les transferts de données
  • les critères de DPIA
  • les règles de notification des violations
  • les exigences de privacy by design

Rendez-la pratique ; pas rédigée en jargon juridique.

9. Politique d'utilisation acceptable (AUP)

Votre première ligne de défense contre l'erreur humaine.

Doit énoncer clairement :

  • l'utilisation acceptable des systèmes informatiques
  • les restrictions (ex. : messagerie personnelle, clés USB)
  • les règles d'utilisation de l'IA
  • les exigences en matière de mots de passe
  • les exigences du télétravail
  • le signalement des comportements suspects

L'AUP doit être suffisamment courte pour que les collaborateurs la lisent réellement.

10. Politique de développement sécurisé et de gestion des changements

La politique qui maintient l'alignement entre l'ingénierie et la gouvernance.

  • attentes en matière de codage sécurisé
  • exigences de revue de code
  • sécurité du pipeline
  • gestion des dépendances
  • processus d'approbation des changements
  • exigences de tests
  • séparation des tâches
  • gouvernance de l'infrastructure-as-code

C'est également ici que le code généré par l'IA doit être revu sous l'angle de la sécurité.

Politiques complémentaires (selon le contexte)

Si cela est pertinent pour votre organisation, envisagez d'ajouter :

  • Politique de cryptographie
  • Politique de journalisation et de supervision
  • Politique de gouvernance de l'IA (alignée sur l'EU AI Act et ISO 42001)
  • Politique de gestion des vulnérabilités
  • Politique de télétravail
  • Politique des appareils mobiles
  • Politique de conservation des enregistrements

Ces politiques ne sont pas obligatoires pour tous ; les 10 premières, elles, le sont.

Modèles gratuits

Vous trouverez ci-dessous des modèles de politiques simplifiés, prêts à l'emploi, que vous pouvez adapter. Ils sont volontairement courts et pratiques.

Réflexion finale

Les politiques ne sont pas des documents ; ce sont des attentes rendues explicites.

Si vos politiques sont trop longues, trop théoriques ou rédigées en jargon juridique, votre programme GRC s'effondrera sous son propre poids.

Commencez léger. Écrivez clairement. Attribuez les responsabilités. Révisez régulièrement. Et faites des politiques l'épine dorsale vivante de votre gouvernance ; pas de la paperasse pour l'auditeur.

Si vous souhaitez des modèles de politiques alignés sur ISO 27001, NIS2, DORA, GDPR et l'EU AI Act ; c'est exactement ce que nous partageons dans les formations Cyber Academy Lead Implementer. Rejoignez la prochaine session et obtenez un accès immédiat.

Vous voulez recevoir la prochaine note de terrain dans votre boîte mail ?

La newsletter The GRC Brief. Cinq liens et une prise de position courte, chaque lundi à 8h CET. Trois minutes de lecture.