---
title: "PCI 3DS Assessment"
description: "Assess an entity against the PCI 3DS Core Security Standard v1.0 in Kliper: record the report details and the findings, leverage a PCI DSS assessment for Part 1, complete the AOC, and export the ROC and AOC 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 3DS Assessment

Kliper runs a **PCI 3DS Core Security Standard v1.0 assessment** in the same requirement editor as a PCI DSS ROC. You record the report details, a finding and the assessor's responses for each sub-requirement, and the answers the Attestation of Compliance asks for, then export the **3DS Report on Compliance** and the **3DS AOC**.

> **Caution**
>
> The PCI SSC publishes the 3DS ROC Reporting Template as a PDF only. Kliper builds the Word ROC from it, in the template's order and wording. Read the exported ROC against the official template before you issue it. The AOC is filled from the official Word form.

## How a 3DS assessment runs

1. **Create the assessment**

   Pick PCI 3DS 1.0.
2. **Record the report details**

   Contacts and dates, the 3DS functions, the scope, whether a PCI DSS assessment is leveraged, the environment, sampling, the documents and the interviewees.
3. **Assess each requirement**

   For each sub-requirement, choose a finding and write the assessor's response to each reporting instruction.
4. **Complete the appendices and the AOC**

   Document compensating controls in Appendix A and explain each N/A in Appendix B. The AOC reads most of itself from the report; you add what it asks beyond it.
5. **Export**

   Download the ROC and the AOC in Word or PDF, after the export checks.

## Create a 3DS assessment

In the full wizard, on the **Framework** step, select **PCI 3DS** and version **1.0**. See [Creating an Assessment](/guides/creating-assessments#starting-a-new-assessment) for the rest of the flow.

## What the assessment contains

| Part | High-level requirements | Sub-groups | Sub-requirements | Reporting instructions |
| --- | --- | --- | --- | --- |
| **Part 1: Baseline Security Requirements** | P1-1 to P1-7 | 18 | 68 | 228 |
| **Part 2: 3DS Security Requirements** | P2-1 to P2-7 | 25 | 75 | 266 |

Requirements are shown with the numbers the ROC prints: **P1-1.1.1**, **P2-6.1.2**. Each high-level requirement has its own page, its sub-groups as headings. In the sidebar, **Executive Summary** holds the report details and the AOC's answers, **Requirements** each part's requirements, and **Appendices** Appendix A, then Appendix B, as the ROC prints them.

## The report details

| Item | What you record |
| --- | --- |
| **1.1 to 1.4** | The parties and their contacts, the dates and timeframe of the assessment, the 3DS version, the services the QSA company disclosed |
| **2.1** | The 3DS functions assessed (3DS Server, ACS, DS) and how the entity performs them |
| **2.2** | How the 3DS environment and the scope were validated |
| **2.3** | Whether a PCI DSS assessment is leveraged for Part 1, with its details and each Part 1 requirement's coverage |
| **3.1 to 3.4** | The network diagrams, the 3DS data flows, where 3DS sensitive data is stored, the critical hardware and software |
| **3.5, 3.6** | Whether sampling was used and, if so, each sample set |
| **3.7 to 3.9** | The third-party service providers, the documents reviewed, the individuals interviewed |
| **3.10** | The requirements In Place with a compensating control, each with a summary |
| **4.1.1, 4.2.1** | Each high-level requirement's result, read from the findings |

3.10 says **Yes** or **No** from the findings. Click **Add the requirements from the findings** to list each one, then write its summary. A question asked only in some cases (3.6 after a Yes in 3.5, 2.3's details after a Yes) appears, and counts towards progress, only then.

### Leverage a PCI DSS assessment

Answer **Yes** in 2.3 when Part 1 is met through the entity's PCI DSS assessment. Part 1's pages leave the sidebar and the progress, 4.1.1 reads **In Place per PCI DSS** for all of Part 1, and the ROC and AOC print it so, without Part 1's detailed findings. Its answers are kept: answer **No** and they come back. 2.3 then asks the PCI DSS assessment's details and, for each Part 1 requirement, its coverage (Full or Partial, with a justification for Partial).

## Record a finding

For each sub-requirement, choose a finding:

| Finding | When |
| --- | --- |
| **In Place** | The requirement is met |
| **In Place w/CCW** | Met with a compensating control: choose In Place and tick **Compensating Control** |
| **N/A** | The requirement does not apply, as the assessor confirmed |
| **Not in Place** | The requirement is not met |

The 3DS ROC has no Not Tested result. 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 its non-applicability was confirmed. The last row, **Additional assessor comments**, is optional.

A high-level requirement's result follows the template: **Not in Place** when a sub-requirement is, **N/A** when all are, **In Place w/CCW** when one is, **In Place** otherwise.

> **Tip**
>
> The 3DS ROC prints no justification for a finding. A note you write on the **Justification** tab stays in Kliper; the tab reads **Not printed**.

## The appendices

| Appendix | What you record |
| --- | --- |
| **Appendix A** | The compensating controls worksheet, for each requirement In Place w/CCW (**Open Appendix A** on the finding) |
| **Appendix B** | Each requirement found N/A and why. **Add the requirements from the findings** lists them |

When 2.1 assesses the **3DS Server only**, Appendix B lists the requirements that apply to an ACS and a DS only, as the standard and its Technical FAQ say, and offers **Mark them N/A**. Each is then marked N/A on its page, its responses kept, and added to Appendix B with the template's own reason. Each still asks, on its page, how its non-applicability was confirmed, and stays yours to change. A requirement that already has a finding keeps it.

## The AOC's answers

The AOC's own pages ask only what the report does not give:

| Part | What you record |
| --- | --- |
| **Part 1a, 1b** | The 3DS entity and the assessor company. **Fill from 1.1** copies the report's contacts |
| **Part 2a** | The functions come from 2.1; give each one its EMVCo Letter of Approval (reference, date, product). Another function a payment brand defines, if any |
| **Part 2b, 2c, 2e, 2f** | The business, the locations, the environment and its segmentation, the third-party service providers |
| **Part 2g** | Each high-level requirement's result, from the findings |
| **Part 3** | The rating is read from the findings: Non-Compliant when a requirement is Not in Place, Compliant once every requirement has its result. A legal constraint asks the requirement affected and its details, and whether it accounts for every requirement Not in Place (the rating is then Compliant but with Legal exception). A Non-Compliant rating asks its target date |
| **Part 4** | Each requirement's compliance, from the findings; a requirement not compliant asks its remediation date and actions |

Parts 3a to 3c, the attestations, are signed on the exported document.

## Export the ROC and the AOC

Click **Export** in the assessment header, or in the top bar's **Actions** menu. Choose the **Report on Compliance**, the **Attestation of Compliance** or both, in **PDF** or **Word**. An unfinished PDF can carry the **DRAFT** watermark. The ROC's contents list is rebuilt for the document as exported. Each export is kept in the ROC Library.

Before the file is made, Kliper runs the **export checks**. Blockers are what the ROC and AOC require; warnings are worth a second look. **Export anyway** produces the file regardless.

| Check | Severity |
| --- | --- |
| A sub-requirement with a finding whose reporting instructions are not all answered ("N/A" or "see …" alone counts as no response) | Blocker |
| A Not Tested finding, which the 3DS ROC has none of | Blocker |
| A compensating control missing from 3.10, or with Appendix A empty | Blocker |
| An N/A requirement not explained in Appendix B | Blocker |
| 2.3 leveraging a PCI DSS assessment without its details or a Part 1 requirement's coverage | Blocker |
| 3.5 saying sampling was used, with no sample set in 3.6 | Blocker |
| An AOC answer that applies but is missing: an EMVCo LOA, the providers after a Yes in 2f, a Part 4 remediation, the legal constraint's details, a target date | Blocker |
| 3.10 or Appendix B listing a requirement the findings do not give that result | Warning |
| No diagram in 3.1 or 3.2 | Warning |
| A response that repeats its instruction, is copied from another sub-requirement, or describes future work under In Place | Warning |

## Cortex on a 3DS assessment

[Cortex](/guides/cortex-ai) reads the 3DS assessment as the ROC does: a sub-requirement's text, validation methods and reporting instructions, your findings and responses, each high-level requirement's result, the report details and appendices, the AOC as the findings rate it, and the export checks. It names requirements as the ROC prints them. Cortex does not save 3DS 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-3ds/index.mdx