5035.2 Identification des risques découlant du recours à l’informatique et des CGI connexes

sept.-2022

Directives du BVG

Dans le cadre de l’acquisition d’une compréhension et de l’évaluation du système de contrôle interne de l’entité, l’auditeur acquiert une compréhension de la façon dont l’entité utilise les technologies de l’information (TI) pertinentes pour la préparation des états financiers et de la façon dont l’entité réagit aux risques découlant du recours à l’informatique, ou il actualise sa compréhension à cet égard. Voir la section BVG Audit 5034 pour de plus amples renseignements sur l’acquisition d’une compréhension de l’environnement informatique lié au système d’information.

Ce n’est qu’après avoir compris la pertinence de l’environnement informatique pour la préparation des états financiers que l’auditeur comprend pleinement les processus, les flux de données et les risques de l’entité, y compris les risques découlant du recours à l’informatique. Voici des exemples de facteurs qui peuvent influencer le besoin d’une entité d’utiliser les technologies de l’information (TI) :

• le type d’activités (p. ex., une entité qui développe une propriété numérique nécessitant la protection d’une infrastructure informatique complexe);

• le modèle opérationnel (p. ex., ventes en ligne, activité d’abonnement);

• la conformité aux lois ou aux règlements (p. ex., lois sur la protection des données ou exigences de dépôt électronique des organismes de réglementation);

• les risques liés à l’information financière identifiés par l’entité dans le cadre de ses activités qui peuvent être atténués au moyen de la technologie (p. ex., calculs automatisés pour réduire au minimum les erreurs manuelles).

Pourquoi est‑ce important?

C’est en identifiant les applications informatiques et d’autres aspects de l’environnement informatique (p. ex., bases de données, système d’exploitation, réseau) pertinents pour la préparation des états financiers que les équipes de mission sont en mesure d’identifier les risques découlant du recours à l’informatique et les contrôles généraux informatiques (CGI) connexes qui répondent à ces risques. Cela permet à l’équipe de mission de comprendre l’entité, d’identifier et d’évaluer les risques d’anomalies significatives et d’évaluer le risque lié aux contrôles documenté par la détermination par l’auditeur du degré d’appui sur les contrôles (c.‑à‑d. aucun, partiel ou élevé), ainsi que d’élaborer des réponses d’audit efficaces et efficientes à l’égard des risques d’anomalies significatives.

Par conséquent, même si l’auditeur décide plus tard de ne pas tester l’efficacité opérationnelle des CGI ou d’autres contrôles, les risques pour lesquels ces contrôles sont conçus devront être compris dans le cadre de l’évaluation des risques et pris en compte lors de l’élaboration des réponses aux risques d’anomalies significatives. Par exemple, l’entité peut gérer ses comptes clients au moyen d’une application informatique (le « grand livre auxiliaire des créances », qui interagit automatiquement avec l’application de recouvrement des recettes utilisée pour comparer les produits par rapport à la facture) parce qu’il y a un volume important d’opérations relatives aux produits et au recouvrement et que la direction a conclu qu’il est plus efficace que de gérer le processus manuellement à l’aide d’une application de feuille de calcul comme Microsoft Excel. La direction met en place des CGI et d’autres contrôles de traitement de l’information visant à assurer un traitement exact de l’information reflétée dans le grand livre auxiliaire des créances et à en maintenir l’intégrité. Indépendamment de tout plan visant à tester l’efficacité opérationnelle des contrôles portant sur les assertions pertinentes relatives au poste des comptes clients, l’utilisation de cette application informatique comporte des risques, comme le risque que des modifications non autorisées ou non testées, ou que l’omission d’apporter les modifications nécessaires à la configuration de l’application lors de la production d’un rapport généré par le système, comme un rapport chronologique des comptes clients, puisse entraîner un traitement incomplet et inexact des enregistrements de transactions. L’auditeur considère ce risque comme faisant partie de son processus d’évaluation des risques, même s’il a l’intention d’utiliser le rapport uniquement à des fins de tests de corroboration. Si l’auditeur prévoit utiliser le rapport dans le cadre d’un test des contrôles ou de procédures de corroboration, il doit tout de même tenir compte de l’exhaustivité et de l’exactitude des données sources (dans cet exemple, il s’agit des données reçues par l’interface avec l’application de recouvrement des recettes; par conséquent, l’auditeur pourrait devoir tenir compte de l’interface comme une dépendance aux TI et de la logique du rapport).

Dans la rubrique ci‑dessous, Identification des risques découlant du recours à l’informatique, on aborde plus en détail l’identification des risques découlant du recours à l’informatique et, dans la rubrique Identification des CGI de l’entité qui répondent aux risques découlant du recours à l’informatique, on se penche sur l’identification des CGI utilisés pour gérer ces risques, ce qui comprend de façon combinée l’élément « Identifier les risques liés à l’informatique et les contrôles généraux informatiques » du processus d’évaluation des risques du BVG illustré ci‑dessous.

Identification des risques découlant du recours à l’informatique par l’entité et des CGI de l’entité qui répondent à ces risques

Le tableau suivant montre comment on utilise la compréhension des divers éléments du système de contrôle interne d’une entité pour identifier les risques découlant du recours à l’informatique par l’entité et des CGI que l’entité a mis en place pour répondre à ces risques :

Diagramme grandeur réelle

Mise en correspondance de la terminologie de la NCA 315 et du Manuel d’audit du BVG

Contrôles généraux informatiques

La NCA 315 utilise le terme « contrôles généraux informatiques », qui correspond au terme « contrôles généraux informatiques (CGI) » utilisé dans le Manuel d’audit du BVG.

Domaines des CGI

La norme NCA 315 fournit des exigences pertinentes qui répondent au besoin de comprendre les contrôles internes de l’entité et souligne l’importance d’acquérir une compréhension appropriée de l’environnement informatique. Bien que les noms de domaine des CGI utilisés dans le Manuel d’audit du BVG n’aient pas été mis à jour pour correspondre aux noms de domaine des CGI révisés utilisés dans la NCA 315 (révisée), la signification des termes est la même et les procédures connexes sont conçues en vue de l’évaluation de la conception et du test du fonctionnement des CGI pertinents pour les couches relatives au réseau, au système d’exploitation ou aux bases de données, en conformité avec les exigences et les directives de la norme révisée. Ces noms de domaine utilisés dans le Manuel d’audit du BVG pourraient être mis à jour à l’avenir afin que soient éliminés les termes plus restrictifs comme « programmes » ou « programmes et données ». Pour l’instant, le tableau suivant présente une mise en correspondance des noms de domaine des CGI utilisés dans le Manuel d’audit du BVG avec ceux utilisés dans la NCA 315 :

*La NCA 315 fait référence à trois processus informatiques : gestion de l’accès, gestion des changements et gestion des opérations informatiques. Les directives du Manuel d’audit du BVG comprennent un quatrième domaine, « Développement de programmes », qui permet à l’auditeur d’identifier et de cibler plus facilement les activités liées au développement au sein de l’entité et les travaux d’audit connexes. De même, si l’entité n’entreprend pas de développement au cours de la période, ce domaine des CGI n’aurait pas besoin d’être évalué, ce qui aide à faciliter des pratiques de travail efficaces et efficientes.

Directives du BVG

Les contrôles généraux informatiques (CGI) sont des contrôles afférents aux processus informatiques de l’entité qui contribuent à assurer le bon fonctionnement continu de l’environnement informatique, notamment le maintien du fonctionnement efficace des contrôles du traitement de l’information et l’intégrité (c’est-à-dire l’exhaustivité, l’exactitude et la validité) des informations se trouvant dans le système d’information de l’entité. (NCA 315.12(d)). Il est question, par exemple, des restrictions et des droits d’accès prévus dans la conception du système de contrôle interne de l’entité.

Les CGI comprennent habituellement l’octroi et le retrait de droits d’accès d’utilisateurs, l’administration de la sécurité, l’application de contrôles d’authentification (p. ex., mot de passe), la séparation des tâches et la surveillance des activités d’accès direct et de changements à la sécurité à l’intérieur et dans l’ensemble de l’environnement informatique. La présence de déficiences dans les CGI pourrait compromettre l’efficacité des contrôles mis en œuvre par la direction relativement à la séparation des tâches ou à d’autres objectifs de contrôle connexes, en permettant des droits d’accès inappropriés. Cet accès pourrait permettre l’apport de changements inappropriés à l’information conservée dans le système d’information de l’entité. Les risques découlant du recours à l’informatique mènent à la prise en compte des CGI qui répondent à ces risques. Des CGI bien conçus, mis en place et tenus à jour de façon appropriée jettent les bases sur lesquelles d’autres contrôles peuvent s’appuyer aux fins de la gestion de ces risques.

Exemple :

Le risque suivant a été identifié par rapport aux soldes des comptes clients d’une entité : « La méthode (y compris tout modèle), les hypothèses importantes et les données utilisées pour estimer les pertes de crédit attendues ne sont pas appropriées/raisonnables ». Les contrôles suivants répondant au risque ont été identifiés :

Détection, contrôle manuel de détection dépendant des TI : le gestionnaire des finances examine le rapport de classement chronologique des comptes clients généré par le système (qui est configuré de manière à répartir les factures en tranches d’âge) pour déterminer les soldes de clients impayés depuis longtemps et les problèmes connus dans le grand livre auxiliaire des créances ainsi que la provision pour créances douteuses correspondante afin de veiller à ce que les soldes des comptes aient des réserves suffisantes. Les écarts sont examinés et corrigés en temps opportun. L’auditeur applique le diagramme d’illustration dans la rubrique ci‑dessus, Identification des applications informatiques et d’autres aspects de l’environnement informatique, pour identifier les dépendances aux TI, les aspects connexes de l’environnement informatique qui sont vulnérables aux risques découlant du recours à l’informatique et les CGI connexes qui répondent à ces risques :

Cet exemple démontre qu’un risque peut être traité par les CGI d’une entité, mais que ceux‑ci ne visent pas à répondre à l’ensemble des risques potentiels découlant du recours à l’informatique.

Il peut y avoir d’autres considérations et contrôles à tester pour permettre de s’appuyer sur ce rapport, selon l’approche de test déterminée. Par exemple, les contrôles en matière de traitement de l’information portant sur la préparation et la tenue à jour du rapport (voir la section BVG Audit 4028.4 pour obtenir des conseils sur les tests de la fiabilité de l’information produite par une application informatique).

Comme l’indique la section BVG Audit 5031, les contrôles au niveau de l’entité (CNE) fonctionnent au niveau de l’entité. Les facteurs relatifs à l’ensemble des processus informatiques sont des contrôles informatiques qui ont une incidence sur plus d’un processus opérationnel et qui sont pris en compte au moment d’évaluer l’efficacité du traitement de l’information ou des contrôles directs au niveau des transactions et au niveau de l’entité dans un processus opérationnel. L’auditeur détermine également si ces facteurs relatifs à l’ensemble des processus informatiques pourraient être liés à des risques généralisés. Voir la rubrique ci‑dessus, Identification des risques découlant du recours à l’informatique.

Les CGI aident à déterminer la fiabilité continue de l’information générée par les applications. Les CGI sont généralement classés dans quatre domaines, comme il est décrit ci‑dessous.

*Les domaines des CGI couvrent l’environnement informatique dans son ensemble et se rapportent aux processus informatiques présentés dans la NCA 315, conformément à la mise en correspondance dans la rubrique Aperçu ci‑dessus.

En ce qui concerne les risques découlant du recours à l’informatique par une entité, l’auditeur examine lequel des quatre domaines des CGI peut être pertinent. Par exemple, dans le cas d’une entité qui s’appuie sur un certain nombre d’applications, le domaine Développement de programmes ne peut être pertinent que lorsque des projets importants de développement, de mise en œuvre ou de conversion ont une incidence sur le risque d’anomalies significatives. Se reporter à la rubrique sur les domaines des CGI ci‑dessous pour obtenir des conseils sur chaque domaine des CGI.

Le tableau suivant présente quelques exemples de CGI couramment mis en place en vue de répondre aux risques découlant du recours à l’informatique, classés par domaine informatique.

Voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité ci‑dessous pour un examen plus approfondi des risques et des contrôles liés à la cybersécurité qui pourraient avoir une incidence sur un ou plusieurs des domaines des CGI.

Directives du BVG

Accès aux programmes et aux données* – Objectif du domaine :

Veiller à ce que l’accès autorisé aux applications informatiques et à d’autres aspects de l’environnement informatique soit accordé uniquement lorsque l’identité d’un utilisateur est authentifiée. Les contrôles d’accès à l’environnement informatique englobent les processus utilisés par l’entité pour ajouter, supprimer et modifier des noms d’utilisateurs (les utilisateurs des opérations et le personnel informatique) et leurs droits d’accès connexes, selon les objectifs de contrôle établis dans la conception du contrôle (autrement dit, pour atteindre les objectifs de l’entité quant à l’accès restreint et à la séparation des tâches).

*Le domaine Accès aux programmes et aux données couvre l’accès à l’environnement informatique dans son ensemble et se rapporte au domaine « Gestion de l’accès » de la NCA 315, conformément à la mise en correspondance présentée à la rubrique Aperçu ci‑dessus.

Lorsqu’il s’agit de comprendre les contrôles d’accès à l’environnement informatique, l’auditeur cherche généralement à comprendre les risques pour la sécurité de l’entité, la stratégie qu’elle a adoptée en matière de sécurité et les aspects pertinents de son architecture de sécurité propre à l’informatique (p. ex. ouverture de session unique pour se connecter au réseau en comparaison à des mesures de sécurité propres aux applications), et ce, avant de déterminer quelles couches de sécurité et quels contrôles de l’accès sont importants pour répondre aux risques découlant du recours à l’informatique qui ont été identifiés (c.‑à‑d. les risques liés l’informatique pertinents pour la préparation des états financiers).

Les sous-composantes du domaine Accès aux programmes et aux données comportent habituellement les éléments suivants :

• gestion des activités de sécurité;
• administration de la sécurité;
• accès direct aux données (bases de données ou fichiers de données)
• sécurité du système d’exploitation;
• programmes utilitaires (p. ex., ordonnanceurs, outils de production de rapports)
• sécurité du réseau;
• sécurité du matériel.

Voici des exemples de CGI qui peuvent servir à gérer l’accès à l’environnement informatique : (NCA 315, annexe 6.2(a)):

• Authentification
• Autorisation
• Attribution
• Révocation
• Accès privilégié
• Examens des accès utilisateurs

Lorsqu’il acquiert une compréhension de ce qui précède, l’auditeur doit prendre en compte que certaines sous-composantes et certains CGI peuvent ne pas s’appliquer à chaque entité et que d’autres facteurs de risque peuvent exister. La manière dont l’accès est demandé, autorisé et contrôlé varie d’une entité à l’autre, en fonction de la taille et de la complexité de l’environnement et du volume et des types d’accès traités.

L’auditeur doit envisager d’utiliser les guides pratiques et les programmes de travail de la plateforme technique applicables pour l’aider à évaluer les contrôles d’accès dans le domaine de l’accès aux programmes et aux données.

L’auditeur acquiert cette compréhension des sous-composantes et des CGI pour l’aider à déterminer quelles couches de contrôles de sécurité sont pertinentes pour la préparation des états financiers et obtenir des éléments probants sur la présence et l’application des éléments les plus importants. Par exemple, les contrôles de la sécurité du périmètre ou du piratage, comme les pare‑feu et les systèmes de détection des intrusions, peuvent être pertinents pour la préparation des états financiers s’il existe des risques significatifs liés à l’information financière qui ne sont pas adéquatement couverts par la sécurité au niveau de l’application à elle seule. De plus, si des applications utilitaires comme des ordonnanceurs ou des outils de production de rapports sont utilisés pour appuyer des rapports ou des interfaces clés, ces applications utilitaires peuvent être pertinentes pour la préparation des états financiers. Le graphique suivant illustre les différentes couches de sécurité dans l’environnement informatique :

Diagramme grandeur réelle

Accès direct aux bases de données ou aux fichiers de données

L’accès aux données est un aspect courant et essentiel de l’exploitation de la plupart des systèmes comptables informatisés. Cependant, la direction doit mettre en place un ensemble équilibré de contrôles pour atténuer les risques d’anomalies significatives dans les états financiers provenant de modifications non autorisées ou erronées apportées aux données comptables par l’accès direct aux données. En général, l’auditeur concentre son évaluation des risques liés à l’accès direct aux données sur les couches des bases de données ou des applications. Le risque lié à l’accès direct aux données au niveau du système d’exploitation est généralement moins élevé, car les données ne devraient pas être conservées ni consultées directement au niveau du système d’exploitation. Comme l’illustre la figure ci‑dessus, tous ces éléments se trouvent dans le réseau interne. Le réseau périmétrique et les activités relatives à la sécurité sont les endroits où se produisent les passages à l’environnement informatique externe et à l’environnement Web (p. ex., Internet). Comme il a été mentionné ci‑dessus, c’est dans le réseau périmétrique que les contrôles de prévention et de détection des intrusions et de surveillance sont établis aux fins de prévention des attaques (p. ex., rançongiciel) qui peuvent empêcher l’entité d’accéder à son infrastructure ou à ses données essentielles. D’autres risques et contrôles en matière de cybersécurité peuvent avoir trait à l’accès aux programmes et aux données, ou à d’autres domaines des CGI. Pour obtenir des directives supplémentaires sur les risques et les contrôles en matière de cybersécurité, voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité ci‑dessous.

Quand l’accès aux données est restreint aux utilisateurs autorisés des services informatiques, les risques opérationnels, tels qu’un arrêt accidentel du système ou la restauration incorrecte de données, d’interfaces ou de programmes, tendent à être plus élevés que les risques d’anomalie intentionnelle ou d’autres types de fraude. Si le personnel responsable de l’information financière (p. ex., le contrôleur financier) peut directement changer des données, l’auditeur pourrait devoir déterminer s’il s’agit d’un indicateur de risque de fraude potentiel. Pour évaluer les risques liés à l’accès privilégié, il faut examiner la probabilité que surviennent ces risques, et non pas uniquement leur ampleur.

Les considérations suivantes peuvent être utiles pour identifier les CGI dans le domaine de l’accès aux programmes et aux données qui répondent aux risques découlant du recours à l’informatique par une entité. Voir la rubrique Identification des risques découlant du recours à l’informatique ci‑dessus pour de plus amples renseignements sur l’identification des risques découlant du recours à l’informatique. Il est à noter que certains points ne sont pas pertinents pour toutes les entités et qu’il y aura peut-être lieu d’examiner d’autres facteurs de risque possibles.

Le tableau ci‑dessous présente des exemples de risques et de points à considérer pour l’audit, répartis par sous-composante et faisant référence aux CGI dont il est question.

*Voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité ci‑dessous pour un examen plus approfondi des risques et des contrôles liés à la cybersécurité qui pourraient avoir une incidence sur un ou plusieurs des domaines des CGI.

Directives du BVG

L’entité doit démontrer, avec une assurance raisonnable, que des contrôles suffisants des modifications sont exécutés de façon constante pour tous les aspects de l’environnement informatique, ce qui comprend les applications informatiques, le réseau, les bases de données ou les systèmes d’exploitation qui sont vulnérables aux risques découlant du recours à l’informatique. Les sous-composantes du domaine Modifications aux programmes comprendraient généralement ce qui suit :

• gestion des activités de maintenance;
• caractéristiques, autorisation et suivi des demandes de modification;
• construction;
• tests et assurance de la qualité;
• implantation du programme;
• documentation et formation;
• modifications de données;
• séparation des tâches.

Voici des exemples de CGI qui peuvent servir à la gestion des changements apportés à l’environnement informatique (NCA 315, annexe 6.2(b)) :

• processus de gestion du changement;
• séparation des tâches dans le cadre de l’intégration des changements à l’environnement de production.

Lorsqu’il acquiert une compréhension de ce qui précède, l’auditeur doit prendre en compte que certaines sous-composantes et certains CGI peuvent ne pas s’appliquer à chaque entité et que d’autres facteurs de risque peuvent exister. La manière dont les modifications sont relevées, suivies et contrôlées varie d’une entité à l’autre, en fonction de la taille et de la complexité de l’environnement et du volume et des types de modifications traitées. Lorsqu’il détermine son approche pour gérer le risque associé aux modifications apportées au programme, l’auditeur acquiert une compréhension de la nature des modifications apportées pendant la période visée l’audit (p. ex., changements apportés au code source, à la configuration des bases de données ou des systèmes d’exploitation, changements apportés aux données, etc.).

Lorsque l’auditeur examine les risques découlant du recours à l’informatique associés aux changements informatiques, il commence par acquérir une compréhension de la nature des changements apportés au cours de la période visée par l’audit (c’est-à-dire les modifications au code source, à la configuration de la base de données ou des systèmes d’exploitation, etc.) aux applications et à d’autres aspects de l’environnement informatique identifiés. Lorsque les changements ont une incidence sur les dépendances aux TI identifiées, l’auditeur peut choisir de s’appuyer sur les contrôles des modifications pour répondre aux risques découlant du recours à l’informatique. La capacité de l’entité de savoir si un contrôle de traitement de l’information automatisé ou un contrôle manuel dépendant des TI clé a été modifié, et quand il l’a été, constitue un élément important de l’efficacité des contrôles sur les modifications, que l’auditeur ait envisagé ou non de le tester dans le processus de modifications et que les contrôles des modifications aient été appliqués ou non de manière uniforme. Cela exige habituellement qu’un certain lien soit établi entre les activités de modifications informatiques et l’imputabilité et la surveillance dans leur ensemble. Il s’agit aussi d’un critère essentiel, non seulement pour appuyer une stratégie d’étalonnage (comme il est décrit à la section BVG Audit 6054), mais également pour se servir des tests des CGI comme fondement à un appui sur l’efficacité du fonctionnement continu des contrôles du traitement de l’information et des contrôles informatiques manuels durant la période d’audit en cours. On peut restreindre considérablement ou éliminer les tests des contrôles sur les modifications si le risque de modifications importantes à une application clé est faible. Cela peut se faire, par exemple, au cours du processus d’identification des risques où le logiciel standard utilisé par le client n’a pas été personnalisé ou si d’autres éléments probants fiables démontrent qu’un contrôle pertinent automatisé ou un contrôle manuel dépendant des TI n’a pas été modifié depuis la dernière fois où il a fait l’objet de tests (p. ex. un rapport du système ou un élément probant sur lequel figure la date de la dernière modification).

Détermination de la population entière de modifications apportées aux programmes

Lorsque l’environnement informatique de l’entité produit des éléments probants fiables (c.‑à‑d. une piste d’audit) concernant la population entière de modifications, il est plus facile de suivre et de vérifier que toutes les modifications pertinentes ont été soumises aux contrôles sur les modifications de l’entité. Par exemple, si un rapport fiable sur toutes les dates de compilation des modifications mises en production est disponible, il est plus facile pour la direction de démontrer que le processus de contrôle a été suivi pour toutes les modifications.

Cependant, les environnements informatiques ne sont pas tous conçus pour produire des renseignements fiables et automatisés au sujet de la population de modifications. Certains consigneront uniquement la date de la dernière modification. D’autres peuvent consigner toutes les modifications, mais il se peut aussi que les personnes ayant un accès direct à l’environnement de production soient capables de contourner cette procédure ou d’écraser les données enregistrées. L’absence de données générées par l’environnement informatique au sujet des modifications n’empêche pas la direction de démontrer, avec une assurance raisonnable, que les contrôles des modifications de l’entité sont appliqués de façon constante aux modifications pertinentes. Certains facteurs à examiner pour déterminer s’il y a une assurance raisonnable que toutes ces modifications ont été prises en charge correctement comprennent généralement :

• les types d’applications utilisés, si l’entité a accès au code source et la nature et le volume des modifications courantes;

• si les modifications font l’objet d’un suivi rigoureux par voie électronique ou manuelle, par des parties indépendantes des personnes qui demandent ou apportent les modifications, au moyen de données ne pouvant être modifiées par ces personnes;

• si des environnements distincts sont maintenus pour l’élaboration, les tests et la production, et si seules les personnes autorisées ont accès à chacun de ces environnements;

• si les responsabilités sont réparties adéquatement, de sorte que la personne responsable du repérage, du suivi et de la présentation de l’information sur l’état des demandes de modifications n’assume pas de responsabilités sur le plan comptable ou financier;

• si un enregistrement automatisé de la « piste d’audit » est activé pour l’environnement informatique.

Les directives ci‑dessous peuvent être prises en compte lors de l’évaluation des risques découlant du recours à l’informatique; voir la rubrique Identification des risques découlant du recours à l’informatique pour obtenir de plus amples renseignements sur l’identification de tels risques. Les points à considérer suivants pourraient guider l’auditeur dans l’identification des CGI dans ce domaine qui répondent aux risques découlant du recours à l’informatique identifiés au sein de l’entité. Il est à noter que certains points ne sont pas pertinents pour toutes les entités et qu’il y aura peut-être lieu d’examiner d’autres facteurs de risque. Par exemple, les risques liés à la cybersécurité et les contrôles connexes peuvent être liés aux modifications de programmes ou à d’autres domaines des CGI. Voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité pour obtenir des directives supplémentaires sur les risques liés à la cybersécurité et les contrôles connexes.

Le tableau ci‑dessous présente des exemples de risques et de points à considérer pour l’audit, répartis par sous-composante et faisant référence aux CGI dont il est question.

*Voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité ci‑dessous pour un examen plus approfondi des risques et des contrôles liés à la cybersécurité qui pourraient avoir une incidence sur un ou plusieurs des domaines des CGI.

Directives du BVG

Développement de programmes* - Objectif du domaine :

Veiller à ce que les applications informatiques et d’autres aspects de l’environnement informatique soient élaborés, configurés et mis en place de manière à atteindre les objectifs de la direction en matière de contrôle. Cela comprend des contrôles portant sur des projets de développement, d’acquisition ou de mise en œuvre ainsi que des contrôles relatifs à la conversion de données.

* Le domaine Développement de programmes couvre les changements apportés à l’environnement informatique dans son ensemble et se rapporte au domaine « Gestion des changements » de la NCA 315, conformément à la mise en correspondance présentée à la rubrique Aperçu.

Ce domaine est pertinent seulement lorsque d’importants projets d’élaboration, d’implantation ou de conversion sont réalisés ou prévus et que ces projets auront une incidence sur le risque d’anomalies significatives dans les états financiers de l’exercice en cours. Les CGI liés au domaine Développement de programmes seront identifiés en vue de l’identification des risques découlant du recours à l’informatique relatifs aux nouvelles applications informatiques ou à d’autres aspects informatiques élaborés, configurés et déployés au cours de la période. Par exemple, lorsqu’une nouvelle application informatique est utilisée dans le cadre d’un contrôle identifié, il se peut que l’auditeur identifie un risque lié à des données qui sont traitées de façon incomplète ou inexacte dans cette application. Par conséquent, afin de répondre au risque, la direction a mis en place des CGI pour tester et approuver l’application informatique.

La NCA 315 prévoit le développement dans le processus informatique « Gestion des changements ». Comme ci‑dessus, le domaine du développement de programmes n’est pertinent que lorsque l’entité a des projets importants de développement, de mise en œuvre ou de conversion au cours de la période. Des projets de développement peuvent ne pas avoir lieu chaque année. La séparation du développement de programmes et de la modification de programmes aide l’auditeur à évaluer de façon plus détaillée la façon dont le changement se produit dans l’environnement informatique de l’entité. Cela l’aide également à identifier et à évaluer les risques découlant du recours à l’informatique au niveau du domaine :

• Lorsque l’entité n’entreprend aucun développement au cours de la période, aucun risque lié au domaine Développement de programmes ne découle du recours à l’informatique.

• Lorsque l’entité entreprend un projet de développement au cours de la période, le domaine Développement de programmes est celui où les risques liés au développement découlant du recours à l’informatique sont documentés.

Les CGI portant sur le développement varieront d’une entité à l’autre et d’un projet à l’autre, selon les risques identifiés. Les contrôles sur le développement de programmes les plus importants ont tendance à être exécutés peu de temps avant la date de l’implantation. L’auditeur surveille et évalue les nouveaux risques qui pourraient découler des activités de développement (c’est-à-dire un accès temporaire de super utilisateur accordé aux employés clés des finances) ainsi que les contrôles que l’entité pourrait mettre en place temporairement pendant la période de conversion.

Par exemple, l’entité compte mettre en place une nouvelle application financière cette année. Ce nouveau système aura une incidence sur les états financiers de l’entité pour l’exercice visé par l’audit. Il est souvent plus efficace et efficient de comprendre les contrôles du traitement de l’information et les conversions de données nouvellement mis en place ou modifiés en examinant les contrôles de l’entité dans les cycles de développement, plutôt que de tester les contrôles uniquement dans l’environnement réel après l’implantation.

L’auditeur doit exercer son jugement professionnel pour déterminer s’il doit acquérir une compréhension des contrôles sur le développement de programmes dans l’exercice en cours, surtout si l’implantation n’aura d’effets directs sur les risques liés à la présentation de l’information financière que lors d’exercices ultérieurs. Se reporter au tableau ci‑dessous pour connaître les facteurs à considérer au moment d’évaluer les risques découlant du recours à l’informatique dans le domaine du développement de programmes. Les CGI liés au développement des programmes sont importants pour de nombreux audits, mais leur pertinence globale est plus étroitement liée au client.

L’auditeur examine les développements importants et évalue les répercussions financières associées aux processus de développement de l’entité lorsque ceux‑ci sont liés à un contrôle identifié dans la composante des activités de contrôle. Par exemple, si une entité déploie une nouvelle application informatique au cours de la période visée par l’audit qui comprend des contrôles et des dépendances aux TI liés à un risque d’anomalies significatives, l’auditeur acquiert une compréhension du processus de déploiement et identifie les risques découlant du recours à l’informatique afin de déterminer si les contrôles relatifs au développement répondent à ces risques. Cette compréhension sert à déterminer s’il est efficient et efficace de tester les contrôles pour obtenir des éléments probants au sujet du nouveau système, du processus de déploiement et de la conversion des données. Dans les cas où le développement est lié à un risque découlant du recours à l’informatique, l’auditeur obtient la documentation à l’appui.

Les sous-composantes du domaine Développement de programmes comprennent généralement ce qui suit :

• gestion des activités d’élaboration et d’implantation;
• initiation, analyse et conception de projet;
• construction/choix du progiciel;
• tests et assurance de la qualité;
• conversion des données;
• implantation du programme;
• documentation et formation;
• séparation des tâches.

Voici des exemples de CGI qui peuvent servir à gérer le développement de l’environnement informatique : (NCA 315, annexe 6.2(b)) :

• processus de gestion des changements;
• séparation des tâches dans le cadre de l’intégration des changements à l’environnement de production;
• élaboration, acquisition ou mise en oeuvre des systèmes;
• conversion des données.

L’auditeur détermine les activités pertinentes et les contrôles en fonction de l’environnement informatique unique de l’entité. Les points à considérer suivants peuvent être utiles pour identifier les CGI dans ce domaine qui répondent aux risques découlant du recours à l’informatique identifiés au sein de l’entité. Voir la rubrique Identification des risques découlant du recours à l’informatique pour de plus amples renseignements sur l’identification de tels risques. Il est à noter que certains points ne sont pas pertinents pour toutes les entités et qu’il y aura peut-être lieu d’examiner d’autres facteurs de risque. Par exemple, les risques liés à la cybersécurité et les contrôles connexes peuvent être liés au développement de programmes ou à d’autres domaines des CGI. Voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité pour obtenir des directives supplémentaires sur les risques liés à la cybersécurité et les contrôles connexes.

Lorsqu’il acquiert une compréhension de ce qui précède, l’auditeur doit prendre en compte que certaines sous-composantes et certains CGI peuvent ne pas s’appliquer à chaque entité et que d’autres facteurs de risque peuvent exister. Le tableau ci‑dessous présente des exemples de risques et de points à considérer pour l’audit, répartis par sous-composante et faisant référence aux CGI dont il est question.

*Se reporter à la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité pour un examen plus approfondi des risques liés aux incidents de cybersécurité et des contrôles connexes qui pourraient avoir une incidence sur un ou plusieurs des domaines des CGI.

Audit de la mise en place et des mises à niveau des progiciels de gestion intégrés

La mise en place et les modifications ou mises à niveau importantes des progiciels de gestion intégrés (PGI) des clients entraînent souvent des changements dans les processus opérationnels. Par conséquent, en raison de telles modifications, il peut arriver que certaines opérations ne puissent plus être traitées comme elles l’étaient jusqu’alors, que certains rapports doivent être remaniés ou que certaines modifications doivent être apportées aux contrôles. Par exemple, certaines mises à niveau ou certains changements entraînent la migration du PGI vers un environnement infonuagique, ce qui signifie que l’infrastructure de soutien peut changer. Parfois, lorsqu’une entité met à niveau ou modifie son PGI, les contrôles préventifs conventionnels sont mis de côté, et on laisse certains contrôles en faveur de contrôles qui ont des caractéristiques de prévention et de détection :

• Contrôles en temps réel conçus de manière à éviter un arrêt immédiat qui interrompt les opérations, tout en permettant le fonctionnement de contrôles à l’appui des opérations;

• Contrôles hybrides ayant des caractéristiques de prévention et de détection.

Lorsque l’auditeur acquiert une compréhension et fait une évaluation de la conception de ces contrôles, il tient compte des caractéristiques de prévention et de détection du contrôle dans la mesure où elles sont adaptées au risque d’anomalies significatives identifié.

Voir la section BVG Audit 5034 pour obtenir des directives et des exemples de différents types de contrôles.

L’auditeur d’états financiers doit tenir compte de l’incidence de ces mises en place ou mises à niveau de PGI dans les risques découlant du recours à l’informatique. Le fait qu’un client possède des systèmes d’une complexité ou d’une étendue suffisante pour justifier les coûts d’implantation d’un PGI aura fort probablement une influence sur la stratégie d’audit. Il doit aussi savoir que la mise en place d’un PGI à grande échelle peut créer un environnement dans lequel il sera probablement impossible de procéder à un audit efficace sans adopter, dans une large mesure, une stratégie axée sur les contrôles.

Chaque mise en place de PGI est unique (p. ex. deux implantations de système SAP ne sont jamais les mêmes). L’auditeur doit donc tenir compte de l’incidence de la mise en place de PGI sur le contrôle interne et déterminer comment mener un audit de façon efficace qui soit adapté à chaque client. En conséquence, les éléments à prendre en compte dans le cas de telles modifications sont les suivants :

• le recours à l’Audit des TI pour comprendre l’incidence du PGI sur l’environnement de contrôle. De plus, il est normalement prévu que les contrôles généraux informatiques (CGI) soient testés.

• l’incidence de la mise en œuvre du PGI sur les facteurs de risque inhérent et le processus global d’évaluation des risques nécessaire pour comprendre et auditer la mise en place. Une planification est effectuée très tôt au cours de la première année suivant la mise en place du PGI ou toute mise à niveau importante, pour :

  • identifier les contrôles qui répondent aux risques d’anomalies significatives au niveau des assertions et qui sont touchés par les modules nouveaux ou modifiés du PGI;

  • identifier les autres aspects de l’environnement informatique qui sont vulnérables aux risques découlant du recours à l’informatique, p. ex. :

    • les interfaces (les PGI sont souvent liés à d’autres systèmes, qui nécessitent à leur tour un contrôle pour garantir que tous les intrants sont reçus aux fins de traitement et que tous les extrants sont acheminés comme il se doit);
    • la sécurité au niveau des réseaux, des bases de données et des applications;
    • d’autres risques et CGI connexes (c.‑à‑d. dans ce cas, le domaine des CGI liés au développement de programmes sera probablement important);

  • obtenir le calendrier d’implantation afin d’établir quand et où l’implantation du PGI risque d’avoir une incidence sur l’audit;

• l’incidence sur les contrôles – a‑t‑on pu acquérir une compréhension de base et effectuer une évaluation initiale du contrôle interne par les moyens ci‑dessous :

  • Examen des audits internes (évaluation des contrôles avant ou après l’implantation);
  • Évaluation de la conception et de la mise en place des contrôles entreprise par le BVG dans le cadre de l’audit;
  • Évaluations par d’autres cabinets réputés;
  • Documentation des contrôles et processus opérationnels pour l’environnement de traitement du nouveau PGI.

• Quelles sont les attentes de l’entité et du comité d’audit en ce qui a trait à l’audit?

  • L’entité s’attend-elle à ce que l’équipe d’audit du BVG comprenne comment accéder à l’information au moyen du PGI?
  • L’entité s’attend-elle à ce que l’équipe d’audit du BVG se fie au nouvel environnement de traitement et de contrôle interne?

• Quelle est l’incidence sur les connaissances acquises par l’équipe d’audit du BVG lors d’audits antérieurs?

  • Le PGI a‑t‑il modifié les procédures ou les méthodes d’exécution des processus opérationnels clés ou d’une majorité de processus opérationnels du client? Des processus opérationnels manuels de l’entité ont‑ils été automatisés?
  • L’implantation d’un PGI a‑t‑elle fait évoluer les contrôles internes de l’entité, les faisant passer de contrôles de détection manuels à des contrôles préventifs automatisés, ou à une combinaison des deux?
  • Le PGI a‑t‑il complètement modifié les CGI? Le PGI a‑t‑il remplacé tous les anciens systèmes sur lesquels l’équipe d’audit a fondé sa connaissance et compréhension du contrôle interne?
  • Les diagrammes logiques des systèmes et processus opérationnels clés de l’entité sont‑ils toujours valables?

Directives connexes

Se reporter à la section BVG Audit 3102 pour obtenir des directives quant au recours à l’Audit des TI.

Directives du BVG

Opérations informatiques – Objectif du domaine :

Veiller à ce que l’information des applications informatiques et d’autres aspects de l’environnement informatique soient traitée de façon exhaustive et exacte, conformément aux objectifs de la direction en matière de contrôle, et à ce que les problèmes de traitement soient détectés et réglés de façon exhaustive et exacte pour assurer l’intégrité des données financières

*Le domaine Opérations informatiques couvre les opérations informatiques dans l’environnement informatique dans son ensemble et se rapporte au domaine « Gestion des opérations informatiques » de la NCA 315, conformément à la mise en correspondance présentée à la rubrique Aperçu.

Les opérations informatiques présentent souvent un risque opérationnel, et non pas un risque d’anomalies significatives, selon la situation particulière de l’entité. Certains éléments des opérations informatiques pourraient être pertinents pour la préparation des états financiers, surtout s’ils servent non seulement en tant que CGI, mais également en tant que contrôles du traitement de l’information qui appuient directement les assertions pertinentes contenues dans les états financiers. Par exemple, la programmation des travaux est une activité des services informatiques qui pourrait avoir une incidence directe sur l’exhaustivité et l’exactitude des données financières si elle devait ne pas aboutir. De même, les procédures de sauvegarde et de récupération peuvent avoir une incidence importante sur le risque d’anomalie dans les états financiers si les récupérations de données sont fréquentes, par exemple quand les systèmes sont instables ou s’il y a un cyberincident qui limite l’accès à l’environnement réel. Les CGI liés aux opérations informatiques sont importants pour de nombreux audits, mais leur pertinence globale est plus étroitement liée à l’entité. L’auditeur peut identifier les opérations informatiques qui servent de contrôles de traitement de l’information dans le cadre de la composante des activités de contrôle. Les sous-composantes types des opérations informatiques comprennent généralement :

• la gestion des opérations informatiques;
• l’ordonnancement et le traitement des lots;
• le traitement en temps réel;
• la sauvegarde et la gestion des problèmes
• le rétablissement après sinistre.

Voici des exemples de CGI qui peuvent servir à gérer les opérations informatiques (NCA 315 annexe 6.2(c)) :

• planification des travaux;
• suivi des travaux;
• sauvegarde et récupération;
• détection des intrusions.

Les points à considérer suivants peuvent être utiles pour identifier les CGI dans ce domaine qui répondent aux risques découlant du recours à l’informatique identifiés au sein de l’entité. Voir la section Identification des risques découlant du recours à l’informatique pour de plus amples renseignements sur l’identification de tels risques. Il est à noter que certains points ne sont pas pertinents pour toutes les entités et qu’il y aura peut-être lieu d’examiner d’autres facteurs de risque. Par exemple, les risques liés à la cybersécurité et les contrôles connexes peuvent être liés aux opérations informatiques ou à d’autres domaines des CGI. Voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité pour obtenir des directives supplémentaires sur les risques liés à la cybersécurité et les contrôles connexes.

Lorsqu’il acquiert une compréhension de ce qui précède, l’auditeur doit prendre en compte que certaines sous-composantes et certains CGI peuvent ne pas s’appliquer à chaque entité et que d’autres facteurs de risque peuvent exister. La manière dont les opérations informatiques sont configurées, autorisées et contrôlées varie d’une entité à l’autre, en fonction de la taille et de la complexité de l’environnement et du volume et des types d’opérations traitées. Le tableau ci‑dessous fournit des exemples de risques et de points à considérer pour l’audit, répartis par sous-composante et faisant référence aux CGI en question.

*Voir la rubrique Considérations relatives à l’évaluation des risques liés à la cybersécurité pour un examen plus approfondi des risques et des contrôles liés à la cybersécurité qui pourraient avoir une incidence sur un ou plusieurs des domaines des CGI.

Directives du BVG

Les considérations relatives à l’évaluation des risques présentées dans la section Considérations relatives à l’évaluation des risques liés à la cybersécurité sont conçues de manière à aider l’auditeur à comprendre, à déterminer et à évaluer la pertinence et l’applicabilité pour l’audit des risques liés à la cybersécurité découlant du recours à l’informatique lorsqu’il conçoit et met en œuvre des procédures pour auditer des états financiers d’une entité.

Les entités peuvent être exposées à un risque lié à la cybersécurité du fait d’un accès non autorisé à des applications d’information financière, à des données et à des actifs électroniques ou numériques comptabilisés au bilan. Toutes ces atteintes pourraient avoir une incidence sur les états financiers. En voici des exemples :

• Une entité a été victime d’une cyberattaque qui a causé la suppression de l’ensemble de ses données financières. Sans la mise en place de contrôles de sauvegarde et de récupération appropriés, il est possible que l’entité ne soit pas en mesure de communiquer des données financières exhaustives et exactes ou de respecter les délais de présentation des rapports.

• Une entité a été victime d’une usurpation d’identité d’un dirigeant par courriel lorsqu’elle a reçu une demande de modification des renseignements sur le compte bancaire d’un fournisseur et de versement d’un paiement pour des factures ouvertes. En l’absence de contrôles portant sur les données de base des fournisseurs et permettant de valider l’authenticité de la demande, l’entité peut, par erreur, dégager ses livres d’un passif, ce qui pourrait entraîner une sous-estimation des comptes créditeurs.

• Une entité spécialisée dans la technologie peut faire l’objet d’un incident de cybersécurité qui entraîne le vol d’une nouvelle technologie brevetée. Si l’entité avait comptabilisé au bilan ce brevet comme une immobilisation incorporelle de valeur significative, elle pourrait avoir subi une dépréciation sans le savoir à la date de clôture si elle n’a pas de contrôles d’intrusion et de détection appropriés.

Aux fins de la présentation de l’information financière, il est également important de tenir compte du risque que les coûts liés aux incidents de cybersécurité ne soient pas comptabilisés, ce qui pourrait comprendre, par exemple, les dédommagements offerts aux clients, les frais juridiques ou les frais liés aux enquêtes judiciaires et aux évaluations réglementaires.

D’autres incidents liés à la cybersécurité peuvent ne pas toucher directement les états financiers. Par exemple, de nombreuses attaques contre la cybersécurité ont pour objectif d’acquérir des informations sensibles sur les clients, y compris les informations des cartes de crédit. Étant donné que ce type de renseignements sur le client n’est normalement pas reconnu comme un actif dans les états financiers d’une entité, le risque est plus susceptible d’être lié à des questions opérationnelles comme l’interruption des activités et les dommages aux relations avec la clientèle, ce qui pourrait compromettre les résultats d’exploitation et les flux de trésorerie futurs. De tels incidents peuvent obliger l’entité à prendre des mesures qui entraînent des coûts supplémentaires devant être comptabilisés, par exemple des coûts liés aux mesures correctives aux fins de dédommagement des clients, ainsi que des coûts supplémentaires découlant de réclamations judiciaires et de mesures réglementaires.

Exemples d’incidents liés à la cybersécurité

Voici d’autres exemples d’incidents liés à la cybersécurité courants. De tels incidents de cybersécurité pourraient donner lieu à des répercussions sur les états financiers et les opérations semblables à celles déjà illustrées dans les exemples ci‑dessus. La nature et l’ampleur des répercussions découlant de tels incidents liés à la cybersécurité varieront en fonction des faits et des circonstances propres à l’entité, ainsi que de la nature de l’incident. Par conséquent, l’auditeur doit examiner les répercussions potentielles des incidents liés à la cybersécurité sur les états financiers d’une entité lorsqu’il acquiert une compréhension de l’entité :

• Une atteinte importante à la protection des données d’une chaîne d’hôtels a compromis le nom des clients, les informations de voyage, les détails des cartes de crédit et d’autres renseignements personnels (attaque par écoute électronique).

• Le piratage d’un système informatique de santé a compromis les données consignées dans les dossiers médicaux de patients (attaque par perçage de mots de passe).

• Un pirate informatique a eu accès aux systèmes de contrôle des services publics d’une entité de services publics (attaque de l’intercepteur ou attaque MITM pour Man‑in-the-middle).

Le service qui est la principale source de recettes de sites Web commerciaux a été la cible d’attaques par déni de service distribué (DDoS), qui vise à rendre les systèmes inaccessibles aux utilisateurs prévus.

• La compromission d’une banque à la suite d’une atteinte à la cybersécurité, au cours de laquelle l’auteur a eu accès aux informations sur les clients (maliciel de type logiciel espion).

• Des pirates informatiques accèdent aux serveurs de sociétés spécialisées dans les données et volent la propriété intellectuelle (attaque par injection SQL).

• L’accès au système d’exploitation d’entités de télécommunications a été bloqué à la suite d’un cryptage de toutes les archives et unités connectées au réseau dans le but d’extorquer de l’argent à la victime. L’auteur a demandé le paiement d’une somme d’argent en échange de l’accès au système (maliciel de type rançongiciel).

• Une entité du secteur du divertissement et des médias fait l’objet d’une atteinte à la sécurité qui entraîne l’acquisition non autorisée d’actifs numériques ayant des répercussions en aval sur la possibilité de récupérer les données financières (attaque par harponnage).

La sous-section Procédures d’audit liées à la cybersécurité met un accent accru sur la prise en compte du risque lié à la cybersécurité auquel les entités sont de plus en plus exposées et fournit à l’auditeur des points à considérer pour l’aider à déterminer si la cybersécurité peut représenter un risque d’anomalies significatives, notamment :

• la discussion des responsabilités de l’auditeur à l’égard de l’évaluation des risques et de la cybersécurité, selon les normes d’audit;

• les points que l’auditeur doit considérer lorsqu’il met en œuvre des procédures d’évaluation des risques afin de déterminer si la cybersécurité peut représenter un risque d’anomalies significatives;

  • des conditions ou des événements qui pourraient accroître les facteurs de risque inhérent, p. ex., l’entité utilise une application tierce dont on a constaté qu’elle présente des vulnérabilités qui sont transmises aux entités si elles appliquent un correctif précis;
  • un risque d’anomalies significatives au niveau des états financiers, p. ex., un rançongiciel malveillant qui bloque l’accès à toutes les données au niveau des transactions dans les environnements de production et de sauvegarde, ce qui aurait une incidence sur chaque élément des états financiers;
  • des risques liés à la cybersécurité découlant du recours à l’informatique, p. ex., le réseau n’empêche pas de façon adéquate les utilisateurs non autorisés d’obtenir un accès inapproprié aux systèmes d’information;

• d’autres facteurs à considérer pour aider l’auditeur à mieux comprendre les activités et les contrôles en place au sein de l’entité pour répondre aux risques liés à la cybersécurité, y compris des exemples de contrôles;

• des mesures pour évaluer un cyberincident éventuel afin de déterminer son incidence sur le plan d’audit ainsi que sur l’information financière de l’entité.

Directives du BVG

La cybersécurité est un risque en évolution dont il faut tenir compte dans le cadre de l’acquisition d’une compréhension de l’environnement informatique et des activités d’évaluation des risques. La compréhension de l’auditeur établit un cadre de référence qui l’aide à planifier les contrôles et les procédures de corroboration. Conformément aux Normes canadiennes d’audit (NCA), l’auditeur doit comprendre les événements, les circonstances et les activités pouvant avoir une incidence importante sur les risques d’anomalies significatives. Les risques d’anomalies significatives peuvent provenir de diverses sources, y compris de facteurs externes, comme des conditions au sein de l’industrie et de l’environnement de l’entité, et de facteurs propres à l’entité, comme la nature de l’entité et de ses activités.

L’auditeur doit notamment acquérir une compréhension de la façon dont l’entité utilise les technologies de l’information afin de pouvoir évaluer les risques liés à la cybersécurité découlant du recours à l’informatique, ce qui lui permet de tenir compte de la fiabilité de l’information financière, des contrôles automatisés, des contrôles généraux informatiques (CGI) et de la fiabilité des données utilisées dans le cadre de l’audit.

L’auditeur obtiendra une compréhension des risques de l’entité liés à la cybersécurité, de son approche à l’égard des risques informatiques et des différents éléments pertinents de son architecture de sécurité en mettant en œuvre des procédures pour comprendre comment l’entité répond aux risques découlant du recours à l’informatique, ce qui comprend l’évaluation de la conception et de la mise en place de certains contrôles. Si l’auditeur identifie des risques liés à la cybersécurité qui donnent lieu à un risque d’anomalies significatives (résultant d’une erreur ou d’une fraude) dans les états financiers, il doit y répondre dans son plan d’audit (p. ex., identifier les contrôles de traitement de l’information et les CGI et tester leur efficacité opérationnelle, ou mettre en œuvre des procédures de corroboration en réponse aux risques identifiés). Il est à noter que tous les risques liés à la cybersécurité ne donneront pas nécessairement lieu à un risque d’anomalies significatives résultant d’une fraude ou d’une erreur, bien qu’il soit important d’évaluer s’il y a des répercussions directes ou indirectes, comme des interruptions des opérations, qui pourraient donner lieu à un risque d’anomalies significatives. Se reporter aux tableaux concernant les points à considérer et les expositions aux risques liés à la cybersécurité dans la section Considérations relatives à l’évaluation des risques liés à la cybersécurité et les exemples de contrôles connexes pour les secteurs à prendre en compte lors de l’évaluation des risques liés à la cybersécurité et des contrôles connexes pour l’entité.

L’auditeur doit d’abord se pencher sur les applications informatiques et d’autres aspects de l’environnement informatique qui gèrent les données des états financiers, comme l’indique le diagramme inclus dans la section Considérations relatives à l’évaluation des risques liés à la cybersécurité – Aperçu qui montre le chemin d’accès habituel à l’environnement informatique, ainsi qu’aux programmes et aux données. Dans le cadre des procédures pour acquérir une compréhension de l’entité et de son environnement informatique, l’auditeur peut obtenir une compréhension de la sécurité de réseau et des contrôles afférents (p. ex. détection d’intrusion) pour identifier les risques d’anomalies significatives liés à la cybersécurité. Lorsqu’il évalue les risques liés à la cybersécurité ou aux attaques informatiques, l’auditeur peut déterminer qu’il y a des signes d’un risque accru d’accès non autorisé à la couche de sécurité du réseau. Les risques liés à la cybersécurité pourraient avoir une incidence sur plus d’un domaine des CGI ou être omniprésents dans l’ensemble de l’entité.

Il faut noter que les incidents liés à la cybersécurité se produisent généralement d’abord dans le réseau périmétrique et le réseau interne, comme l’indique la figure dans la section Accès aux programmes et aux données. Ces couches de sécurité sont généralement éloignées des applications financières qui sont celles qui retiennent généralement l’attention de l’auditeur pendant l’audit.

Les responsables de mission doivent participer suffisamment à l’identification des risques liés à la cybersécurité, à la détermination de l’incidence ou de la portée possible des anomalies possibles dans les états financiers et à la prise en considération de la possibilité que les risques liés à la cybersécurité puissent entraîner des risques d’anomalies significatives. Pour élaborer la stratégie d’audit, le responsable de la mission et le gestionnaire d’équipe doivent comprendre l’entité et son secteur d’activité, examiner l’évaluation des risques de la direction et tenir compte des autres risques. Tous ces éléments sont nécessaires à la réalisation d’une évaluation des risques rigoureuse.

Il est important que les responsables de mission planifient et sollicitent des discussions internes et externes appropriées sur le processus d’évaluation des risques et la façon de voir la cybersécurité comme une considération à l’échelle de l’entreprise au lieu d’une simple question de technologie de l’information. Étant donné que la cybersécurité est un risque important à l’échelle de l’entreprise que la plupart des équipes de direction, des comités d’audit et des conseils d’administration d’entités auront généralement pris en considération, l’évaluation des risques peut être améliorée grâce à une collaboration avec eux sur ce sujet pendant l’étape de planification de l’audit. L’auditeur doit envisager de faire appel à l’Audit des TI ou à d’autres experts en cybersécurité ayant l’expérience requise pour l’aider à évaluer les risques liés à la cybersécurité dans des environnements complexes ou lorsque des incidents de cybersécurité se sont produits.

Directives du BVG

Les incidents liés à la cybersécurité pourraient avoir une incidence sur l’évaluation des risques. Selon le type d’incident et la réponse de l’entité, cela pourrait avoir une incidence sur un petit secteur visé par l’audit, par exemple, nécessitant un test de cheminement plus détaillé à l’égard des contrôles de l’entité relatifs à la détection des intrusions. Certains incidents liés à la cybersécurité pourraient être plus répandus et avoir une incidence sur l’ensemble des transactions financières, par exemple, une attaque par rançongiciel qui menace la capacité de l’entité de préparer les états financiers. Les directives suivantes peuvent aider l’auditeur à mener des discussions initiales avec les clients audités lorsqu’il est informé de la possibilité d’une corruption des données, d’atteintes à la sécurité ou d’autres incidents liés à la sécurité :

Comme il est indiqué à l’étape 1, les questions ci‑après peuvent être soulevées avec le client pour aider l’auditeur à mieux comprendre l’incident :