Questionnaire sécurité d'une banque ou d'un assureur : répondre vite sans surpromettre

Une affaire avance, puis la banque ou l'assureur envoie son questionnaire de sécurité fournisseur : des questions fermées, des pièces à joindre, une date de rendu. La tentation est de répondre « oui » partout pour ne pas bloquer la vente. C'est la réponse la plus risquée : chaque « oui » engage l'éditeur, et une partie des réponses peut se retrouver dans le contrat.

Ce guide s'adresse aux dirigeants et directeurs techniques d'éditeurs SaaS B2B. Il explique ce que l'acheteur cherche à établir, en particulier depuis l'entrée en application de DORA, propose un registre de réponses et une liste de contrôle pour constituer un dossier de preuves réutilisable, puis une méthode pour répondre « non » ou « partiel ». Il s'appuie sur le règlement (UE) 2022/2554 (DORA) et ses textes d'application, le RGPD, la Cloud Controls Matrix et le CAIQ de la Cloud Security Alliance, le questionnaire SIG, l'OWASP ASVS et trois publications du NIST ; les pages officielles citées ont été vérifiées le 7 octobre 2026. Il décrit une méthode, pas un dossier type accepté d'avance : la décision appartient toujours au client.

Ce que demande une banque ou un assureur, et pourquoi davantage depuis DORA

Le questionnaire documente une obligation de l'acheteur : montrer à son autorité de contrôle qu'il a choisi ses prestataires en connaissance de cause. Lire cette obligation indique quelles réponses comptent.

Trois mécanismes qui descendent jusqu'à l'éditeur

DORA s'applique depuis le 17 janvier 2025 aux vingt catégories d'entités financières énumérées à son article 2, dont les établissements de crédit, les établissements de paiement et les entreprises d'assurance et de réassurance. L'entité financière reste pleinement responsable du respect de ses obligations lorsqu'elle recourt à des prestataires tiers de services TIC (technologies de l'information et de la communication). Le règlement range les prestataires tiers de services TIC dans son champ d'application (article 2, paragraphe 1, point u)), mais ses obligations portent pour l'essentiel sur l'entité financière ; seuls les prestataires désignés comme critiques par les autorités européennes de surveillance relèvent d'un cadre de supervision directe (articles 31 et suivants). Un éditeur SaaS non désigné est atteint par trois mécanismes.

1. La diligence raisonnable avant contrat. Avant de conclure un accord sur l'utilisation de services TIC, l'entité évalue les risques et procède aux vérifications préalables sur le prestataire pressenti (article 28, paragraphe 4). Elle ne conclut d'accords qu'avec des prestataires qui appliquent des normes appropriées de sécurité de l'information, et tient compte, pour les fonctions critiques ou importantes, de l'usage des normes les plus récentes et de la plus haute qualité (article 28, paragraphe 5). Pour ces fonctions, l'article 6 du règlement délégué (UE) 2024/1773 détaille les vérifications : normes de sécurité, sous-traitants, traitement des données dans un pays tiers, acceptation d'audits, y compris sur place.
2. Les clauses contractuelles. L'article 30, paragraphe 2, fixe un contenu minimal pour tous les contrats, dont les lieux, régions ou pays, où les services sont fournis et où les données sont traitées, y compris leur lieu de stockage ; des dispositions sur la disponibilité, l'authenticité, l'intégrité et la confidentialité des données ; une assistance en cas d'incident TIC, sans coût supplémentaire ou à un coût fixé à l'avance. Pour une fonction critique ou importante, le paragraphe 3 ajoute notamment des descriptions complètes des niveaux de service avec des objectifs de performance quantitatifs et qualitatifs précis, des délais de préavis et des obligations de notification, la mise en œuvre et le test de plans d'urgence, des droits illimités d'accès, d'inspection et d'audit, et des stratégies de sortie. Pour ces fonctions, l'entité financière n'autorise la sous-traitance que si le prestataire est en mesure d'identifier tous les sous-traitants concernés, et le contrat oblige le prestataire à informer l'entité, en temps utile, de tout changement significatif de ses accords de sous-traitance (règlement délégué (UE) 2025/532, articles 3 et 5).
3. Le registre d'information. L'entité inscrit ses accords dans un registre conforme aux modèles du règlement d'exécution (UE) 2024/2956. Chaque prestataire personne morale y est identifié par un identifiant d'entité juridique (LEI, Legal Entity Identifier) valide et actif ou par l'identifiant unique européen (EUID), le LEI étant seul admis pour une société établie hors de l'Union. Le modèle B_02.02 demande notamment le pays depuis lequel le service est fourni, le pays de stockage des données au repos et celui de leur traitement. Ces données, c'est l'éditeur qui les fournit.

Le RGPD imposait déjà au responsable du traitement de ne recourir qu'à des sous-traitants présentant des garanties suffisantes, avec un contrat qui oblige le sous-traitant à mettre à disposition les informations nécessaires pour démontrer le respect de ses obligations et à permettre des audits, y compris des inspections (article 28) ; il prévoit aussi que le sous-traitant notifie au responsable du traitement toute violation de données à caractère personnel dans les meilleurs délais (article 33, paragraphe 2). DORA ajoute une horloge côté banque : la notification initiale d'un incident majeur lié aux TIC à l'autorité compétente intervient dans les quatre heures suivant sa classification comme majeur, et au plus tard 24 heures après que l'entité en a eu connaissance (règlement délégué (UE) 2025/301, article 5). D'où l'attention portée au délai dans lequel l'éditeur prévient son client.

Le point décisif tient au paragraphe 3 de l'article 6 du règlement délégué (UE) 2024/1773 : la politique de la banque y précise quels éléments fondent le niveau d'assurance exigé, parmi ses propres audits ou évaluations indépendantes, des rapports d'audit indépendants établis à la demande du prestataire, les rapports de la fonction d'audit interne du prestataire, des certifications de tiers appropriées et d'autres informations, dont celles fournies par le prestataire. Un questionnaire rempli relève de cette dernière catégorie : il reste une déclaration de l'éditeur, que la politique peut combiner avec d'autres éléments (même article, paragraphe 4). D'où les demandes de preuves jointes, et parfois de certificats.

Dix familles de questions

Les grilles diffèrent d'un acheteur à l'autre. Leurs questions peuvent se ranger en dix familles, rattachées ici aux domaines de la Cloud Controls Matrix (CCM) de la Cloud Security Alliance ; ce rattachement aide à réutiliser un CAIQ déjà rempli. Les pièces détaillées figurent dans la liste de contrôle du troisième chapitre.

Grilles et référentiels publics

Le questionnaire SIG (Standardized Information Gathering) de Shared Assessments existe en version SIG Lite, pour les fournisseurs à risque faible, et SIG Core, pour les fournisseurs à risque plus élevé ; son contenu suit un cycle annuel. Un acheteur peut aussi utiliser sa propre grille.

Le CAIQ (Consensus Assessments Initiative Questionnaire) de la Cloud Security Alliance pose des questions fermées, à réponse oui ou non, alignées sur la CCM. La version 4.1 de la CCM et du CAIQ, publiée le 27 janvier 2026, compte 207 contrôles répartis en 17 domaines et 283 questions. Un éditeur peut publier son CAIQ rempli au registre STAR comme auto-évaluation (niveau 1). Selon le calendrier de transition de la Cloud Security Alliance, le registre STAR accepte depuis mars 2026 les soumissions en version 4.1 comme en version 4.0 ; à partir de décembre 2027, seules les soumissions en version 4.1 seront acceptées, et les versions 4.0 de la CCM et du CAIQ seront retirées en janvier 2028. Un CAIQ rempli sert de base de réponse à une grille maison, à condition de le lire pour ce qu'il est : une déclaration.

Pour les questions applicatives, l'OWASP ASVS (Application Security Verification Standard), en version 5.0.0 depuis mai 2025, définit des exigences de sécurité pour les applications et services web, réparties en trois niveaux de vérification ; chaque exigence se cite avec sa version, par exemple v5.0.0-1.2.5. L'OWASP ne certifie ni fournisseur ni logiciel, et aucune marque de confiance ou certification revendiquant la conformité ASVS n'est approuvée officiellement par l'OWASP. Une réponse sérieuse annonce donc le niveau visé, les exigences couvertes, les exclusions justifiées et la méthode de vérification.

Pour le développement, le Secure Software Development Framework du NIST (SSDF, publication SP 800-218, version 1.1 de février 2022) décrit des pratiques de développement sécurisé auxquelles rattacher ses réponses ; un projet de version 1.2 (SP 800-218 Rev. 1) a été mis en consultation publique le 17 décembre 2025. Côté acheteur, la publication NIST SP 800-161 Rev. 1, mise à jour le 1er novembre 2024, guide la gestion des risques cyber de la chaîne d'approvisionnement : identifier, évaluer et réduire les risques liés aux produits et services acquis. Lue depuis ce point de vue, une grille sert à évaluer un risque fournisseur, pas à noter un candidat.

Déclaré contre démontrable : quatre niveaux de preuve

Entre ce qu'un éditeur déclare et ce qu'il peut démontrer, un écart peut exister sans qu'aucune mesure ne manque : la mesure existe, c'est la pièce qui fait défaut. La question utile devient : ce contrôle peut-il être montré, à une date donnée, sur tout le périmètre vendu ?

Quatre niveaux de preuve

Chaque « oui » vise le niveau « démontré » : une politique de revue des accès sans compte rendu ne prouve que l'intention.

D'où peut venir l'écart

• La règle sans trace. Une procédure peut exister sans que son exécution laisse d'enregistrement daté.
• La mesure partielle. Une mesure couvre une partie des accès d'administration, pas tous les outils qui affichent des données clients. Le « oui » vaut alors pour une partie du périmètre, alors que la question porte sur tout le service vendu.
• La preuve périmée. Une pièce antérieure à un changement d'hébergeur, d'architecture ou de périmètre décrit un système qui n'existe plus.
• La réponse recopiée. Une réponse reprise d'une grille précédente n'a de valeur que si quelqu'un a vérifié l'état actuel.

Décider de la réponse, question par question

Le dossier de preuves réutilisable : registre et liste de contrôle

Répondre vite, c'est ne plus produire les preuves au moment de la demande. Le dossier se construit une fois, s'indexe par famille et se revoit à dates fixes ; au questionnaire suivant, il reste à relier chaque question à des pièces existantes.

Le registre : une ligne par réponse

Le registre relie chaque réponse à sa preuve et à son périmètre. Un tableur suffit, à condition que chaque ligne porte la question reformulée dans les termes de l'éditeur, la réponse (oui, partiel ou non), le périmètre couvert, la référence de la pièce, son propriétaire désigné par sa fonction, la date de dernière vérification, les restrictions de partage (diffusable, sous accord de confidentialité, consultation sur place), l'écart éventuel, l'action et son échéance. Une réponse se revoit dès que son périmètre ou sa preuve change.

Les pièces elles-mêmes s'indexent dans le même tableur : pour chaque pièce, un identifiant stable, la famille, une légende d'une ligne, la date et le système d'origine, le propriétaire, la prochaine mise à jour et le niveau de diffusion.

Exemple fictif : trois lignes du registre

Liste de contrôle des pièces

Fiche fournisseur, pour le registre de la banque

• Raison sociale, pays du siège, entreprise mère ultime le cas échéant
• LEI valide et actif, ou EUID pour une société établie dans l'Union ; un LEI non renouvelé passe au statut « lapsed » dans la base de la GLEIF : la GLEIF le considère toujours comme valide, mais les autorités européennes de surveillance rappellent que le registre exige un LEI actif, d'où l'intérêt de le renouveler avant de remplir la fiche
• Services fournis, pays de fourniture, pays de stockage et de traitement des données
• Sous-traitants qui concourent au service, avec leur pays et, pour une fonction critique ou importante, leur LEI ou EUID
• Contact sécurité et contact de notification d'incident

Gouvernance

• Politique de sécurité signée et datée ; rôles nommés par fonction
• Analyse de risques et plan de traitement datés
• Registre des activités de traitement tenu en qualité de sous-traitant (RGPD, article 30, paragraphe 2)

Accès

• Export de configuration du fournisseur d'identité : authentification multifacteur imposée, y compris sur les outils internes qui affichent des données clients
• Liste des comptes à privilèges ; compte rendu daté de la dernière revue des accès
• Échantillon de départs avec la date de révocation des accès

Chiffrement et journalisation

• Configuration du service de gestion de clés : propriétaire, rotation ; chiffrement des sauvegardes
• Résultat daté d'un test de configuration TLS du point d'entrée public
• Sources de journaux collectées, durée de conservation, exemple d'alerte horodatée et traitée

Vulnérabilités et développement

• Politique de correction avec délais par niveau de sévérité
• Synthèse du dernier scan, tickets de correction fermés, analyse des dépendances dans l'intégration continue
• Exigences de sécurité applicative suivies, citées avec leur version : par exemple ASVS 5.0.0, niveau visé et exclusions
• Historique des changements en production, avec revue et approbation

Continuité

• Plan de continuité et de reprise, avec objectifs de perte de données (RPO, Recovery Point Objective) et de reprise (RTO, Recovery Time Objective) déclarés
• Compte rendu daté du dernier test de restauration : périmètre, durée mesurée, écarts

Sous-traitants et localisation

• Certificats ou rapports des principaux sous-traitants, dont l'hébergeur, avec leur date de validité
• Schéma d'architecture et de flux, régions d'hébergement, accès d'administration hors de l'Union et garanties associées

Incidents

• Procédure de gestion et de notification, délai proposé, canal
• Compte rendu anonymisé du dernier exercice ou incident traité

Attestations, si elles existent

• Certificat ISO/IEC 27001 avec son périmètre et sa déclaration d'applicabilité
• Rapport SOC 2 et période couverte

Les pièces de la chaîne de livraison, de l'analyse d'une image à sa signature et à sa promotion en production, sont détaillées dans DevSecOps en pratique : scanner, signer et promouvoir l'image qu'on déploie vraiment.

Une pièce de preuve est aussi une information sensible : masquez secrets, adresses internes et noms de personnes, transmettez sous accord de confidentialité par un espace d'échange à accès limité dans le temps, et réservez les pièces les plus sensibles à une consultation sur place. Un export brut expose plus qu'il ne prouve ; un extrait filtré, daté et légendé répond à la question posée.

Quand une preuve périme

Une réponse peut rester vraie alors que sa preuve ne l'est plus. Un changement de fournisseur, d'architecture ou de périmètre invalide les pièces qui décrivaient l'état antérieur : le registre indique lesquelles, qui les remplace et si le client doit être informé. Pour un service qui soutient une fonction critique ou importante, le contrat prévoit des obligations de notification de tout développement susceptible d'avoir une incidence significative sur la capacité du prestataire à fournir le service (DORA, article 30, paragraphe 3, point b).

Exemple fictif : changements et preuves invalidées

Répondre « non » ou « partiel » avec un plan daté

Un « non » bien écrit se défend ; un « oui » faux ne se rattrape pas. L'acheteur n'attend pas un fournisseur sans écart : il évalue un risque et décide s'il l'accepte. Un écart daté lui donne cette matière ; un « oui » démenti plus tard par un incident ou une vérification fragilise toute la grille.

Les six éléments d'une réponse honnête

1. L'état actuel, en une phrase factuelle.
2. Le périmètre couvert, et celui qui ne l'est pas.
3. La mesure compensatoire en place, avec sa preuve.
4. La cible, formulée comme un résultat vérifiable.
5. La date et le responsable, désigné par sa fonction.
6. La preuve de clôture promise, et la manière dont le client en sera informé.

Exemple fictif. Question : « Des tests de restauration sont-ils réalisés et documentés ? » Réponse : « Partiel. Les sauvegardes de la base de production sont automatisées et chiffrées (pièce CON-02). Le dernier test de restauration n'a pas été consigné. Un test de restauration complète dans un environnement isolé est planifié avant la fin du trimestre, sous la responsabilité du directeur technique ; son compte rendu (périmètre, durée mesurée, écarts) sera transmis à votre contact sécurité dès sa validation. »

Formulations qui surpromettent

Formulations types, établies pour cet article.

Tenir les dates, et relire ce qui devient contractuel

Un plan daté est une promesse. Ses dates tiennent compte des dépendances : une certification dépend aussi du calendrier de l'organisme qui la délivre. Un glissement s'annonce avant l'échéance, avec sa raison. Chaque action se clôt par la preuve promise, qui rejoint le dossier.

Le contrat transforme ensuite une partie des réponses en obligations : localisation, assistance en cas d'incident, notification, droits d'accès, d'inspection et d'audit. Pour un SaaS mutualisé, des droits d'audit illimités peuvent toucher la confidentialité des autres clients ; l'article 30, paragraphe 3, point e) ii), prévoit le droit de convenir d'autres niveaux d'assurance lorsque les droits d'autres clients sont affectés. Ces clauses se relisent avec votre conseil juridique avant signature.

Quand une certification ou un rapport d'assurance devient nécessaire

Plusieurs signaux indiquent que le niveau « attesté » devient nécessaire : les mêmes questions reviennent d'un acheteur à l'autre ; le produit soutient une fonction critique ou importante du client, dont la politique peut retenir des certifications de tiers ou des rapports d'audit indépendants parmi ses éléments d'assurance ; la grille pose la certification comme prérequis.

Deux rôles restent distincts. Préparer, c'est construire le système de management, organiser les preuves et combler les écarts. Attester, c'est vérifier de manière indépendante : un certificat ISO/IEC 27001 reconnu est délivré par un organisme de certification accrédité, un rapport SOC 2 par un cabinet d'experts-comptables agréés aux États-Unis (CPA, Certified Public Accountants). La préparation ne remplace pas l'attestation.

Ce qu'un certificat ou un rapport change, et ce qu'il ne change pas

Un certificat ISO/IEC 27001 place la gouvernance au niveau « attesté » et appuie les autres familles, dans la limite de son périmètre. L'acheteur lit ce périmètre en premier : un certificat qui exclut la plateforme produit répond mal à la question d'un client SaaS. Il lit aussi la déclaration d'applicabilité, qui liste les mesures de sécurité retenues et exclues avec leur justification. Il peut vérifier le certificat dans IAF CertSearch, base de certifications accréditées alimentée par les organismes d'accréditation et de certification ; une absence se vérifie auprès de l'organisme émetteur.

Un rapport SOC 2 de type 1 porte sur la conception des contrôles à une date ; un rapport de type 2 porte aussi sur leur efficacité de fonctionnement au cours d'une période, avec le détail des tests de l'auditeur. Son usage étant en principe restreint, il se transmet sous accord de confidentialité. La différence entre rapport d'attestation et certification, et le choix entre les deux référentiels, sont détaillés dans SOC 2 ou ISO 27001 : lequel choisir pour un SaaS français, et comment préparer un premier SOC 2.

Ni l'un ni l'autre ne remplace les clauses de l'article 30 ni les informations du registre : une grille peut admettre un renvoi au certificat pour une famille, elle demandera toujours la localisation des données, les sous-traitants et le délai de notification.

Pour relier une exigence client à des contrôles et à des preuves techniques, la page Conformité technique : de l'exigence à la preuve présente nos interventions et leurs limites. Nous ne délivrons ni certificat ni attestation, et les réponses au questionnaire restent celles de l'éditeur.

Sources officielles et limites de lecture

• DORA oblige l'entité financière. La qualification d'une fonction comme critique ou importante relève du client ; deux acheteurs peuvent poser la même question avec des attentes différentes.
• Les grilles évoluent. Le SIG suit un cycle annuel, la CCM et le CAIQ sont passés en version 4.1, le SSDF a un projet de version 1.2, chaque acheteur révise sa grille.
• Les textes font foi. Les points de l'article 30 sont résumés ici ; une clause se négocie sur le texte publié au Journal officiel de l'Union européenne.
• Les exemples sont fictifs. Registre, réponses et changements illustrent une méthode ; ils ne reproduisent aucun questionnaire ni dossier réel.
• Un dossier de preuves ne garantit ni l'acceptation par l'acheteur ni la signature du contrat. Il rend les réponses vérifiables ; la décision appartient au client.

Un client qui exige une installation du produit dans son propre environnement pose d'autres questions, traitées dans Livrer votre SaaS on-premise ou en air gap : ce que le client va exiger.

Sources

1. Règlement (UE) 2022/2554 du Parlement européen et du Conseil du 14 décembre 2022 sur la résilience opérationnelle numérique du secteur financier (DORA), articles 2, 28, 30, 31 et 64, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022R2554, consulté le 07/10/2026.
2. European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act (18 novembre 2025), EIOPA, https://www.eiopa.europa.eu/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital-2025-11-18_en, consulté le 07/10/2026.
3. Règlement délégué (UE) 2024/1773 de la Commission du 13 mars 2024 (politique relative aux accords contractuels sur l'utilisation de services TIC soutenant des fonctions critiques ou importantes), article 6, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202401773, consulté le 07/10/2026.
4. Règlement délégué (UE) 2025/532 de la Commission du 24 mars 2025 (sous-traitance de services TIC soutenant des fonctions critiques ou importantes), articles 3 à 6, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202500532, consulté le 07/10/2026.
5. Règlement d'exécution (UE) 2024/2956 de la Commission du 29 novembre 2024 (modèles types du registre d'information), article 3 et modèles B_02.02 et B_05.01, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202402956, consulté le 07/10/2026.
6. Règlement délégué (UE) 2025/301 de la Commission du 23 octobre 2024 (contenu et délais des notifications et rapports d'incidents majeurs liés aux TIC), article 5, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=OJ:L_202500301, consulté le 07/10/2026.
7. Règlement (UE) 2016/679 (RGPD), articles 28, 30 et 33, EUR-Lex, https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32016R0679, consulté le 07/10/2026.
8. The Power of Transparency: A Closer Look at LEI Renewal Rates, GLEIF, https://www.gleif.org/en/newsroom/blog/the-power-of-transparency-a-closer-look-at-lei-renewal-rates, consulté le 07/10/2026.
9. DORA Register of Information reporting FAQ (version du 28 mars 2025), question 44, autorités européennes de surveillance, EBA, https://www.eba.europa.eu/sites/default/files/2025-03/31bb6e60-7d10-4405-a8c5-9f04934630ac/20250328%20-%20DORA%20RoI%20reporting%20FAQ%20(updated).pdf, consulté le 07/10/2026.
10. SIG FAQ, Shared Assessments, https://sharedassessments.org/sig-faq/, consulté le 07/10/2026.
11. Cloud Controls Matrix and CAIQ v4.1, Cloud Security Alliance, https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1, consulté le 07/10/2026.
12. CCM v4.1 Transition Timeline, Cloud Security Alliance, https://cloudsecurityalliance.org/blog/2026/02/19/ccm-v4-1-transition-timeline, consulté le 07/10/2026.
13. STAR Level 1: Security Questionnaire (CAIQ v4.1), Cloud Security Alliance, https://cloudsecurityalliance.org/artifacts/star-level-1-security-questionnaire-caiq-v4-1, consulté le 07/10/2026.
14. Cloud Controls Matrix, liste des domaines, Cloud Security Alliance, https://cloudsecurityalliance.org/research/cloud-controls-matrix, consulté le 07/10/2026.
15. OWASP Application Security Verification Standard 5.0.0, dépôt officiel GitHub OWASP/ASVS, https://github.com/OWASP/ASVS/releases/tag/v5.0.0_release, consulté le 07/10/2026.
16. What is the ASVS?, OWASP ASVS 5.0.0, dépôt officiel GitHub OWASP/ASVS, https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x03-What-is-the-ASVS.md, consulté le 07/10/2026.
17. Assessment and Certification, OWASP ASVS 5.0.0, dépôt officiel GitHub OWASP/ASVS, https://github.com/OWASP/ASVS/blob/v5.0.0/5.0/en/0x04-Assessment_and_Certification.md, consulté le 07/10/2026.
18. NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1, NIST, https://csrc.nist.gov/pubs/sp/800/218/final, consulté le 07/10/2026.
19. NIST SP 800-218 Rev. 1 (projet), Secure Software Development Framework (SSDF) Version 1.2, NIST, https://csrc.nist.gov/pubs/sp/800/218/r1/ipd, consulté le 07/10/2026.
20. NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (mise à jour 1), NIST, https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final, consulté le 07/10/2026.
21. System and Organization Controls: SOC Suite of Services, AICPA & CIMA, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services, consulté le 07/10/2026.
22. Explaining the 3 faces of SOC, Journal of Accountancy (AICPA), https://www.journalofaccountancy.com/newsletters/2016/jun/3-face-of-soc/, consulté le 07/10/2026.
23. IAF CertSearch, Global Accreditation Cooperation Incorporated (Global ACI, qui a repris les rôles de l'IAF le 1er janvier 2026), https://www.iafcertsearch.org/, consulté le 07/10/2026.
24. Auditing Practices Note: Statement of Applicability, ISO/IEC JTC 1/SC 27/WG 1 (N3298, septembre 2022), https://committee.iso.org/files/live/sites/jtc1sc27/files/resources/ISO-IECJTC1-SC27-WG1_N3298_Auditing%20Practices%20Note%20-%20SoA.pdf, consulté le 07/10/2026.