Findings, severity, and risk
A finding is one problem on one asset. It is the unit of work in the CyberOptix CTEM Platform: it has a severity, an owner, a status, and a lifecycle that ends in fixed or accepted.
Findings arrive from every part of the platform - network scans, web application tests, cloud posture checks, source code analysis, endpoint agents, breach data - and they all land in the same queue with the same shape. That is the point: you triage one list, not six.
Severity
Every finding carries one of five severities:
| Severity | Score range |
|---|---|
| Critical | 9.0 - 10.0 |
| High | 7.0 - 8.9 |
| Medium | 4.0 - 6.9 |
| Low | 0.1 - 3.9 |
| Informational | 0.0 |
Those bands are the standard CVSS v3 qualitative ratings, so a High here means what a High means anywhere else. A finding with a severity the platform does not recognise is counted as Informational rather than discarded - it stays visible, it just is not promoted.
Where the score comes from
This is the part worth understanding, because it differs by source and it explains apparent inconsistencies:
Network and web application findings take their score from the vulnerability test that produced them, which generally carries the published CVSS score for the CVE involved.
Cloud posture findings are different. A misconfiguration usually has no CVE, so each check carries a score assigned by whoever wrote it, reflecting how exposed that misconfiguration typically leaves you. An S3 bucket with no encryption is scored 7.0; a publicly reachable managed database is 9.0.
Endpoint findings carry the severity the EDR vendor assigned.
Identity exposure is not scored this way at all. A breached credential is not more or less severe by CVSS; what matters is whether it is still valid.
Cloud posture findings display a CVSS vector alongside the score. Treat it as context for why a check is scored the way it is, not as the derivation of the score - the score is assigned directly, and the vector is descriptive. Where the two appear to disagree, the score is what determined the severity band and what sorting and SLAs act on.
Severity is not priority
Severity describes the problem. It knows nothing about your environment, and on its own it is a poor work queue.
A Critical on a decommissioned test box matters less than a High on the server holding your customer data. The platform gives you the things severity lacks:
- Business units scope a finding to the part of the organization that owns the asset, so it reaches the people who can act on it. See Organizations, business units, and zones.
- Zones say where an asset sits on the network, which is often a better proxy for exposure than severity.
- Tags carry whatever else you need to sort by - environment, owner, compliance scope.
- Remediation SLAs turn severity into a deadline, which is what actually drives work. See Remediation and SLAs.
The useful question is rarely "what is Critical?" but "what is Critical, internet-facing, and in production?" - and that is a question only severity plus context can answer.
Lifecycle
A finding moves through statuses rather than being deleted, and they fall into three groups. The group is what reporting and filtering act on.
Pending - not yet confirmed as real work.
| Status | Meaning |
|---|---|
| Pending Validation | Raised, awaiting confirmation |
Open - live work. Everything here counts as outstanding.
| Status | Meaning |
|---|---|
| Open | Confirmed, not yet being worked |
| Remediation In Planning | A fix is being worked out |
| Remediation Scheduled | A fix has a date |
| Remediation In Progress | Being fixed now |
| Awaiting Approval | The fix needs sign-off |
| Pending Retest | Fixed, awaiting confirmation by a scan |
| Risk Accepted Requested | Acceptance proposed, not yet approved |
| Risk Acceptance Approved | Acceptance approved |
Closed - no longer live.
| Status | Meaning |
|---|---|
| Closed | Resolved and confirmed |
| Archived | The asset was archived at its source, so this can never be retested |
False Positive sits outside all three. It is terminal - nothing moves it on - but it is deliberately not grouped with Closed, because nothing was resolved.
Risk Acceptance Approved is an open status, and SLA due dates are computed from when a finding was opened regardless of its status. An approved acceptance keeps its due date and keeps accruing overdue days.
If your overdue count is higher than the work you believe is outstanding, accepted risks are the usual reason. Filter them out explicitly rather than assuming acceptance removed them.
Archived is worth understanding separately: it is set by the platform, never by a person. The asset the finding was raised against 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.
Nothing here removes a finding. A finding that disappears is indistinguishable from one nobody noticed, so nothing is silently dropped.
Findings and vulnerabilities
The two words are not interchangeable:
- A vulnerability is a class of problem - a CVE, a misconfiguration type. It exists independently of you.
- A finding is one instance of one vulnerability on one of your assets.
One vulnerability affecting forty hosts produces forty findings. That is deliberate: each one is fixed, accepted, or waived on its own, because the forty hosts are not necessarily the same answer.
Next
- Assets - what a finding attaches to
- Remediation and SLAs - turning severity into a deadline
- Findings and triage - working the queue