--- title: "ROC Report Export" description: "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." 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. # ROC Report Export 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](#roc-library)**. You can also **[import an existing ROC](#importing-an-existing-roc)** to pre-fill an assessment. ## Prerequisites Before generating the ROC, ensure the following are complete: 1. **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. 2. **Assessment Dates (Section 1.2)** Fill in the report date, assessment start date, assessment end date, and onsite dates. 3. **Business Description (Section 2.1)** Describe the nature of the business, how cardholder data is stored/processed/transmitted, and any other relevant details. 4. **Scope & Segmentation (Section 3)** Document scope validation results, segmentation details, and validated product usage. 5. **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. 6. **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. 7. **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. 1. **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**. 2. **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`). 3. **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. 4. **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**. 5. **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. 1. **Open the importer** From the assessment **Overview** tab, click **Import existing ROC**. 2. **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). 3. **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. 4. **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. > **Note** > > Import accepts **DOCX only**. Checkbox state lives in the document's XML; a PDF flattens it, so a PDF can't be parsed reliably. ## 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** > **Note** > > Stored ROCs are private and access-controlled — served only through authenticated endpoints, never from a public URL. ## 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 `` (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 `` 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 `` (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: Section 1 — Contact & Assessment Info | 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 | Section 2 — Business Description | Tag | Source | |---|---| | `{{Biz-Desc}}` | Nature of business | | `{{How}}` | How cardholder data is stored/processed/transmitted | | `{{Why}}` | How services impact security | | `{{Other}}` | Other relevant details | Section 3 — Scope & Segmentation | 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 | Section 5 — Vulnerability Scans | 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 | Section 6 — Evidence & Sampling | 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) | Section 7 — Findings (auto-generated) 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. Requirement Summary Counts 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 Section 1.8 — Status Lists 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`. > **Caution** > > Custom templates must be based on the PCI SSC's official ROC template structure. Tags that do not match the expected naming convention will be left as-is in the output document. ## 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 | Source: https://docs.kliper.dev/guides/roc-report/index.mdx