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 lives in the Evidence tab of the assessment editor. Open an assessment, select a section, then choose Attach File in the gear menu at the left of the editor’s toolbar, or Open full page on the Evidence tab of the right rail. The Evidence entry of the assessment’s sidebar menu opens the same tab. The header names the section you are in and the assessment’s file count. All files opens the assessment’s full file library, and the Files / Coverage toggle switches between the table and the coverage view.

Accepted File Types

Executables, scripts, and other potentially dangerous file types are blocked at upload. See Security & 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.

The Attachments Table

Every file of the section appears as a row. Click a row to open the file’s drawer; tick the checkbox at its left to select it for a bulk action.

Above the table, the All / Pending / Open / Closed tabs filter the rows by status group, each with its count, and the search box narrows them by file name. The line under the table reads how many of the section’s files are shown.

Who provided it. A client submission through the portal reads From client · 12.1.1, with the requirement it was requested for. A team upload reads Added by the uploader’s first name and the section it was uploaded for — Added by Sara · Requirement 12, Added by Sara · Contact Information — so a file filed under the wrong section is visible at a glance. A file uploaded without a section link shows only the uploader until a team member links it to a section; Cortex’s Link does not change it.

Malware Scan Status

The Scan chip carries the verdict of the security pipeline the file went through:

A file uploaded in the app is checked by ClamAV (local antivirus) and a VirusTotal hash lookup (70+ antivirus engines) in parallel, after static checks on its type, extension and content. If a scanner is unavailable, the file stays Not scanned rather than being passed. A file the client uploads through the portal is scanned by ClamAV, and its verdict reaches the assessment’s copy of the file: at acceptance, or as soon as the scan finishes if it is still running then.

Evidence Validation Status

Each file has a validation status that tracks the assessor’s review of it. The dropdown sits in the Status column and at the top of the drawer; a change saves immediately.

The Pending / Open / Closed tabs above the table group the rows by these statuses. Validating a file against a requirement’s criteria from the drawer sets its status from the result: Accepted when every criterion is met, Improvements when at least half are, Not Provided otherwise — see Criteria Validation.

The Evidence Drawer

Click a row and the file’s drawer slides in from the right. It holds everything about one file:

Preview and Download are disabled on a quarantined file and on a file missing from storage, and absent on a file that was analysed without being stored. A file Cortex has not analysed yet offers Run analysis, or a limit notice once your plan’s monthly allowance of Cortex analyses is spent.

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 are assigned in the file’s drawer, in the Tags section. Click the file’s row in the attachments table to open it.

• Suggested tags are the dashed chips, each with the tag code and Cortex’s confidence (for example DOCFW 92%). Click one to assign it.
• Assigned tags are the solid chips with a check mark. Click one to remove it.
• Hover a chip for the tag’s definition.

The table’s Tags column lists each file’s assigned tags and, when Cortex has suggestions you have not acted on, +N suggested. Cortex’s suggestions come from its analysis of the file, so the Tags section appears once Cortex has suggested a tag, or once a tag has been assigned.

A tag Cortex did not suggest is assigned from the file library (All files in the Evidence header): on a wide screen, each file’s row there has a tag selector.

Common Doctags

Over 100 doctags are available, covering every documentation category defined in the PCI DSS v4.0.1 ROC template.

Automatic Section 6.4 Sync

Section 6.4 of the ROC, Documentation Evidence, is where the PCI ROC template lists every document the assessor reviewed, one row per document. Kliper keeps that table in step with your tagged files: the moment you assign a doctag to a file, the file gets a row of its own in Section 6.4.

A file with several tags gets one row under each tag. Removing a tag from the file removes the row the sync created under that tag. Everything else in the table is yours:

• Rows you typed are never removed. If a row you typed under that reference already names the file, the sync counts the file as listed and adds nothing; removing the tag then only takes the file’s name out of that row’s Document Name.
• Your edits to a synced row stay. The sync fills Document Purpose only while it is empty, and never touches the other columns of a row that already exists.
• Deleting a file does not remove its row. Remove the row by hand, or remove the tag before you delete the file.

Everything that reads the table, the ROC export, Evidence Coverage and Cortex’s finding drafts, reads it row by row, so each document carries its own purpose into the report. Rows you typed by hand, including any that list several documents, are read as before.

Sync from Files

A file tagged before this sync existed may have no row yet. To list every tagged file at once, open 6.4 Documentation Evidence in the ROC editor and click Sync from Files in the table’s header (on a phone, on the bar above the list). Kliper walks every file of the assessment, lists each tagged file under each of its tags, and reports the result in a toast: Synced from Files: 3 newly listed, 12 already listed. Files already on a row are left as they are.

The same action tidies the older layout, in which the sync stacked several documents in one row under their reference: each such row is split into one row per document. The first document keeps the row’s purpose and revision date; each of the others takes its own file’s Cortex summary as purpose, when the file has one.

On the laptop

In the Section 6.4 table, rows that sit together under the same reference show the reference once, drawn over the documents listed under it, and the shared reference cell lights up with whichever of its rows you hover. A newly tagged file is placed right after the last row that carries its reference, so it joins its documents instead of landing at the bottom of the table. A reference left empty is never merged.

Add row below the table adds a row of your own. The trash icon at the end of a row removes it, and the toast’s Undo brings it back for eight seconds.

The Reference Number field

The Reference Number cell is a picker as well as a text field. As you type, a list opens with the tag catalogue, every code with its short description, followed by any references this assessment already uses that are not in the catalogue, marked Used in this assessment. The list’s header says how many references it holds and, as you type, how many match. Codes that begin with what you typed come first, then codes that contain it. Use the arrow keys and Enter, or click a code, to fill the cell; Escape closes the list.

A code outside the catalogue still types in. Unless another row of the assessment already uses it, Not in the catalogue appears under it as soon as nothing in the list matches, or once you leave the field, so a typo is caught before it reaches the report. Kliper does not add the code to the catalogue.

On the phone

Section 6.4 folds its documents under their reference: one line per reference with the code, its catalogue description when it has one, and a count of documents. Tap the reference to unfold its documents, and a document to edit it. In the row editor, Reference Number is the same picker, Document Name is a single line, Document Purpose is a text area and Document Revision Date is a date picker. Sync from Files and Add sit on the bar above the list.

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.

By Control

Every control with a finding is classified:

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.

Cortex AI Analysis

Cortex reads each file uploaded in the Evidence tab, and each file you accept from the portal, and writes what it found into the file’s drawer; for a file added another way, click Run analysis there. Click the file’s row to open it. While Cortex reads a file you uploaded here, the row reads Analysing… and the drawer says so; the sections below appear when it finishes.

Requirement Matching

The Requirements section of the drawer lists what the file is linked to and what Cortex suggests, with a count of each in its header (2 linked · 3 suggested).

• A linked row shows the section or requirement name with a green check. Links made from the section page, the bulk bar or the portal show here; a link made from a suggestion also offers Undo.
• A suggested row shows the requirement (Req 12.1.1 and its title), a confidence meter with its percentage — green from 80%, amber from 50%, grey below — and Cortex’s reason in one sentence.

Click Link to cite the file for that requirement. The citation is the same one the row menu and the bulk bar make: the file stays where it is in the library, earlier links stay, the table’s Requirements column shows the new one, and the Draft from Evidence drafter sees it. Click the × to dismiss a suggestion you disagree with; a dismissed suggestion leaves the list and the +N suggested count, and nothing else changes.

Criteria Validation

Kliper keeps a checklist of what the ROC template expects a document to contain for a requirement. The Validation against criteria section of the drawer offers Validate N criteria for each requirement the file’s assigned doctags map to, so assign the tag first.

The result opens under the requirement: All criteria met in green, or N of M met in amber, then one line per criterion:

• A check mark — criterion found, with a short excerpt from the document
• A cross — criterion not found, with a note on what is missing

The file’s validation status follows the result: Accepted when every criterion is met, Improvements when at least half are, Not Provided otherwise. Re-validate runs the check again.

What Cortex Read

The What Cortex read section holds Cortex’s reading of the file: a summary of its contents, why it matters here for the assessment, and the numbered key findings. Its header names the model and the date of the analysis; Regenerate runs the analysis again.

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.

What changes

In the attachments table, files handled this way are labelled Analysed, not stored, and the download action is unavailable.

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.

File Metadata Preview

Kliper extracts metadata from every uploaded file, so an assessor has context without downloading it:

The drawer’s facts line, under the file name, is drawn from it: the type, the page count, word count or row count, the size, and the date the file was Added by the team or Received from the client.

View Modes and Filtering

The Evidence tab shows the evidence of the section you have open. Three controls narrow or widen the list:

The requirement folder browser of earlier versions is no longer part of this tab.

Bulk Operations

Tick the checkbox on one or more rows (the header checkbox selects every visible row) and a bar appears at the bottom of the screen:

• Set status — applies one validation status to every selected file
• Link to section — cites every selected file for a section chosen from the assessment’s structure
• Download — downloads each selected file
• Clear — drops the selection

The selection resets when you change section, tab or search. On a phone, Select above the list turns the rows into checkboxes, and the bar at the bottom edge offers the status, the section link and Delete for the selected files.

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

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:

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

Template Coverage

Downloading and Deleting Files

Download

Open the row’s File actions menu (the three dots at its right) and choose Download, or click Download in the drawer’s header. To download several, tick their rows and click Download in the bulk bar.

The drawer turns Download off for a quarantined file and for a file missing from storage. A file that was analysed without being stored cannot be downloaded at all.

Delete

Open the row’s File actions menu, choose Delete and confirm. The file is removed from the assessment immediately. On a phone, Select and the Delete action at the bottom edge remove several files at once, after one confirmation.