Un document de contrôle rédigé à partir de bonnes intentions décrit une organisation mieux gérée que la réalité. La relecture qui compte le plus est celle des personnes qui administrent les systèmes.
Cette année, nous avons réécrit nos propres documents de contrôle informatique en vue de notre audit annuel d’assurance indépendant. La rédaction a été soignée. Chaque document a reçu des objectifs de contrôle, des contrôles numérotés, un responsable pour chacun, une fréquence d’exécution et la preuve que le contrôle laisse derrière lui. Sur le papier, le résultat décrivait un parc informatique bien gouverné.
Puis trois de ces documents m’ont été soumis pour relecture, en tant que personne qui administre les systèmes qu’ils décrivent, et un certain nombre de contrôles ne tenaient pas tels qu’ils étaient rédigés.
Personne n’a rien écrit de faux délibérément. Les documents de contrôle sont généralement rédigés à partir d’un mélange d’anciennes politiques, de schémas d’architecture, de propositions de fournisseurs et de souvenirs. Chaque source est un peu dépassée, et chacune décrit quelque chose qui a été vrai un jour, qui est prévu pour plus tard, ou que l’on suppose standard.
Mises bout à bout, elles décrivent le parc tel que chacun voulait qu’il soit. Certains contrôles faisaient référence à des équipements que nous n’avons pas. D’autres décrivaient des processus prévus mais pas encore activés. Quelques-uns mentionnaient des serveurs qui ne sont plus dans nos locaux. Tous se lisaient très bien.
Une mission ISAE 3402 pose une question simple à propos de chaque contrôle : existe-t-il, et est-il conçu et mis en œuvre comme décrit ? L’auditeur ne note pas la qualité rédactionnelle. Il demande des preuves, et un contrôle qui décrit une capacité jamais construite n’en produit aucune.
Un document qui surestime l’environnement est donc pire qu’un document succinct. Il crée des constatations qui n’avaient pas lieu d’être, et il signale à l’auditeur qu’aucune des personnes qui gèrent les systèmes ne l’a lu avant sa signature.
L’opérateur relit avant toute approbation. Chaque document de contrôle est désormais soumis aux personnes qui gèrent les systèmes avant d’être présenté à la direction pour signature. Leur question est simple : pourrais-je produire demain la preuve de ce contrôle ?
Les inconnues repartent sous forme de questions. Lorsque la relecture ne permettait pas de confirmer un fait, le document n’a pas été réécrit sur la base d’une hypothèse. La question a été renvoyée par écrit à la personne qui connaissait la réponse, et le document a attendu.
Les écarts deviennent des décisions. Lorsqu’un contrôle décrit quelque chose que l’entreprise n’a pas, il existe deux options honnêtes : le mettre en place, ou le consigner comme exception avec un responsable, une justification et une date de revue. Certains cas relèvent de corrections techniques d’une journée. D’autres ont un coût, et doivent être soumis à la direction pour décision.
La plupart des organisations qui passent par une mission d’assurance pour la première fois font ce constat, et beaucoup le font tard, face à l’auditeur. Il coûte bien moins cher de le faire à son propre bureau.
Si vous préparez une mission ISAE 3402 ou tout exercice similaire, confiez le projet de dispositif de contrôle à la personne qui administre les systèmes et demandez-lui de barrer tout ce dont elle ne peut pas apporter la preuve. Ce qui reste constitue votre environnement de contrôle. Ce qui est barré constitue votre plan de travail.
Notre approche de la sécurité et de l’assurance pour nos clients est présentée sur la page confiance et sécurité.
Fait partie de la série Contrôles internes. Recevez les nouvelles analyses par e-mail ou suivez le flux RSS.
La plupart des politiques informatiques disent ce qui devrait se passer. Un auditeur a besoin de savoir qui fait quoi, à quelle fréquence, et quelle preuve cela laisse. Réécrire nos politiques sous cette forme a changé bien plus que leur présentation.
Des normes appliquées de la même façon sur chaque mission, c’est ce qui permet à une petite équipe de développement de garder son rythme au-delà du premier mois. Voici ce que cela donne en pratique.
L’IA change le rythme auquel le travail de livraison est produit. Elle ne change rien à la question de savoir qui en répond. C’est la place de cette ligne qui fait d’une livraison assistée par l’IA un avantage ou un risque.