4028.3 Tests des CGI

sept.-2022

Directives du BVG

Comme il est expliqué à la section BVG Audit 5035.2, l’approche de test des CGI est basée sur la compréhension des applications informatiques et des dépendances aux TI pertinentes. L’auditeur tiendra compte alors du type d’application, des risques liés à l’informatique pertinents pour les dépendances aux TI et des contrôles à l’égard de ces risques.

Les éléments probants nécessaires pour confirmer l’efficacité du fonctionnement d’un contrôle général informatique (CGI) sont fonction du risque associé à ce contrôle. Bien que plusieurs CGI soient très répandus (p. ex. de nombreux contrôles automatisés du traitement de l’information de processus multiples peuvent dépendre des CGI), leur caractère généralisé en soi ne détermine pas automatiquement la nature du test à effectuer. Au contraire, le caractère généralisé est l’un parmi plusieurs facteurs de risques à prendre en compte. Le type de procédure de test mis en œuvre est déterminé en fonction de l’évaluation des facteurs de risque. Il faut éviter l’automatisme d’appliquer des tests de réexécution à tous les CGI. Voir la section BVG Audit 6053 pour obtenir des directives supplémentaires sur l’étendue des tests des contrôles. De plus, lorsque l’on établit dans quelle mesure l’on peut utiliser les travaux des auditeurs internes relatifs aux CGI, il importe de tenir compte que l’on peut accorder une plus grande confiance aux travaux des auditeurs internes à l’égard de CGI qui ne présentent pas un niveau de risque élevé. Par exemple, l’auditeur peut s’appuyer sur les travaux d’auditeurs internes pour tester les contrôles à l’égard des sauvegardes de données, c’est-à-dire des contrôles qui exigent normalement moins de jugement, mais il serait moins convenable d’utiliser ces travaux pour tester une modification à l’égard d’un contrôle et pour lequel il doit déterminer si les procédures sont planifiées et exécutées d’une manière adéquate et appropriée à la nature de cette modification et aux risques connexes. Voir les directives supplémentaires sur les facteurs à prendre en compte dans l’utilisation des travaux d’auditeurs internes, ou d’une fonction équivalente, à la section BVG Audit 6030. De plus, il convient de rappeler que les tests des contrôles par rotation mentionnés au paragraphe 14 de la NCA 330 ne s’appliquent habituellement pas aux CGI. L’auditeur doit habituellement tester au moins quelques contrôles généraux informatiques dans le cadre de l’audit en cours. Voir la section BVG Audit 6056 pour les directives supplémentaires sur la façon dont le paragraphe 14 de la NCA 330 impacte les CGI.

Une approche « universelle » de test des CGI ne répond pas aux risques pertinents pour l’audit de manière efficace et efficiente. En établissant l’approche, il est important de noter que les domaines des CGI et les CGI qui en font partie peuvent être pertinents pour l’audit à des degrés divers. Il est important de relever de manière appropriée les dépendances aux TI pertinentes pour l’audit et d’évaluer les risques liés à l’informatique à l’étape de la planification de l’audit, avec, s’il y a lieu, la collaboration de l’équipe Audit TI. L’approche serait ainsi adaptée aux risques connexes et produirait les éléments probants suffisants pour se fier au fonctionnement continu des dépendances aux TI pertinentes.

Voir la section BVG Audit 5035.2 pour plus de directives concernant la compréhension des domaines des CGI pertinents (accès aux programmes et aux données, modifications aux programmes, développement des programmes et opérations informatiques).

Directives du BVG

Introduction

En raison de la nature même des opérations des TI, des éléments probants écrits au sujet du fonctionnement des CGI ne sont peut-être pas toujours faciles à obtenir ou maintenus de manière constante, sans pour autant que les contrôles ne soient pas efficaces. Il suffit de trouver les éléments appropriés même s’ils sont différents. Les déficiences des CGI doivent être évaluées en fonction de leur impact individuel et cumulé sur la fiabilité des contrôles du traitement de l’information pertinents et d’autre information produite par le système (c.‑à‑d. rapports) avant de penser à apporter des changements importants à la stratégie d’audit.

Lorsque les audits antérieurs ont montré que l’environnement de contrôle informatique est déficient ou que certains CGI sont inefficaces et que nous savons que des mesures de correction apportées sont insuffisantes, il faudra élaborer notre plan d’audit en tenant compte de l’incapacité potentielle à se fier aux dépendances aux TI touchées pour l’audit des états financiers. Généralement, il serait nécessaire d’obtenir des éléments probants limités pour confirmer que les CGI dont les déficiences n’ont pas été corrigées restent inefficaces.

Cependant, si l’intégrité d’une dépendance aux TI est touchée par une ou plusieurs déficiences des CGI, il est important de ne pas poser automatiquement l’hypothèse que les dépendances des TI ne sont pas fiables et conclure qu’il faut effectuer des tests de corroboration supplémentaires des soldes des comptes et des opérations. Il faut faire appel au jugement professionnel pour évaluer l’efficacité générale des CGI à produire les éléments probants étayant l’intégrité des dépendances aux TI dont ils dépendent pendant la période au cours de laquelle les CGI ont été évalués; déterminer si une déficience des CGI peut aller jusqu’à compromettre l’intégrité de la dépendance aux TI. S’il est établi que la déficience ou la combinaison des déficiences des CGI a un impact sur une ou plusieurs dépendances aux TI, il faudrait envisager d’appliquer une autre approche de tests des dépendances aux TI avant de réviser le plan d’audit en raison de l’absence de fiabilité aux contrôles. Voir les sections BVG Audit 6054 et BVG Audit 4028.4 pour des directives sur la manière de tester les dépendances aux TI lorsque les CGI n’ont pas été testés.

Se reporter au graphique ci‑dessous pour savoir comment déterminer si les déficiences des CGI n’ont pas été exploitées.

Les déficiences des TI des progiciels standards

Notre évaluation des déficiences des progiciels standards ne diffère pas de celle visant les applications commandées sur mesure ou personnalisées. Cependant, les déficiences du contrôle de ces types d’applications sont généralement associées aux droits d’accès privilégiés. L’auditeur doit examiner la probabilité, et non seulement l’ampleur, d’un écart possible lorsqu’il évalue les risques associés à des droits d’accès inappropriés, y compris les droits d’accès puissants et la séparation des tâches potentiellement conflictuelle. Il serait avisé dans ces circonstances de demander l’aide de l’Audit des TI.

Évaluer les déficiences des CGI

Exemples de déficiences potentielles dans les contrôles internes :

• Un employé de l’entité possède un accès « super-utilisateur ». Un accès privilégié ne constitue pas de facto une déficience des contrôles. Toutes les applications sont assorties de comptes d’utilisateurs privilégiés. Une déficience n’existe que si une personne non autorisée détient un tel accès privilégié. Il peut y avoir des contrôles compensatoires en place : par exemple, toutes les écritures sont enregistrées dans un journal par l’application; une surveillance du journal est effectuée par la direction. Si l’auditeur est en mesure de prouver que la personne n’a pas utilisé l’accès de super-utilisateur au cours de l’année, le risque associé à cette déficience est faible.
• De nombreux utilisateurs au sein du service des finances partagent un code d’ouverture de session et un mot de passe. Ainsi, lorsqu’un employé est muté dans un autre service, il peut encore accéder à l’application. Il se peut qu’il y ait des contrôles compensatoires en place, par exemple l’examen des journaux d’activité par la direction ou l’évaluation des performances effectuée à un niveau de précision suffisamment élevé pour détecter toute entrée non autorisée.
• Les sauvegardes des données cruciales ne sont pas faites. Si le client n’a pas eu besoin de rétablir les sauvegardes pendant l’année en cours, on pourrait alors lui recommander de faire des sauvegardes à l’avenir en vue de se protéger contre toute perte éventuelle de données. Toutefois, si des problèmes sont survenus au cours de l’année précédente, la présence d’une déficience dépendra de la capacité qu’avait l’entité de restaurer ses données.

Si l’équipe de la mission a relevé une ou plusieurs déficiences dans les CGI, elle évalue quand même s’il est possible de se fier aux dépendances aux TI pertinentes, étant donné que l’entité peut exercer des contrôles compensatoires pour réduire l’incidence de déficiences des CGI, par exemple l’examen par la direction des journaux, ou appliquer d’autres méthodes de test aux dépendances aux TI pour éviter d’augmenter les tests de corroboration. Se reporter à BVG Audit 4028.4 pour des directives sur la manière de tester les dépendances aux TI lorsque les CGI sont déficients ou qu’ils n’existent pas.

Diagramme grandeur réelle

La présence d’un accès privilégié ne constitue pas une déficience de facto du contrôle interne. L’auditeur doit exercer son jugement professionnel lorsqu’il évalue les risques liés à l’accès privilégié (à la fois les risques de fraude et les risques d’erreur par inadvertance ou de corruption des données) ainsi que la nature et l’étendue des contrôles nécessaires pour atténuer ces risques. Voici certains facteurs dont il faut tenir compte lors de l’évaluation de ces risques :

• A‑t‑on un besoin opérationnel légitime d’accéder directement aux données? Si la direction estime qu’une restriction complète de l’accès aux données n’est pas réaliste sur un plan opérationnel ou risque de menacer la stabilité de l’environnement informatique, des restrictions à tout le moins partielles sont-elles appliquées, par exemple la restriction de l’accès à des applications ou à des plateformes en particulier et la répartition des responsabilités?
• Quels sont les risques inhérents associés à l’accès direct aux données, en tenant compte de facteurs comme :
  • la nature et le volume des activités liées à l’accès (p. ex. la maintenance normale des applications en comparaison à des activités fréquentes de nettoyages ou de correction des données);
• L’importance des données touchées relativement aux assertions contenues dans les états financiers;
• La portée des droits d’accès (p. ex. le nombre de cycles ou de processus opérationnels touchés);
  • la disponibilité de renseignements fiables sur la population de modifications apportées aux données;
  • le niveau de risque que des actifs et des passifs connexes soient touchés par des pertes ou la fraude;
  • la complexité de l’environnement informatique et de l’application, l’efficacité des contrôles intégrés de l’intégrité des données et la vulnérabilité des données à des accès par des moyens indirects;
  • les antécédents d’anomalies attribuables à des erreurs ou à la fraude liées à l’accès aux données.
• Les personnes qui accèdent à la base de données et aux fichiers de données sous-jacents sont-elles compétentes et autorisées à le faire dans le cadre de leurs responsabilités et pour les raisons approuvées par la direction? L’accès direct est‑il restreint à quelques personnes responsables des activités de maintenance informatique légitimes? Ces personnes sont-elles tenues à l’écart :
  • des responsabilités financières ou comptables;
  • de la responsabilité d’utiliser ou d’examiner les contrôles du traitement de données informatisées, comme les contrôles de rapprochement et d’interface;
  • de la possibilité de modifier le traitement du flux des données par rapport aux données pertinentes, par exemple par l’entremise des droits d’accès du programmeur ou du statut de « super-utilisateur »;
• La possibilité de changer des contrôles automatisés, au moyen par exemple des droits d’accès du programmeur ou de configuration :
  • l’accès aux biens matériels contrôlé au moyen de l’application, à des formulaires imprimés à l’avance ou à des chèques de nature délicate;
  • la possibilité d’autoriser ou de traiter des transactions au moyen d’autres droits d’accès (p. ex. au moyen des applications, ou manuellement, à l’extérieur de l’environnement informatique);
  • la possibilité d’accorder ou de modifier l’accès des utilisateurs;
  • la possibilité de modifier ou de supprimer les journaux des applications dans lesquels figurent les activités d’accès aux données;
  • la possibilité d’ajouter, de supprimer ou de modifier l’accès d’un utilisateur aux privilèges de sécurité;
• Des contrôles ont‑ils été mis en place pour examiner périodiquement les droits d’accès aux données en vue de déterminer s’ils cadrent toujours avec les responsabilités inhérentes au poste et les raisons approuvées par la direction?
• Les personnes ayant des droits d’accès aux données sont-elles soumises à une supervision compétente et attentive?
• Y-a-t‑il des contrôles en place pour offrir un accès temporaire et au besoin seulement (p. ex. l’accès global est accordé exceptionnellement pour régler un problème précis, mais est révoqué rapidement par la suite)?
• Des contrôles ont‑ils été mis en place pour faire un suivi et une surveillance indépendants des activités des personnes qui accèdent aux données directement, soit au moyen de journaux d’applications fiables, soit au moyen de journaux manuels, par des personnes indépendantes de celles qui possèdent les droits d’accès et suffisamment compétentes pour détecter des erreurs ou des activités non autorisées? (Si la dégradation du système pose un problème dans le cas des journaux d’exploitation du système, l’entité a-t‑elle envisagé d’enregistrer les journaux dans un serveur distinct et protégé?)
• Des vérifications des antécédents ou d’autres contrôles sont‑ils en place pour analyser correctement l’intégrité des personnes à qui l’on a accordé des droits d’accès à des données délicates?
• Des contrôles ont‑ils été mis en place pour veiller à ce que toutes les personnes ayant reçu un accès général aux données sachent, comprennent et attestent que la consultation ou la modification de fichiers de données à l’extérieur du processus normal et documenté pourrait avoir des conséquences graves? Ces attentes sont-elles régulièrement communiquées et renforcées?
• Y-a-t‑il un processus de gestion des modifications officiel en place pour contrôler les modifications apportées aux données? Obtient‑on des approbations officielles pour toutes les modifications, auprès de la partie qui en a fait la demande, des services informatiques (pour consigner la nécessité de la modification et sa justification) ainsi que du gestionnaire des utilisateurs (pour vérifier si la modification a été apportée correctement)?
• Des contrôles ont‑ils été mis en place, tels que l’examen d’un rapport présentant tous les éléments de données existants ou cumulés ayant été modifiés d’une période à une autre, afin de confirmer qu’aucune modification non autorisée n’a été apportée (comme la transmission d’avis électroniques ou l’examen d’un journal manuel lorsque le volume de modifications est raisonnable et que les personnes qui ont l’accès général ne peuvent consulter ni modifier le journal)? Si la direction affirme qu’il est difficile à mettre en place un tel contrôle de détection fiable en raison du volume de modifications ou de la difficulté à interpréter les journaux de modifications, existe-t‑il une solution de rechange satisfaisante, comme le suivi des modifications apportées à un sous-ensemble d’éléments de données dont le risque est élevé?
• Existe-t‑il d’autres contrôles (manuels ou automatisés) pour vérifier si les données n’ont pas été modifiées autrement que ce qui était prévu (p. ex. des rapprochements avec des données d’autres applications bien contrôlées ou des données d’une source externe)?

Les facteurs à prendre en compte ci‑dessus servent à évaluer d’abord s’il existe une déficience du contrôle interne et, le cas échéant, la gravité de cette déficience. Les déficiences du contrôle interne peuvent se présenter dans la conception des contrôles (p. ex. un accès direct et non surveillé aux données est accordé à des personnes qui peuvent également traiter des transactions financières) ou dans l’efficacité opérationnelle (p. ex. une défaillance des contrôles conçus pour surveiller et détecter des activités non autorisées quant à l’accès aux données). Généralement, la gravité d’une déficience liée à l’accès direct aux données d’applications importantes sur le plan financier doit être évaluée directement en ce qui concerne les anomalies significatives éventuelles au niveau des assertions pour un compte, puisque la restriction de l’accès aux données sur les transactions est habituellement directement rattachée à l’obtention d’assertions pertinentes des états financiers. Il n’est pas rare que des contrôles compensatoires manuels au niveau des processus opérationnels (p. ex. des évaluations des performances de l’entreprise, des analyses de transactions ou des rapprochements, et autres) constituent une partie importante de l’évaluation des déficiences liées à l’accès aux données, surtout pour les cycles d’affaires qui sont les plus vulnérables au risque de fraude. Note : il est très important que l’efficacité de ces contrôles compensatoires ne soit pas compromise par les déficiences liées à l’accès aux données qui font l’objet de l’évaluation (p. ex. la personne qui a obtenu un accès inapproprié aux données est la même que celle qui exécute les contrôles de détection compensatoires).

Savoir si la direction peut ou non démontrer, au moyen d’un ensemble équilibré de contrôles et de facteurs qualitatifs, que le risque d’une anomalie significative dans les états financiers attribuable à des modifications non autorisées ou incorrectes aux données comptables, apportées en raison d’un accès direct aux données, a été adéquatement réduit est essentielle pour évaluer les déficiences. Dans de nombreux cas, l’objectif du contrôle sera atteint au moyen de plusieurs couches de contrôle qui travaillent de concert pour atténuer le risque de façon suffisante. Pour prendre ces décisions, il faut faire preuve de beaucoup de jugement axé sur une grande compréhension de l’approche qu’a adoptée l’entité pour atténuer les risques de fraude et d’anomalie dans les états financiers associés à un accès direct aux données.

La dégradation du rendement du système est un argument fréquent contre la mise en place d’outils d’audit ou de journaux automatisés. Les entités estiment aussi que le volume de l’information enregistrée dans le journal serait trop important pour permettre un examen ou un contrôle raisonnable. Cependant, il pourrait être possible, dans la plupart des environnements, de réduire le volume d’activités d’accès direct par la mise en place de bon nombre des autres contrôles décrits plus haut, de sorte que l’enregistrement automatisé et l’examen des journaux deviennent moins contraignants.