Policy Compliance: every screen, column and action¶
Complements Reading the Policy Compliance screens. The module has the largest data volumes in the product, so almost everything here is queued, and the queue screens carry the answers.
The audit list¶
| Column | What it holds |
|---|---|
| Request Info | Who requested it, when, and the request ID |
| Audit Details | Audit name and the benchmark being assessed |
| Vulnerabilities | Failed checks with their severity split |
| Audit Properties | Type, cycle, scope, considered |
| Audit Status | Current state |
| Data Process | Whether the uploaded data has finished processing |
Data Process matters more here than anywhere else. A policy run produces hundreds of thousands of rows, so the gap between "upload finished" and "data processed" is minutes to hours — and counts move throughout. An audit reporting a number that keeps changing is still processing, not miscounting.
Row actions — eight¶
| Action | What it does |
|---|---|
| Edit Audit Details | Name, dates, properties |
| Manage Audit Scope | What was in and out of scope |
| Assign Auditors | Who runs it |
| Export IPs | Downloads the hosts in scope |
| Re-Audit | A follow-up assessment against the same scope |
| View Audit Chain | The original and every re-audit — Audit ID, Type, Audit Name, Status, Auditors |
| View Status History | Every status change |
| Delete Audit | Soft delete |
Export IPs is how a scope dispute gets settled. Compliance scope is defined by host list, and the export is what you compare against the benchmark tool's own target list when the two disagree on coverage.
Bulk Approve Audit Status acts on the audits ticked in the first column, so a cycle's worth of completed audits can be approved together rather than one at a time.
Changing an audit's status¶
Every status change goes through a confirmation step rather than applying on click. The dialog states, in order:
- the audit name and ID, so you can see you are moving the audit you meant to
- the transition itself — from status → to status
- a warning, where the transition has a consequence worth stopping for
- a Comments box, labelled (optional) or marked required depending on the target status
Then Change Status, or Cancel.
Whether a comment is required is a property of the target status
The same screen asks for a mandatory comment on one transition and offers an optional one on the next. That is configuration, not inconsistency — each status carries its own comment required flag on the status master.
Comments accept letters, numbers, and _ - . & only, up to 5000 characters. A comment
pasted from a ticketing system often carries characters outside that set, and the
dialog rejects it rather than truncating.
Filters¶
The filter drawer is reached from More Filters (All Filters on the policies screen), and the button carries a badge with the number of filters currently applied.
That badge is the answer to most "why can't I see my audit" questions: filters persist as you move around the module, and a non-zero badge on a screen that looks empty means the list is filtered, not empty.
Postures by host¶
| Column | What it holds |
|---|---|
| Host | The machine |
| Policy Details | Which benchmark was applied |
| Tool | Which scanner produced the result |
| Total | Checks run against this host |
| Critical / High / Medium / Low / Info | The severity split of the failures |
Remember that a row is a host and the numbers are check counts, not findings. One control across two hundred hosts produces two hundred postures.
Postures for one control¶
Opened from a host or a control.
| Column | What it holds |
|---|---|
| Posture ID | The individual result |
| Control Name | The rule being checked |
| Severity | As rated |
| Status | The working state |
| Posture Status | Pass, fail or error — the technical result |
| Cause | Why it failed |
| Evidence | What was actually found on the machine |
| Instance | Which occurrence, where a control is checked more than once per host |
| Discovered On / Last Observed Date | First and most recent sighting |
Row actions: View Posture Status History, Vulnerability History, and add a comment.
The two histories, and the comment trail¶
Three separate records sit behind a posture, and they answer different questions:
| Screen | Columns | Answers |
|---|---|---|
| View Posture Status History | By, On, Status, Evidence |
Who moved this posture to its current state, when, and on what basis |
| Vulnerability History | Audit Details, Risk, Status, Status Changed By, with its own More Filters |
How this finding has behaved across audits |
| View Posture Comments | By/On, Comments |
What people said about it, in order |
Both histories are headed by the Control Name, so a modal opened from a long list still says which control it belongs to.
Evidence on the status history is the audit trail, not the scan output
The Evidence column here is what the person changing the status recorded as their justification. It is not the machine reading — that is the Evidence column on the posture row itself.
They are deliberately separate: one is what the scanner found, the other is why a human decided to accept, defer or close it.
Status and Posture Status are different columns
Posture Status is what the check returned — pass, fail, error. Status is what your team has decided to do about it.
A posture can be fail and Risk accepted at the same time, and that combination is
correct: the machine is still non-compliant, and the organisation has agreed to leave
it that way.
Cause and Evidence together are what make a compliance finding arguable or not. Cause is the rule's explanation; Evidence is the actual value read from the machine. When an owner says "that setting is correct", Evidence is what settles it.
Controls and policies¶
| Screen | Columns |
|---|---|
| Controls | Control Details (identifier and name together), Severity, Tool, Policies, Created By |
| View controls | Control ID, Control Name, Severity, Created By |
| Policies | Policy Title/ID, Tool / ID, organisation, Policy Config Category, Created By |
| View control policies | Policy ID, Title, Tool, Org, Category |
| Categories | ID, Policy Config Category, Created By, Sync |
The Policies column on a control counts how many policies include it — a control in six policies is checked by all six, and fixing it improves every one of their scores.
Category actions are View Controls and Delete Config Category. The Sync column shows whether a category is kept in step with its source tool.
Host selection¶
Host IP, Host Name, Application Name, App Code, Selected — used when defining
what an audit covers. App Code is included because compliance scope is usually agreed
per application, while the scan runs per host.
Excluded assets¶
Network Asset ID, Host IP/Host Name, Comment.
Hosts deliberately outside a compliance run — a lab machine, an appliance the benchmark does not apply to. The Comment is the justification, and an exclusion without one is the first thing an auditor questions.
Updating asset status¶
Network Asset Id, Host IP/Host Name, Status — bulk-sets whether hosts are active in
compliance runs.
The screen accepts a CSV upload for bulk changes and offers a sample to download, so a list of several hundred hosts does not have to be set one at a time.
The posture upload queue¶
| Column | What it holds |
|---|---|
| Queue ID | The job |
| Policy | Which benchmark |
| Report Type | The kind of report uploaded |
| Upload Type | Merge or replace |
| Workflow | How results were processed |
| Status | Where the job is |
| Initiated By / Initiated At | Who and when |
Actions: Queue File, Queue Summary, Log File, and Retry on a failed upload. The queue can be filtered by Host IP as well as by status, so one host's uploads can be followed across runs.
Queue Summary is what was processed; Log File is the per-row detail including rejections. On any "the compliance numbers are wrong after an upload" question, check Upload Type first and the Log File second — those two answer it almost every time.
Scheduling a scan instead of uploading a report¶
Upload PC Report → Upload Report opens Upload New Report, and it is offered only on an audit that is still in progress with an auditor assigned — a completed audit's menu has View Upload Report alone. The form unfolds as you choose:
| Field | What it decides |
|---|---|
| Policy Config Category | Which category of the policy this run covers |
| Report Type | Qualys, Nessus or Manual — the scanner, or a hand-assessed sheet |
| Workflow | Upload takes a report file. Scan asks the scanner to run the benchmark and bring the result back. Automatic Scan — Nessus with a Tenable SC connection only — re-runs it on a schedule |
| Scan Option | Start a New scan, or reuse an Existing one by its Scan Result or Scan ID |
| Config Policy | The benchmark the scanner runs |
| Scan Zone, Repository | Where the scanner runs from and where its results are kept, as defined in Tenable SC |
| Track hosts which have been issued new IP address | Follow a host across an address change, for estates using dynamic addressing |
| Credentials | The scanner's own credential sets, one or more, for an authenticated scan |
| Schedule Scan / Schedule At | Run now, or at a chosen date and time |
| Upload Type | Ignore leaves assets that already have a posture untouched; Override replaces their results |
Qualys shows the same shape with an Option Profile in place of the Tenable fields. A scheduled scan appears in the queue like an upload and can be cancelled while it is running — the confirmation asks whether to cancel the on-going scan. A scan needs a target, so an IP is mandatory for it; a report upload has no such requirement, since the hosts are in the file.
The Host selection step searches by App Code, Application Name, Host IP or Host Name, so the hosts in scope can be picked from either the application side or the network side of the inventory.
Bulk upload of policies and controls¶
Accepts CSV or XLSX. The queue reports Status, Initiated By, Uploaded At,
with Download and Log File Download.
Reporting¶
Download xlsx Report from the postures view exports the current posture set as filtered — the format compliance teams actually work in, because they annotate it and send it back to system owners.