Compliance
The regulatory requirements Vulnerability Management supports, the evidence it produces, and which feature flags you need.
Vulnerability Management supports several regulatory requirements. The table shows how. The module provides evidence and controls but does not by itself make an organisation compliant.
Requirements and evidence
| Requirement | TENSOR feature | Evidence produced |
|---|---|---|
| DORA RTS Art. 10 (Delegated Regulation (EU) 2024/1774): vulnerability and patch management | Finding lifecycle with severity and CVSS; the CVE to patch to Change chain with per-CI outcomes. Scan-verified closure is Planned — not yet available. | DORA RTS Art. 10 remediation evidence report, sealed and hash-bound (started through the API today, not yet from a button) |
| DORA Art. 10: detection mechanisms | A CVE with CVSS of at least the tenant threshold (default 7.0) on a CI that supports a critical function emits a detection event into the reporting workflow | Detection event, Critical CVE evidence report |
| DORA Art. 5 / MaRisk AT 4.3.1 / historical BAIT 6: evidence and logging | One audit event per change in the same transaction; append-only, hash-chained log | Audit log with daily chain verification |
| MaRisk AT 4.3.1 / historical BAIT 5: segregation of duties | Change requester is not the approver; accepting the risk of a CVE exposure on a CI needs a co-signer other than the recorder. The same rule for vulnerability risk acceptance, derived from the audit chain, is Planned — not yet available. | Refused actions with SoD error; approval records |
| Historical BAIT 8 and 9: IT operations and changes | Patch deployment always runs as a governed Change with CAB, freeze windows and rollback plan | Change records linked to patches and CIs |
| ISO/IEC 27001 Annex A 8.8: management of technical vulnerabilities | CVE detection workflow and end-of-life risk register (assessed as partially implemented in TENSOR's own Statement of Applicability) | Findings, patch status, reports |
| GDPR Art. 5(1)(c): data minimisation | Raw plugin output, banners, paths or file bytes are never stored; only normalized, allowlisted fields and hashes are kept | Schema-level PII classification |
| BetrVG §87(1)(6): works council co-determination | List and detail views respect the view context, so Works Council views show masked identities; no individual employee ranking. Aggregated, pseudonymized program views are Planned — not yet available. | Masked Works Council projections |
Scope of RTS Art. 10
DORA RTS Art. 10 applies to entities under the full ICT risk-management framework (Title II). Entities under the simplified framework (DORA Art. 16(1)) fall under RTS Art. 34(d), which prescribes no scanning cadence. TENSOR does not present a Title II cadence as universal.
NIS-2
NIS-2 Art. 21(2)(e) (network and system security) is documented as largely outside platform scope, because the controls live in your infrastructure. TENSOR supports NIS-2 indirectly through incident handling, the audit trail and, with the compliance module, a framework catalogue that includes NIS-2 Art. 21(2).
DORA detection in practice
With cve_detection_ui and dora_detection_workflow on, recording a CVE with a CVSS score at or above the tenant threshold on a CI flagged as supporting a critical function raises a detection event into the DORA reporting workflow. The Critical CVE evidence report is the point-in-time snapshot of which CIs carry critical CVEs; the DORA RTS Art. 10 remediation evidence is the other half, showing 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.
Both 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.
For DORA incident classification, which is a separate capability, see Turn on DORA major-incident classification.
Segregation of duties in practice
- A patch Change follows the normal Change process: the requester cannot approve it, and freeze windows apply. See Approvals.
- On the CMDB CVE exposure page, a different person from the one who recorded the exposure must sign a risk acceptance. See CVEs and lifecycle risk.
- The platform-wide rules are listed in Segregation of duties.
Which flags you need
| To get | Switch on |
|---|---|
| The findings workspace | vulnerability_management (or cve_detection_ui, which implies it) |
| CVE recording on CIs | cve_detection_ui |
| DORA detection events and DORA RTS Art. 10 evidence | dora_detection_workflow |
| Known-issue handling for patches | patch_known_issues |
| Risk acceptance in the shared exceptions store | compliance_module (vulnerability risk acceptance itself is Planned — not yet available) |
The financial-services bundle of the sign-up wizard switches cve_detection_ui and the DORA flags on by default; the critical-infrastructure bundle switches on cve_detection_ui. See Sign-up bundles and the toggle catalogue.
Lifecycle
Finding states and dispositions, CVE exposure and patch states, how patch Changes flow, notifications and the end-to-end process per persona.
Guides for coordinators and operators
Step-by-step tasks for vulnerability coordinators, infrastructure and network administrators and change managers — findings, CVE exposures, patches and patch Changes.