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.
How a 3DS assessment runs
Create the assessment
Pick PCI 3DS 1.0.
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.
Assess each requirement
For each sub-requirement, choose a finding and write the assessor’s response to each reporting instruction.
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.
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 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.
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 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.