Network Security: support reference

Internal. The customer-facing explanation of these screens is in Reading the Network Security screens and the screen reference. This page is what you need in addition to those when handling a ticket.

Network VA carries the highest finding volumes in the platform, so almost everything here is a consequence of scale: queued processing, pre-computed counts, and identity decided at import.

Controls that depend on permission, not on state

A caller reporting "the button isn't there" is usually describing a permission, and the product does not say so — a control the role cannot use is absent rather than disabled.

Control	Needs
Approve / reject a finding	The approval permission for the module
Edit vulnerability master details	Master-data permission, separate from editing the finding
Delete an audit or finding	Delete permission, granted separately from edit
Export	Export permission — a role can read a screen and not export it
Bulk status change	The same approval permission, plus the checkbox column

Before investigating a missing action as a defect, have the caller read out what they can see on the row menu, and compare it against their role.

Status transitions

An audit's status dropdown offers only the transitions legal from its current state, and only those the caller's role may perform. A missing option is one of those two things.

Changing status opens a confirmation dialog rather than applying immediately. It states the audit, the transition, and whether a comment is required — which is a property of the target status, not of the screen. Comments accept letters, numbers and _ - . & up to 5000 characters, so text pasted from a ticketing system is often rejected for characters rather than length.

Counting rules

These four decide almost every "the numbers are wrong" ticket:

1. A finding is not counted until it is approved. Discovered On is blank before approval for the same reason.
2. Only considered audits reach dashboards and reports. The module screens show everything; the dashboards do not.
3. An audit counts on the date it reached a final state, not the date it was created or the date the scan ran.
4. Only two statuses close a finding. Everything else — including Risk accepted — still counts as open. See platform limitations.

Asynchronous processing

Uploads and syncs are queued. The Data Process column on the audit list shows how far a tool-fed audit has got, and it is the difference between "upload finished" and "data available".

A count that changes each time the caller refreshes is still processing. A count that has been static and wrong is not — check the queue for a failed job before assuming the data is bad.

Identity, and why counts jump

VA findings are matched either by the scanner's own identifier or by a composite key built from columns you configure. Changing that configuration redefines what "the same finding" means: existing findings stop matching, so they stay open with no new sightings while fresh copies arrive with no history, and totals appear to double.

Full detail, including the coercion rules that can collapse two findings into one, is in how findings are identified on import.

Deletion

Deleting an audit or a finding hides it; it does not remove it. A deleted audit's name still appears on historical findings and on reports already generated. That is the design, and it is the answer to "I deleted it but it is still in the report".

What to collect before escalating

1. The audit ID and the client, not just the audit name — names repeat across clients.
2. Whether the audit is considered, and the date it reached a final state.
3. The Data Process state, and whether any queue job for it failed.
4. For count disputes: the same number from two places — the module screen and the dashboard — because the difference between them is usually the answer rather than the problem.
5. For import disputes: the source file, and whether the key configuration changed since the previous import.