Reading the Policy Compliance screens¶
This module counts differently from every other one, and the difference catches people out: a posture screen shows checks, not findings, and a single host contributes hundreds of them.
One row is a host, and the numbers are check counts¶
The postures screen groups by host. Each severity has four separate counts:
| Column family | Meaning |
|---|---|
<severity>_total_posture |
Checks at that severity that ran against this host |
<severity>_total_passed |
Of those, how many passed |
<severity>_total_failed |
How many failed |
<severity>_total_error |
How many could not be evaluated |
Total postures = passed + failed + error. If it does not, something did not complete.
Error is not failure
A check in error did not run — the agent could not read the setting, the file was absent, permissions were wrong. It is neither a pass nor a fail, and treating errors as passes is how a compliance score comes out optimistic.
A sudden compliance improvement with no configuration change is very often a rise in error counts. Check the error column before reporting the improvement.
Compliance percentage depends on what you divide by¶
Passed ÷ total is not the only defensible calculation. Passed ÷ (passed + failed) — excluding errors — gives a different and usually higher number.
When a compliance figure here disagrees with one from the scanner, this is the most likely reason, and it is worth establishing which convention each side uses before treating the gap as a data problem.
Postures versus controls¶
Two words used loosely in conversation and precisely in the product:
- A control is the rule — "SSH root login must be disabled". Defined once.
- A posture is the result of that rule checked against one asset. One control across 200 hosts produces 200 postures.
So "we have 40 controls" and "we have 8,000 postures" describe the same estate. Reports switch between the two, which is why a count can appear to change by two orders of magnitude between screens.
The posture upload queue¶
Policy Compliance data volumes are the largest in the platform — a single benchmark run across an estate produces hundreds of thousands of rows — so imports are queued and processed in batches.
The queue screen carries what you need when an import is questioned:
| Column | Use |
|---|---|
| Queue status | Pending, in progress, completed or failed |
| Queue summary | What was processed |
| Queue error | Why it stopped, where it did |
| Upload type | Whether this run replaced or merged with existing data |
| Policy title / repository / scan zone | Which benchmark, and over what |
| Initiator | Who started it |
| Automatic sync | Whether it was scheduled or hand-triggered |
Upload type is the one to check first on any "the numbers are wrong after an import" question. A merge and a replace produce very different totals from the same file, and the difference is invisible once the import has finished.
Why a host disappeared from the compliance report¶
In order of likelihood:
- The scan did not cover it. Compliance runs against a defined scope; a host outside it produces no postures and so no row — it is absent rather than passing.
- Every check errored. With no passes and no failures, some views have nothing to show.
- The import is still running. A partly loaded batch is missing hosts that will appear shortly.
The first is the most common and the least obvious, because an absent host looks the same as a compliant one on a summary screen.