Presque chaque audit IT, rapport SOC et évaluation SOX repose sur la même fondation, et ce n'est pas la partie clinquante. Avant qu'un auditeur ne se fie au rapprochement automatisé à trois voies de votre système d'achats, il vérifie si les bonnes personnes peuvent modifier cette logique, si les changements sont testés avant leur mise en production, et si quelqu'un pourrait discrètement s'octroyer des accès le week-end. Cette fondation, ce sont les contrôles généraux informatiques.
Les ITGC sont ingrats et ils décident si le reste de votre cadre de contrôle tient. Bien faits, les contrôles applicatifs deviennent fiables. Mal faits, l'auditeur traite chaque contrôle automatisé comme suspect, ce qui transforme une opinion propre en une longue liste de constats.
Que sont les contrôles généraux informatiques ?
Les contrôles généraux informatiques sont les contrôles pervasifs sur un environnement IT qui rendent fiables les systèmes et données derrière le reporting financier. « Généraux » est le mot clé : contrairement à un contrôle applicatif, qui protège un processus précis, un ITGC protège l'environnement dans lequel toutes les applications tournent.
La logique que suivent les auditeurs est simple. Les contrôles applicatifs automatisés ne sont dignes de confiance que si l'environnement autour d'eux est maîtrisé. Si n'importe qui peut modifier la logique d'un programme sans revue, ou s'octroyer des accès sans approbation, alors aucun contrôle automatisé ne peut être considéré comme fiable, car il a pu être altéré ou contourné. Les ITGC sont donc testés en premier, et tout le reste en dépend.
Les quatre domaines ITGC
Accès aux programmes et aux données
Qui peut s'authentifier, et ce qu'il peut faire une fois à l'intérieur. C'est le plus grand domaine et celui qui produit le plus de constats. Il couvre l'attribution et la révocation des accès, les accès privilégiés, les revues d'accès périodiques et la séparation des tâches. Pour les environnements SAP, c'est exactement là que vivent les autorisations, l'analyse SoD et le Firefighter / accès d'urgence.
Changements de programmes
Comment les changements aux systèmes existants sont autorisés, testés, approuvés et mis en production, avec un développement séparé de la production et personne ne pouvant écrire et livrer un changement sans contrôle. Dans SAP, cela correspond directement à la gestion des transports et aux contrôles qui l'entourent.
Développement des programmes
Comment les nouveaux systèmes et les implémentations majeures sont gouvernés, des exigences aux tests jusqu'au go-live. Une migration S/4HANA est un événement de développement de programme, et la conception des accès et des contrôles réalisée à cette occasion est précisément ce qu'un auditeur testera ensuite.
Exploitation informatique
Le fonctionnement quotidien de l'environnement : ordonnancement et surveillance des travaux, sauvegarde et restauration, gestion des incidents et des problèmes. Encore moins glamour, et régulièrement là où la preuve manque quand l'auditeur la demande.
ITGC face aux contrôles applicatifs
Les deux sont souvent confondus. Un contrôle applicatif est spécifique à un processus métier dans un système : un rapprochement à trois voies avant le paiement d'une facture, un blocage de comptabilisation sur une écriture déséquilibrée, une limite de tolérance sur un changement de prix. Un ITGC est le contrôle pervasif sur l'environnement dans lequel ces applications tournent.
Ce ne sont pas des alternatives ; ce sont des couches. Les auditeurs testent d'abord les ITGC précisément parce que les contrôles applicatifs héritent de leur fiabilité de l'environnement. Un rapprochement à trois voies parfait ne vaut rien si un développeur peut en modifier la logique et la mettre seul en production.
Correspondance des ITGC avec les cadres
Les mêmes contrôles sous-jacents apparaissent sous des noms différents selon qui pose la question :
- SOX: pour les sociétés cotées aux États-Unis et leurs filiales, y compris les entités suisses de groupes cotés. Les ITGC sur l'accès, le changement et l'exploitation sont une part centrale du périmètre IT.
- ISAE 3402 / SOC 1: pour les prestataires de services rendant compte des contrôles pertinents pour le reporting financier de leurs clients. Les ITGC en forment l'ossature.
- SOC 2: un ensemble plus large de Trust Services Criteria (sécurité, disponibilité, intégrité de traitement, confidentialité, vie privée), mais les contrôles d'accès, de changement et d'exploitation en sont aussi le cœur.
- Code des obligations suisse: les sociétés soumises au contrôle ordinaire doivent maintenir un système de contrôle interne, dont les contrôles généraux informatiques font partie.
En pratique, un jeu d'ITGC bien conçu sert plusieurs de ces cadres à la fois. Vous ne construisez pas un cadre de contrôle distinct par acronyme ; vous en construisez un et vous le démontrez face à chacun.
Là où ITGC et sécurité SAP se rejoignent
Pour une organisation qui exploite SAP, la plupart des ITGC qui comptent vivent dans le paysage SAP. Le domaine des accès, ce sont les autorisations SAP, la séparation des tâches et Firefighter. Le domaine des changements, c'est la gestion des transports SAP. Le domaine du développement se manifeste le plus nettement lors d'une migration S/4HANA. C'est pourquoi la sécurité SAP et l'audit IT sont pour nous la même conversation plutôt que deux métiers séparés, et pourquoi notre travail de sécurité SAP et notre travail d'audit IT sont indissociables.
Le versant plateforme compte aussi. Une revue d'accès n'a de sens que si le système sous-jacent est patché et surveillé, ce qui est la couche cybersécurité SAP sous les contrôles qu'un auditeur teste.
Être prêt pour l'audit sans sur-ingénierie
L'erreur la plus fréquente est de construire un cadre de contrôle plus lourd que ce dont l'organisation a besoin, puis de ne pas l'opérer. Un contrôle que vous concevez sans l'exécuter est pire que pas de contrôle, car vous avez désormais un contrôle documenté qui échoue de façon démontrable.
Bien dimensionner, c'est ajuster le cadre à votre taille, votre risque et votre contexte réglementaire réels. Une entreprise suisse de taille moyenne n'a pas besoin du catalogue de contrôles d'une banque mondiale. Elle a besoin des contrôles qui traitent ses risques réels, démontrés d'une manière que l'auditeur accepte, et opérés de façon constante. C'est la différence entre réussir un audit et vivre en remédiation permanente.
Comment MTC aide
Nous évaluons les contrôles généraux informatiques, remédions les écarts et préparons les organisations à SOX, ISAE 3402, SOC et aux audits statutaires suisses, avec une force particulière là où les contrôles vivent dans SAP. Notre parcours couvre à la fois l'audit IT et la sécurité SAP, si bien que nous concevons des contrôles testables, démontrés et dimensionnés pour votre organisation plutôt que copiés d'un modèle. Sur les mandats de plus grande ampleur, nous collaborons avec des cabinets internationaux de premier plan en audit, risque et technologie, tout en gardant une équipe senior basée en Suisse responsable du résultat.
À lire également
- Conseil en sécurité SAP, où vivent la plupart des ITGC pour les environnements SAP
- Conception des rôles Firefighter SAP : l'accès d'urgence comme contrôle ITGC
- Cybersécurité SAP : durcir la plateforme SAP
- SAP GRC Access Control : ce que c'est et quand vous en avez besoin
Questions fréquentes
Que sont les contrôles généraux informatiques (ITGC) ?
Les contrôles généraux informatiques (ITGC) sont les contrôles sur un environnement IT qui rendent fiables les systèmes et données soutenant le reporting financier. Ils couvrent l'accès aux programmes et aux données, les changements de programmes, le développement des programmes, et l'exploitation informatique. Les ITGC sous-tendent les contrôles applicatifs : si les contrôles généraux sont faibles, les auditeurs ne peuvent pas se fier aux contrôles automatisés dans les applications.
Quels sont les principaux domaines ITGC ?
Il existe quatre domaines ITGC classiques : l'accès aux programmes et aux données (qui peut se connecter et ce qu'il peut faire, y compris la séparation des tâches) ; les changements de programmes (comment les changements sont autorisés, testés et mis en production) ; le développement des programmes (comment les nouveaux systèmes sont construits et implémentés) ; et l'exploitation informatique (ordonnancement des travaux, sauvegardes, gestion des incidents et des problèmes).
Quelle différence entre ITGC et contrôles applicatifs ?
Les contrôles applicatifs sont spécifiques à un processus métier dans une application, comme un rapprochement à trois voies aux achats ou un blocage de comptabilisation sur une écriture déséquilibrée. Les ITGC sont les contrôles pervasifs sur l'environnement dans lequel ces applications tournent. Les auditeurs testent d'abord les ITGC, car des contrôles applicatifs fiables dépendent d'un environnement maîtrisé ; des ITGC faibles fragilisent tout le cadre de contrôle.
Quel lien entre ITGC, SOX et rapports SOC ?
Les ITGC sont une composante centrale de la conformité IT SOX pour les sociétés cotées et leurs filiales, et ils forment l'ossature des rapports SOC 1 / ISAE 3402 pour les prestataires de services. SOC 2 couvre un ensemble plus large de Trust Services Criteria (sécurité, disponibilité, confidentialité et plus), mais les contrôles d'accès, de changement et d'exploitation en sont aussi le cœur.