Scoping Engine & Assessment Workbench

The Scoping Questionnaire

Every assessment carries a 62-question scoping questionnaire, organized into themed sections — Background, Assessment, Business Type, Business Environment, Transaction Channels, Changes, Data Storage, Data Transmission, Legacy SSL/TLS, Networking, Wireless, Web Applications, Time Sync, and third-party coverage. The question set follows the official PCI DSS v4 ROC scoping interview, so completing it produces the scoping narrative your ROC needs anyway.

Saving

• Autosave — answers save automatically about a second after you stop typing. A save indicator in the panel shows the current state.
• Save & Continue — the button at the end of the questionnaire performs an explicit save before moving you into the assessment. If the save fails, you stay on the questionnaire with an error — Kliper never silently discards scoping answers.

Live Applicability Suggestions

As you answer, the Scoping Insights card evaluates your answers against the official SAQ eligibility criteria and suggests controls that may be Not Applicable for this environment.

• Apply — sets the control to Not Applicable in the requirement editor, recorded as a justified N/A with the scoping reason attached. Reversible at any time.
• Dismiss / Undo — hides a suggestion you disagree with; dismissals persist per assessment.
• Conflicts — if you already answered a control differently in the editor, the suggestion becomes a conflict entry with an Open in requirement editor link. In the editor, a banner offers Keep your finding or Accept N/A — your recorded finding is never overwritten silently.
• Jump pill — when new suggestions appear below the fold, a floating pill announces them and jumps you there, so results never land invisibly off-screen.
• Segmentation guard — when answers about network segmentation are incomplete or ambiguous, the engine fails open: it withholds N/A suggestions rather than guessing scope reduction.

The card also surfaces a SAQ determination hint (which SAQ the environment would map to, useful context even on ROC engagements) and generic scope hints for common environment patterns.

N/A in the Requirement Editor

Controls set Not Applicable via scoping show a Scoping chip and a banner with the recorded reason. Marking the control applicable again restores it to normal editing. Setting any control to N/A (by scoping or manually) also fills its empty testing-procedure responses with “Not Applicable.” — typed content is never touched, and leaving N/A removes exactly the auto-filled text.

PCI DSS Scoping Engine (Requirement Visibility)

Not every PCI DSS requirement applies to every merchant. The Scoping Engine automatically adjusts the assessment to reflect the merchant’s actual environment by hiding requirements that are not relevant and marking the corresponding fields as Not Applicable.

How Scoping Works

The scoping engine evaluates a set of scoping rules against the assessor’s answers to scoping questions. Each rule consists of:

1. A condition — a field path, an operator, and an expected value.
2. An action — what to do when the condition is met (hide_requirement, show_requirement, or set_na).

When an assessor answers a scoping question (e.g., “Does the entity use wireless technologies?”), the engine evaluates all rules whose conditions reference that field. Requirements that fall out of scope are removed from the workbench view, and their fields are automatically set to “Not Applicable — Hidden by scoping rules.”

Supported Condition Operators

Built-In Scoping Rules

Kliper ships with scoping rules derived from the official PCI DSS v4.0.1 ROC template. These rules cover the most common scoping scenarios:

Scoping Evaluation Flow

Re-Scoping

Scoping is not permanent. If the assessor changes a scoping answer (e.g., updates “Uses wireless?” from No to Yes), the engine re-evaluates all rules immediately. Previously hidden requirements reappear in the workbench, and their N/A markers are cleared. No assessment data is lost during re-scoping — answers that were previously entered for a now-hidden requirement are preserved and restored if the requirement becomes visible again.

Assessment Workbench

The Assessment Workbench is the primary interface where assessors conduct their evaluation. It is designed for extended, focused work sessions on individual requirements.

Layout

The workbench uses a three-panel layout:

View Modes

The section editor offers three rendering modes, switchable from the top bar:

Live Presence (Live Status)

When multiple assessors are working on the same assessment, Live Status in the top bar shows who else is present. Each active user appears as an avatar with their name on hover, updated in real time via the platform’s presence system. This makes multi-assessor engagements visible without manual check-ins.

Managing collaborators

Open Edit Assessment to control who can work on an assessment. Each collaborator row has a role — Editor or Viewer — that you can change inline, plus a remove control; the owner is pinned with a crown. Add a person by selecting them and choosing a role. Changes apply immediately — no separate save step.

Linking evidence inline (/ typeahead)

In any assessor-response or evidence textarea, type / to open a typeahead of your document and evidence tags. Use the arrow keys to navigate and Enter to insert — so you can reference a specific uploaded file or document without leaving the field.

Compact Section Rows

When a finding status has been set on a requirement, the row in the section tree collapses to a single status chip showing the current finding (In Place, Not in Place, Not Applicable, or Not Tested). All four options only appear when no finding is set, reducing visual clutter on assessments where most requirements are complete.

Section Tree (Left Panel)

The section tree displays all 12 PCI DSS principal requirements and their sub-sections in a collapsible hierarchy. Each node shows:

• Requirement number (e.g., 3.4.1)
• Completion indicator — visual status showing whether the requirement has been answered
• Scoping visibility — requirements hidden by the scoping engine do not appear in the tree

Clicking a node loads that requirement into the center panel.

Question Panel (Center)

For each requirement, the center panel presents:

Context Panels (Right Side)

The right side of the workbench contains collapsible panels that provide contextual information without leaving the current requirement:

Answer Status Progression

Each assessment answer progresses through a defined status lifecycle:

Pending  ──▶  Reviewed  ──▶  Approved
   │              │
   └──────────────┘
     (can return to Pending if changes are needed)

• Pending — initial state. The assessor is still working on the requirement.
• Reviewed — the answer has been reviewed by a peer or supervisor.
• Approved — the answer is finalized and locked for inclusion in the ROC report.

Document Evidence Sync

When files are uploaded to an assessment, Kliper automatically syncs them into the Section 6.4 Documentation Evidence table. This happens transparently:

1. File is uploaded with optional tags (e.g., doctag-DOCFW for a firewall documentation tag).
2. The platform creates or updates a row in the 6.4 answer’s docEvidence array.
3. Each row contains: file ID, document reference tag, file name, AI-generated purpose summary, and upload date.
4. Manual rows (entered directly by the assessor) are preserved alongside auto-generated rows.

A “Resync All” action is available to force re-synchronization of all files into the 6.4 table.

Requirement Priorities

Each requirement can carry a manual priority (High / Medium / Low) set from the Requirements toolbar — your own triage lens for “what do I attack first,” independent of the PCI Prioritized Approach milestone shown on each control. Filter the requirement list by priority to focus a working session.

Vault Guidance

Every control card includes a collapsed Guidance accordion between the requirement criteria and the finding — reference content from a practicing QSA’s working library, rendered verbatim (not AI-generated):

• Purpose, Good practice, and Further information for the control.
• Cloud guidance for Azure and AWS environments where available.
• Response templates — real ROC response patterns with a copy button; [CLIENT-NAME] placeholders stay visible for you to fill.

Inside each testing procedure, a How to test toggle in the reference column reveals the per-TP material: category and evidence level, the expected evidence tags (with hover definitions — the same codes the coverage view tracks), plus validation steps, sampling procedures, and assessment questions.

Resume Where You Left Off

The dashboard tracks the last subsection you worked on per-assessment and offers a one-click resume.

How It Works

• Per-assessment tracking — when you open a specific requirement in the workbench, the platform stores the assessment ID, subsection ID, and a human-readable label in your browser’s localStorage.
• Dashboard Resume Card — the next time you visit the dashboard, a Resume Card appears with the assessment name, the specific requirement you last worked on, and a Continue button.
• Strict matching — the card only appears when localStorage has a confirmed match for an assessment you still have access to. There is no arbitrary “in progress” fallback — the card either shows the exact location you left, or it doesn’t show at all.
• Per-device — because tracking uses localStorage, the resume position is specific to the browser you were working in. Switching devices starts fresh.

Why It Matters

On long engagements, assessors often work in short sessions spread across days. Resume eliminates the “which requirement was I on?” moment at the start of each session — the dashboard remembers for you.

Compact Assessment Hub Cards

The stat cards at the top of the Assessment Hub (Total Requirements, Completed, In Progress, Not Started, etc.) use a compact layout:

• Reduced padding, icon size, and font size
• Tighter progress bars
• More cards visible without scrolling

Designed to fit more engagement context on screen during daily standup reviews.