---
title: "Évaluation PCI P2PE"
description: "Évaluez une Solution P2PE, un composant, une Merchant-Managed Solution ou une application selon PCI P2PE v3.2 dans Kliper : renseignez les détails du rapport et les constatations de son P-ROV, complétez le P-AOV, et exportez les deux en Word ou en PDF."
version: "fr"
---

> Index de la documentation
> Index complet de la documentation : https://docs.kliper.dev/fr/llms.txt
> Utilisez ce fichier pour découvrir toutes les pages disponibles.

# Évaluation PCI P2PE

Kliper mène une **évaluation PCI P2PE v3.2** dans le même éditeur d'exigences qu'un ROC PCI DSS. Chaque évaluation porte sur un seul **P2PE Report on Validation (P-ROV)** : vous renseignez ses détails du rapport, une constatation et les réponses de l'évaluateur pour chaque exigence, et les réponses que demande son **Attestation of Validation (P-AOV)**, puis vous exportez les deux.

> **Caution**
>
> Le PCI SSC publie les six modèles de P-ROV uniquement en PDF. Kliper écrit le P-ROV Word à partir du contenu de chaque modèle, dans son ordre et sa formulation, avec sa propre mise en page. Relisez le P-ROV exporté au regard du modèle officiel avant de le soumettre. Le P-AOV est rempli à partir du formulaire Word officiel.

## Déroulement d'une évaluation P2PE

1. **Créer l'évaluation**

   Choisissez PCI P2PE 3.2 et le P-ROV sur lequel elle porte.
2. **Renseigner les détails du rapport**

   Contacts et dates, le produit et ses fournisseurs de composants, le périmètre, les diagrammes, les sites, les documents, les personnes interrogées et les échantillons.
3. **Évaluer chaque exigence**

   Pour chaque exigence, choisissez une constatation et rédigez la réponse de l'évaluateur à chaque instruction de rapport de chaque procédure de test.
4. **Expliquer les exigences N/A et compléter le P-AOV**

   Listez chaque exigence N/A en 4.2 avec sa raison, puis répondez à ce que le P-AOV demande au-delà du rapport.
5. **Exporter**

   Téléchargez le P-ROV et le P-AOV en Word ou en PDF, après les contrôles d'export.

## Créer une évaluation P2PE

Dans **Création rapide**, choisissez **PCI P2PE 3.2** : un champ **Rapport de validation (P-ROV)** apparaît, où vous choisissez le P-ROV. Dans l'assistant complet, sélectionnez **PCI P2PE** et la version **3.2** à l'étape **Référentiel**, puis choisissez le **Rapport de validation (P-ROV)** à l'étape **Périmètre et visibilité**. **Plus d’options** reporte les deux de Création rapide vers l'assistant complet, et inversement. Un fournisseur de solution qui a besoin de plusieurs P-ROV (celui de la Solution et un EMS, par exemple) crée une évaluation pour chacun dans le même engagement. Le P-ROV ne peut plus être changé après la création. Voir [Créer une évaluation](/fr/guides/creating-assessments#démarrer-une-nouvelle-évaluation) pour la suite du parcours.

| Report on Validation | Couvre | Exigences | Procédures de test |
| --- | --- | --- | --- |
| **P2PE Solution** | Domaine 3 | 19 | 36 |
| **Encryption Management Services** | Domaines 1 et 5 | 175 | 322 |
| **Decryption Management Services** | Domaines 4 et 5 | 236 | 467 |
| **Key Management Services** | Domaine 5 | 281 | 507 |
| **Merchant-Managed Solution** | Domaine 3 et annexe A | 34 | 65 |
| **P2PE Application** | Domaine 2 | 62 | 113 |

Chaque P-ROV garde la formulation de son modèle : l'EMS et le DMS formulent différemment certaines exigences du domaine 5.

## Ce que contient l'évaluation

Les exigences sont affichées avec les numéros qu'imprime le P-ROV : **1A-1.1**, **6-1.1**, **5I-1.1**, **MM-A-2.1**. Chaque section a sa page sous son domaine (**1A** sous le domaine 1), et le domaine 5 est paginé par Control Objective, ses exigences regroupées en **Requirement 6**, **Requirement 7**. Dans les P-ROV EMS et KMS, chaque procédure de test indique les types de composant auxquels elle s'applique.

## Les détails du rapport

La section 1 est la même dans tous les P-ROV ; les sections 2 et 3 sont propres à chaque modèle.

| Élément | Ce que vous renseignez |
| --- | --- |
| **1.1 à 1.4** | L'entité évaluée, la société P2PE Assessor et l'évaluateur principal, l'affirmation du contrôle qualité interne et le relecteur QA, les éventuels évaluateurs supplémentaires, les dates, les services déclarés, l'affirmation de la v3.2 |
| **2.1** | Le produit : son nom, s'il est listé et sa référence ; pour un P-ROV de composant, s'il est soumis avec l'évaluation d'une Solution ou comme composant, et son type ; pour une application, le type d'évaluation auquel elle se rattache |
| **2.2 et suivants** | Les fournisseurs de composants validés, les tiers, les applications, les terminaux POI, les SCD, les implémentations de chiffrement supplémentaires et le résumé de conformité, comme le demande le modèle |
| **Section 3** | Le périmètre, les diagrammes, les sites, les documents, les personnes interrogées, les terminaux échantillonnés, la matrice des clés et, là où le modèle le demande, les transactions de test et les jeux d'échantillons |
| **4.1** | Le Summary of Findings, chaque ligne du modèle lue à partir des constatations |
| **4.2** | Chaque exigence jugée N/A et pourquoi. **Add the requirements from the findings** les liste |

Une question posée seulement selon une autre réponse (une référence de listing après **Yes**, le type d'un composant une fois que 2.1 dit qu'il est évalué comme tel) apparaît, et compte dans la progression, seulement à ce moment. Sur un P-ROV **Decryption Management Services**, 4D demande si l'environnement est un environnement de déchiffrement hybride et 4E-1 si le fournisseur est un P2PE Component Provider : sinon, le modèle laisse 4D et 5H, ou 4E-1.1 à 4E-1.2.b, vides ou N/A.

## Enregistrer une constatation

Pour chaque exigence, choisissez une constatation :

| Constatation | Quand |
| --- | --- |
| **In Place** | L'exigence est satisfaite |
| **N/A** | L'exigence, après tests et revue, ne s'applique pas au produit |
| **Not in Place** | L'exigence n'est pas satisfaite |

P2PE n'a pas de résultat Not Tested et n'admet aucun contrôle compensatoire. Rédigez ensuite la réponse de l'évaluateur à chaque instruction de rapport : ce qui a été examiné, observé ou recueilli en entretien, et ce que cela a montré. Une constatation N/A se rapporte de la même façon, en disant comment il a été déterminé qu'elle ne s'applique pas, et figure en 4.2.

Une ligne du Summary of Findings indique **Not in Place** quand une exigence qu'elle couvre l'est, **N/A** quand toutes le sont, et **In Place** sinon : un mélange de In Place et de N/A.

## Les réponses du P-AOV

Les pages de l'**Attestation of Validation** ne demandent que ce que le rapport ne donne pas. Son formulaire suit le P-ROV :

| P-ROV | P-AOV |
| --- | --- |
| Solution, composant évalué comme tel, application listée séparément | Le P2PE Product P-AOV (v3.1) |
| Merchant-Managed Solution | L'AOV P2PE Merchant-Managed Solution (v3.0) |
| Application validée dans le cadre d'une Merchant-Managed Solution | Son propre AOV (v3.0) |
| Composant soumis avec l'évaluation d'une Solution, application évaluée uniquement pour une Solution | Aucun qui lui soit propre : celui de la Solution le couvre |

| Page | Ce que vous renseignez |
| --- | --- |
| **Type de soumission ou de validation** | Administrative Change, Delta Change, Annual Revalidation ou Full Assessment, selon ce que propose le formulaire |
| **Fournisseur et évaluateur** | Les parties et leurs adresses. **Fill from 1.1** copie les contacts du rapport |
| **Parties 3b à 3e** (Merchant-Managed Solution) | Les terminaux POI, les applications, les HSM et les fournisseurs de composants listés |

Le produit, son type et son listing viennent de 2.1 ; les terminaux d'une application MMS, de son 2.5. Les attestations, leurs dates et les signatures se font sur le document exporté.

## Exporter le P-ROV et le P-AOV

Cliquez sur **Export** dans l'en-tête de l'évaluation, ou dans le menu **Actions** de la barre supérieure. Choisissez le **Report on Validation**, l'**Attestation of Validation** ou les deux, en **PDF** ou en **Word**. La carte du P-AOV est indisponible quand 2.1 dit que le P-ROV n'en a pas qui lui soit propre. Un PDF inachevé peut porter le filigrane **DRAFT**.

Avant de produire le fichier, Kliper lance les **contrôles d'export**. Les bloquants sont ce qu'exige le P-ROV ; les avertissements méritent un second regard. **Export anyway** produit le fichier quand même.

| Contrôle | Gravité |
| --- | --- |
| Une exigence avec une constatation dont toutes les instructions de rapport n'ont pas de réponse (« N/A » ou « see … » seul compte comme aucune réponse, sauf s'il cite Doc-1 ou Int-1, et jamais pour un N/A) | Bloquant |
| Une constatation Not Tested ou un contrôle compensatoire enregistré auparavant, que le P-ROV ne prévoit pas | Bloquant |
| Une exigence N/A non expliquée en 4.2 (une ligne peut nommer une exigence, son groupe, une section ou **Requirement 6**) | Bloquant |
| 4.2 liste une exigence que les constatations ne donnent pas N/A | Avertissement |
| 4.2 nomme un numéro sous lequel le P-ROV n'a aucune exigence (une coquille, celui d'un autre P-ROV) | Avertissement |
| Une exigence Not in Place : le produit n'est pas validé | Avertissement |
| Une exigence DMS rapportée alors que 4D ou 4E-1 l'écarte | Avertissement |
| Un élément de diagramme sans diagramme | Avertissement |
| Une réponse qui répète sa procédure de test ou son instruction, est copiée d'une autre exigence, ou décrit un travail futur sous In Place | Avertissement |

## Cortex sur une évaluation P2PE

[Cortex](/fr/guides/cortex-ai) lit l'évaluation P2PE comme son P-ROV : le texte d'une exigence et ses procédures de test avec leurs instructions de rapport et les types de composant auxquels chacune s'applique, vos constatations et réponses, le Summary of Findings, les détails du rapport, le P-AOV tel que rempli, et les contrôles d'export. Il nomme les exigences comme les imprime le P-ROV. Cortex n'enregistre pas les réponses P2PE : demandez-lui de rédiger une réponse et il écrit le brouillon dans sa réponse, pour que vous le relisiez et le colliez. La constatation vous appartient toujours.

Source: https://docs.kliper.dev/fr/guides/pci-p2pe/index.mdx