Guide d audit des applications informatiques

Transcription

1 Guide d audit des applications informatiques Une approche inspirée des audits financiers Novembre 2008 Processus métier Applications Systèmes IT Infrastructure IT ITACS Training Auteurs: Peter R. Bitterli Jürg Brun Thomas Bucher Brigitte Christ Bernhard Hamberger Michel Huissoud Daniel Küng Andreas Toggwyler Daniel Wyniger Georges Berweiler (revue de la traduction française)

2

3 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Guide d audit des applications informatiques Novembre

4 Cet ouvrage est le fruit des réflexions et des expériences des membres de la Commission informatique de la Chambre fiduciaire suisse. Travaillant dans les principaux cabinets d audit comptables et financiers suisses ou dans d importants services d audit interne, ceux-ci ont voulu saisir, structurer et standardiser l approche qui est la leur dans le cadre de l audit des comptes annuels.ce document a vocation à servir de passerelle entre les auditeurs financiers et les auditeurs informatiques et devrait renforcer l indispensable cohérence entre les travaux de ces deux disciplines. Ce texte reflète l expérience et la réflexion de ses auteurs. Il est publié avec l aimable autorisation de la commission informatique de la Chambre fiduciaire suisse. Copyright ISACA Switzerland Chapter, Auteurs: Peter R. Bitterli Jürg Brun Thomas Bucher Brigitte Christ Bernhard Hamberger Michel Huissoud Daniel Küng Andreas Toggwyler Daniel Wyniger Georges Berweiler (revue de la traduction française) Graphiques et mise en page: Felice Lutz, ITACS Training AG 2

5 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Table des matières Table des matières 3 Présentation générale et introduction 4 Analyse du bilan et du compte de résultats 7 Identification des processus métier et des flux de traitement des données 9 Identification des applications de base et des principales interfaces IT pertinentes 13 Identification des risques et des contrôles clés 18 Tests de cheminement 22 Evaluation de la conception des contrôles 24 Evaluation du fonctionnement des contrôles 28 Appréciation globale 32 Annexe 1 - Contrôles liés aux applications 36 Annexe 2 - Glossaire 38 3

6 Présentation générale et introduction But de l approche Dans le cadre des procédures d audit orientées processus et basées sur l utilisation d applications informatiques, il est essentiel de prendre en compte tous les domaines importants, y compris les des domaines IT spécifiques ayant une influence significative sur l objectif de contrôle de l auditeur. Pour y parvenir une approche de contrôle intégrée (auditeur et auditeur informatique) est nécessaire. L absence de procédure concertée entre auditeurs et auditeurs informatiques (auditeurs IT) constitue à cet égard un risque élevé.. Le présent document décrit, dans le cadre des procédures d audit orientées processus, une méthode de vérification et une approche intégrée de l audit des contrôles applicatifs destinées à prévenir ce risque d audit. Etendue et délimitation La méthode présentée se limite à la procédure de contrôle des applications IT au sein d un processus métiers. Les domaines connexes sont abordés dans la mesure où ils ont un lien avec la procédure de contrôle, mais ils ne seront pas traités en détail. Il s agit par exemple des contrôles par échantillonnage, des qualifications des auditeurs et des «contrôles IT généraux» (vérifications indépendantes d une application). L utilisation de l approche n est pas limitée à l audit des critères réglementaires; la procédure a été conçue sciemment de manière plus générique afin de convenir également à d autres vérifications (par ex. vérifications de conformité). Utilisateurs Les exemples et la description de la procédure se réfèrent à l audit des états financiers. Compte tenu de son caractère générique, l approche de contrôle est utilisable aussi bien par l auditeur financier que par l auditeur IT. L audit des états financiers d une entreprise représente pour les auditeurs financiers un nombre de défis de plus en plus grand; d un côté l évolution rapide des normes comptables, de l autre l automatisation croissante de la préparation des états financiers au moyen de systèmes d information toujours plus complexes. Ce deuxième aspect est le sujet qui est développé ci-après. La qualité des informations financières dépend dans une large mesure de la qualité des processus métiers et des flux de traitement des données s y rapportant. Il est donc logique que l auditeur concentre son travail sur ces processus métiers et intègre le contrôle des applications correspondantes dans son approche d audit. L approche présentée ci-après est destinée à aider l auditeur financier à développer une approche d audit intégrée et à recentrer la procédure d audit de manière plus efficace et plus ciblée sur les risques, en intégrant l audit des processus métiers pertinents et des applications correspondantes. L approche commence donc avec l analyse des états financiers de l entreprise et se termine par l appréciation de l impact des résultats d audit sur ces états financiers. 4

7 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Les 8 étapes de la méthode de vérification: Analyse du bilan et du compte de résultats Identification des processus opérationnels et flux de données Identification des applications clés et interfaces Identification des risques et contrôles clés Test de cheminement Evaluation de la conception du contrôle Evaluation du fonctionnement du contrôle Appréciation globale Il est judicieux d analyser les états financiers afin d orienter les procédures d audit des processus de l entreprise et des applications correspondantes sur les tests des comptes financiers significatifs et sur les risques d audit s y rapportant. Cette analyse lie les principales positions comptables aux processus métiers pertinents ou, plus concrètement, détermine les flux de traitement des données à l origine des principales positions comptables et des applications de base qui supportent ces flux de traitement des données. Une fois les applications de base identifiées, l auditeur s intéresse à la qualité du système de contrôle. Il détermine d abord si la conception du système de contrôle est adaptée à la situation de risque actuelle des processus de l entreprise et enfin si les contrôles prévus sont implémentés et sont efficaces. L évaluation du système de contrôle des processus métiers pris en compte dans le cadre de l audit permet à l auditeur de savoir s il peut s appuyer sur les procédures de production des états financiers et, le cas échéant, de définir l étendue des procédures d audit substantives supplémentaires qu il doit effectuer. La présente méthode ne traite pas, de manière explicite, les «contrôles IT généraux». L auditeur doit évaluer et tester systématiquement les contrôles IT généraux afin de définir une stratégie de test adaptée aux contrôles applicatifs. Les contrôles IT généraux sont dans une large mesure déterminants pour savoir si un contrôle applicatif, dont la conception est considérée comme effective, a fonctionné pendant toute la période d audit, ou si l auditeur doit l évaluer explicitement, par exemple par le biais de tests directs (par ex. procédures de validations détaillées). La méthode de contrôle repose sur un modèle à quatre niveaux. Ce modèle est présenté de manière schématique et simplifiée ci-après. Dans la réalité, les interactions peuvent être beaucoup plus complexes, la schématisation permet simplement de comprendre l approche de contrôle. 5

8 Délimitation de l approche de contrôle couvert par la méthode non couvert par la méthode Contrôles IT généraux Environnement de contrôle IT (polices, directives) Développement de programmes Modifications IT Exploitation IT Gestion des accès Sécurité des systèmes Sécurité des données Processus métier / transactions Applications financières Middleware / base de données Systèmes d exploitation / réseau Contrôles d applications IT Intégralité Exactitude Validité Autorisation Séparation des fonctions La figure ci-dessus montre, sous forme simplifiée, le modèle en couches utilisé dans la présente approche de contrôle. Chacune des quatre couches représente un type de processus et de ressource. La couche supérieure (bleue) contient les principaux processus (manuels) de l entreprise présentés typiquement par domaines d activités et subdivisés en sous-processus et en activités individuelles. La deuxième couche (rouge) contient les éléments automatisés des processus de l entreprise, les applications IT à proprement parler. A l exception peut-être des PME de petite taille, la majorité des opérations commerciales dans toutes les entreprises est traitée à l aide d applications IT. La troisième couche (jaune) contient les systèmes IT de base. Ce terme recouvre une grande diversité de plates-formes possibles supportant les applications de la deuxième couche. Exemple: systèmes de gestion de base de données (par ex. Oracle, DB2), composants de base d applications intégrées (par ex. SAP Basis, Avaloq, ) ou des systèmes plus techniques (par ex. Middleware). La couche inférieure (verte) contient les éléments d infrastructure informatique. Pour l essentiel, cette couche contient les éléments matériels (Mainframe, systèmes périphériques, serveurs) ainsi que les composants du réseau et les systèmes de surveillance technique y relatifs. L approche présentée dans ce document traite principalement des deux couches supérieures (signalées par une flèche verte) autrement dit, des contrôles liés aux applications au sein des processus métiers et des applications sous-jacents. Les deux dernières couches, l infrastructure IT et les processus IT sous-jacents (signalés par une flèche rouge) sont bien entendu importants du point de vue de l auditeur mais ne sont pas traités dans le cadre présent. 6

9 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 1 Analyse du bilan et du compte de résultats Vue d ensemble Contenu et objectif Contexte Nous considérons que l objectif de contrôle est la conformité de la tenue de la comptabilité. La procédure est la suivante: définition des positions du bilan et du compte de résultats pertinentes pour l audit identification des transactions (opérations commerciales) ou des classes de transaction 1 à l origine de ces positions. L analyse 2 du bilan et du compte de résultats est centrale dans le cadre d un audit ciblé et orienté sur les risques, et sert à identifier les positions du bilan et du compte de résultats pertinentes, c est-à-dire importantes pour l audit. L analyse fournit à l auditeur des informations clés pour l identification des risques et l identification des développements ayant une influence sur les comptes annuels. Elle sert en même temps d instrument de planification pour la définition des points de contrôle principaux et des méthodes de vérification 2 utilisées. Procédure Principaux comptes par ex. débiteurs RISQUE RISQUE Assertions dans les états financiers, par ex.: Processus métier Applications Systèmes IT Infrastructure IT ITACS Training RISQUE RISQUE Authenticité Évaluation Intégralité Droits et obligations 1 Une classe de transaction est un ensemble de transactions ou d opérations commerciales au sein d un processus d entreprise qui reposent sur une même base et qui peuvent être comptabilisées de manière quasiment identique. 2 Manuel suisse d audit, 1998, chapitre Analyse des comptes annuels 7

10 Identification des comptes et groupes de comptes significatifs L auditeur procède à une évaluation des risques pouvant avoir une influence sur les états financiers en orientant ses procédures d audit sur ces risques. A cet égard, la définition du caractère significatif joue un rôle central. Il s agit d identifier les comptes ou les groupes de comptes qui dépassent le seuil de matérialité 3 et par conséquent entrent dans le champ d audit. Sont également identifiés les comptes ou les groupes de comptes dont l existence ou les évolutions comportent des risques spécifiques ou signalent des risques spécifiques, par exemple une évolution inattendue de certains indicateurs. Identification des transactions et des classes de transactions significatives Une fois les groupes de compte identifiés, l auditeur peut, dans une deuxième phase, analyser les transactions ou classes de transactions qui ont un impact significatif sur ces comptes. Il peut être judicieux ici de rechercher, sur la base d une analyse de données, les écritures qui ont été effectuées sur certains comptes spécifiques. Il est alors possible de déduire de ces données quelles opérations commerciales ou transactions ont été à l origine de ces écritures. Cela peut s effectuer dans un environnement ERP en répartissant les écritures électroniques dans les comptes significatifs par «code transaction». L auditeur remonte ainsi des principaux comptes et groupes de comptes au travers des principales transactions aux opérations à partir desquelles ces transactions ont été générées. L avantage de cette approche rétrospective est qu elle exclut d emblée les classes de transactions non significatives résultant des subdivisions de processus. Lorsque l auditeur connaît les classes de transactions significatives et les opérations commerciales qui les génèrent, il peut procéder à l analyse des risques aux différentes étapes du processus comme décrit à l étape suivante. Particularités Dans le cadre du contrôle des applications IT, l auditeur se concentre généralement sur les transactions de routine sachant que la plupart d entre elles sont gérées par l application et que c est là qu ont lieu la plupart des contrôles automatisés et ceux liés aux systèmes informatiques. Les transactions non routinières, en particulier les procédures d estimation, font fréquemment l objet d un système de contrôle principalement manuel. L auditeur devrait, à ce stade de sa mission, prendre également en compte les principaux événements de l entreprise qui ont eu une influence sur les comptes ou classes de transactions sélectionnés. Ex.: introduction d une nouvelle application informatique migration ou regroupement d applications ou de données 3 Manuel suisse d audit, 1998, chapitre 3.114: «Ont un caractère significatif, tous les éléments qui influencent l évaluation et la présentation des comptes individuels, des comptes du groupe ou certains de leurs postes, modifiant ainsi l assertion au point d influencer les décisions des destinataires des comptes individuels ou des comptes du groupe concernant l entreprise.» 8

11 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 2 Identification des processus métier et des flux de traitement des données Vue d ensemble Contenu et objectif Contexte Identification des processus métiers significatifs qui sont à l origine des transactions et classes de transactions précédemment identifiées. Par «processus métiers significatifs» on entend les principaux processus qui ont une influence directe sur le flux de traitement comptable. Il s agit du processus de comptabilité en tant que tel, de processus métiers complexes tels que la facturation et les processus de support, par ex. dans le domaine des ressources humaines. Les processus IT tels que définis dans COBIT par exemple ne sont pas concernés 4. Les états financiers d une entreprise sont le résultat de la consolidation de plusieurs activités que l on peut regrouper en processus et qui peuvent être très différents les uns des autres (processus complexes, limités dans le temps; processus pouvant influencer plusieurs transactions, etc.). Potentiellement, certaines faiblesses de ces processus peuvent remettre en cause la fiabilité des états financiers. C est pourquoi une identification minutieuse des processus métiers et des flux de traitement des données est indispensable pour pouvoir évaluer les risques au sein de chaque processus. Procédure Identification des processus significatifs Sur la base des transactions identifiées, l auditeur identifie les processus qui influent sur ces positions. L analyse s étend par exemple du processus ponctuel de clôture des comptes annuels (avec influence directe sur le montant d une provision) jusqu à un processus de vente et de facturation complexe qui influence le flux de marchandises et le flux financier. Dans ce dernier cas, plusieurs positions du bilan et du compte de résultat auront le même processus comme «source». Les processus peuvent judicieusement être représentés sous forme de cartographie de processus dans un tableau ou un graphique. Les deux formes de représentation présentent des avantages qu il peut être utile de combiner en cas d interactions de processus complexes. Utilisation de la documentation existante Si disponible, l auditeur doit s appuyer sur la documentation des processus existante auprès de l entreprise. La documentation se concentre généralement sur les activités et précise, pour chaque étape de processus, les entrées, les traitements et résultats ainsi que les rôles des différents acteurs. Toutefois, ce type de documentation contient rarement les risques de processus ou les contrôles clés, ceux-ci doivent donc être identifiés et documentés par l auditeur dans une phase ultérieure des travaux liés aux contrôles des applications. Création d une nouvelle documentation formes de représentation L auditeur doit acquérir une connaissance approfondie des processus sélectionnés. Il convient, à cet égard, de distinguer les processus métier (par ex. processus de vente) et les processus financiers parfois très ponctuels (par ex. consolidation des chiffres trimestriels d une succursale ou calcul de l amortissement annuel d une immobilisation). Ces deux catégories de processus comportent des risques susceptibles de se matérialiser dans les états financiers. 4 Un processus peut être défini comme «une chaîne de tâches manuelles, semi-manuelles ou automatisées servant à l élaboration ou au traitement d informations, de produits ou de services. Exemples: vente, relance, production, inventaire, comptabilité, etc.». 9

12 Présentation sous forme de tableau. solution adaptée à des éléments comptables et interactions simples. Position de bilan ou du compte de résultats Montant en milliers de CHF Résultat (Output) Processus Entrée (Input) Chiffre d affaires Factures Vente Contrats, services fournis Coûts Inventaire Equipements Créditeurs Frais de personnel Assurances Paiements Achat Commandes Paiements Gestion ressources humaines Etc Contrats, services Immobilisation Amortissement Bouclement Valeur Divers Positions consolidées Consolidation Positions d une filiale Présentation sous forme de graphique (forme de flux de traitement) - solution adaptée à des interactions complexes Exemple A Sales Materials management Purchasing Strategic purchasing Operating purchasing Vendor Raw materials Goods recept MRP Production Work scheduling Engineering Warehouse Job preparation Inventory accounting Materials management Finished production Production Internal accounting MRP Strategic sales Operative sales Warehouse Shopping Customer Billing Inventory accounting Accounts receivable Invoice vertification GL accounting Accounting Controlling Assets accounting Overhead cost management Accounts payable 10

13 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Exemple B Corporate Governance Processus de pilotage Processus de définition des objectifs Contrôle de gestion Stratégie Organisation d entreprise Gestion du personnel Category Management (CM) Acquisition (achat/dispatching) Marché Logistique Marché Vente Processus de support Finances/Services Informatique Personnel/formation Communication Gestion de la qualité Gestion immobilière Gestion des emplacements Services internes Production Présentation graphique (forme de flux de traitement des données). En cas d analyse d interactions complexes. 11

14 Particularités Degré de détail Une description trop générale rend difficile l identification des risques. Inversement, un degré de détail trop élevé peut nuire à l analyse et à la lisibilité. Selon la complexité d un processus, il peut être utile de le subdiviser en plusieurs sous-processus. Exemples Le processus d achat est composé des sous-processus gestion des données de base fournisseurs, facturation fournisseurs et comptabilisation des achats. Le processus de vente est composé des sous-processus gestion des données de base clients, facturation clients et comptabilisation des ventes. Le processus de salaire est composé des sous-processus gestion des données de personnel, préparation du décompte du salaire, fixation du salaire, décompte du salaire et comptabilisation du salaire. Gestion des paramètres et des données de base Pour certains processus métiers, il est conseillé de considérer la gestion (première saisie, mutations et suppression) des paramètres et des données de base comme deux sous-processus distincts. Les paramètres d une application IT sont les valeurs constantes utilisées pour un même type de transaction (par ex. taux de retenue pour la caisse de pension dans une application de calcul de salaire). Les données de base sont les attributs permanents d un objet, par ex. données de base créditeurs, données de base clients, données de base produits Interfaces manuelles L objectif de cette étape est de comprendre le flux de traitement des informations et des données pertinentes. Il ne s agit pas de considérer uniquement les données électroniques; une analyse complète prend également en compte des flux de documents (par ex. rapport sur l évaluation des stocks) et des interfaces manuelles. 12

15 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES 3 Identification des applications de base et des principales interfaces IT pertinentes Vue d ensemble Contenu et objectif Identification des applications IT concernées et de leurs interfaces Processus métier Applications Systèmes IT Infrastructure IT ITACS Training Contexte De nombreux contrôles sont automatisés et intégrés dans les applications IT. De plus, l automatisation des étapes de processus présente des risques inhérents supplémentaires. Il peut s agir par exemple de la difficulté de mettre en œuvre une séparation adéquate des fonctions, mais également d une impossibilité de contrôle humain compte tenu du niveau élevé d intégration, du traitement en temps réel et du principe de «single point of entry», lesquels génèrent un traitement et un enregistrement automatiques des transactions. Il est donc utile d identifier à temps les applications impliquées, leurs caractéristiques et leurs interfaces. Ces informations permettent de définir de manière détaillée l étendue de l audit et d élaborer un programme d audit. 13

16 Procédure Elaboration d une cartographie des applications Une représentation des applications impliquées n est pas toujours superposable avec le flux des données. En particulier avec les applications fortement intégrées (par ex. Enterprise Resource Planning Systems, ERP), plusieurs processus métiers sont pris en charge par une seule et même application (par ex. couplage automatique d un processus d achat avec un processus de vente). Exemple SALAIRE COMPTA EXCEL FACTURE Inventaire et catégorisation des applications pertinentes du point de vue financier Nous distinguons les différents types d applications ci-après. Compte tenu de leurs profils de risque très différents, les types de programmes sont une caractéristique importante pour la planification et la réalisation de l audit et doivent donc être documentés: application standard application standard fortement adaptée développement interne 14

17 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Applications standard Les applications standard au bénéfice d une certaine maturité présentent généralement une multitude de contrôles intégrés pertinents. Le tableau ci-après montre, à titre d exemple, quelques contrôles de base destinés à assurer l intégrité des transactions traitées: Une application de comptabilité standard devrait disposer des fonctionnalités suivantes (liste non exhaustive) Datation automatique des opération et des transactions par le système Offrir plusieurs identifications utilisateurs avec des mécanismes d authentification Ces fonctionnalités offrent (ou impliquent) les contrôles suivants Protection de l accès aux paramètres de la date système Cryptage du mot de passe Contrôle de la syntaxe du mot de passe Contrôle de la validité du mot de passe Historique des tentatives de connexion échouées Paramétrisation des autorisations Traces des mutations des paramètres et des données de base (paramètres de sécurité, plan de comptes, données de base créditeurs et débiteurs, etc.) Interdiction de supprimer Mécanisme de protection d accès par des profils de groupe ou des autorisations individuelles. Enregistrement automatique des anciennes valeurs dans un fichier historique (avec date de validité: valable dès le / jusqu au, date de la mutation et identification de l utilisateur qui a effectué la modification) Protection des accès aux paramètres et au fichier historique. Le programme ne doit pas proposer de fonction de suppression des données. En outre, les contrôles énumérés ci-dessous sont également très importants: valider les données (par ex. listes de sélection, formules de validation, etc.), piloter le traitement (job control, ordre de traitement journalier, mensuel, de fin d année, etc.), déroulement des transactions (par ex. gestion du workflow, contrôles des limites, principes des 4 yeux et signature électronique, vérification de la concordance entre commande/livraison/facture), gérer les dépenses (disponibilité des rapports, etc.). Lors de l évaluation des applications standard il convient de répondre par ex. aux questions suivantes: quel type d application standard l entreprise utilise-t-elle? l application standard est-elle répandue dans son secteur d activité? l application standard est-elle certifiée? s agit-il d un progiciel établi, connu ou d une nouveauté? existe-t-il des sources d informations sur cette application et, éventuellement, des faiblesses de sécurité ou de processus connues (remarque: les applications standards contiennent parfois des erreurs et l auditeur doit disposer d une connaissance suffisante sur les sources d erreur connues). l auditeur dispose-t-il de connaissances et d expériences personnelles relatives à l application? 15

18 Les réponses servent, conformément à la norme NAS 310 chiffre 10, à «l identification des domaines requérant une attention ou une connaissance particulières». Elles fournissent à l auditeur un aperçu des risques inhérents à l application utilisée. Si l auditeur conclut que l application standard ne présente pas de faiblesses connues dans les domaines qui le concernent, il peut limiter ses efforts dans les étapes suivantes de l approche d audit des applications au niveau de l identification des risques et l évaluation des contrôles pertinents. Au minimum, il doit s assurer que: les contrôles sur lesquels il compte s appuyer existent et fonctionnent en cas de paramètres d application, que ceux-ci étaient actifs pendant la période d audit concernée. Applications standard fortement adaptées Par applications standard fortement adaptées, nous entendons des progiciels dont le but principal est de mettre à disposition des fonctionnalités de base et des outils de création de processus et de workflows, et dont la paramétrisation permet la mise en place de solutions spécifiques qui répondent aux besoins de l entreprise. L auditeur est ici confronté à un grand défi dans la mesure où, même s il dispose d informations sur la fiabilité des composants des applications et systèmes éprouvés, il n en a pas sur l interaction de ces composants avec les éventuelles configurations et programmations supplémentaires dans l environnement spécifique du client. En pareilles situations, l auditeur devra prévoir davantage de temps pour l identification des risques et l évaluation des contrôles pertinents. Plus une application standard a été adaptée aux exigences spécifiques d une entreprise, plus l analyse des paramètres, de la gestion du workflow et des adaptations techniques des programmes est importante. Développements internes Dans le cas de développements internes, l auditeur n est pas en mesure de s appuyer sur les informations et les expériences généralement connues et doit adapter sa procédure d audit à l application concernée. Les applications développées en interne exigent généralement un travail de vérification plus important. En pareilles situations, la collaboration entre l auditeur, le responsable de l application et, le cas échéant, le développeur de l application revêt une grande importance. Dans le cas d applications standards fortement adaptées et d applications développées en interne, l auditeur s appuiera, pour des raisons d efficacité, et dans la mesure du possible, sur des tests documentés au sein de l entreprise. Si les tests correspondant n existent pas ou ne sont pas pertinents (concept ou documentation de test lacunaires, erreurs non corrigées après les tests, absence de prise en main formelle par les utilisateurs, etc.), il doit réaliser lui-même les tests nécessaires à sa vérification. Exploitation de l application par des tiers ou au sein de l entreprise L externalisation de domaines d activités ou de processus métiers comporte des risques inhérents et des risques d audit supplémentaires compte tenu de la délégation de responsabilité. La question de l organisation d un audit chez le prestataire de services est particulièrement pertinente: le standard de vérification NAS 402 (ou SAS 70) doit être pris en compte dans ce cas. 16

19 GUIDE D AUDIT DES APPLICATIONS INFORMATIQUES Utilisation centralisée ou décentralisée de l application De même, en raison des responsabilités déléguées mais également d une complexité technique souvent considérable (par ex. en termes d intégrité liée à des procédures de sauvegardes redondantes des données ou des séquences de traitement au travers de plusieurs périodes ou zones temporelles différentes), l utilisation décentralisée d une application comporte des risques inhérents et des risques d audit supplémentaires qui augmentent la complexité de l audit. Représentation des informations Représentation sous forme de tableau Position de bilan Montant en millier Processus Application utilisée Commentaire / présystèmes Type Exploitation Utilisation CA Facturation SAP FI Interfaces FACTURE et LIVRAISON Standard Int. Centralisée Salaires Gestion du personnel SAP HR ASP extern Standard Out. Centralisée Inventaire des principales interfaces Les interfaces d entrée et de sortie d une application de type financier doivent être considérées comme des sources de risque. Il est important de les identifier et de les contrôler. Nom de l interface Type Applications en amont/aval Type de flux Fréquence Listes d erreur Evaluation des risques 17

20 4 Identification des risques et des contrôles clés Vue d ensemble Contenu et objectif Cette étape consiste à délimiter le périmètre d audit qui sera ensuite évalué et testé. Elle consiste notamment à définir pour chaque risque significatif des scénarios d erreurs, afin d évaluer la manière dont ils peuvent être compensés par des contrôles clés. Il s agit donc à la fois de réduire l impact et la probabilité de survenance de ces erreurs. Par ailleurs, l impact sur les assertions dans les états financiers est également analysé (par ex. exhaustivité, authenticité, évaluation, rattachement à l exercice ou représentation dans les comptes annuels). Processus métier Applications Systèmes IT Infrastructure IT = Risques = Contrôle ITACS Training Contexte Compte tenu de la complexité des processus et des applications, il est important de se concentrer sur l essentiel lors des travaux d audit. L identification des risques et des contrôles clés attendus constitue la base pour un audit efficace. Les contrôles clés attendus par l auditeur sont ensuite comparés aux contrôles effectivement implémentés et la couverture des risques est évaluée. 18