Support d'audit

Important : Cette compétence assiste les workflows de conformité SOX mais ne fournit pas de conseil en audit ou en droit. Tous les dossiers de travail de test et les évaluations doivent être examinés par des professionnels financiers qualifiés. Bien que « la signification » et « la matérialité » soient des concepts contextuels évalués en dernier ressort par les auditeurs, cette compétence est destinée à assister les professionnels dans la création et l'évaluation de contrôles internes efficaces et de la documentation pour les audits.

Méthodologie de test de contrôle SOX 404, approches de sélection d'échantillon, normes de documentation des tests, classification des défaillances de contrôle et types de contrôles courants.

Méthodologie de test de contrôle SOX 404

Aperçu

La section 404 de SOX exige que la direction évalue l'efficacité des contrôles internes sur les rapports financiers (ICFR). Cela implique :

1. Détermination de la portée : Identifier les comptes significatifs et les assertions pertinentes
2. Évaluation des risques : Évaluer le risque d'anomalie significative pour chaque compte significatif
3. Identification des contrôles : Documenter les contrôles qui traitent chaque risque
4. Test : Tester la conception et l'efficacité opérationnelle des contrôles clés
5. Évaluation : Évaluer si des défaillances existent et leur sévérité
6. Rapportage : Documenter l'évaluation et toute faiblesse significative

Détermination de la portée des comptes significatifs

Un compte est significatif s'il existe plus qu'une probabilité lointaine qu'il puisse contenir une anomalie qui est significative (individuellement ou en agrégat).

Facteurs quantitatifs :

• Le solde du compte dépasse le seuil de matérialité (généralement 3-5% d'un repère clé)
• Le volume de transactions est élevé, augmentant le risque d'erreur
• Le compte est soumis à des estimations significatives ou au jugement

Facteurs qualitatifs :

• Le compte implique une comptabilité complexe (reconnaissance de revenus, dérivés, pensions)
• Le compte est susceptible à la fraude (trésorerie, revenus, transactions avec des parties liées)
• Le compte a eu des anomalies antérieures ou des ajustements d'audit
• Le compte implique un jugement ou des estimations significatifs de la direction
• Nouveau compte ou processus considérablement modifié

Assertions pertinentes par type de compte

Efficacité de la conception par rapport à l'efficacité opérationnelle

Efficacité de la conception : Le contrôle est-il correctement conçu pour prévenir ou détecter une anomalie significative dans l'assertion pertinente ?

• Évaluée par des procédures de cheminement (tracer une transaction de bout en bout dans le processus)
• Confirmer que le contrôle est placé au bon endroit dans le processus
• Confirmer que le contrôle traite le risque identifié
• Effectuée au moins annuellement, ou en cas de modification de processus

Efficacité opérationnelle : Le contrôle a-t-il réellement fonctionné comme prévu tout au long de la période de test ?

• Évaluée par des tests (inspection, observation, re-exécution, demande de renseignements)
• Nécessite des tailles d'échantillon suffisantes pour soutenir une conclusion
• Doit couvrir la période complète de reliance

Approches de sélection d'échantillon

Sélection aléatoire

Quand l'utiliser : Méthode par défaut pour les contrôles au niveau des transactions avec de grandes populations.

Méthode :

1. Définir la population (toutes les transactions soumises au contrôle pendant la période)
2. Numéroter séquentiellement chaque élément de la population
3. Utiliser un générateur de nombres aléatoires pour sélectionner les éléments d'échantillon
4. Assurer l'absence de biais dans la sélection (tous les éléments ont une probabilité égale)

Avantages : Statistiquement valide, défendable, pas de biais de sélection Inconvénients : Peut manquer les éléments à risque élevé, nécessite une énumération complète de la population

Sélection ciblée (jugement)

Quand l'utiliser : Supplément à la sélection aléatoire pour les tests basés sur les risques ; méthode principale quand la population est petite ou très variée.

Méthode :

1. Identifier les éléments avec des caractéristiques de risque spécifiques :
   • Montant élevé (au-dessus d'un seuil défini)
   • Transactions inusitées ou non-standard
   • Transactions de fin de période (risque de délai)
   • Transactions avec des parties liées
   • Transactions manuelles ou d'override
   • Transactions avec de nouveaux fournisseurs/clients
2. Sélectionner les éléments correspondant aux critères de risque
3. Documenter le justificatif de chaque sélection ciblée

Avantages : Se concentre sur les éléments à plus haut risque, utilisation efficace de l'effort de test Inconvénients : Pas statistiquement représentatif, peut sur-représenter certains risques

Sélection aléatoire simple

Quand l'utiliser : Quand la sélection aléatoire est impraticable (pas d'énumération séquentielle de la population) et la population est relativement homogène.

Méthode :

1. Sélectionner les éléments sans aucun motif ou biais spécifique
2. S'assurer que les sélections sont réparties sur la période complète de la population
3. Éviter le biais inconscient (ne pas toujours choisir les éléments au sommet, les nombres ronds, etc.)

Avantages : Simple, aucune technologie requise Inconvénients : Pas statistiquement valide, susceptible au biais inconscient

Sélection systématique

Quand l'utiliser : Quand la population est séquentielle et que vous voulez une couverture égale sur la période.

Méthode :

1. Calculer l'intervalle d'échantillonnage : Taille de la population / Taille de l'échantillon
2. Sélectionner un point de départ aléatoire dans le premier intervalle
3. Sélectionner tous les Nèmes éléments à partir du point de départ

Exemple : Population de 1 000, échantillon de 25 → intervalle de 40. Départ aléatoire : élément 17. Sélectionner les éléments 17, 57, 97, 137, ...

Avantages : Couverture égale sur la population, simple à exécuter Inconvénients : Les motifs périodiques dans la population pourraient biaiser les résultats

Guide de taille d'échantillon

Facteurs augmentant la taille de l'échantillon :

• Risque inhérent plus élevé dans le compte/processus
• Le contrôle est le seul contrôle traitant un risque significatif (pas de redondance)
• Défaillance de contrôle identifiée au cours de la période antérieure
• Nouveau contrôle (non testé au cours des périodes antérieures)
• Reliance du vérificateur externe sur les tests de direction

Normes de documentation des tests

Exigences relatives aux dossiers de travail

Chaque test de contrôle doit être documenté avec :

1. Identification du contrôle :

   • Numéro/ID du contrôle
   • Description du contrôle (ce qui est fait, par qui, à quelle fréquence)
   • Type de contrôle (manuel, automatisé, manuel dépendant de l'IT)
   • Fréquence du contrôle
   • Risque et assertion traités

2. Conception du test :

   • Objectif du test (ce que vous essayez de déterminer)
   • Procédures de test (instructions étape par étape)
   • Preuves attendues (ce que vous vous attendez à voir si le contrôle est efficace)
   • Méthodologie de sélection d'échantillon et justificatif

3. Exécution du test :

   • Description et taille de la population
   • Détails de sélection d'échantillon (méthode, éléments sélectionnés)
   • Résultats pour chaque élément d'échantillon (réussi/échoué avec preuves spécifiques examinées)
   • Exceptions notées avec description complète

4. Conclusion :

   • Évaluation globale (efficace / défaillance / défaillance significative / faiblesse significative)
   • Fondement de la conclusion
   • Évaluation d'impact pour les exceptions
   • Contrôles compensatoires considérés (si applicable)

5. Approbation :

   • Nom et date du testeur
   • Nom et date du réviseur

Normes de preuve

Les preuves suffisantes incluent :

• Captures d'écran montrant les contrôles appliqués par le système
• Documents d'approbation signés/paraphés
• Approbations par email avec approbateur identifiable et date
• Journaux d'audit système montrant qui a effectué l'action et quand
• Calculs re-effectués avec résultats correspondants
• Notes d'observation (avec date, lieu, observateur)

Preuves insuffisantes :

• Confirmations verbales seules (doivent être corroborées)
• Documents non datés
• Preuves sans exécutant/approbateur identifiable
• Rapports système génériques sans horodatage
• « Per discussion with [name] » sans documentation corroborante

Organisation des dossiers de travail

Organiser les fichiers de test par domaine de contrôle :

Testing_SOX/
├── [Année]/
│   ├── Scoping_and_Risk_Assessment/
│   ├── Revenue_Cycle/
│   │   ├── Control_Matrix
│   │   ├── Walkthrough_Documentation
│   │   ├── Test_Workpapers (un par contrôle)
│   │   └── Supporting_Evidence
│   ├── Procure_to_Pay/
│   ├── Payroll/
│   ├── Financial_Close/
│   ├── Treasury/
│   ├── Fixed_Assets/
│   ├── IT_General_Controls/
│   ├── Entity_Level_Controls/
│   └── Summary_and_Conclusions/
│       ├── Deficiency_Evaluation
│       └── Management_Assessment

Classification des défaillances de contrôle

Défaillance

Une défaillance du contrôle interne existe quand la conception ou l'exploitation d'un contrôle ne permet pas à la direction ou aux employés, dans le cours normal de l'exécution de leurs fonctions assignées, de prévenir ou de détecter les anomalies en temps opportun.

Facteurs d'évaluation :

• Quelle est la probabilité que la défaillance du contrôle puisse entraîner une anomalie ?
• Quelle est l'ampleur de l'anomalie potentielle ?
• Y a-t-il un contrôle compensatoire qui atténue la défaillance ?

Défaillance significative

Une défaillance, ou une combinaison de défaillances, qui est moins grave qu'une faiblesse significative mais suffisamment importante pour mériter l'attention de ceux chargés de la gouvernance.

Indicateurs :

• La défaillance pourrait entraîner une anomalie plus que mineure mais inférieure à significative
• Il existe plus qu'une probabilité lointaine (mais inférieure à raisonnablement possible) d'une anomalie significative
• Le contrôle est un contrôle clé et la défaillance n'est pas entièrement atténuée par les contrôles compensatoires
• Combinaison de défaillances individuellement mineures qui ensemble représentent une préoccupation significative

Faiblesse significative

Une défaillance, ou une combinaison de défaillances, telle qu'il existe une probabilité raisonnable qu'une anomalie significative des états financiers ne soit pas prévenue ou détectée en temps opportun.

Indicateurs :

• Identification de fraude par la haute direction (toute ampleur)
• Retraitement des états financiers antérieurement émis pour corriger une erreur significative
• Identification par le vérificateur d'une anomalie significative qui n'aurait pas été détectée par les contrôles de la société
• Surveillance inefficace des rapports financiers par le comité d'audit
• Défaillance d'un contrôle envahissant (niveau d'entité, contrôle IT général) affectant plusieurs processus

Agrégation de défaillances

Les défaillances individuelles qui ne sont pas significatives individuellement peuvent être significatives en combinaison :

1. Identifier toutes les défaillances dans le même processus ou affectant la même assertion
2. Évaluer si l'effet combiné pourrait entraîner une anomalie significative
3. Considérer si les défaillances dans les contrôles compensatoires exacerbent d'autres défaillances
4. Documenter l'analyse et la conclusion d'agrégation

Correction

Pour chaque défaillance identifiée :

1. Analyse de la cause racine : Pourquoi le contrôle a-t-il échoué ? (lacune de conception, défaut d'exécution, personnel, formation, problème système)
2. Plan de correction : Actions spécifiques pour corriger le contrôle (reconception, formation supplémentaire, amélioration système, révision ajoutée)
3. Calendrier : Date cible pour l'achèvement de la correction
4. Propriétaire : Personne responsable de la mise en œuvre de la correction
5. Validation : Comment et quand le contrôle corrigé sera re-testé pour confirmer son efficacité

Types de contrôles courants

Contrôles IT généraux (CITG)

Contrôles sur l'environnement IT qui soutiennent le fonctionnement fiable des contrôles d'application et des processus automatisés.

Contrôles d'accès :

• Approvisionnement en accès utilisateur (les nouvelles demandes d'accès requièrent une approbation)
• Retrait d'accès utilisateur (les utilisateurs résiliés sont supprimés en temps opportun)
• Gestion des accès privilégiés (l'accès admin/superuser est restreint et surveillé)
• Révisions d'accès périodiques (l'accès utilisateur est recertifié selon un calendrier défini)
• Politiques de mot de passe (complexité, rotation, verrouillage)
• Application de la séparation des fonctions (l'accès conflictuel est prévenu)

Gestion des modifications :

• Les demandes de modification sont documentées et approuvées avant la mise en œuvre
• Les modifications sont testées dans un environnement hors production avant la promotion
• Séparation des environnements de développement et de production
• Procédures de modification d'urgence (documentées, approuvées post-implémentation)
• Révision des modifications et validation post-implémentation

Opérations IT :

• Surveillance des travaux batch et gestion des exceptions
• Procédures de sauvegarde et de récupération (sauvegardes régulières, restaurations testées)
• Surveillance de la disponibilité système et de la performance
• Gestion des incidents et procédures d'escalade
• Planification et test de la reprise après sinistre

Contrôles manuels

Contrôles effectués par des personnes utilisant le jugement, généralement impliquant la révision et l'approbation.

Exemples :

• Révision par la direction des états financiers et des indicateurs clés
• Approbation supervisée des écritures de journal au-dessus d'un seuil
• Vérification en trois sens (BC, réception, facture)
• Préparation et révision de rapprochement de compte
• Observation physique d'inventaire et comptage
• Approbation des modifications de données maître fournisseur
• Approbation de crédit client

Attributs clés à tester :

• Le contrôle a-t-il été effectué par la bonne personne (autorité appropriée) ?
• A-t-il été effectué en temps opportun (dans le délai requis) ?
• Y a-t-il une preuve de la révision (signature, paraphes, email, journal système) ?
• Le réviseur avait-il suffisamment d'informations pour effectuer une révision efficace ?
• Les exceptions ont-elles été identifiées et traitées de manière appropriée ?

Contrôles automatisés

Contrôles appliqués par les systèmes IT sans intervention humaine.

Exemples :

• Flux d'approbation appliqués par le système (ne peut pas procéder sans approbations requises)
• Automatisation de la correspondance en trois sens (le système bloque le paiement si BC/réception/facture ne correspondent pas)
• Détection de paiement en double (le système signale ou bloque les factures en double)
• Application des limites de crédit (le système empêche les commandes dépassant la limite de crédit)
• Calculs automatisés (amortissement, amortissement, intérêt, impôt)
• Séparation des fonctions appliquée par le système (les rôles conflictuels sont empêchés)
• Contrôles de validation d'entrée (champs requis, vérifications de format, vérifications de plage)
• Rapprochement automatisé

Approche de test :

• Test de conception : Confirmer que la configuration du système applique le contrôle comme prévu
• Test d'efficacité opérationnelle : Pour les contrôles automatisés, si la configuration du système n'a pas changé, un test du contrôle est généralement suffisant pour la période (complété par le test des CITG de gestion des modifications)
• Vérifier que les CITG de gestion des modifications sont efficaces (si le système a changé, re-tester le contrôle)

Contrôles manuels dépendant de l'IT

Contrôles manuels qui s'appuient sur l'exhaustivité et l'exactitude des informations générées par le système.

Exemples :

• Révision par la direction d'un rapport d'exception généré par le système
• Révision supervisée d'un rapport de vieillissement généré par le système pour évaluer les réserves
• Rapprochement utilisant les données de balance générale générées par le système
• Approbation des transactions identifiées par un flux de travail généré par le système

Approche de test :

• Tester le contrôle manuel (révision, approbation, suivi des exceptions)
• ET tester l'exhaustivité et l'exactitude du rapport/des données sous-jacentes (IPE — Information Produced by the Entity)
• Le test IPE confirme que les données sur lesquelles s'est appuyé le réviseur étaient complètes et exactes

Contrôles au niveau de l'entité

Contrôles généraux qui opèrent au niveau organisationnel et affectent plusieurs processus.

Exemples :

• Ton du sommet / code de conduite
• Processus d'évaluation des risques
• Surveillance du comité d'audit sur les rapports financiers
• Fonction et activités d'audit interne
• Évaluation des risques de fraude et programmes anti-fraude
• Ligne d'éthique/dénonciation
• Surveillance par la direction de l'efficacité des contrôles
• Compétence en matière de rapports financiers (personnel, formation, qualifications)
• Processus de rapportage financier de fin de période (procédures de clôture, révisions de conformité GAAP)

Signification :

• Les contrôles au niveau de l'entité peuvent atténuer mais généralement ne peuvent pas remplacer les contrôles au niveau du processus
• Les contrôles au niveau de l'entité inefficaces (en particulier la surveillance du comité d'audit et le ton du sommet) sont de forts indicateurs d'une faiblesse significative
• Les contrôles au niveau de l'entité efficaces peuvent réduire l'étendue du test nécessaire pour les contrôles au niveau du processus