Findings and triage
Findings is where the work is. Everything the CyberOptix CTEM Platform discovers - network scans, web application tests, cloud posture checks, source analysis, endpoint agents - lands in one queue with one shape, so you triage a single list rather than six.
If you have not read Findings, severity, and risk, start there. This page assumes it.
What to do first
Sorting by severity and starting at the top is the obvious approach and the wrong one. Severity describes the flaw; it knows nothing about your environment. A Critical on a decommissioned test box matters less than a High on the server holding customer data.
A better first pass, in order:
- Overdue against SLA. These already breached a deadline you set. Note that accepted risks appear here too - see below.
- Critical or High, internet-facing, exploitable. Severity plus exposure plus a known exploit is the combination that actually gets used.
- Anything on an asset you did not expect to exist. Unknown infrastructure is a finding in itself.
- Everything else, by severity.
The filters that make this possible are business unit, zone, tag, severity, status and asset. The useful question is never "what is Critical?" but "what is Critical, in production, reachable from outside?"
SCREENSHOT: the findings queue with the filter bar in use.
Assignment
A finding with no owner is a finding nobody is working on.
Assign to a person, and use business units to make the queue navigable for them - a team that sees only its own findings acts on them; a team that sees the whole estate filters past them. See Organizations, business units, and zones.
Moving a finding through its statuses
The statuses exist to distinguish states that look identical in a simple open/closed model but mean very different things operationally:
| You are | Status |
|---|---|
| Still deciding how to fix it | Remediation In Planning |
| Committed to a date | Remediation Scheduled |
| Doing it now | Remediation In Progress |
| Waiting on a change approval | Awaiting Approval |
| Done, waiting for a scan to confirm | Pending Retest |
The distinction that earns its keep is Scheduled versus In Planning. "We will fix this in next month's maintenance window" and "we do not yet know how to fix this" are both "not fixed", and only one of them needs a conversation.
Pending Retest matters because a fix is not confirmed until something checks. A finding closes when a subsequent scan stops seeing it, not when someone says it is done.
Risk acceptance
Some findings will not be fixed, and saying so explicitly is better than leaving them open forever. Requesting acceptance moves a finding to Risk Accepted Requested; approval moves it to Risk Acceptance Approved.
Both acceptance statuses are in the open group, and SLA due dates are computed from when a finding was opened without regard to status. An approved acceptance keeps its due date and keeps accruing overdue days.
That is worth knowing before you use acceptance to bring an overdue count down, because it will not. Filter on status explicitly instead.
What acceptance does buy you is a recorded decision with a name against it. The difference between an accepted finding and a forgotten one is exactly that.
False positives
Marking a finding as a false positive is terminal - nothing moves it on. It is deliberately not grouped with Closed, because nothing was resolved.
Use it when the finding is genuinely wrong, not when it is inconvenient. A false positive is a statement about the detection; an accepted risk is a statement about your tolerance. Conflating them makes the first useless as a signal.
Archived findings
Archived is set by the platform, never by a person. The asset no longer exists at its source, so the finding can neither be fixed nor retested.
It is distinct from Closed on purpose. Nobody resolved anything - the question simply became unanswerable, usually because a cloud resource was deleted. If you are auditing what happened to a finding, Archived means "the thing it was about went away", which is a different answer from "we fixed it".
One vulnerability, many findings
A vulnerability affecting forty hosts produces forty findings, because each is fixed, accepted or waived on its own.
When that is genuinely one piece of work, the grouping and bulk actions in the queue are what you want, rather than forty visits.
API
The endpoints behind this section are in the API reference.
Next
- Remediation - the work queue and templates
- Remediation and SLAs - how deadlines are set