Policy Compliance: support reference¶
Internal. The customer-facing explanation is in Reading the Policy Compliance screens and the screen reference.
This module counts differently from every other one and carries the largest data volumes in the product. Both facts generate most of its tickets.
It counts postures, not vulnerabilities¶
Everywhere else a finding is a weakness. Here a posture is one control checked against one host, and every check produces a row whether it passed or failed.
Total postures = passed + failed + error. If that sum does not hold, the run is still processing rather than miscounting.
A single audit against 400 hosts and 300 controls is 120,000 rows. Nothing about this module is instant, and screens that look wrong are frequently screens that are not finished.
Posture Status is not Status¶
| Column | Means |
|---|---|
| Posture Status | What the check returned — pass, fail, error |
| Status | What your team decided to do about it |
A posture can legitimately be fail and Risk accepted at once: the machine is still non-compliant and the organisation has agreed to leave it that way. Reports that conflate the two overstate remediation.
Error is neither pass nor fail — the check could not run. A benchmark reporting mostly errors is usually a credential or agent problem on the target, not a compliance result.
The upload queue answers "where is my data"¶
Every posture upload is queued. The queue records the policy, report type, upload type, workflow, status, who initiated it and when.
- A job in Pending or In Progress has not landed yet; counts will keep moving.
- A Failed job carries a per-row reason — most often a host in the file that is not in the audit's scope.
- Cancelled was stopped deliberately by someone.
If a caller says an upload "did nothing", the queue is the first screen to open, not the posture list.
The queue heading can read 'undefined'
Reached from a bookmark or a refresh that loses its parameters, the heading prints Uploaded Report Status - undefined. The table beneath it is still correct. This is a known defect (FINDINGS #17), not a sign of a broken upload.
Upload types change what an upload does¶
The upload type decides how incoming rows meet existing ones — merge, closure, limited closure, ignore. Choosing the wrong one is not a parsing error and produces no warning; it produces the wrong result quietly.
A caller reporting that "everything closed" or "nothing updated" after an upload has usually chosen a different type from last time. The queue records which was used.
Evidence and Cause¶
Two different things, and support answers depend on which is meant:
- On a posture row, Evidence is the value read from the machine, and Cause is the rule's explanation. Together they are what makes a finding arguable or not — "that setting is correct" is settled by Evidence.
- On the status history, Evidence is what the person changing the status recorded as justification. It is an audit trail, not a machine reading.
Scope disputes¶
Compliance scope is a host list. Export IPs on the audit produces it, and comparing that export against the benchmark tool's own target list settles almost every "you didn't scan X" disagreement.
Excluded assets carry a Comment; an exclusion without one is the first thing an external auditor questions.
Bulk operations¶
- Bulk Approve Audit Status acts on ticked rows — the reason the checkbox column exists.
- Asset status can be set for hundreds of hosts by CSV upload, with a downloadable sample.
- Status changes always pass through a confirmation dialog that names the audit and the
transition. Whether a comment is required is a property of the target status, and comments
reject characters outside
A-Z a-z 0-9 _ - . &.
An empty screen is usually a filter¶
The filter drawer is reached from More Filters / All Filters, and the button carries a badge with the number of filters applied. Filters persist as the caller moves around the module. A non-zero badge over an empty list means filtered, not empty — and this is the single most common false alarm in the module.
What to collect before escalating¶
- The audit ID, the client, and the benchmark.
- The queue entry for the upload in question — status, upload type, and the failure reason if any.
- Whether the three posture counts reconcile.
- The filter badge count on the screen the caller is describing.
- For scope disputes: the Export IPs file and the tool's own target list.