Skip to content

The two status fields, and why findings disappear

More tickets come from this one design point than from anything else in the product, because two different fields are both called "status" in conversation and they answer different questions.

They are not the same field

Every finding carries two independent statuses:

Question it answers Owned by
Validation status Is this finding genuine and agreed? The security team
Client status What is being done about it? The asset owner

A finding has both at all times. Neither is derived from the other, and changing one does not change the other.

Validation status moves through Saved → Submitted → Approved, with Closed and False Positive as terminal outcomes. Those five are the whole set. A finding is not visible outside its audit until it is approved.

Client status covers remediation and has fourteen values: New, To be patched, Patch in progress, Patched, Not Patched, On hold, Reopen, Validated, Not Applicable, Risk accepted, Risk acceptance, Duplicate, Exception Handled, Expired.

Only Validated and Exception Handled are flagged as closed in the product. Everything else — Patched included — is still counted as an open finding, which surprises people who have just marked a batch as patched and seen no movement in the totals.

The consequence people hit

A finding that exists is not necessarily counted

Dashboards, SLA clocks and posture counts consider approved findings. A finding that has been imported and is visible inside its audit but is still Submitted will not appear in any of them.

So "the dashboard is missing findings I can see in the audit" is almost always approval status — not a data loss, a caching problem, or a filter.

This is deliberate. It stops an unreviewed scanner export from moving the numbers a board sees. But it is invisible from the dashboard end, which is why it generates tickets.

The three questions that resolve most of these

  1. Is the finding approved? If not, it is working as designed. The remedy is review, not a bug report.
  2. Is the audit considered? An audit can be excluded from counting entirely. Its findings then exist, are approved, and still do not appear in aggregate figures.
  3. Is the client status one that counts as open? Risk Accepted and Not Applicable findings are not closed — they are open findings deliberately not being fixed, and different screens treat them differently.

Work through them in that order. The first two account for most cases.

Re-opening, and what it does to the SLA

A finding closed and then seen again by a later scan is re-opened rather than created fresh. It keeps its identity and its history, which is what you want for audit purposes.

The corner case worth knowing: re-opening sets a new discovery date but does not always reset the SLA expiry. A finding can therefore show as discovered today and overdue at the same time — an apparent contradiction that is really two fields updated on different schedules. Treat the discovery date as "last seen", not "first seen", and read the SLA from the expiry date rather than inferring it from the age.

Why a count differs between two screens

When a module screen and the analytics dashboard disagree, it is one of four things, in descending order of likelihood:

  1. Approval. The module screen shows unapproved findings; aggregate views do not.
  2. Considered. An excluded audit is visible in its module and absent from totals.
  3. Timing. Analytics is served from a synchronised copy of the data. A gap between the two is a sync interval, not a discrepancy — the Warehouse Sync screen shows when the copy was last refreshed.
  4. Scope. The two screens are filtered differently. Asset-owner accounts see only their own assets, so the same screen shows different totals to different people, both correct.

Checking them in that order is faster than comparing row by row.