Guides for coordinators and operators

Each guide lists its purpose, the permission you need, the steps and what happens afterwards. Labels in bold are the texts you see in the product. Guides for importing Nessus files, resolving asset matches, planning remediation groups, requesting risk acceptance and closing findings without scan proof are not included, because those capabilities are Planned — not yet available — see Availability.

Find and open findings

Get an overview of open weaknesses and inspect one in detail.

Prerequisites: vulnerability.finding.read.

1. Open Assets & Risk > Vulnerabilities.
2. Scan the list Vulnerability findings: Severity and State are colour-coded, Due shows the deadline.
3. Click Load more at the end of the list to load the next page.
4. Click a finding title to open its detail page.
5. Check Source identity, Source asset, Port, Protocol, Recorded by and First seen.
6. Use Back to findings to return to the list.

What happens next: Nothing changes; reading is not audited as a change.

If the page says No vulnerability findings, nothing has been recorded yet. If you see an access message instead, you are missing vulnerability.finding.read. The list page does not yet offer filter controls; filtering by state and severity and text search exist in the API only.

Record a manual finding

Track a weakness that did not come from a scanner, for example from a penetration test.

Prerequisites: vulnerability.finding.triage.

1. Open Assets & Risk > Vulnerabilities.
2. Click Record manual finding.
3. In Finding, enter a short, descriptive title.
4. In Source asset key, enter a stable identifier of the affected asset, for example its host name or asset tag.
5. In Source finding key, enter a stable identifier of the weakness, for example the test report item number.
6. In References (comma-separated), enter CVE IDs or other references, for example CVE-2026-1234, CVE-2026-5678.
7. Select the Severity.
8. Click Record finding.

What happens next: The finding appears in the list with state New and one audit event is written. If the same source asset key and finding key already exist, TENSOR opens the existing finding instead of creating a duplicate. The CI link and CVSS score can be set through the API only.

Tip: Use keys that will not change. A title can be improved later; the source keys form the finding's identity.

Triage a finding

Confirm that a new finding is real work.

Prerequisites: vulnerability.finding.triage; the finding is in state New.

1. Open the finding from Assets & Risk > Vulnerabilities.
2. Review severity, references and the affected asset.
3. Click Triage finding.

What happens next: The state changes to Triaged and one audit event is written. Recording a due date and the policy inputs used at triage is Planned — not yet available.

Important: If someone else changed the finding while you were looking at it, TENSOR refuses the action with "The finding changed. Refresh and retry." Reload the page and check the new state before trying again.

Review vulnerabilities and suggested patches on a CI

See which CVEs affect one asset and which patches close them.

Prerequisites: cmdb.cve.read and patch.status.read.

1. Open Assets & Risk > Configuration Items and open the CI.
2. Scroll to the CVEs panel. Each entry shows the CVE ID, CVSS score and status.
3. Under Suggested patches, check the catalogue patches that close the CVE.
4. Click a patch to open its detail page, or click the CVE ID to open the CVE exposure view.

What happens next: You have the asset view of the exposure. The impact view of the CI also shows the number of Open CVEs.

Record a CVE exposure on a CI

Note that a known CVE affects a specific CI.

Prerequisites: cmdb.cve.record; cve_detection_ui is on.

1. Open Assets & Risk > Configuration Items and open the CI.
2. In the CVEs panel, click Record an exposure.
3. Enter the CVE ID in the form CVE-2026-1234 and the CVSS score between 0 and 10.
4. Click Record.

What happens next: The exposure is stored with status Open and you are taken to the CVE exposure list. If the CI supports a critical function and the CVSS score reaches the threshold, a DORA detection event is raised (with dora_detection_workflow).

If the CVE is already recorded on that CI, TENSOR shows That CVE is already recorded on this CI.

Set the disposition of a CVE exposure

Record that a CVE on a CI is mitigated, accept its risk, or reopen it.

Prerequisites: cmdb.cve.record. Accepting risk requires a person other than the one who recorded the exposure.

1. Open the CVE from the CI's CVEs panel. The page CVE disposition lists each affected CI separately.
2. In Justification or notes, record the rationale.
3. Click Mark mitigated if a fix or compensating control is in place, or Reopen to return a mitigated exposure to Open.
4. To accept the risk, click Accept risk, read the warning and confirm. The page shows Risk accepted by afterwards.

What happens next: The disposition and its time are recorded per CI and audited.

Important: On this CMDB page a risk acceptance is final and cannot be revoked. Time-bounded, revocable risk acceptance in the Vulnerabilities workspace is Planned — not yet available.

Find the right patch in the catalogue

Check which patches exist for a vendor, product or CVE and how widely they are installed.

Prerequisites: patch.definition.read.

1. Open Assets & Risk > Patches.
2. Use the Severity, Vendor and CVE filters or type in Search (vendor or product).
3. Sort by release date or severity.
4. Check Adoption % and Missing CIs. Not assessed means no CI has been assessed against this patch yet.
5. Click a patch to open Patch details with CVE references, KB article and CI deployment status.
6. Click Show missing CIs to list the CIs that still need it.

What happens next: You know the patch, its reach and the CIs still exposed.

Tip: If an old filter value no longer exists, TENSOR ignores it and tells you which values were ignored. Use Clear filters to start over.

Deploy a patch as a Change

Create the governed Change that rolls a patch out to every CI that is missing it.

Prerequisites: patch.deploy; at least one CI has the patch status Missing.

1. Open Assets & Risk > Patches and open the patch.
2. Click Deploy patch.
3. Read the confirmation Deploy patch as a Change request? and confirm.
4. Note the Change number in the message Change request created., which also shows how many CIs are affected.
5. Open the Change under Service desk > Changes and complete planning and scheduling as for any Normal Change.

What happens next: The Change is submitted to the regular approval process with all affected CIs, a description from the patch and a rollback plan. The patch status of each CI records the deploying Change.

If no CI is missing the patch, TENSOR shows No missing CIs to deploy this patch to. An Emergency Change is only created when it is explicitly requested.

Record deployment outcomes per CI

Report for each CI whether the patch was installed.

Prerequisites: patch.deploy; the Change was created from a patch.

1. Open the Change under Service desk > Changes.
2. Scroll to Patch deployment outcomes.
3. For each CI, choose Installed, Failed or Deferred in Outcome.
4. For a failed installation, enter the Failure reason.
5. Click Save outcome.

What happens next: The patch status of each CI is updated and adoption figures change accordingly. Failed CIs keep the patch as Failed with the reason.

Important: An installed patch is not proof that the weakness is gone. Closing findings only after a later covering scan confirms the fix is Planned — not yet available.

Decide on a Change flagged with a known issue

Decide whether a pending patch deployment goes ahead after a vendor reported a problem.

Prerequisites: Change manager or CAB member.

1. Open the Change from your notification or under Service desk > Changes.
2. Read the banner Known issue on a patch this change deploys and open the advisory with Open the advisory.
3. If the Change was a pre-authorized Standard Change, note that it has returned for a decision as a Normal Change.
4. Approve, reschedule or reject the Change through the normal CAB decision.

What happens next: Your decision is recorded on the Change with the usual audit trail. A later withdrawal of the advisory clears the patch mark but does not re-approve the Change. See Changes and Approvals for the CAB process.