Pourquoi le RACI est important dans les environnements réglementés
Les cadres réglementaires — notamment DORA, NIS2 et ISO 27001 — partagent une attente commune : les organisations doivent démontrer une responsabilité claire pour les décisions de sécurité. Lorsqu’un régulateur ou un auditeur demande « qui a approuvé cette exception ? » ou « qui est responsable de s’assurer que les contrôles de sécurité du pipeline sont appliqués ? », la réponse ne peut être vague ou répartie entre des équipes non identifiées.
Une matrice RACI (Responsable, Redevable, Consulté, Informé) est l’instrument de gouvernance établi pour cartographier les activités vers les rôles. Dans un contexte DevSecOps, elle sert un double objectif : elle structure la prise de décision interne et fournit aux auditeurs un document unique qui témoigne de la conception de la responsabilité.
Sans un RACI documenté, les organisations font face à plusieurs risques réglementaires :
- Incapacité à démontrer qui a approuvé les exceptions de sécurité ou les acceptations de risques
- Chemins d’escalade peu clairs lorsque les portes de sécurité échouent ou sont contournées
- Constats d’audit liés aux violations de séparation des tâches
- Sanctions réglementaires au titre de l’article 5 de DORA (responsabilité de l’organe de direction) ou de l’article 20 de NIS2 (gouvernance et responsabilité)
Le RACI expliqué pour les parties prenantes non techniques
Avant d’appliquer la matrice, il est essentiel que toutes les parties prenantes — en particulier les responsables conformité et les propriétaires de risques — comprennent les quatre désignations :
| Lettre | Rôle | Signification | Question clé |
|---|---|---|---|
| R | Responsable | La personne ou l’équipe qui effectue le travail | Qui fait la tâche ? |
| A | Redevable | La seule personne qui est finalement tenue de rendre des comptes — elle approuve ou signe | Qui répond au régulateur ? |
| C | Consulté | Ceux dont l’avis est sollicité avant qu’une décision ou action ne soit prise | Dont l’expertise est nécessaire ? |
| I | Informé | Ceux qui sont notifiés après qu’une décision ou action a été prise | Qui doit être informé ? |
Règle de gouvernance critique : Il doit y avoir exactement un « A » par activité. Si la redevabilité est partagée, elle est diluée — et une redevabilité diluée est, en termes réglementaires, aucune redevabilité du tout.
Matrice RACI complète pour les activités DevSecOps
La matrice suivante cartographie quatorze activités DevSecOps fondamentales vers huit rôles organisationnels. Elle doit être adaptée à la structure de votre organisation, mais fournit un point de départ robuste pour les environnements réglementés.
| Activité | CISO | Architecte sécurité | Responsable DevSecOps | Équipe plateforme / CI-CD | Responsable équipe dev | Développeur | Responsable conformité | Propriétaire de risque |
|---|---|---|---|---|---|---|---|---|
| Définition de la politique de sécurité | A | C | C | I | I | I | C | C |
| Configuration de sécurité du pipeline | I | C | A | R | C | I | I | I |
| Gestion des outils SAST/DAST/SCA | I | C | A | R | I | I | I | I |
| Triage des vulnérabilités | I | C | A | I | R | C | I | I |
| Exécution de la remédiation | I | C | I | I | A | R | I | I |
| Approbation d’exception/suppression | I | C | C | I | I | I | C | A |
| Configuration des portes de sécurité | I | R | A | R | C | I | C | I |
| Gestion du contrôle d’accès | A | C | R | R | C | I | C | I |
| Gestion des secrets | I | A | R | R | C | C | I | I |
| Réponse aux incidents | A | C | R | R | C | C | I | I |
| Préparation d’audit | I | C | R | C | C | I | A | I |
| Reporting des métriques | I | I | R | C | C | I | A | I |
| Évaluation des risques tiers | I | C | C | I | I | I | C | A |
| Formation sécurité | A | C | R | I | C | R | I | I |
Notes de gouvernance : Redevabilité et escalade
Redevabilité finale pour la sécurité du pipeline
Dans la matrice ci-dessus, le responsable DevSecOps est redevable de la configuration technique et de l’application de la sécurité du pipeline. Cependant, le CISO conserve la redevabilité ultime de la politique de sécurité et de son efficacité. Cette redevabilité à deux niveaux doit être clairement documentée.
Sous DORA, l’organe de direction (généralement le conseil d’administration ou le comité de direction) porte la responsabilité du cadre global de gestion des risques ICT. Le CISO agit comme leur délégué pour les opérations de sécurité. Cette délégation doit être formellement documentée et périodiquement révisée.
Chemin d’escalade
Lorsque des conflits surviennent — par exemple, une équipe de développement conteste une porte de sécurité bloquant une release — le chemin d’escalade doit suivre une procédure documentée :
- Premier niveau : Le responsable DevSecOps et le responsable d’équipe de développement tentent la résolution
- Deuxième niveau : L’architecte sécurité fournit une décision technique
- Troisième niveau : Le propriétaire de risque et le responsable conformité évaluent l’acceptation du risque
- Niveau final : Le CISO prend la décision contraignante, documentée dans le registre des risques
Chaque escalade doit être enregistrée. Les auditeurs rechercheront des preuves que le chemin d’escalade a été suivi — pas simplement qu’il existe sur le papier.
Adapter le RACI à la taille de l’organisation
Grande entreprise (séparation complète des rôles)
Les grandes organisations réglementées — banques, assureurs, opérateurs d’infrastructures critiques — doivent maintenir une séparation complète des rôles comme indiqué dans la matrice ci-dessus. Chaque rôle est tenu par un individu ou une équipe distinct(e). Cela fournit la séparation des tâches la plus forte et la piste d’audit la plus claire.
Exigences clés à cette échelle :
- Équipe DevSecOps dédiée séparée du développement et des opérations
- Rôle d’architecte sécurité distinct du responsable DevSecOps
- Implication formelle du responsable conformité dans les approbations d’exceptions
- Propriétaire de risque désigné par ligne métier ou portefeuille d’applications
Taille moyenne (rôles combinés)
Les organisations de 200 à 1 000 employés peuvent avoir besoin de combiner certains rôles. Les combinaisons acceptables incluent :
- Architecte sécurité + responsable DevSecOps (une personne, double rôle documenté)
- Responsable conformité + propriétaire de risque (s’il n’y a pas de conflit d’intérêt direct)
- Équipe plateforme + équipe DevSecOps (avec responsabilités de sécurité documentées)
Combinaisons inacceptables :
- Développeur + approbateur d’exceptions (l’auto-approbation viole la séparation des tâches)
- Responsable DevSecOps + seul trieur de vulnérabilités et seul approbateur d’exceptions (pas de revue indépendante)
Petite taille (séparation minimale viable)
Les petites entreprises réglementées doivent encore démontrer la redevabilité. Au minimum :
- Une personne désignée redevable de la politique de sécurité (même à temps partiel)
- Les approbations d’exceptions nécessitent la signature de quelqu’un d’autre que le demandeur
- Les responsabilités de préparation d’audit sont attribuées à un individu nommé
- Le conseil d’administration ou le comité de direction reçoit des rapports de sécurité périodiques
Documentez explicitement où les rôles sont combinés et quels contrôles compensatoires existent (par exemple, revue par les pairs, audit externe, contrôles automatisés).
Ce que les auditeurs doivent vérifier
Lors de l’évaluation du RACI DevSecOps d’une organisation, les auditeurs doivent rechercher des preuves selon trois dimensions :
1. Documentation
- Existe-t-il une matrice RACI formellement approuvée couvrant les activités DevSecOps ?
- Est-elle versionnée et révisée au moins annuellement ?
- Couvre-t-elle toutes les activités de sécurité critiques, pas seulement un sous-ensemble ?
- Les définitions de rôles sont-elles claires et cartographiées vers des individus ou équipes nommés ?
2. Preuves de redevabilité en pratique
- Échantillon d’approbations d’exceptions : qui les a effectivement approuvées ? Cela correspond-il au RACI ?
- Enregistrements de contournement de portes de sécurité : la partie redevable était-elle impliquée ?
- Enregistrements de réponse aux incidents : les rôles désignés ont-ils participé comme défini ?
- Permissions d’accès : les droits d’accès système s’alignent-ils avec les attributions RACI ?
3. Alignement entre RACI et permissions système
- Seuls ceux désignés comme Responsable ou Redevable de la gestion du contrôle d’accès doivent avoir des privilèges administratifs sur les plateformes CI/CD
- Les workflows d’approbation d’exceptions doivent appliquer la chaîne de signature définie dans le RACI
- L’accès aux journaux d’audit doit être restreint à ceux ayant des rôles Responsable ou Redevable pour la préparation d’audit
Signaux d’alerte pour les auditeurs et les responsables conformité
| Signal d’alerte | Pourquoi c’est important | Implication réglementaire |
|---|---|---|
| Pas de RACI documenté pour le DevSecOps | La redevabilité ne peut être démontrée | DORA Art. 5, ISO 27001 A.5.2 |
| Développeurs auto-approuvant les exceptions de sécurité | Violation de la séparation des tâches | PCI DSS Req. 6, SOC 2 CC6.1 |
| Équipe sécurité non consultée sur les changements de pipeline | Les contrôles de sécurité peuvent être affaiblis sans supervision | NIS2 Art. 21, ISO 27001 A.8.32 |
| CISO non informé des acceptations de risques | Lacune de supervision de l’organe de direction | DORA Art. 5(4), NIS2 Art. 20 |
| Plusieurs personnes listées comme Redevable pour la même activité | Redevabilité diluée — pas de point unique de propriété | Faiblesse de gouvernance générale |
| RACI non mis à jour après des changements organisationnels | La matrice ne reflète pas la réalité | ISO 27001 A.5.4 |
| Pas de preuve d’utilisation du chemin d’escalade | Suggère que les conflits sont résolus de manière informelle sans gouvernance | Déficience de piste d’audit |
Prochaines étapes
Une matrice RACI DevSecOps bien gouvernée est un document de contrôle fondamental. Elle sous-tend toutes les autres activités de gouvernance — de la conception du programme DevSecOps à la préparation à l’audit et à la gouvernance.
Les organisations doivent :
- Rédiger ou réviser leur RACI DevSecOps par rapport au modèle ci-dessus
- Valider que les permissions d’accès système s’alignent avec la matrice
- Tester le chemin d’escalade avec un exercice sur table
- Planifier une revue annuelle, alignée avec la gestion des changements organisationnels
- Conserver des copies versionnées comme preuves d’audit
Ressources connexes pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- Briefing d’audit exécutif
- Comment les auditeurs examinent le CI/CD
- Contrôles de sécurité CI/CD fondamentaux
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
