Guides for administrators and compliance

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 approving or rejecting vulnerability risk acceptances and for running the evidence preflight are not included, because those capabilities are Planned — not yet available — see Availability.

Switch on vulnerability management for your tenant

Make the Vulnerabilities workspace available to your organisation.

Prerequisites: Tenant administrator with settings.featureflags.toggle.

1. Open Admin > Regulatory features.
2. Find vulnerability_management in the flag list and switch it on.
3. If you also need CVE recording on CIs, switch on cve_detection_ui; for DORA detection and evidence, switch on dora_detection_workflow.
4. Reload the page. Vulnerabilities now appears in the Assets & Risk group of the sidebar for users with read permission.

What happens next: All read and write paths of the workspace are available. With the flag off, the navigation entry disappears and the page shows Vulnerability management is not configured.

Important: cve_detection_ui and dora_detection_workflow become sticky once they have produced regulated records. Switching them off later requires a reason and a second approver.

Give a team access to vulnerability work

Let infrastructure staff triage findings and deploy patches.

Prerequisites: Tenant administrator with role management rights.

1. Open Admin > Roles and review the standard roles; for example Infrastructure admin already reads and triages findings.
2. If no standard role fits, clone the closest one into a custom role.
3. Add the required permissions, for example vulnerability.finding.triage for staff who triage findings or patch.deploy for staff who deploy patches.
4. Open Admin > Users, select the user and assign the role, or assign it to a group.

What happens next: The assignment is audited and the Platform Owner is notified. Users see the new actions after their next page load. Permissions tagged as compliance-relevant, such as report exports, need approval by a second administrator before they take effect.

Tip: The permissions for planned capabilities — imports, remediation groups, risk acceptance and manual closure — already exist. Keep request and approval of risk acceptances in different roles, as the standard roles do. See Roles and permissions.

Connect a vulnerability scanner

Let TENSOR pull assets and findings from Tenable.io, Qualys VMDR or Rapid7 InsightVM.

Prerequisites: Tenant administrator with integration.config.manage.

1. Open Workspace settings > Integrations and add the Tenable / Qualys / Rapid7 (Vulnerability Management) integration.
2. Select the vendor and enter the API credentials; they are stored as integration secrets.
3. Confirm the data residency of the scanner console. The default assumes a US-hosted SaaS console; pin an EU pod or on-premises console where available.
4. Test the connection and save.

What happens next: The integration pulls on its schedule. Assets are reconciled to CIs by FQDN, DNS name or MAC address; open findings with a CVE are recorded on the matched CI. When the closing Change ships, a non-destructive "remediated" status can be pushed back to the scanner.

An enabled scanner that is polled before it is fully wired reports a sync failure instead of a silent "nothing found".

Set up the known-issue feed

Get warned automatically when a vendor reports problems with a patch.

Prerequisites: patch.definition.manage; patch_known_issues is on.

1. Open Assets & Risk > Patches.
2. Scroll to Known-issue feed.
3. Enter the Feed URL (https) of your advisory feed.
4. Tick Check the feed every day.
5. Optionally tick Also send Standard changes back for a decision on "Caution".
6. Click Save feed settings.

What happens next: TENSOR checks the feed daily and shows Last checked or Last check failed with the error. Matching patches show Known issue or Caution in the list.

The feed is fetched through TENSOR's outbound request guard, so only https URLs to public hosts are accepted. The feed can use the documented JSON format or the Microsoft Windows release-health list.

Check a sealed evidence report

Confirm that a Critical CVE evidence or DORA RTS Art. 10 remediation evidence report has been generated and sealed.

Prerequisites: vulnerability.finding.read and reporting.run; for the DORA report also dora_detection_workflow.

1. Make sure the evidence report has been generated for the reporting period. The DORA RTS Art. 10 remediation evidence is started through the API, not yet from a button.
2. Open Reports > Reports.
3. In the History section, find the new entry.
4. Check that its state is Ready and note its Hash.

What happens next: The report is stored immutably, content-hashed and bound to the audit chain. Generating a DORA artifact makes the DORA flag sticky.

Compliance: The Critical CVE evidence is the detection half — which CIs carry critical CVEs. The DORA RTS Art. 10 remediation evidence shows, for every CVE on a CI, the patch, the Change, its approval and state, the per-CI outcome and the resulting CVE status. See Reporting and evidence.

Trace the history of a finding or patch

Show an auditor who did what, and when.

Prerequisites: A role with audit log access (Auditor, Compliance officer or Platform Owner).

1. Open Admin > Audit log.
2. Filter by entity type, for example vulnerability_finding, or by the patch.
3. Open the entries: creation, triage, CVE disposition changes and deployment outcomes each appear once.

What happens next: You see the complete, hash-chained history. Payloads contain IDs, states and counts; rationales stay in the record itself.