NIS2 Asset Visibility for Energy and Telecom in Madrid
A Madrid grid operator learns of a substation gateway failure at 06:40. The telecom carrier supporting its telemetry path reports no incident on its side. The operator opens three inventories. The OT register shows the gateway. The IT register shows the server. Neither shows the link between them. NIS2 asset visibility for Madrid energy and telecom critical infrastructure fails exactly here, in the gap between two accurate lists.
Each operator holds strong local records. The shared dependency between energy control and telecom transport has no joint owner. This article shows how to build NIS2-ready visibility from discovery-sourced data, so both sectors prove what they hold and how it connects. See how enterprise teams establish Trusted Runtime Truth as the shared evidence layer under critical operations.
Why NIS2 treats energy and telecom visibility as one problem
NIS2 names both energy and digital infrastructure as essential sectors with risk management and incident duties. The European Commission confirms the directive covers energy plus digital infrastructure providers in its NIS2 directive overview. Member states had until 17 October 2024 to transpose it into national law.
The legal text places these duties on essential and important entities together. Read the binding source in the NIS2 Directive 2022/2555. The same directive sets fines of up to EUR 10 million or 2 percent of global annual turnover for essential entities, whichever amount is higher. Those fines apply when risk management evidence does not hold up.
Madrid concentrates the overlap. National control centers, carrier hubs, and data centers share buildings, power feeds, and fiber paths across the capital. A single cabinet can carry grid telemetry and carrier routing side by side.
When each sector proves only its own side, three gaps open. Grid SCADA gateways carry one owner. Carrier transport nodes carry another. The enterprise IT joining them often carries a third. An incident spanning all three then needs three evidence packs. The regulator reads one event.
Closing that gap before an incident, not during one, is the same discipline behind Improve your incident response process with service mapping.
Why do energy and telecom need shared NIS2 asset visibility?
Energy control depends on telecom transport for telemetry, dispatch, and restoration. Telecom sites depend on grid power for uptime. Shared visibility maps each dependency once, so incident evidence names the full chain instead of two disconnected halves.
What NIS2 asset visibility must prove in Madrid
NIS2 evidence rests on three proofs. Prove the inventory is complete. Prove each asset links to its service and owner. Prove the record stays current through scheduled verification.
Prove completeness: NIS2 asset inventory for energy and telecom
A complete NIS2 asset inventory joins substation gateways, historians, and control servers from grid operators with the enterprise IT behind them. Telecom operators must join core routers, aggregation nodes, and management platforms with supporting IT. Shared sites need one record per asset with a stated sector owner. Unowned assets need a named remediation owner, not a blank field.
A September 2026 Honeywell benchmark study of more than 600 OT cybersecurity, compliance, and operations leaders found that only 21 percent maintain a complete inventory of their OT assets. Yet 88 percent rated their own OT security programs as mature. That gap between perceived maturity and actual inventory completeness is exactly what NIS2 evidence requests expose first.
Prove service linkage for incident reporting
ENISA technical guidance frames risk management around identified assets and their users and dependencies. The current guidance sits in the ENISA implementation guidance. Apply that frame to Madrid operations: each telemetry path, dispatch service, and restoration workflow needs a named asset set behind it.
An evidence pack built this way lists:
- The telemetry path’s name
- Its grid and carrier asset IDs
- The owning teams on each side
- The date each entry was last verified
Incident reports then cite the service and its assets together.
Prove freshness: discovery-sourced NIS2 evidence on a schedule
Evidence holds value only when verification dates stay recent. Virima reconciles multi-source discovery into one authoritative configuration item (CI) record with source tags and last-verified dates — the foundation of discovery-sourced NIS2 evidence rather than a manually assembled snapshot. Scheduled cycles refresh the record.
Manual entries stay fenced behind review. Freshness becomes a timetable, not a claim. Keeping that timetable visible is the same practice that keeps license and compliance audits from turning into fire drills, a pattern covered in Before You Run AI Agents on ServiceNow, Answer These 5 Questions About Your CMDB.
Grid systems, carrier systems, and enterprise IT belong in one map
The fix is not a larger spreadsheet. It is one ViVID™ service map with three node types, each fed by scheduled discovery and each tied to a named essential service.
What each node contributes
Discovery feeds three node types onto the map:
- Energy nodes — SCADA gateways, historians, dispatch servers, and substation links
- Telecom nodes — core and aggregation routers, transmission gear, and network management systems
- Enterprise IT nodes — identity servers, patch systems, backup targets, and monitoring platforms
Discovery finds the infrastructure. Service definitions name which pieces form one essential service.
How the map supports joint response
When a telemetry path degrades, the responder opens the service map and traces the failing CI to affected grid zones and carrier segments. Ownership shows on the same screen. Both operators brief from one record — the same shared view that functions as the critical infrastructure CMDB Madrid teams can audit directly, instead of reassembling it from three separate systems. That path from failing CI to affected service is the core behavior to demand from any CMDB platform.
The same map answers a second NIS2 duty before it becomes an incident. When a change request touches a shared cabinet or fiber path, reviewers can check which grid zones and carrier segments sit downstream before approving it, not after.
Which assets belong in the first NIS2 visibility map?
Start with one telemetry path: grid gateways, carrier transport nodes, and enterprise identity and monitoring behind them. Add dispatch and restoration services once the first path holds. Narrow scope proves completeness faster than estate-wide collection.
Feed NIS2 evidence into the ITSM you already run
NIS2 visibility earns trust when it shows up inside daily ITSM work. Problem records reference the same service definition that evidence packs cite, so tickets stay linked to one authoritative CI instead of accumulating conflicting manual edits. Teams making this shift often start by auditing how today’s tickets reference CIs at all, a gap covered in How Does Virima Connect ITSM Incident Management to CMDB? A Practical Guide.
Virima supports this pattern by syncing discovered CIs and relationships into existing ITSM workflows. Platform names stay as plain references here: ServiceNow, Jira Service Management, Ivanti, HaloITSM, Xurrent, and Hornbill teams each keep their desk while reading the same CI truth. One integration reference covers the path: the integrations hub lists the supported ITSM sync options.
Keep the data flow one-directional at first. Discovery sources the CMDB, the CMDB feeds the desk, and manual edits stay fenced behind review. That order keeps audit evidence anchored to observed data.
How should NIS2 asset data reach the service desk?
Sync discovered CIs and relationships into incident and change workflows so agents and approvers read the same record. Keep discovery as the source and fence manual edits behind review. One-directional flow keeps evidence anchored to observed data.
Where to start: one telemetry path, then expand
Start with one path. Pick one grid zone, one carrier segment, and the enterprise services behind both. Name one owner from each side, energy operations and telecom network engineering, before the pilot starts. Skip that owner assignment and the pilot repeats the opening problem: two accurate records with no one accountable for the link between them.
Run the first cycle in four steps:
- Discover the full chain
- Define the service
- Map the dependencies
- Run incident and change work from that map for one full cycle
Measure three outcomes before expanding. Check whether incident tickets link to the right CI on first touch. Check whether change reviews name cross-sector impact without extra calls. Check whether the service map matches the estate at cycle end. Expand path by path only when all three hold.
Teams scoping that first path internally can apply the three-proof framework above — completeness, linkage, and freshness — before bringing in outside support.
Build the evidence map before the next incident tests it
Incident clocks do not wait for inventory projects. Reporting windows, restoration pressure, and regulator questions arrive on their own timetable. That’s the timetable national authorities already supervise essential entities under — laws already in force, not a future deadline.
Waiting for the next scheduled audit to start mapping these dependencies leaves the gap open exactly when it matters most. The operators that read one shared visibility map before that hour will brief faster and restore with more care than teams that assemble evidence by phone. Build the joint layer now, prove it on one path, and expand while verification dates stay fresh — that’s NIS2 asset visibility for Madrid energy and telecom critical infrastructure in practice, not a future compliance project.
Frequently Asked Questions
How is NIS2 asset visibility different from a standard inventory?
A standard inventory lists owned assets. NIS2 visibility adds service linkage, ownership, and verification dates, so each asset supports incident evidence and risk management duties.
Does Virima integrate with ServiceNow or Jira Service Management for NIS2 evidence?
Yes. Virima syncs discovered CIs and relationships into ServiceNow, Jira Service Management, Ivanti, HaloITSM, Xurrent, and Hornbill so incident and change workflows read the same evidence record discovery produces.
Do service maps update when infrastructure changes?
Maps stay current as discovered infrastructure changes, once service definitions are provided. Definitions come from manual entry, spreadsheet import, or architecture input, and map building runs automatically.
Can NIS2 evidence feed our existing ITSM?
Yes. Discovered CIs and relationships sync into incident and change workflows so agents and approvers read the same record. Keep discovery as the source during rollout.
How does Virima support NIS2 asset visibility work?
Virima reconciles multi-source discovery into authoritative CI records, builds service dependency maps from provided definitions, and syncs that context into ITSM workflows for incident and change decisions.
What happens if OT and IT inventories disagree during an audit?
Auditors treat the mismatch itself as a finding, not only the asset it affects. Reconciling both records to one shared CI, with a named owner and a verification date, closes the finding and the underlying coverage gap at the same time.
