Counting rules, limitations and checks¶

Most escalations that reach the support team are not faults. They are one of the rules on this page working exactly as designed, in a way the screen does not explain.

Everything here was read out of the application code and the status master tables, not inferred from the interface. Where a rule is configurable, the setting is named.

The single most common question

"The dashboard count doesn't match the number of rows in the table."

This is almost always one of the first two rules below. Check them before treating it as a defect.

1. Only two statuses actually close a vulnerability¶

A vulnerability counts as open unless its status is flagged as a closed type. Of the fourteen statuses shipped in the status master, only two carry that flag:

Status	Counts as closed?
Validated	Yes
Exception Handled	Yes
New · Patched · Patch in progress · Not Patched · To be patched · On hold · Reopen	No
Risk accepted	No
Not Applicable	No
Duplicate	No
Expired	No

The four in bold are the ones that surprise people. Marking a finding Risk accepted, Not Applicable or Duplicate does not remove it from open counts, SLA ageing, or overdue reporting. It stays open until someone sets it to Validated (or Exception Handled).

Check before escalating

Filter the list by status and compare. If the "missing" rows are Risk accepted, Duplicate, Not Applicable or Expired, the count is correct and the expectation is what needs adjusting.

Why it is built this way. Accepting a risk is a decision about treatment, not a statement that the weakness is gone. It remains a live exposure and continues to be reported as one. Closure is reserved for evidence-backed validation.

This mapping is configuration, not a fixed rule. Which statuses count as closed is set per deployment on the status master (Configurations → System). If a customer's counts behave differently from this table, check their configured statuses before anything else.

2. A finding must be approved before it counts¶

Open is not simply "not closed". A vulnerability is counted as open only when both are true:

its issue status is Approved, and
its client status is not a closed type (rule 1).

Findings still sitting at Saved or Submitted — uploaded or drafted, but not yet approved into the audit — appear in working lists but are absent from posture counts and dashboards.

What this looks like in practice: an analyst uploads a scan, sees 400 findings in the audit, and reports that the dashboard "lost" 60 of them. Those 60 are almost always awaiting approval.

3. SLA overdue is calculated live, never stored¶

Overdue status is evaluated at query time by comparing today's date against the vulnerability's SLA expiry date. Nothing is written to the record when an item breaches.

Three consequences worth knowing:

Items become overdue with no data change. A report run yesterday and the same report run today can differ with nobody touching anything. This is correct behaviour, and a frequent "the report changed by itself" ticket.
Overdue counts cannot be back-dated. Asking "how many were overdue last month" is not answerable from the live flag; it needs the historical tables.
A record with no SLA expiry date is never overdue. It is not counted as compliant either — it is simply outside SLA reporting. If a set of findings never appears in overdue figures, check whether they have an expiry date at all.

4. The "considered" gate can hide whole audits from posture¶

Each audit carries a considered on date. Findings from an audit that has not been stamped as considered can be excluded from posture reporting even though the audit and its findings are perfectly visible in their own module.

The stamp is applied only when both conditions hold:

Consider Only Final State Audits As Active (AppSec / API) is switched on (Configurations → System → System Settings). It is off by default, and
the audit is moved into a status marked as a final state.

So on a default deployment this gate is inactive and every audit contributes. On a deployment where it has been switched on, an audit sitting in Work in progress or Review Requested contributes nothing to posture until it reaches a final state.

Check this before investigating missing data

If a customer reports that a whole audit's findings are absent from dashboards while visible in the module, check this setting first. It is a one-line answer that otherwise costs hours.

5. Audit status closure is separate from vulnerability closure¶

Audit statuses carry their own closed type flag, set on the audit status master, and it is independent of vulnerability status. As shipped, Completed and Aborted are closed audit states; Not started, Work in progress, Hold, Review Requested, Changes Requested, Reverted, PMO Verified, Report Published, Requested and Approved are not.

Two independent notions of "closed" exist, and they do not imply one another:

Closing an audit does not close its vulnerabilities.
Closing every vulnerability does not close the audit.

Note in particular that Report Published and PMO Verified are not closed audit states. An audit whose report has been issued is still open as far as the platform is concerned.

6. Deleted records are hidden, not removed¶

Deleting a record marks it deleted and hides it from the lists rather than removing it. Anything still holding a reference to a deleted record continues to resolve it.

The practical consequence: a deleted asset, project or user can still be named on historical findings, in audit history, and in older reports. This is intended — deleting a record must not rewrite the past — but it does mean "I deleted it, why is it still showing" is expected behaviour on historical views.

Quick triage order¶

When counts do not reconcile, work down this list:

Are the "missing" rows Risk accepted / Duplicate / Not Applicable / Expired? → rule 1
Are they awaiting approval? → rule 2
Did the figure change with no data edit? → rule 3
Is a whole audit missing from posture? → rule 4
Is the customer conflating audit closure with vulnerability closure? → rule 5
Does a deleted record still appear on history? → rule 6