Compliance
The regulatory requirements Discovery provides evidence for, the evidence it produces, and the feature flags each piece needs.
Discovery supports your regulatory obligations by producing evidence about the accuracy of your ICT asset inventory. It does not by itself make you compliant. The mappings below are the ones documented in TENSOR's compliance mapping and control crosswalk.
Preview module
Discovery has been tested with simulated data only, and several of the evidence sources below are partially available. Read the status column and Availability before you present any figure to an auditor.
Requirement mapping
| Requirement | TENSOR feature | Evidence produced | Current status |
|---|---|---|---|
| DORA Art. 8 (identification of ICT assets) and NIS-2 asset inventory | Discovery sources reconciled into the CMDB; independent verification | Attestation with verified, stale and single-sourced figures per class; sealed artifact | Attestation and sealing are available. Independent verification is partially available: confirmations are not yet written by the sweep, so the attestation shows no verified CIs. |
| DORA Art. 8(1), MaRisk AT 7.2, BAIT 4 (provenance): K4 Soll/Ist comparison | Deviations against verified discovery sources | Deviation records with owner, decision and reason; MTTR in the attestation | Deviations with SLA and decision dialog are available. The K4 control is kept at roadmap — see below. |
| DORA Art. 10 (detection) and RTS Art. 10 (vulnerability management) | Scanner findings and CVE correlation recorded on CIs | CVE entries with audit rows; detection event for critical CVEs on critical-function CIs | Scanner findings are recorded as CVEs today. CVE correlation from installed software is built and tested but not yet scheduled in the sweep. |
| DORA Art. 8 (EoL/EoS on critical functions) | End-of-life enrichment of CI lifecycle dates | Lifecycle facts with feed evidence; risk-register entries from the daily check | End-of-life enrichment is built and tested but not yet scheduled in the sweep. |
| DORA Art. 5 / audit trail expectations | Hash-chained audit events for every discovery mutation | Tamper-evident audit log, append-only verification evidence | Available. |
| DSGVO (GDPR) data minimisation and residency | PII tagging, EU feed mirror, residency and region acknowledgements; works council package for the collector | Recorded acknowledgements; PII-free audit payloads | PII tagging, the EU feed mirror and integration residency acknowledgements are available. The cloud region acknowledgement register records acknowledgements but does not yet enforce them before the first pull. The works council package is planned — not yet available. |
Which flags you need
All of the above requires the discovery_sources flag. In addition:
| Evidence | Extra flag |
|---|---|
| CVE recording from scanner findings, and CVE correlation | cve_detection_ui |
| End-of-life enrichment and the daily EoL/EoS risk check | eol_eos_risk_register |
| On-premises collector enrollment and heartbeat | discovery_collectors |
| Integration adapters still marked Preview | integrations_preview |
cve_detection_ui and eol_eos_risk_register depend on your bundle; the others are off by default. See the toggle catalog and, for how CVEs and lifecycle dates behave once recorded, CVEs and lifecycle risk.
K4 stays at roadmap until your pilot is complete
TENSOR's own control crosswalk keeps the K4 Soll/Ist control at roadmap until at least one live discovery source has been verified against a real estate. Do not present K4 figures to an auditor before your pilot is complete.
Controls that protect the evidence
The evidence is only worth something if the people it measures cannot shape it. Discovery enforces this in code:
- Auditors attest, they do not control. The auditor role can read the attestation, the deviation queue, per-CI verification and the absence queue, but is never granted export, verification-policy or deviation-decision rights.
- The verification window needs two people. A new verification policy must be approved by someone other than the person who records it.
- A widened window is visible. The attestation shows coverage at both the effective and the seeded default window, and the denominator policy states whether the window was ever changed.
- Open deviations reduce the verified count. A CI with an open deviation is excluded from the verified count, however recently it was confirmed.
- Deviations cannot be reset. Resolved and dismissed deviations cannot be reopened; a persisting disagreement opens a new deviation with its own detection time, so breach history and MTTR stand.
- Sealed means sealed. A sealed attestation is an immutable, hash-chained artifact. A later report supersedes it; the sealed one stays on record.
- The flag cannot be switched off quietly. After the first sealed attestation, switching
discovery_sourcesoff needs a dual-approval request; the requester cannot approve it. - Every mutation is audited. Each discovery mutation writes exactly one hash-chained audit event in the same transaction. Audit payloads carry structural facts only, not discovered values.
The roles behind these rules are in Roles and permissions; the platform-wide rules are in Segregation of duties.
Use the right verb
When you describe Discovery to auditors, say it supports or provides evidence for a requirement. It does not fulfil or guarantee any regulation.
Lifecycle and processes
States and transitions for discovery sources, runs, deviations and tombstone candidates, SLA handling, and the end-to-end sequence for each persona.
Guides for administrators
Step-by-step procedures for tenant and CMDB administrators — switching Discovery on, connecting and commissioning sources, handling runs and granting access.