NIS2 Effectiveness Dashboard

Audience: telemetry operators, compliance owners, and implementers wiring NIS2 effectiveness views.

Status: sprint 060/062 implementation contract. Runtime emission, the Platform read endpoint, and the offline Grafana JSON are available; Console rendering remains owned by sprint 062.

Purpose

The NIS2 effectiveness dashboard maps Stella telemetry and tenant-supplied evidence to the 13 thematic areas used by the NIS2 closure plan. It is an operator-facing aid for customers that are responsible for their own NIS2 obligations. Stella provides defaults, telemetry, evidence links, and export mechanics; the customer/operator owns applicability decisions, overrides, legal conclusions, and regulator submissions.

Primary inputs:

• KPI catalogue: NIS2 KPI Catalog.
• Default target YAML: nis2-kpi-targets-defaults.yaml.
• Control-register authoring guide: NIS2 Control Register.
• Control templates: NIS2 control templates.
• Telemetry architecture: Telemetry architecture.

Current Integration State

As of sprint 062 N3-062-2 completion on 2026-04-30, Telemetry Core has the NIS2 KPI catalog, the deterministic reporting primitive (INis2AreaMetricsService.GetAreaReportAsync), and the live threshold-crossing evaluator. Platform WebService exposes the tenant-scoped dashboard snapshot endpoint that the Console client is prepared to call:

GET /api/telemetry/nis2/effectiveness?tenantId=<tenantId>&window=<window>

The endpoint returns a tenant-scoped nis2-effectiveness-dashboard-v1 payload containing tenantId, generatedAt, rollingWindow, 13 ordered areas, KPI metrics, target/override metadata, linked controls, optional targetDocumentHash, optional controlRegisterSnapshotHash, and any live blockers.

Live KPI observations recorded through INis2AreaMetricsService.RecordMeasurementAsync are classified against the catalog effective target bands. The evaluator emits a breach on the first warning or critical crossing for a tenant/control/KPI series, emits again on warning-to-critical escalation, and resets after an OK observation.

Grafana import is offline-compatible through the Offline Kit path telemetry/dashboards/nis2-effectiveness-dashboard.json. The source JSON lives at docs/modules/telemetry/operations/dashboards/nis2-effectiveness-dashboard.json and is inventoried in manifest/offline-manifest.json during OUK packaging.

Federated sharing is opt-in via the existing Federated Telemetry consent lifecycle. NIS2 KPI measurements stay local unless an administrator grants federation consent and FederatedTelemetry.SealedModeEnabled is false; v1 does not add a second NIS2-only federation config surface.

Configuration Contract

Defaults load under platform.nis2.targets. The effective target for a tenant is resolved in this order:

1. Stella default from platform.nis2.targets.areas.<areaNumber>.kpis.<kpiKey>.
2. Tenant override from platform.nis2.targets.tenantOverrides.<tenantId>.areas.<areaNumber>.kpis.<kpiKey>.
3. Runtime fallback state unknown if neither a target nor a valid evidence source is available.

Tenant overrides are sparse. They may change thresholds and review cadence, but they must carry audit metadata:

• owner
• reason
• effectiveFrom
• nextReview
• previousValueHash
• newValueHash
• approvedBy

The dashboard must show that an override is active and must preserve both the default and effective target in exports.

Metric Contract

Metric names follow the sprint 060 convention:

nis2_area_<areaNumber>_<metric_slug>_<unit>

Required labels:

Forbidden label content: personal data, secrets, credential material, expanded human-actor details, regulator portal credentials, or unredacted incident descriptions.

Dashboard Layout

The dashboard contains one card per thematic area. Each area card should show:

• area number, label, responsible role, and evidence mode;
• worst current KPI state across the area’s KPIs: healthy, warning, critical, or unknown;
• effective target, default target, and active override indicator;
• latest observed value, rolling window, and trend;
• linked control id and evidence refs;
• next review date and stale-evidence state.

Area state is computed from KPI states:

Areas 8, 10, and 13 must be visibly marked tenant-supplied. The UI should show attestation freshness and review state for those areas without implying Stella operates customer training, HR, or physical-security controls.

Evidence Handling

Evidence modes come from the defaults file and the control templates:

Evidence refs must be replayable offline. For monthly exports, include refs rather than copying mutable evidence content into the dashboard payload.

Alerting

Crossing a configured threshold emits the Notify event nis2.effectiveness.threshold_breached with payload schema nis2-effectiveness-threshold-breach-v1. Platform registers AddNis2EffectivenessNotifyThresholdEmitter and enqueues the event through the configured Notify queue (notify:queue). Outside Testing or the explicit development local harness (Platform:Nis2:ThresholdAlerts:UseLocalHarness=true), Platform fails closed if the Notify queue is not configured.

The alert is routed to role:<responsibleRole> using the NIS2 responsible-role default for the area until the N1 control-register snapshot is live. The payload includes:

• tenant id;
• area number and control id;
• KPI key and metric name;
• observed value, target, and threshold state;
• evidence mode and latest evidence ref;
• default target hash and override hash, if any.

If the source measurement omits an evidence ref, Telemetry uses a deterministic telemetry://nis2/effectiveness/... fallback ref derived from tenant, area, control, KPI, and observation time. Target override hashes and control-register snapshot hashes remain nullable in v1 until the downstream N1 target/control-register sources are available.

The alert must not include personal data, secret material, or regulator-channel credentials.

Monthly Effectiveness Export

The planned stella export nis2-effectiveness --month <yyyy-mm> bundle should include:

• effective target document hash;
• tenant override hashes and audit metadata;
• all area KPI values, threshold states, evidence refs, and review cadences;
• linked control-register snapshot hash;
• dashboard schema version;
• signer, generated-at timestamp, and payload hash.

Exports must be deterministic for the same frozen inputs and must be usable in sealed or air-gapped environments without live external endpoints.

Offline Kit Expectations

Offline deployments need the same operator experience as online deployments:

• ship the defaults YAML with Offline Kit runtime assets;
• ship Grafana dashboard JSON at telemetry/dashboards/nis2-effectiveness-dashboard.json in the Offline Kit;
• ship any alert rules and sample Prometheus fixtures in-repo;
• allow replay from frozen telemetry and tenant evidence refs;
• avoid live ENISA, NCA, SaaS, or regulator endpoint dependencies during tests.

Implementation Notes For Sprint 060 And 062

• Sprint 060 should emit one to three metrics per area using the names in the KPI catalogue.
• Sprint 062 should render tenant overrides and evidence modes explicitly.
• The dashboard should consume the shared Policy control register, not duplicate control ownership or applicability logic.
• The asset-management area must consume the shared asset registry once sprint 070 lands.
• The incident-handling area must consume the shared reporting timeline once sprint 050 lands.