PCI DSS Report on Compliance (ROC)

PCI DSS Payment Security ROC QSA Compliance Cybersecurity

Overview

Author PCI DSS v4.0 ROC documentation for Level 1 QSA assessments: scope workpapers, requirement-by-requirement findings, Compensating Controls Worksheets (CCWs), Customized Approach Worksheets (CAWs), and the Attestation of Compliance (AOC).

Getting Started

Add your source materials to the project workspace, then activate the PCI DSS Report on Compliance (ROC) skill. The agent will guide you through the process step by step.

Example Conversation

You: We’re a Level 1 service provider starting our PCI DSS v4.0 ROC. I’ve uploaded our network diagrams, system inventory, and existing policies. Let’s start with scoping and the CDE.
Agent: To define the CDE I need a few answers: (1) Which systems store, process, or transmit PANs or SAD directly? (2) Are you using a P2PE or tokenisation solution that could reduce scope? (3) What segmentation controls separate CDE systems from the rest of your network?
You: We use a tokenisation gateway — CHD never touches our app servers. CDE is the gateway cluster and its supporting infrastructure. Segmentation is dedicated firewall zones with deny-all defaults.
Agent: Tokenisation significantly limits scope. I’ve created scope-workpapers.md documenting the CDE as the tokenisation gateway cluster (3 nodes), the HSM, the supporting database, and the management bastion. App servers are out of scope. I’ve drafted the segmentation testing section — annual penetration testing of the firewall boundary is required. Shall I start with Requirement 1 (Network Security Controls) findings?
You: Yes. We have Palo Alto firewalls with rule review logs from last quarter and our hardening standard.
Agent: I’ve reviewed the firewall docs. Requirement 1.2 — In Place: firewall rule baseline document v3.1 reviewed 14 Feb 2025; three change management tickets reviewed; quarterly review confirmed. Requirement 1.3 — In Place: deny-all default with explicit CDE permit rules only; no direct public internet access to CDE. I’ll continue through Requirements 2–12 — want me to flag anything as a gap rather than In Place before I proceed?

Sample Output Excerpt

Below is a representative excerpt from a PCI DSS v4.0 ROC findings document.

Requirement 3: Protect Stored Account Data

Assessed entity: Acme Payment Services, Inc. | Period: 1 Jan – 31 Mar 2025

3.3 — Sensitive Authentication Data (SAD) Not Retained After Authorization

Finding status: In Place

Testing performed:

Interview: Data architect confirmed SAD is never written to persistent storage; CHD handling design reviewed.
Examine: Reviewed tokenisation service source code (commit a4f9c2d); no SAD fields present in database schema or log output.
Test: Authenticated scan of tokenisation gateway database — no SAD fields (track data, CVV, PIN) detected in any table.

Evidence cited: Data retention policy v2.0 §4.2; database schema export (prod, 15 Mar 2025); scan tool output (0 SAD fields detected, 18 Mar 2025).

3.6 — Cryptographic Key Management — Compensating Control (CCW-003)

Finding status: In Place (via Compensating Control)

Gap (CCW-003 summary): Legacy batch module uses 3DES for PAN encryption; AES-256 upgrade blocked pending vendor certification (expected Q4 2025).

Compensating control: The 3DES-encrypted batch files are stored on an air-gapped system in a camera-monitored server room with dual-person access log. Triple-key 3DES (168-bit effective) is used. Network path is fully isolated.

Objective met: PAN confidentiality is maintained; compensating control provides equivalent protection for data at rest.

CCW Field	Detail
Reason for non-compliance	Vendor-constrained legacy system; upgrade contractually scheduled
Constraints	No AES-capable replacement available until Q4 2025
Objective met	PAN confidentiality at rest per Req 3.5 objective
Risk mitigated	Unauthorised access to PAN eliminated by physical isolation
Compensating controls	Air-gapped storage, dual-person access, camera monitoring, 168-bit 3DES
Validation testing	Physical access log reviewed; network isolation confirmed by firewall rule audit

Built-in Scripts and Validation

The skill includes a validation tool the agent runs against the ROC findings document before the AOC is produced.

Validation tools

Tool	Purpose
roc_completeness_check	Scans the ROC findings file (JSON or Markdown) and validates: (1) all 12 top-level PCI DSS requirements are represented; (2) every sub-requirement has an explicit finding status — In Place, Not in Place, Not Applicable, or Not Tested; (3) all “In Place” findings cite at least one evidence item; (4) all “Not in Place” findings include a gap description and affected system components; (5) all “Not Applicable” findings include a written justification; (6) every CCW has all six required fields completed (reason, constraints, objective met, risk mitigated, compensating controls, validation testing); (7) every CAW has the solution description, targeted risk analysis, and controls matrix. Returns PASS when all checks pass, or FAIL with a numbered list of specific issues to fix before the AOC can be signed.

Tool

Purpose

roc_completeness_check

Scans the ROC findings file (JSON or Markdown) and validates: (1) all 12 top-level PCI DSS requirements are represented; (2) every sub-requirement has an explicit finding status — In Place, Not in Place, Not Applicable, or Not Tested; (3) all “In Place” findings cite at least one evidence item; (4) all “Not in Place” findings include a gap description and affected system components; (5) all “Not Applicable” findings include a written justification; (6) every CCW has all six required fields completed (reason, constraints, objective met, risk mitigated, compensating controls, validation testing); (7) every CAW has the solution description, targeted risk analysis, and controls matrix. Returns PASS when all checks pass, or FAIL with a numbered list of specific issues to fix before the AOC can be signed.