---
title: "Quelle mesure prouve chaque exigence de sécurité du marché ?"
description: "Décomposez la demande de l’acheteur en propositions vérifiables, puis reliez chacune aux mesures mises en œuvre et aux preuves de même périmètre."
canonical: "https://zephior.com/fr/insights/map-security-controls-to-rfp-requirements"
last-updated: 2026-09-04
---

# Quelle mesure prouve chaque exigence de sécurité du marché ?

> Décomposez la demande de l’acheteur en propositions vérifiables, puis reliez chacune aux mesures mises en œuvre et aux preuves de même périmètre.

Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Publié le 2026-09-04; mis à jour le 2026-09-04. 20 min de lecture.

## Définition

Une cartographie des exigences de sécurité relie chaque proposition vérifiable de l’acheteur aux mesures organisationnelles ou techniques réellement appliquées au service offert. Elle précise qui exécute la mesure, dans quel périmètre, par quel mécanisme et avec quelle preuve de conception, de déploiement, de fonctionnement ou d’évaluation. La relation n’est pas forcément individuelle. Une exigence peut dépendre de plusieurs mesures, tandis qu’une mesure peut contribuer à plusieurs exigences. Une table de correspondance entre référentiels oriente l’analyse, mais ne démontre pas la mise en œuvre du fournisseur.

## Problème

Un questionnaire demande si le fournisseur gère les vulnérabilités, tient un inventaire des composants, corrige les failles critiques sous quatorze jours et fait tester le service chaque année. L’équipe répond par une référence ISO ou NIST et joint un rapport de test. Rien ne montre encore que l’inventaire couvre le connecteur proposé, que le délai est mesuré, que les exceptions sont approuvées ou que le rapport inclut la version offerte. Le référentiel, la procédure interne, le scanner et l’évaluation externe deviennent une seule notion de « contrôle ». Cette simplification produit une réponse rassurante, mais impossible à vérifier exigence par exigence.

## Point de vue

Prenez le texte de l’acheteur comme point de départ. Figez le lot, la version documentaire, le service, ses environnements, ses composants et les tiers concernés. Séparez chaque résultat attendu, puis recherchez les mesures internes qui le produisent dans ce périmètre. Qualifiez le lien entre exigence et mesure, attribuez les responsabilités et associez une preuve dont l’objet, la population et la période correspondent. La réponse peut être rédigée lorsque toutes les propositions obligatoires disposent d’un chemin de preuve. Toute couverture partielle reste visible et rejoint la revue de l’écart de sécurité.

## Conservez la demande avec son rôle et son périmètre

Commencez par les pièces en vigueur. La question de sécurité doit rester reliée aux définitions, aux instructions de réponse, au règlement de consultation, aux critères, au calendrier de déploiement, aux annexes et au projet de contrat. Une mesure peut être exigée au dépôt, vérifiée avant la mise en service ou attendue pendant toute l’exécution. La date d’effet change la preuve et le verbe utilisables.

Figez ensuite la solution proposée. Nommez l’entité candidate, le lot, l’édition du service, l’hébergement, les environnements, les régions, les données, les interfaces, les composants optionnels, les accès d’administration, la reprise et les sous-traitants. Une mesure appliquée au réseau bureautique ne démontre pas la sécurité d’une plateforme proposée au client.

Gardez les paramètres ajoutés par l’acheteur. Il peut citer ISO/IEC 27002 tout en imposant sa propre fréquence de contrôle, un délai de correction ou une preuve indépendante. La référence ne neutralise aucune de ces précisions. Si deux pièces divergent, la cartographie attend la résolution documentaire au lieu de choisir le texte le plus simple à satisfaire.

**Identité minimale de l’exigence**

| Champ | Contenu | Erreur évitée |
| --- | --- | --- |
| Autorité | Pièce, version, section, question, additif et clarification | Travailler sur une phrase remplacée |
| Offre | Candidat, lot, service, édition, environnement et région | Prouver un autre système |
| Population | Composants, données, rôles, interfaces et tiers | Oublier un chemin inclus |
| Moment | Dépôt, attribution, recette, démarrage ou exploitation | Confondre état actuel et engagement futur |
| Réponse attendue | Case, texte, pièce, rapport ou démonstration | Fournir une preuve d’une autre nature |

## Transformez chaque exigence composée en tests indépendants

Formulez une proposition courte pour chaque résultat. Elle indique qui agit, sur quel actif ou quelle donnée, selon quelle condition, à quelle fréquence, dans quel délai, pour quelle population et avec quel résultat observable. Reprenez seulement les paramètres présents dans les pièces. Une valeur manquante reste indéterminée tant qu’une source autorisée ne la précise pas.

Les conjonctions, alternatives et quantificateurs ont un effet direct. « Inventorier et analyser chaque semaine » contient deux actions. « Toutes les dépendances logicielles » impose un test de population. « Après toute évolution majeure » ajoute un déclencheur distinct de l’évaluation annuelle. Une alternative n’existe que si le texte de la consultation l’autorise. La qualité d’une mesure ne compense pas l’absence d’une autre proposition obligatoire.

Séparez la mesure de la preuve demandée. Le service peut corriger les vulnérabilités selon le délai exigé sans disposer du rapport indépendant au format demandé. À l’inverse, un rapport externe peut exister alors qu’une nouvelle version n’entre plus dans son périmètre. Deux lignes permettent d’identifier la nature exacte du manque.

**Lecture d’une exigence de gestion des vulnérabilités**

| Élément | Proposition à vérifier | Famille de mesures probable |
| --- | --- | --- |
| Inventaire | Chaque composant et dépendance inclus dans l’offre est identifié | Gestion des actifs logiciels |
| Détection | Le périmètre est analysé selon la fréquence et la méthode prévues | Analyse de vulnérabilités |
| Priorisation | Les constats reçoivent une gravité et un propriétaire | Traitement des vulnérabilités |
| Correction | Chaque niveau est traité dans le délai applicable ou selon l’exception admise | Remédiation et suivi |
| Mise en production | Les contrôles de sécurité précèdent la livraison | Développement et changement sécurisés |
| Évaluation indépendante | Le service offert entre dans le périmètre du test exigé | Assurance externe |

## Descendez du référentiel jusqu’à la mise en œuvre

Un résultat de cadre, une mesure interne et un mécanisme ne sont pas le même objet. Le NIST CSF formule des résultats de haut niveau et ne prescrit pas une liste unique d’actions. Le catalogue NIST SP 800-53 fournit des contrôles adaptables. L’organisation définit ensuite sa mesure, sa population, sa fréquence et ses responsables. Enfin, les outils et procédures du service réalisent cette mesure.

Conservez l’identifiant, la version et la justification de chaque correspondance externe. Le NIST rappelle que les tables de correspondance ne sont pas toujours individuelles et que leur analyse comporte une part de jugement. Les références informatives du CSF offrent un point de départ et non une liste obligatoire. Une similarité de vocabulaire peut donc orienter vers une mesure sans conclure qu’elle satisfait l’acheteur.

Le même principe vaut pour les référentiels sectoriels. Le Cyber Assessment Framework britannique évalue des résultats contributifs et s’appuie sur le jugement compétent. Le SecNumCloud 3.2 de l’ANSSI porte sur les services qualifiés selon son propre référentiel. Une qualification ou un statut obtenu dans un périmètre précis ne devient pas une preuve générale pour tout service, toute configuration et toute exigence.

**La chaîne à conserver**

| Niveau | Question | Exemple de contenu |
| --- | --- | --- |
| Exigence acheteur | Quel résultat doit être fourni ? | Périmètre, délai, fréquence et preuve |
| Référence externe | Quel concept publié est pertinent ? | Identifiant, version et justification du lien |
| Mesure interne | Quelle activité gouvernée produit le résultat ? | Objectif, propriétaire, population et enregistrements |
| Mise en œuvre | Comment la mesure fonctionne-t-elle dans cette offre ? | Système, configuration, procédure et opérateur |
| Preuve | Qu’est-ce qui montre son état ou son résultat ? | Objet, méthode, période, conclusion et limites |

## Représentez les contributions multiples et leurs responsables

Créez une ligne par relation entre une proposition et une mesure. La couverture complète signifie que la mesure, sa mise en œuvre et ses preuves couvrent toute la proposition. La couverture partielle nomme la condition, la population ou la période manquante. Une contribution conjointe fournit un élément nécessaire d’un résultat collectif. Une dépendance alimente la mesure principale sans satisfaire directement l’exigence. Référence seule, périmètre incompatible et absence de support complètent les résultats utiles.

Cette représentation évite deux erreurs opposées. La première consiste à attribuer tout un paragraphe de sécurité à une seule mesure générique. La seconde additionne plusieurs mesures faibles et en déduit un résultat complet. Chaque proposition conserve son propre test. Une exigence globale n’est étayée que lorsque toutes ses branches obligatoires le sont.

Attribuez aussi chaque action. Dans un service cloud, le fournisseur d’infrastructure, le candidat et l’acheteur peuvent participer au même objectif. Le prestataire protège certains équipements, le candidat configure et surveille son application, et l’acheteur administre ses utilisateurs. Le guide BSI d’analyse des rapports C5 distingue d’ailleurs les mesures du fournisseur cloud et les contrôles que l’utilisateur doit mettre en place. Une réponse doit conserver ces frontières.

**Résultats possibles d’une relation**

| Résultat | Signification | Conséquence pour la réponse |
| --- | --- | --- |
| Couverture complète | La proposition entière est étayée dans le périmètre offert | Peut soutenir une affirmation après revue |
| Couverture partielle | Un manque précis demeure | Limiter, réserver ou examiner l’écart |
| Contribution conjointe | Plusieurs mesures sont nécessaires ensemble | Vérifier chaque contribution |
| Dépendance | La mesure fournit une condition préalable | Ne pas la citer comme preuve unique |
| Référence seule | Le concept publié est pertinent | Chercher la mise en œuvre et la preuve |
| Hors périmètre ou absent | La population offerte n’est pas couverte | Bloquer l’affirmation positive |

## Associez à chaque lien une preuve de la bonne nature

La conception décrit ce que la mesure doit faire. Le déploiement montre que le mécanisme est présent. Les traces d’exploitation montrent qu’une action a été réalisée pendant une période. L’évaluation précise comment la mesure a été examinée ou testée et quel résultat a été observé. Une assurance indépendante ajoute un avis externe limité par le système, les critères, les dates et les exceptions de son rapport.

Consignez l’objet exact, la version, la source, la population, la méthode, l’échantillon, la période, le résultat, les écarts et la date d’examen. NIST SP 800-53A propose des procédures d’évaluation adaptables. La spécification d’évaluation CIS distingue également la présence d’une mesure et la qualité de son effet. Une capture de configuration peut établir la première. Elle ne mesure pas nécessairement la seconde.

L’échantillonnage doit rester visible. Un examen de vingt tickets de correction montre ce qui s’est passé pour ces tickets selon la méthode choisie. Pour conclure sur tous les constats critiques, rapprochez l’échantillon de la population complète et expliquez les exclusions. Une exception non résolue ne disparaît pas parce que le taux global paraît élevé.

**Ce que chaque preuve peut établir**

| Type | Exemples | Limite principale |
| --- | --- | --- |
| Conception | Politique, procédure ou description de mesure approuvée | Ne prouve pas le déploiement |
| Déploiement | Inventaire, configuration ou enregistrement de livraison | Ne prouve pas la continuité du fonctionnement |
| Fonctionnement | Tickets, journaux, revues, rapprochements ou métriques | Reste borné par sa population et sa période |
| Évaluation | Objet, méthode, évaluateur, date, résultat et constats | Ne garantit pas l’état après une évolution |
| Assurance externe | Rapport ou certificat avec périmètre et exceptions | Ne couvre pas chaque mesure de l’offre |

## Cartographiez la gestion des vulnérabilités d’une plateforme universitaire

Une université publique fictive achète une plateforme destinée à des projets de recherche. L’appel d’offres exige un inventaire de tous les composants et dépendances, une analyse hebdomadaire, la correction des vulnérabilités critiques sous quatorze jours, un contrôle de sécurité avant chaque mise en production et un test d’intrusion indépendant annuel ainsi qu’après toute évolution majeure. L’offre comprend le service principal et un nouveau connecteur vers un dépôt de données de recherche.

La cartographie crée des propositions distinctes pour l’exhaustivité de l’inventaire, la fréquence des analyses, la qualification des résultats, le délai de correction, le contrôle avant livraison et les deux déclencheurs du test indépendant. AST-03 tient l’inventaire logiciel. VUL-04 réalise les analyses et rattache les constats aux actifs. REM-06 mesure les délais et gouverne les exceptions. REL-05 bloque une livraison sans contrôle de sécurité. ASS-02 organise l’évaluation externe et le suivi des constats.

Les preuves internes montrent que le connecteur figure dans l’inventaire, entre dans l’analyse hebdomadaire et passe la vérification de livraison. Le registre de remédiation couvre la dernière période et distingue les exceptions approuvées. En revanche, le rapport d’intrusion annuel a été achevé avant l’ajout du connecteur. Son périmètre couvre le service principal, pas toute la version proposée. La référence à une mesure d’évaluation indépendante est pertinente, mais la preuve disponible ne satisfait pas la population de l’offre.

La proposition relative au test indépendant reste donc partielle. Les cinq autres résultats ne la rendent pas complète. La réponse est retenue pour revue avec le composant exclu, la date de changement, le rapport existant et le texte exact de l’acheteur. La cartographie ne décide ni la réalisation d’un nouveau test ni l’acceptation d’une réserve par l’acheteur.

**Extrait de la cartographie des vulnérabilités**

| Proposition acheteur | Mesure et preuve | Résultat |
| --- | --- | --- |
| Tous les composants et dépendances sont inventoriés | AST-03 inventaire, rapprochement de version et liste des dépendances | Couverture complète de la version proposée |
| Le périmètre est analysé chaque semaine | VUL-04 planification, résultats et contrôle des actifs manquants | Couverture complète sur la période examinée |
| Les vulnérabilités critiques sont corrigées sous quatorze jours | REM-06 horodatages, population complète et registre des exceptions | Couverture complète pour la période mesurée |
| Chaque mise en production passe un contrôle de sécurité | REL-05 règles de livraison et historique des contrôles | Couverture complète de l’échantillon rapproché |
| Un test indépendant couvre le service chaque année | ASS-02 rapport annuel et lettre de périmètre | Partiel, le nouveau connecteur est exclu |
| Une évolution majeure déclenche un nouveau test | ASS-02 procédure et registre de changements | Conception établie, fonctionnement à examiner pour ce changement |

## Rédigez avec le niveau de certitude démontré

La réponse finale indique le service et la population couverts, décrit le résultat en termes compréhensibles et renvoie vers la preuve que l’acheteur peut consulter. Un identifiant de mesure interne facilite le contrôle, mais ne doit pas remplacer la substance. Lorsque plusieurs mesures contribuent, expliquez leur combinaison sans présenter chacune comme suffisante seule.

Choisissez les verbes selon les faits. « La politique prévoit » porte sur la conception. « La configuration impose » demande une preuve de déploiement. « La revue a été exécutée chaque mois pendant la période » s’appuie sur des traces d’exploitation. « L’évaluateur a constaté » reste limité par l’objet, la méthode et la date du rapport. Le mot « conforme » ne doit pas transformer cette cartographie ciblée en conclusion générale.

Réduisez l’exposition des informations sensibles. Une extraction contrôlée, une attestation précise ou un accès protégé peut être préférable aux journaux bruts, aux noms de comptes, aux détails de topologie ou aux constats ouverts. Le propriétaire de la preuve valide la forme communicable. Cette précaution ne change pas le fond: la proposition doit rester étayée.

- Identifiez le service, la version et la population couverte.
- Décrivez le résultat de la mesure dans le vocabulaire de l’acheteur.
- Indiquez la nature et la période de la preuve pertinente.
- Conservez toute limite qui modifie matériellement la réponse.
- Ne validez pas une affirmation positive tant qu’un lien obligatoire reste incomplet.

## Maintenez la cartographie au niveau du dossier concerné

La cartographie correspond à une offre et à une date d’examen. Rouvrez les liens touchés par un additif, une nouvelle définition, un changement de version, de composant, d’environnement, de région, de rôle d’administration, de sous-traitant, de responsabilité, de mesure, de constat ou de validité documentaire. Conservez l’état remplacé et la raison de sa révision.

Des états simples rendent le résultat lisible: exigence saisie, lien en examen, couverture complète, couverture partielle, responsabilité non résolue, périmètre incompatible, preuve périmée, absence de support, revue sécurité requise, réponse approuvée et remplacée. Ils décrivent l’état de la proposition. Ils ne valent ni acceptation globale du risque ni conclusion juridique.

Rattachez la cartographie à la consultation. Une question ultérieure peut reprendre un lien vérifié seulement si son texte, son périmètre, sa population, sa date et sa demande de preuve concordent. La réutilisation porte sur le raisonnement et les pièces contrôlées, pas sur une ancienne case oui.

## Résultats utiles

- Le texte de l’acheteur reste lié à sa version, ses définitions, son lot, son emplacement de réponse et sa demande de preuve.
- Chaque mot qui modifie le résultat, comme tous, avant, périodique ou indépendant, devient un test explicite.
- Les références externes, les mesures internes et leurs mises en œuvre dans le service offert ne sont pas confondues.
- Chaque proposition reçoit toutes les mesures nécessaires ou un résultat indiquant clairement l’absence de support.
- Les obligations du fournisseur, de l’acheteur et des sous-traitants sont distinguées au niveau de chaque action.
- La nature de la preuve indique si elle établit la conception, le déploiement, le fonctionnement ou une évaluation.
- Une exclusion de produit, d’environnement, de composant ou de période demeure visible dans le résultat.
- La formulation remise à l’acheteur reste dans les limites des faits examinés et des informations communicables.
- Une modification pertinente rouvre les seuls liens qu’elle peut invalider.

## Déroulement

1. **Définir le dossier et le service.** Consignez la consultation, le lot, les versions, le candidat, le service, les environnements, les régions, les données, les rôles, les interfaces et les prestataires concernés.
2. **Conserver la demande exacte.** Gardez ensemble le texte, les termes définis, les renvois, le format de réponse, la preuve demandée, l’échéance et le traitement prévu.
3. **Créer les propositions de contrôle.** Isolez l’acteur, l’action, l’objet protégé, le résultat, la condition, la fréquence, le délai, la population et la preuve.
4. **Identifier les mesures appliquées.** Retrouvez pour chaque proposition l’objectif interne, le propriétaire, le mécanisme, le périmètre, les dépendances et les enregistrements attendus.
5. **Qualifier le lien.** Distinguez couverture complète, couverture partielle, contribution conjointe, simple dépendance, référence, écart de périmètre et absence de mesure.
6. **Examiner les preuves.** Vérifiez l’objet, la version, la population, la méthode, la période, le résultat, les exceptions et la date de chaque élément.
7. **Rédiger sans étendre la conclusion.** Transformez les propositions étayées en réponse, conservez les réserves matérielles et bloquez toute affirmation qui dépend d’un lien incomplet.
8. **Faire approuver et réexaminer.** Obtenez la validation sécurité et offre, alignez les répétitions de la réponse et fixez les événements qui imposent une nouvelle vérification.

## Décisions clés

- Quelle version de la pièce et quelle clarification gouvernent la question pour ce lot ?
- L’exigence est-elle une condition minimale, un critère noté, une demande de diligence, une étape de mise en service ou une obligation contractuelle ?
- Quels produits, composants, environnements, données, utilisateurs, lieux et chemins exceptionnels sont inclus ?
- Quels résultats doivent tous être établis avant de répondre oui ?
- L’acheteur impose-t-il un objectif, un mécanisme, une fréquence, un délai, une évaluation ou leur combinaison ?
- Quelle mesure interne produit chaque résultat et comment est-elle appliquée dans le service proposé ?
- La responsabilité appartient-elle au candidat, au client, à un fournisseur de cloud ou à plusieurs parties ?
- Le périmètre de la mesure couvre-t-il toute la population visée par la consultation ?
- La preuve concerne-t-elle la conception, le déploiement, l’exploitation, l’efficacité ou une assurance indépendante ?
- La correspondance entre référentiels a-t-elle été analysée ou seulement copiée ?
- Quelle phrase exacte peut être remise sans exagération ni divulgation technique inutile ?

## Risques

- Une référence reconnue remplace l’examen de la mesure réellement appliquée.
- Une exigence composée reçoit une seule mesure alors que plusieurs résultats sont demandés.
- Une politique approuvée est présentée comme la preuve d’un fonctionnement continu.
- Le rapport couvre l’entreprise, mais pas le service, la région ou la version de l’offre.
- Les environnements de support, de test, de reprise ou les nouveaux connecteurs sont absents de la population.
- Une assurance du prestataire cloud est étendue aux configurations sous responsabilité du fournisseur ou du client.
- Un échantillon conforme devient, dans la réponse, une preuve de couverture totale.
- Une évaluation ancienne reste utilisée après une évolution importante du produit.
- Plusieurs contributions partielles masquent une condition obligatoire qui n’est toujours pas satisfaite.
- La pièce d’offre révèle des détails d’architecture, des comptes ou des constats qui ne sont pas nécessaires.
- Un écart identifié est reformulé en réserve vague au lieu d’être soumis à la décision de sécurité.

## Indicateurs

- propositions de sécurité reliées à une source acheteur, un périmètre offert et un résultat attendu
- propositions associées à des mesures internes en vigueur et à leur mise en œuvre concrète
- liens qualifiés comme complets, partiels, conjoints, dépendants, référentiels, hors périmètre ou absents
- actions attribuées au fournisseur, au client ou au prestataire qui doit réellement les exécuter
- preuves dont le service, la population, la période et l’objet correspondent à la proposition
- évaluations avec méthode, échantillon ou population, date, résultat, exceptions et limites
- propositions partielles ou non étayées envoyées en revue avant la clôture de la rédaction
- réponses finales rapprochées de la cartographie approuvée
- affirmations positives matérielles sans chemin de preuve complet ; objectif zéro

## Questions fréquentes

### Une table de correspondance entre référentiels prouve-t-elle une exigence ?

Non. Elle indique une relation entre concepts publiés. Il faut encore vérifier la mesure interne, sa mise en œuvre, son périmètre et ses preuves par rapport au texte de l’acheteur.

### Faut-il une seule mesure par exigence ?

Non. Une exigence composée dépend souvent de plusieurs mesures. Une même mesure peut aussi soutenir plusieurs propositions. Chaque relation doit rester identifiable.

### Un certificat ISO/IEC 27001 suffit-il ?

Il peut soutenir une affirmation sur le système de management certifié dans son périmètre. Il ne prouve pas à lui seul toutes les mesures demandées pour le service offert.

### Une procédure approuvée prouve-t-elle le fonctionnement ?

Elle établit surtout la conception attendue. Le déploiement, l’exécution et l’efficacité nécessitent des configurations, des enregistrements, des rapprochements ou des tests adaptés à la question.

### Comment représenter les responsabilités de l’acheteur ?

Séparez les actions du fournisseur et du client, puis décrivez leur point de passage. Le candidat ne doit pas s’attribuer la couverture d’une mesure exploitée par l’acheteur.

### Une mesure planifiée permet-elle de répondre oui ?

Elle ne prouve pas un état actuel. Consignez-la comme plan ou engagement proposé, avec ses validations et son futur test, puis transmettez l’écart au processus de décision approprié.

### Comment utiliser une preuve de sécurité confidentielle ?

Employez la voie de communication autorisée, par exemple un extrait contrôlé, une attestation ou une consultation protégée. Ne joignez pas des éléments bruts sensibles pour renforcer l’apparence de la réponse.

### Quand faut-il revoir une relation ?

Après toute modification importante du texte acheteur, du service, de la population, de la mesure, de la responsabilité, du prestataire, de l’évaluation ou de la validité de la preuve.


## Sources primaires

- [NIST SP 800-53 révision 5, catalogue des contrôles de sécurité et de protection de la vie privée](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), US National Institute of Standards and Technology
- [NIST SP 800-53A révision 5, évaluation des contrôles de sécurité et de protection de la vie privée](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final), US National Institute of Standards and Technology
- [Présentation de l’Open Security Controls Assessment Language](https://csrc.nist.gov/projects/open-security-controls-assessment-language), US National Institute of Standards and Technology
- [Questions fréquentes sur le NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework/faqs), US National Institute of Standards and Technology
- [Guide NIST sur les références informatives du Cybersecurity Framework](https://www.nist.gov/cyberframework/informative-references-what-are-they-and-how-are-they-used), US National Institute of Standards and Technology
- [Cyber Assessment Framework version 4.0](https://www.ncsc.gov.uk/collection/cyber-assessment-framework), UK National Cyber Security Centre
- [Introduction au Cyber Assessment Framework](https://www.ncsc.gov.uk/collection/cyber-assessment-framework/introduction-to-caf), UK National Cyber Security Centre
- [Cloud Controls Matrix et CAIQ version 4.1](https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1), Cloud Security Alliance
- [CIS Critical Security Controls version 8.1](https://www.cisecurity.org/controls/v8-1), Center for Internet Security
- [CIS Controls Assessment Specification pour la version 8.1](https://cas.docs.cisecurity.org/en/latest/source/About%20the%20CIS%20Controls%20Assessment%20Specification/), Center for Internet Security
- [Compendium IT-Grundschutz, édition 2023](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium/IT_Grundschutz_Kompendium_Edition2023.pdf?__blob=publicationFile&v=4), Office fédéral allemand de la sécurité des technologies de l’information
- [Cours IT-Grundschutz 5.5, adaptation des exigences](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/Zertifizierte-Informationssicherheit/IT-Grundschutzschulung/Online-Kurs-IT-Grundschutz/Lektion_5_Modellierung/Lektion_5_05/Lektion_5_05_node.html), Office fédéral allemand de la sécurité des technologies de l’information
- [Cours IT-Grundschutz 6.2, préparation et réalisation du contrôle](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/Zertifizierte-Informationssicherheit/IT-Grundschutzschulung/Online-Kurs-IT-Grundschutz/Lektion_6_IT-Grundschutz-Check/Lektion_6_02/Lektion_6_02_node.html), Office fédéral allemand de la sécurité des technologies de l’information
- [Guide BSI d’analyse des rapports d’assurance C5](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/C5_AktuelleVersion/Auswertung/Auswertung_node.html), Office fédéral allemand de la sécurité des technologies de l’information
- [Référentiels de qualification ANSSI, dont SecNumCloud 3.2](https://cyber.gouv.fr/offre-de-service/solutions-certifiees-et-qualifiees/comprendre-levaluation-de-securite/qualification-de-produit-et-services/referentiels-qualification/), Agence nationale de la sécurité des systèmes d’information
- [Exigences de sécurité indispensables pour l’achat de produits et services TIC sécurisés](https://www.enisa.europa.eu/publications/indispensable-baseline-security-requirements-for-the-procurement-of-secure-ict-products-and-services), Agence de l’Union européenne pour la cybersécurité
- [ISO/IEC 27001:2022, exigences des systèmes de management de la sécurité de l’information](https://www.iso.org/standard/27001), Organisation internationale de normalisation
- [ISO/IEC 27002:2022, mesures de sécurité de l’information](https://www.iso.org/standard/75652.html), Organisation internationale de normalisation


## Articles complémentaires

- [Répondre aux exigences négatives avec des preuves](https://zephior.com/fr/insights/respond-to-negative-rfp-requirements)
- [Comment relier les preuves RGPD à une question d’appel d’offres ?](https://zephior.com/fr/insights/map-privacy-controls-to-rfp-questions)
- [Automatiser les questionnaires de sécurité avec preuves](https://zephior.com/fr/solutions/security-questionnaire-automation)
- [Coordonner un RFP SaaS et un questionnaire de sécurité séparé](https://zephior.com/fr/industries/coordinate-a-saas-rfp-and-security-questionnaire)