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.
How a P2PE assessment runs
Create the assessment
Pick PCI P2PE 3.2 and the P-ROV it reports on.
Record the report details
Contacts and dates, the product and its component providers, scope, diagrams, facilities, documents, interviewees and samples.
Assess each requirement
For each requirement, choose a finding and write the assessor’s response to each reporting instruction of each testing procedure.
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.
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 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 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.