Skip to content

ROC Report Export

Generate a PCI DSS v4.0.1 Report on Compliance (ROC) as PDF or DOCX, import an existing ROC, and browse every export in the versioned ROC Library.

Updated View as Markdown

Kliper builds a fully formatted Report on Compliance (ROC) directly from your assessment data — as a print-ready PDF or an editable DOCX (based on the official PCI DSS v4.0.1 ROC template, Revision 3). The export runs through a guided modal where you pick deliverables and format, see a completion check, and every export is archived automatically in the ROC Library. You can also import an existing ROC to pre-fill an assessment.

Prerequisites

Before generating the ROC, ensure the following are complete:

Contact Information (Section 1.1)

Complete all contact fields: assessed entity details (company name, DBA, address, website, primary contact), QSA company information, lead QSA credentials, QA reviewer details, and any associate QSAs, other assessors, or ISAs.

Assessment Dates (Section 1.2)

Fill in the report date, assessment start date, assessment end date, and onsite dates.

Business Description (Section 2.1)

Describe the nature of the business, how cardholder data is stored/processed/transmitted, and any other relevant details.

Scope & Segmentation (Section 3)

Document scope validation results, segmentation details, and validated product usage.

Testing Procedure Responses (Section 7)

Complete the assessor responses for each testing procedure across all applicable requirements. Each response populates a Response-X.Y.Z tag in the final document.

Findings & Statuses

Select a finding status (In Place, Not Applicable, Not Tested, Not in Place) for every requirement. Write or auto-generate findings descriptions for each requirement.

Evidence & Sampling (Section 6)

Upload evidence files, document sampling methodology, and complete the evidence retention attestation.

Generating the Report

Open your assessment, then use the Actions → Export menu to open the export modal.

Choose deliverables

Select what to include:

  • Report on Compliance (ROC) — the full PCI DSS report (always available)
  • Attestation of Compliance (AOC) — generated from the same export engine, summarizing the overall result and per-requirement findings
  • Items Noted for Improvement (INFI) — the supplemental improvement-notes deliverable; available once you’ve added INFI notes in the requirement editor
  • Closure plan (XLSX) — a remediation tracker for open and Cortex-flagged gaps. Available once you’ve generated a closure plan in Cortex; it’s advisory and not part of the ROC.

Single-deliverable exports carry a ROC / AOC / INFI / Closure tag in the filename; exporting several packages them as one .zip.

Pick a format

For the ROC, choose PDF (print-ready) or DOCX (editable). When you export more than one deliverable, they’re packaged together as a .zip (e.g. name-ROC.pdf + name-Closure.xlsx).

PDF options

PDF exports can include an identity cover page, an evidence index appendix (every referenced evidence file, indexed per requirement), and a Cortex advisory appendix (open advisory flags with their CRESS scores). Incomplete assessments get a DRAFT watermark across every page — on by default, and the ROC Library version is marked Draft with its completion percentage. DOCX exports set the flag that makes Word refresh the table of contents on first open.

Integrity & completion checks

Before generating, Kliper runs deterministic integrity checks — contradictions between the overall result and per-requirement findings, interviewees referenced in responses but missing from the interview roster, and field-hygiene flags (malformed dates, placeholder text, values that don’t match the field type) carried in from the section editor. Issues are listed in collapsible groups with jump links. If the assessment isn’t 100% complete, a breakdown — Setup & Summary / Requirements / Appendices with done/total counts — appears alongside. You can Go back & finish or Export anyway.

Download

Name the file (defaults to {assessment}-{YYYY-MM-DD}), generate, and download. The export is also saved to the ROC Library as a new version.

Importing an existing ROC

Already have a ROC from a prior period? Import it to pre-fill the assessment instead of re-keying everything.

Open the importer

From the assessment Overview tab, click Import existing ROC.

Choose version & upload

Pick the PCI DSS version (v4.0 or v4.0.1 — v3.2.1 is legacy and not supported) and upload the ROC as a DOCX (up to 25 MB).

Review extracted items

Kliper parses the document — auto-detecting the version — and shows the extracted content grouped for review: each executive-summary section as its own row, per-requirement findings (status, method flags, justifications, testing-procedure responses), the Section 3–6 form tables (contacts, assessor details, scan attestations, sampling), and Appendix C / Appendix E worksheets. Imported values pass through the same field-hygiene checks as manual entry, so malformed dates or placeholder text are flagged inline rather than silently accepted.

Apply, with overwrite control

Apply the import. Requirements and executive-summary fields that are already answered are skipped by default — flip Overwrite on a row to replace an existing answer. v4.0 findings map 1:1 to v4.0.1; the few requirements that changed in 4.0.1 are skipped.

ROC Library

Every ROC you export is captured as an immutable version in the ROC Library — the full history per engagement, from first draft to signed final. Open it from ROC Library in the sidebar.

Browse by assessment or by client. Each version shows:

  • Filename, version number (v1, v2, …) with a Latest badge
  • Final or Draft · X% status (green at 100%, amber while in progress)
  • Format, file size, page count (PDF), who exported it and when, and which deliverables it contains
  • Preview (PDF only) and Download

Tracking completion

The assessment sidebar shows live progress so you know what’s left before exporting:

  • Status dots on each section/subsection — green when complete, amber when partial, gray when empty
  • Per-subsection counters (e.g. 3.1 → 2/4) and per-requirement spec counts (e.g. Req 1 → 8/12 specs)
  • Group headers roll up — Executive Summary as a percentage, Requirements and Appendices as completed/total

What counts as one completion unit: each setup field is one; a table is one unit (done only when it has at least one complete row); a checkbox group is one answer; and each requirement spec is one (decided once it has a finding). Progress refreshes automatically a moment after you save.

Assessment Summary Report (PDF)

For a quick status snapshot — without generating the full ROC — export a branded Summary Report straight from the assessment. Open the assessment and, on the Progress Status card, click Summary PDF.

It’s a one- to two-page branded PDF covering:

  • Progress and compliance — drafting completion (requirements decided) and compliance level (requirements In Place), reported as two distinct numbers so a partly-drafted assessment reads honestly rather than looking finished.
  • Requirement status — the In Place / Not in Place / In Progress / Not Applicable / Not Started breakdown, per PCI requirement.
  • Milestones — completion against the PCI DSS prioritized-approach milestones.
  • Backlog — the open tasks tied to the assessment.

Use it to keep a client or engagement manager current between formal ROC exports. The numbers match the assessment Overview exactly (same risk-model source), and the report reflects the moment you export it.

Data exports

Beyond the ROC itself, the Reports page (/reports) generates supporting data exports through the Generate report modal:

Report Contents
Assessment summary Requirement statuses, findings, and progress for an assessment
Evidence inventory Uploaded evidence files with their requirement links and review status
Audit trail The activity log (supports a date range)

Each exports as a styled Excel (.xlsx) — dark header row, status-coloured cells, filter dropdowns, and auto-sized columns — or CSV (UTF-8 with a BOM, so it opens cleanly in Excel and Google Sheets).

How the Export Works

The DOCX export engine processes the ROC template through a multi-step pipeline:

Step 1 — Template Loading

The engine loads a Word document template from the templates/ directory. The default template is report.docx, based on the PCI SSC’s official ROC template (Revision 3). Custom templates can be used by specifying a template name.

The template is a standard .docx file (ZIP archive containing XML). Tags are placed inline in the Word document as {{Tag-Name}} placeholders.

Step 2 — XML Run Merging

Word frequently splits text across multiple XML <w:r> (run) elements due to spell-check markers, formatting changes, and language attributes. This means a tag like {{Client-Name}} may be split across 3 or more XML elements.

The engine merges adjacent runs within each paragraph so that {{ ... }} tags appear in a single <w:t> element. This ensures reliable tag detection and replacement.

Step 3 — Loop Processing (Table Row Cloning)

For repeating data (tables with multiple rows), the template uses loop tags:

{{#LoopName}}
  {{.fieldA}}  |  {{.fieldB}}  |  {{.fieldC}}
{{/LoopName}}

The engine:

  1. Identifies the <w:tr> (table row) elements that contain the loop open and close tags.
  2. Treats the enclosed row(s) as a template.
  3. Clones the template row once per item in the data array.
  4. Replaces {{.fieldName}} with each item’s field values.
  5. Renders boolean fields as checkbox symbols: true → ☒, false → ☐.

Supported loop data sources:

Loop Name Data Source Description
AssociateQSAs Section 1.1 Associate QSA names and mentor assignments
OtherAssessors Section 1.1 Additional assessors with certificate numbers
ISAs Section 1.1 Internal Security Assessors
ValidatedProducts Section 3.3 PCI SSC validated product listing references
DataFlows Section 4.2 Account data flow descriptions
SADStorage Section 4.3 Sensitive authentication data storage locations
TPSPs Section 4.4 Third-party service providers
InScopeNetworks Section 4.5 In-scope network segments (account data)
NonADNetworks Section 4.5 In-scope network segments (non-account data)
Locations Section 4.6 Assessment locations and facilities
Components Section 4.7 In-scope system component types
ExtScans Section 5.1 External vulnerability scan results
IntScans Section 5.3 Internal vulnerability scan results
SampleSets Section 6.3 Sampling sets and methodology
DocEvidence Section 6.4 Documentation evidence table
InterviewEvidence Section 6.5 Interview evidence records
OtherEvidence Section 6.6 Other evidence (observation, configuration review)

Step 4 — Diagram Image Insertion

For Sections 4.1 (Network Diagrams) and 4.2 (Account Data Flow Diagrams), the engine:

  1. Queries uploaded image files tagged to these sections.
  2. Embeds the images directly into the Word document at the {{diagrams-4.1}} and {{diagrams-4.2}} tag locations.
  3. Creates the necessary Word XML relationships for inline image rendering.

Step 5 — Tag Replacement

All remaining {{Tag-Name}} placeholders are replaced with assessment data. The engine maintains a comprehensive tag map covering every section of the ROC:

Tag Source
{{Client-Name}} Assessed entity company name
{{Client-DBA}} Doing Business As
{{Client-Address}} Company address
{{Client-URL}} Company website
{{Client-Contact-Name}} Primary contact name
{{Client-Contact-Phone}} Primary contact phone
{{Client-Contact-Email}} Primary contact email
{{QSAC-Name}} QSA company name
{{QSAC-Address}} QSA company address
{{QSAC-URL}} QSA company website
{{QSA-Name}} Lead assessor name
{{QSA-Phone}} Lead assessor phone
{{QSA-Email}} Lead assessor email
{{QSA-Credentials}} Lead assessor certificate number
{{QA-Name}} QA reviewer name
{{QA-Phone}} QA reviewer phone
{{QA-Email}} QA reviewer email
{{QA-Credentials}} QA reviewer credentials
{{Report-Date}} Date of report
{{Date-of-Kick-off}} Assessment start date
{{Assessment-End-Date}} Assessment end date
{{Onsite-Dates}} Onsite assessment dates
Tag Source
{{Biz-Desc}} Nature of business
{{How}} How cardholder data is stored/processed/transmitted
{{Why}} How services impact security
{{Other}} Other relevant details
Tag Source
{{ScopeVal-*}} Scope validation fields (results, assessor, methods, documentation)
{{Segmentation-*}} Segmentation details (used, implementation, out-of-scope environments)
{{Validated-Products-*}} PCI SSC validated product usage attestation
Tag Source
{{Is-Initial-External}} Whether this is the initial external scan
{{Ext-Scan-Doc}} External scan documentation
{{Ext-Scan-Comments}} External scan comments
{{ASV-Attestation}} ASV attestation completion status
{{Is-Initial-Internal}} Whether this is the initial internal scan
{{Int-Scan-Doc}} Internal scan documentation
{{Int-Scan-Comments}} Internal scan comments
Tag Source
{{Ev-Repos-Desc}} Evidence repository description
{{Ev-Controller}} Evidence repository controller
{{Ev-Retention-Ack}} Evidence retention acknowledgment
{{Ev-Assessor-Name}} Evidence assessor name
{{Sampling-*}} Sampling methodology fields (used, rationale, representative, standardized)

Per-requirement findings are populated dynamically:

  • {{Findings-X.Y.Z-N}} — the justification text for requirement X.Y.Z, finding index N.
  • {{Response-X.Y.Z.a-N}} — assessor response for testing procedure letter a, row index N.
  • {{Response-X.Y.Z}} — all assessor responses for requirement X.Y.Z, concatenated.

Summary counts per requirement group are populated as:

  • {{rs-OK-N}} — count of “In Place” findings for group N
  • {{rs-NA-N}} — count of “Not Applicable” findings
  • {{rs-NT-N}} — count of “Not Tested” findings
  • {{rs-KO-N}} — count of “Not in Place” findings
  • {{rs-CC-N}} — count of compensating controls
  • {{rs-CA-N}} — count of customized approach findings

Auto-computed lists of requirements by status, with manual override from Section 1.8 notes:

  • {{list-NA}} — requirements marked Not Applicable
  • {{list-NT}} — requirements marked Not Tested
  • {{list-KO-Legal}} — requirements Not in Place with legal exception
  • {{list-KO-NotLegal}} — requirements Not in Place without legal exception
  • {{list-CC}} — requirements using compensating controls
  • {{list-CA}} — requirements using customized approach

Step 6 — Checkbox Resolution

The template uses checkbox tags for selection fields (radio buttons in the assessment UI):

{{check-onsite}}     → ☒ (if selected) or ☐ (if not)
{{check-combination}} → ☒ or ☐
{{check-remote}}      → ☒ or ☐

Checkbox tags cover: remote testing method, QSA consultation, subcontractor usage, assessment completion type, and overall compliance result.

Step 7 — Output Generation

The processed document is compressed using DEFLATE and returned as a buffer. The file is named using the pattern {client-slug}-roc-{date}.docx and streamed to the user’s browser for download.

Custom Templates

Organizations can use custom Word templates by placing .docx files in the templates/ directory. Custom templates must use the same {{Tag-Name}} convention. If a requested template is not found, the engine falls back to the default report.docx.

Troubleshooting

Issue Cause Resolution
Tags appear as {{Tag-Name}} in output Tag name does not match the expected convention, or the field was not filled in Verify the tag name matches the tag map; ensure the corresponding field is populated in the assessment
Table rows are empty Loop data source returned no items Populate the corresponding assessment section (e.g., fill in the TPSPs table for the {{#TPSPs}} loop)
Diagrams missing No image files tagged to Section 4.1 or 4.2 Upload network diagram or data flow diagram images and tag them to the correct section
Checkboxes show ☐ for all options Selection field not answered Select the appropriate radio option in the assessment form
Split or garbled text Word XML run splitting not resolved This is handled automatically by the run-merging engine; report the issue if it persists

Was this helpful?

Report an issue with this page
Navigation

Type to search…

↑↓ navigate↵ selectEsc close