---
title: "Evidence Management"
description: "How to upload, tag, validate, and manage evidence files throughout your PCI DSS assessment."
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.
# Evidence Management
Every PCI DSS assessment depends on evidence — firewall configurations, policy documents, access control screenshots, scan reports, and more. Kliper provides a structured evidence management pipeline that handles file uploads, malware scanning, integrity hashing, AI-powered validation, and document tagging in a single workflow.
## Uploading Evidence Files
Evidence files are uploaded through the **Attachments Panel** on the right side of the Assessment Workbench.
1. **Open the Attachments Panel**
In the Assessment Workbench, expand the **Attachments** panel on the right side. The upload area appears at the top of the panel.
2. **Upload a File**
You have two options:
- **Drag and drop** a file directly onto the upload area
- **Click** the upload area to open a file browser
A progress bar displays the upload percentage. The file name and upload status appear while the upload is in progress.
3. **Link to Current Section (Optional)**
If you are viewing a specific requirement (e.g., 1.2.3), check the **Link to Current Section** checkbox before uploading. This automatically tags the file to the active sub-requirement, making it visible when that requirement is selected.
4. **Automatic Processing**
After upload completes, the file passes through the security pipeline automatically:
1. **SHA-256 hash** computed for integrity verification
2. **Malware scan** — ClamAV antivirus and VirusTotal hash lookup run in parallel
3. **Metadata extraction** — page count, word count, headers, and preview text extracted
4. **Cortex AI analysis** — automatic content analysis, requirement matching, and doctag suggestions
No action is required from you during processing. Results appear in the file's row as each step completes.
### Accepted File Types
| Category | Formats |
|---|---|
| Documents | PDF, DOCX, DOC, XLSX, XLS, PPTX, PPT, VSDX |
| Images | PNG, JPG, JPEG, GIF, BMP, TIFF, SVG, WebP |
| Text & Config | TXT, CSV, JSON, XML, YAML, LOG, MD, HTML, SQL, CONF, INI |
| Certificates | PEM, CRT, CER, KEY, PUB, CSR, P12, PFX |
| Archives | ZIP |
| Logs | EVTX (Windows Event Logs) |
Executables, scripts, and other potentially dangerous file types are **blocked** at upload. See [Security & AI Trust](/security-and-ai-trust) for the full blocklist.
### Scanned PDFs
A PDF holds text in one of two ways. Most are **text-based**: the words are stored as text and can be read directly. A **scanned** PDF is a photograph of a page — to a computer it is an image, with no text inside it at all.
Kliper detects which kind it has. When a PDF has no text layer, it says so, rather than reporting a successful upload with an empty analysis. This matters for evidence such as a signed policy that was printed, signed, and scanned back in: there is genuinely nothing for Cortex to read, and knowing that is more useful than a blank summary you have to work out for yourself.
If you hit this, run the file through OCR — most scanners and PDF tools offer "make searchable" or "recognise text" — and upload the result. Kliper does not perform OCR itself.
> **Note**
>
> Text extraction also preserves table structure, so control matrices, firewall rule tables, and access-review exports reach Cortex as tables rather than as a run of disconnected words. Repeated page headers and footers are dropped, which leaves more of the analysis budget for the content that matters.
---
## The Attachments Table
Each uploaded file appears as a row in the attachments table with the following columns:
| Column | What It Shows |
|---|---|
| **File Name** | Name and file type icon (color-coded: red for PDF, yellow for ZIP, blue for images) |
| **Size** | Formatted file size (KB / MB / GB) |
| **Scan Status** | Malware scan result badge — see below |
| **Status** | Evidence validation status dropdown — see below |
| **Cortex AI** | AI analysis result with match count — see below |
| **Actions** | Download, Delete |
Each file also records **who provided it** — the person who uploaded it in the app, or the client contact who submitted it through the portal. The row shows the provider, not the surface the file happened to arrive on, so "who gave us this" is answerable at a glance and carries through to the full-page evidence view.
### Malware Scan Status
Every file displays a scan status badge immediately after processing:
| Badge | Meaning |
|---|---|
| **Clean** (green checkmark) | File passed all scan engines with no detections |
| **Threat** (red warning) | File was flagged by one or more scan engines — quarantined and rejected |
| **Scanning** (spinner) | Scan is currently in progress |
| **Pending** (clock) | Scan has not started yet |
Each file is checked by **ClamAV** (local antivirus) and a **VirusTotal** hash lookup (70+ antivirus engines) during processing.
### Evidence Validation Status
Each file has a **validation status** dropdown that tracks the assessor's review progress:
| Status | Category | Meaning |
|---|---|---|
| Pending | — | File uploaded, not yet reviewed |
| QSA Review | Open | Provided by client, awaiting QSA review |
| Not Provided | Open | Expected evidence not yet received |
| Improvements | Open | Evidence received but needs revisions |
| To Discuss | Open | Requires discussion with client |
| Observe | Open | Flagged for observation in formal assessment |
| N/A | Closed | Not applicable to this requirement |
| Recommendation | Closed | Accepted with recommendations noted |
| Accepted | Closed | Evidence fully accepted |
Select the appropriate status from the dropdown to update the file's review state. Changes persist immediately.
---
## Document Tags (Doctags)
**Doctags** are standardized reference codes that categorize evidence files by their purpose in the PCI DSS assessment. They map files to specific documentation requirements in the ROC template (e.g., `DOCFW` for firewall documentation, `PENTEST` for penetration test reports).
### How Doctags Are Assigned
Doctags can be assigned in two ways:
**AI-Suggested Tags:**
After Cortex AI analyzes a file, it suggests relevant doctags with confidence scores. In the file's expanded detail row:
- **Suggested tags** appear as outline badges with a confidence percentage (e.g., `DOCFW 92%`)
- Click the **+** button on a suggested tag to assign it
- Assigned tags appear as solid blue badges with an **x** to remove
**Manual Assignment:**
In the file's detail panel, you can manually search for and assign doctags that Cortex did not suggest.
### Common Doctags
| Tag | Description | Related Requirements |
|---|---|---|
| `DOCFW` | Firewall documentation | 1.2.2, 1.2.5, 1.2.6, 1.2.7, 1.5.1 |
| `DOCHARD` | Hardware documentation | 1.2.1, 1.4.5, 2.1.1 |
| `DOCCRYPTO` | Cryptography documentation | 3.6.1.1 |
| `DOCPWD` | Password policy documentation | 8.2.2, 8.2.3, 8.2.4, 8.3.10 |
| `DOCPOI` | Point-of-sale documentation | 9.5.1 |
| `PENTEST` | Penetration test reports | 11.4.2, 11.4.3, 11.4.4, 11.4.5 |
| `CERTINV` | Certificate inventory | 4.2.1.1 |
Over 100 doctags are available, covering every documentation category defined in the PCI DSS v4.0.1 ROC template.
### Automatic Section 6.4 Sync
When a doctag is assigned to a file, the platform automatically updates the **Section 6.4 Documentation Evidence** table in your assessment. Each tagged file creates or updates a row with:
- **Reference** — the assigned doctag(s) (e.g., `DOCFW, DOCHARD`)
- **Document Name** — the file name
- **Purpose** — AI-generated description of the file's content
- **Revision Date** — the upload date
This sync happens transparently. Manual rows you enter directly in Section 6.4 are preserved alongside auto-generated rows.
---
## Evidence Coverage
The Evidence tab of an assessment has two views — **Files** (the attachments table) and **Coverage**, a traceability lens over the control → tag → artifact chain.
### How the Chain Works
1. In a testing-procedure response, cite the evidence tag you relied on (type `/` to open the tag menu — e.g. `DOCFW` for firewall documentation).
2. Section 6.4 resolves each tag to the actual artifacts that were provided.
3. Coverage cross-references the two and tells you where the chain holds and where it breaks.
> **Note**
>
> **One file can back many controls.** A single firewall export or policy PDF often satisfies several requirements. Citing it against a second control links the same file again rather than duplicating it, and removing one citation leaves the file — and its other citations — intact. When a client submits evidence through the portal, accepting it links the file to the control it was requested for automatically.
### By Control
Every control with a finding is classified:
| State | Meaning |
|---|---|
| **Backed** | The response cites tags, and every cited tag resolves to registered evidence in Section 6.4 |
| **Dangling** | The response cites at least one tag with no matching Section 6.4 artifact — the citation points at nothing |
| **No proof** | The control has a finding but its responses cite no evidence tags at all |
Controls are grouped by requirement (collapsed by default) with summary chips to filter — **No proof** and **Dangling** are the review-day lists. Each row deep-links into the requirement editor.
### By Tag
The inverse lens: every cited tag with how many controls cite it and how many Section 6.4 artifacts back it. Dangling tags sort first. A registered-but-never-cited tag shows as **Unused** — evidence someone collected that no response leans on.
### Matrix
A controls-by-tags citation grid: rows are controls, columns are cited tags, cells mark where a citation is backed or dangling. Tag headers are hoverable for definitions, and a **Cited rows only** toggle hides controls with no citations.
> **Tip**
>
> The Gap Analysis panel cross-links here — a requirement can have a clean finding and still have thin proof. Coverage answers "could we defend this finding with artifacts today?"
---
## Cortex AI Analysis
After upload, Cortex AI automatically analyzes each file and provides:
### Requirement Matching
Cortex identifies which PCI DSS requirements the file is relevant to. In the expanded file detail row:
- Each suggested requirement shows the **requirement number**, **title**, and a **confidence score**
- Confidence is color-coded: green (80%+), amber (50–79%), gray (below 50%)
- Click **Link** to associate the file with a requirement, or **Unlink** to remove the association
### Criteria Validation
If a validation specification exists for the linked requirement, Cortex checks the file against the specific content criteria that the ROC template requires:
| Indicator | Meaning |
|---|---|
| **Complete** (green) | All criteria found in the document |
| **Partial** (amber) | 50% or more criteria found, some gaps |
| **Insufficient** (red) | Less than 50% of criteria found |
Expand the validation result to see a per-criterion checklist:
- Checkmark — criterion found, with a brief excerpt from the document
- X mark — criterion not found, with a note explaining what is missing
### AI Summary
Each analyzed file receives:
- **Relevance** — why this file matters for compliance
- **Summary** — AI-generated description of the file's contents
- **Document Type** — classification badge (e.g., PDF, spreadsheet, configuration)
- **Model** — which AI model performed the analysis
---
## Analyse Without Retaining
Some clients will not let their documents rest on a third-party platform — a common condition when the evidence contains network diagrams, key-management procedures, or personal data. For those engagements, Kliper can read a file once for analysis and never store it.
The setting is **per client**, so one client's documents can be handled this way while the rest of your book of business works normally.
1. **Open the client record**
Go to **Clients**, open the client, and choose **Edit**.
2. **Set the retention mode**
In the PCI section, set **Evidence retention** to **Analyse without retaining**. The default is **Store uploaded files**.
3. **Save**
The mode applies to every subsequent upload for that client's assessments. Files uploaded before the change are unaffected — they remain stored.
### What changes
| | Store uploaded files (default) | Analyse without retaining |
|---|---|---|
| File body written to storage | Yes | **Never** |
| Malware scan and SHA-256 hash | Yes | Yes — the file is scanned in memory before anything else happens |
| Cortex analysis | Queued after upload | Runs during the upload |
| Result kept | File + analysis | **Analysis only** |
| Download | Available | Blocked |
| Counts against storage allowance | Yes | No |
In the attachments table, files handled this way are labelled **Analysed, not stored**, and the download action is unavailable.
> **Caution**
>
> The trade-offs are real, and worth agreeing with the client before you switch the mode on:
>
> - **Uploads are slower.** Analysis runs inline rather than in the background, because there is no stored copy to read back later.
> - **A failed analysis cannot be retried.** For the same reason, a failure fails the upload — you re-upload the file rather than re-running the analysis.
> - **Integrity verification is not available.** The hash is recorded at upload, but there is no stored copy to re-hash later.
> - **You cannot get the file back.** The analysis, doctags, and requirement matches persist; the document does not.
> **Note**
>
> What this claim does and does not cover: the file is never written to Kliper's storage, and only the extraction is retained — you can delete that too. During analysis, document text transits Kliper's AI provider, which does not train on it. See [Security & AI Trust](/security-and-ai-trust#cortex-ai--privacy-and-data-handling) for the full data flow.
Every analysed-not-stored upload is recorded in the audit trail, so the engagement file shows what was examined even though the document itself was not kept.
---
## File Integrity Verification
Every file is SHA-256 hashed at the moment of upload. At any time after upload, you can verify that the file has not been altered in storage.
1. **Trigger Verification**
Use the **Verify** action on the file to initiate an integrity check.
2. **Review the Result**
The platform re-downloads the file from storage, recomputes the SHA-256 hash, and compares it against the stored original:
| Result | Meaning |
|---|---|
| **Verified** | Current hash matches stored hash — file is intact |
| **Tampered** | Hashes do not match — file has been altered in storage |
The verification timestamp is recorded in the file's metadata for audit purposes.
> **Note**
>
> Integrity verification is non-destructive and read-only. It does not modify the file or its metadata beyond recording the verification result and timestamp.
---
## File Metadata Preview
Kliper automatically extracts metadata from uploaded files, giving assessors immediate context without downloading:
| File Type | Extracted Preview |
|---|---|
| PDF | Page count, word count, text preview (first 500 characters) |
| Word (DOCX/DOC) | Word count, text preview |
| Excel (XLSX/XLS) | Sheet names, row/column counts, header names |
| PowerPoint (PPTX) | Slide count, text preview from first slide |
| Visio (VSDX) | Page count, text labels from diagram elements |
| CSV | Column headers, row count, first 3 rows as preview |
| Images | Format, file size |
| Text/Config | Line count, word count, text preview |
| Certificates (PEM) | Certificate type (certificate, private key, public key, CSR) |
This metadata appears in the file's expanded detail row and helps assessors identify files without opening them.
---
## View Modes and Filtering
The Attachments Panel supports multiple view modes:
| Mode | Behavior |
|---|---|
| **Section View** | Shows only files linked to the currently selected requirement (e.g., files tagged to 1.2.3) |
| **All Files** | Shows every file uploaded to the assessment, regardless of section |
| **Requirement Folder Browser** | Browse files organized by requirement number in a hierarchical folder structure |
Toggle between modes using the view buttons at the top of the Attachments Panel.
### Bulk Operations
Select multiple files using the checkboxes to perform bulk actions:
- **Download Selected** — downloads all selected files
- **Delete Selected** — removes all selected files from the assessment
Selection resets automatically when you switch between requirements or view modes.
---
## Evidence Requests by Assessment
When working across multiple assessments, the Evidence Requests panel groups requests into collapsible sections — one per assessment. This lets you focus on one engagement at a time without losing sight of the others.
Each section header displays:
- **Assessment name**
- **Total request count** — all requests in that assessment
- **Accepted badge** — number of requests in accepted status
- **Open badge** — number of requests still pending or in progress
Click the section header to collapse or expand it. All sections are expanded by default. Badge counts update immediately when a request status changes.
---
## Reviewing submitted evidence
> **Note**
>
> **You are told when evidence arrives.** The moment a client hits **Send for Review**, whoever created that request gets a notification and an email, linked straight to the Evidence tab holding it — no need to keep checking back. Control it with **Evidence uploads** in [notification settings](/operations/personal-settings#notifications).
When a client uploads evidence against a request, you review it and record a decision. Open the request and choose one of three actions — each shows the **consequence** before you confirm, writes to the **audit log**, and (where relevant) **notifies the client**:
| Action | What it does |
|---|---|
| **Accept** | Marks the request accepted. Logged as `EVIDENCE_ACCEPTED`. |
| **Request changes** | Emails your note to **all invited clients** and reopens the request for re-submission. Logged as `EVIDENCE_CHANGES_REQUESTED`. |
| **Waive** | Closes the request as not required, with your rationale. Logged as `EVIDENCE_WAIVED`. |
The expanded request row shows a per-status footer — e.g. **Review evidence** when something's awaiting review, **Re-review** on an already-accepted or waived request, and **Nudge client** while a request is still open.
### Nudge a client
While a request is still **open** (nothing submitted yet), click **Nudge client** to email a reminder — the request title, due date, and a portal sign-in link — to every invited (non-revoked) client on the assessment.
---
## Evidence Request Templates
Kliper includes **56 pre-built PCI DSS evidence request templates** covering all 12 principal requirements. Templates let assessors create evidence requests in seconds instead of filling forms from scratch.
### Using Templates
1. **Open the New Request Dialog**
Click **New Request** in the Evidence Requests panel. A chooser dialog appears with two options: **Custom Request** (blank form) or **From Template** (pre-built templates).
2. **Browse and Select Templates**
Templates are grouped by PCI DSS requirement (Req 1–12). Use the search bar to filter by title, requirement number, or description. Select individual templates or use the category checkbox to select all templates in a group.
3. **Configure and Create**
Optionally override the priority for all selected templates and set a shared due date. Click **Create** to generate all selected evidence requests at once.
### Template Coverage
| Category | Examples |
|---|---|
| **Req 1 — Network Security** | Firewall configs, network diagrams, data flow diagrams |
| **Req 2 — Secure Configuration** | Hardening standards, default credential removal |
| **Req 3 — Account Data Protection** | Encryption policies, key management procedures |
| **Req 4 — Transmission Encryption** | TLS certificates, secure transmission policies |
| **Req 5 — Malware Protection** | Anti-malware deployment, scan reports |
| **Req 6 — Secure Development** | SDLC documentation, change management, code reviews |
| **Req 7 — Access Restriction** | Access control policies, role matrices |
| **Req 8 — User Identification** | Password policies, MFA configuration, account reviews |
| **Req 9 — Physical Security** | Facility access logs, visitor logs, media handling |
| **Req 10 — Logging & Monitoring** | Audit log configurations, time sync, log review procedures |
| **Req 11 — Security Testing** | Vulnerability scans, penetration test reports, IDS/IPS configs |
| **Req 12 — Organizational Policies** | Information security policy, incident response plan, risk assessments |
> **Tip**
>
> Templates are a starting point — after creation, you can edit the title, description, priority, and due date of any evidence request.
---
## Downloading and Deleting Files
### Download
Click the **Download** button in the actions column for any file. The file downloads with its original filename. For bulk downloads, select multiple files and click **Download Selected**.
### Delete
Click the **Delete** button in the actions column. The file is removed from the assessment immediately. If the file was linked to a requirement section, the link is automatically cleared.
> **Caution**
>
> File deletion is immediate. Deleted files are soft-deleted (preserved in the database with a deletion timestamp) but are no longer visible in the Attachments Panel.
Source: https://docs.kliper.dev/operations/evidence-management/index.mdx