---
title: "PCI P2PE Assessment"
description: "Assess a P2PE Solution, component, Merchant-Managed Solution or application against PCI P2PE v3.2 in Kliper: record the report details and the findings of its P-ROV, complete the P-AOV, and export both in Word or PDF."
version: "en"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.kliper.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# PCI P2PE Assessment

Kliper runs a **PCI P2PE v3.2 assessment** in the same requirement editor as a PCI DSS ROC. Each assessment reports on one **P2PE Report on Validation (P-ROV)**: you record its report details, a finding and the assessor's responses for each requirement, and the answers its **Attestation of Validation (P-AOV)** asks for, then export both.

> **Caution**
>
> The PCI SSC publishes the six P-ROV templates as PDFs only. Kliper writes the Word P-ROV from each template's content, in its order and wording, in its own layout. Read the exported P-ROV against the official template before you submit it. The P-AOV is filled from the official Word form.

## How a P2PE assessment runs

1. **Create the assessment**

   Pick PCI P2PE 3.2 and the P-ROV it reports on.
2. **Record the report details**

   Contacts and dates, the product and its component providers, scope, diagrams, facilities, documents, interviewees and samples.
3. **Assess each requirement**

   For each requirement, choose a finding and write the assessor's response to each reporting instruction of each testing procedure.
4. **Explain the N/A requirements and complete the P-AOV**

   List each N/A requirement in 4.2 with its reason, then answer what the P-AOV asks beyond the report.
5. **Export**

   Download the P-ROV and the P-AOV in Word or PDF, after the export checks.

## Create a P2PE assessment

In **Quick create**, pick **PCI P2PE 3.2**: a **Report on Validation** field appears, where you choose the P-ROV. In the full wizard, select **PCI P2PE** and version **3.2** on the **Framework** step, then choose the **Report on Validation** on **Scope & visibility**. **More options** carries both from Quick create to the full wizard, and back. A solution provider that needs several P-ROVs (the Solution's and an EMS, for instance) creates one assessment for each in the same engagement. The P-ROV cannot be changed after creation. See [Creating an Assessment](/guides/creating-assessments#starting-a-new-assessment) for the rest of the flow.

| Report on Validation | Covers | Requirements | Testing procedures |
| --- | --- | --- | --- |
| **P2PE Solution** | Domain 3 | 19 | 36 |
| **Encryption Management Services** | Domains 1 and 5 | 175 | 322 |
| **Decryption Management Services** | Domains 4 and 5 | 236 | 467 |
| **Key Management Services** | Domain 5 | 281 | 507 |
| **Merchant-Managed Solution** | Domain 3 and Appendix A | 34 | 65 |
| **P2PE Application** | Domain 2 | 62 | 113 |

Each P-ROV keeps its template's own wording: the EMS and the DMS word some of Domain 5's requirements differently.

## What the assessment contains

Requirements are shown with the numbers the P-ROV prints: **1A-1.1**, **6-1.1**, **5I-1.1**, **MM-A-2.1**. Each section has its own page under its domain (**1A** under Domain 1), and Domain 5 is paged by Control Objective, its requirements grouped as **Requirement 6**, **Requirement 7**. In the EMS and KMS P-ROVs, each testing procedure says which component types it applies to.

## The report details

Section 1 is the same in every P-ROV; sections 2 and 3 are each template's own.

| Item | What you record |
| --- | --- |
| **1.1 to 1.4** | The assessed entity, the P2PE Assessor company and lead assessor, the internal QA affirmation and the QA reviewer, any additional assessors, the dates, the services disclosed, the v3.2 affirmation |
| **2.1** | The product: its name, whether it is listed and its reference; for a component P-ROV, whether it is submitted with a Solution's assessment or as a component, and its type; for an application, the type of assessment it belongs to |
| **2.2 onwards** | The validated component providers, third parties, applications, POI devices, SCDs, additional encryption implementations and the compliance summary, as the template asks |
| **Section 3** | Scope, the diagrams, facilities, documents, interviewees, sampled devices, the key matrix and, where the template asks, test transactions and sample sets |
| **4.1** | The Summary of Findings, each of the template's rows read from the findings |
| **4.2** | Each requirement determined N/A and why. **Add the requirements from the findings** lists them |

A question asked only on another answer (a listing reference after **Yes**, a component's type once 2.1 says it is assessed as one) appears, and counts towards progress, only then. On a **Decryption Management Services** P-ROV, 4D asks whether the environment is a hybrid decryption environment and 4E-1 whether the vendor is a P2PE Component Provider: when not, the template leaves 4D and 5H, or 4E-1.1 to 4E-1.2.b, blank or N/A.

## Record a finding

For each requirement, choose a finding:

| Finding | When |
| --- | --- |
| **In Place** | The requirement is met |
| **N/A** | The requirement, through testing and review, does not apply to the product |
| **Not in Place** | The requirement is not met |

P2PE has no Not Tested result and allows no compensating control. Then write the assessor's response to each reporting instruction: what was examined, observed or interviewed, and what it showed. An N/A finding is reported the same way, saying how it was determined not to apply, and is listed in 4.2.

A row of the Summary of Findings reads **Not in Place** when a requirement under it is, **N/A** when all are, and **In Place** otherwise: a mix of In Place and N/A.

## The P-AOV's answers

The **Attestation of Validation** pages ask only what the report does not give. Its form follows the P-ROV:

| P-ROV | P-AOV |
| --- | --- |
| Solution, a component assessed as one, a separately-listed application | The P2PE Product P-AOV (v3.1) |
| Merchant-Managed Solution | The P2PE Merchant-Managed Solution AOV (v3.0) |
| An application validated as part of a Merchant-Managed Solution | Its own AOV (v3.0) |
| A component submitted with a Solution's assessment, an application assessed only for a Solution | None of its own: the Solution's covers it |

| Page | What you record |
| --- | --- |
| **Submission or validation type** | Administrative Change, Delta Change, Annual Revalidation or Full Assessment, as the form offers |
| **Vendor and assessor** | The parties and their addresses. **Fill from 1.1** copies the report's contacts |
| **Parts 3b to 3e** (Merchant-Managed Solution) | The POI devices, the applications, the HSMs and the listed component providers |

The product, its type and its listing come from 2.1; an MMS application's devices from its 2.5. The attestations, their dates and the signatures are made on the exported document.

## Export the P-ROV and the P-AOV

Click **Export** in the assessment header, or in the top bar's **Actions** menu. Choose the **Report on Validation**, the **Attestation of Validation** or both, in **PDF** or **Word**. The P-AOV card is unavailable when 2.1 says the P-ROV has none of its own. An unfinished PDF can carry the **DRAFT** watermark.

Before the file is made, Kliper runs the **export checks**. Blockers are what the P-ROV requires; warnings are worth a second look. **Export anyway** produces the file regardless.

| Check | Severity |
| --- | --- |
| A requirement with a finding whose reporting instructions are not all answered ("N/A" or "see …" alone counts as no response unless it cites Doc-1 or Int-1, and never for an N/A) | Blocker |
| A Not Tested finding or a compensating control stored before, which the P-ROV has none of | Blocker |
| An N/A requirement not explained in 4.2 (a row may name a requirement, its group, a section or **Requirement 6**) | Blocker |
| 4.2 listing a requirement the findings do not give N/A | Warning |
| 4.2 naming a number the P-ROV has no requirement under (a typo, another P-ROV's) | Warning |
| A requirement Not in Place: the product is not validated | Warning |
| A DMS requirement reported where 4D or 4E-1 leaves it out | Warning |
| A diagram item with no diagram | Warning |
| A response that repeats its testing procedure or instruction, is copied from another requirement, or describes future work under In Place | Warning |

## Cortex on a P2PE assessment

[Cortex](/guides/cortex-ai) reads the P2PE assessment as its P-ROV does: a requirement's text and testing procedures with their reporting instructions and the component types each applies to, your findings and responses, the Summary of Findings, the report details, the P-AOV as filled, and the export checks. It names requirements as the P-ROV prints them. Cortex does not save P2PE answers: ask it to draft a response and it writes the draft in its reply, for you to review and paste. The finding is always yours.

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