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.

Undo

In the Modern view, sections 1 to 7 carry an Undo that walks the section’s changes back one step at a time. On the laptop it sits next to Save in the section header. On a phone it is an icon button: in the subsection bar beside the previous and next arrows for sections 1 to 6, and in a table’s row editor; beside Save on a requirement.

• Each change is a step — a typed response, a Yes/No answer, a finding, a table edit — up to 50 steps; beyond that the oldest drops off. Keystrokes in one field fold into a single step as long as the pauses between them stay under a second and a half.
• The history belongs to the section you are in, every subsection of it included: it starts empty when you open a section and is dropped when you move to another section or reload the page. Section 7’s requirements share one history, Appendix A1 and A2 included; the Appendix C and E worksheets have no Undo.
• Undo is greyed when there is nothing left to walk back.
• An undone change saves like any other: autosave writes the section about 2.5 seconds after your last change, and Save writes it at once.

A deleted table row can also come back from the toast that confirms the deletion; see Deleting a table row.

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)

In the Modern view, each requirement opens as a stack of cards:

Report Sections 1 to 6

In the Modern view, sections 1 to 6 — the report sections that come before the requirements — are forms rather than requirement cards: text fields, Yes/No questions, dates, tables, checkbox grids and file fields, with a fill count in the section header. Two behaviors are worth knowing, and a phone gets its own layout.

If Yes and If No fields

Several subsections hold a field that only applies when the Yes/No question above it is answered one way — its label usually starts with If Yes or If No: the consultation description in 1.4, the subcontractor details in 1.5, the four segmentation details in 3.2, the initial-assessment document in 5.1 and 5.3, and the sampling chain in 6.2. Kliper fills these for you:

• Text you typed is never replaced. A field that already holds a response keeps it whatever the answer; only an empty field receives the N/A.
• Changing the answer back removes the N/A Kliper wrote and leaves the field empty for your response. An N/A you typed yourself stays until the question’s answer moves.
• Chains follow through. In 6.2, answering No to sampling sets the rationale, the representativeness, the standardized-controls question and its validation to N/A at once. A standardized-controls answer you had already given is kept rather than replaced, and its validation still follows to N/A; answering Yes again reopens the chain with that answer in place.
• Tables, file fields and checkbox grids never receive an N/A: the products table in 3.3 simply stays empty when the entity uses no listed products, though a phone shows it as N/A.

On the laptop the field stays in place and holds the N/A as its value. On a phone the field is hidden until the question is answered, then shows either an N/A box or the field itself.

Deleting a table row

Every table in these sections — on the laptop, and in the phone’s row editor — lets a deleted row come back. Click the row’s trash icon (in section 1’s tables, its Remove button; on a phone, Delete in the row editor): a Row removed toast appears with an Undo action for eight seconds, and Undo puts the row back where it was. The deletion saves with the section’s autosave like any other change, and so does the row Undo brings back. After the toast closes, the section’s Undo can still step back over the deletion while you stay in the section.

On a phone

Below 768 px wide, sections 1 to 6 switch to a phone layout. Picking a section opens a list of its subsections, each row with its field count, its completed count and a Complete chip once every required field is filled. Tap a row to open the subsection on its own page: the bar at the top goes back to the list and steps to the previous or next subsection, the fields stack with their label above, and a table lists its rows one under the other — tap a row to edit it in a full-screen editor that steps to the previous or next row. In sections 4 to 6, a subsection with gaps shows a What’s missing count under its title: open it for every empty required field, row and table, each with a Resolve that jumps to the field or opens the row. On 4.1 and 4.2 the Cortex card with the diagram scope check closes the page. The fields, the autosave and the Undo are the laptop’s; nothing changes from 768 px up.

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

A requirement’s answer moves through the review states of the QA Review Workflow. The card’s header chip shows where it stands:

The assessment as a whole is then signed off once from the Reviews page; see QA Review Workflow.

Document Evidence Sync

Section 6.4 Documentation Evidence lists one row per document, as the ROC table does. Kliper keeps it in step with your files:

• When a document tag is assigned to a file, the file is listed on its own row under that tag: the tag as the Reference Number, the file’s name as the Document Name, Cortex’s summary of the file as the Document Purpose when one exists, and an empty Document Revision Date for you to fill. A file with two tags gets a row under each.
• A new document joins the rows of its reference, so on the laptop the reference is drawn once over the documents listed under it. On a phone, 6.4 folds the documents under their reference, with the catalogue description and a count, and opens them on a tap.
• Removing a tag from a file takes it off the table again: a row the sync created is deleted, while a row you typed keeps its place and loses only the file’s name. A row you typed under the same reference that already names the file counts as its listing, so the file gets no second row.
• Sync from Files, in the table’s header, lists every tagged file of the assessment that has no row yet and reports what it did — for example Synced from Files: 3 newly listed, 5 already listed. Use it when a tagged file is missing from the table, such as one tagged before this sync was introduced or one whose row you deleted.

In the Reference Number field, start typing and Kliper offers the tag catalogue and the references this assessment already uses, each with its description; pick one with the arrow keys and Enter, or with a click. A code outside both still types in, and the field says Not in the catalogue under it.

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.