---
title: "PCI PIN Assessment"
description: "Assess an entity against the PCI PIN Security Requirements v3.1 in Kliper: choose the annexes, record the report details and the findings, 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 PIN Assessment

Kliper runs a **PCI PIN Security Requirements v3.1 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 **PIN Report on Compliance** and the **PIN AOC** from the official PCI SSC templates (ROC Reporting Template 1.0e, AOC v3.3).

## How a PIN assessment runs

1. **Create the assessment**

   Pick PCI PIN 3.1 and the annexes the entity is assessed for, besides the transaction processing operations.
2. **Record the report details**

   Contacts and dates, the services assessed, the facilities, the keys, the hardware, the documents and the interviewees.
3. **Assess each control objective**

   For each sub-requirement, choose a finding and write the assessor's response under each testing procedure.
4. **Complete the AOC**

   The AOC reads most of itself from the report; you add the parties, the justifications and the action plan it asks for.
5. **Export**

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

## Create a PIN assessment

In the full wizard, on the **Framework** step, select **PCI PIN** and version **3.1**. The **Scope & visibility** step then lists the **Annexes**:

| Annex | Covers |
| --- | --- |
| **Annex A1** | Remote key distribution using asymmetric techniques |
| **Annex A2** | Certification and registration authorities |
| **Annex B** | Key-injection facilities |

The transaction processing operations are always assessed. **Quick create** asks no annexes: an assessment made there starts with none. Change the annexes later from the assessment's **Edit assessment** dialog. An annex switched off keeps its answers: they are hidden and left out of every count, and come back if you switch it on again.

See [Creating an Assessment](/guides/creating-assessments#starting-a-new-assessment) for the rest of the flow.

## What the assessment contains

| Part | Control objectives | Sub-requirements | Testing procedures |
| --- | --- | --- | --- |
| **Transaction processing operations** | 1 to 7 | 155 | 298 |
| **Annex A1** | 3 to 6 | 11 | 17 |
| **Annex A2** | 3 to 7 | 96 | 180 |
| **Annex B** | 1 to 7 | 184 | 325 |

Requirements and procedures are shown with the numbers the ROC prints: **1-3**, **6-1.1**, and for an annex **B 1-3**. In the sidebar, **Executive Summary** holds the report details and the AOC's answers, **Requirements** each part's control objectives under it (an annex adds its own, such as **B CO 1** to **B CO 7**, never an appendix), and **Appendices** Appendix 2.

## 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 PIN version, the services disclosed |
| **1.5** | Each control objective's result. It is read from the findings: Non-Compliant when a sub-requirement is Not in Place, then Not Tested, Not Applicable when all are, Compliant otherwise |
| **2** | The high-level network diagrams |
| **3a, 3b** | The types of service assessed and not assessed, and the facilities |
| **4.1 to 4.4** | The keys, the hardware, the documents and the interviewees |
| **4.5, 4.6** | The requirements In Place with a compensating control, and those Not Tested, each with a summary |

4.5 and 4.6 say **Yes** or **No** from the findings. Click **Add the requirements from the findings** to list each one, then write its summary.

## Record a finding

Each control objective has its own page, with its sub-requirements in the ROC's order. For each one, choose a finding:

| Finding | When |
| --- | --- |
| **In Place** | The requirement is met |
| **In Place with CCW** | Met with a compensating control: choose In Place and tick **Compensating Control** |
| **Not Applicable** | The requirement does not apply, as testing confirmed |
| **Not Tested** | The requirement was left out of the assessment |
| **Not in Place** | The requirement is not met |

Then write the assessor's response under each testing procedure: what was examined, observed or interviewed, and what it showed. A Not Applicable finding is reported the same way, with the testing that confirmed it does not apply. A compensating control is documented in **Appendix 2**, the compensating controls worksheet (**Open Appendix 2** on the finding).

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

## The AOC's answers

The AOC's own page, after the report details, asks only what the report does not give:

| Part | What you record |
| --- | --- |
| **Part 1a, 1b** | The PIN service provider and the QPA company. **Fill from 1.1** copies the report's contacts |
| **Part 2c** | Each control objective's coverage (Full, Partial or None) is read from the findings; write the justification Partial and None ask for |
| **Part 3** | The rating is read from the findings: Non-Compliant when an objective is, Compliant once every objective is Compliant or Not Applicable. 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 objective's compliance, from the findings; a non-compliant one asks its remediation date and actions |

The AOC's Parts 2a and 2b come from the report's 3a and 3b.

## 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 holds only the annexes the assessment covers; its 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 procedures are not all answered ("N/A" or "see …" alone counts as no response) | Blocker |
| A compensating control or a Not Tested requirement missing from 4.5 or 4.6, or listed without a summary | Blocker |
| A compensating control with Appendix 2 empty | Blocker |
| An AOC answer that applies but is missing: a Part 2c justification, a Part 4 remediation, the legal constraint's details, a target date | Blocker |
| 4.5 or 4.6 listing a requirement the findings do not give that result | Warning |
| No network diagram in section 2 | Warning |
| A response that repeats its procedure, is copied from another sub-requirement, or describes future work under In Place | Warning |

## Cortex on a PIN assessment

[Cortex](/guides/cortex-ai) reads the PIN assessment as the ROC does: a sub-requirement's text and procedures, your findings and responses, each control objective's result, the report details, the AOC as the findings rate it, and the export checks. It names requirements as the ROC prints them. Cortex does not save PIN 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-pin/index.mdx