Something fundamental shifted in European IT over the last two years: data residency and operational accountability stopped being a procurement checkbox and became core risk management. CIO.com recently covered the result — telcos across Europe repositioning themselves as sovereign AI factories, built specifically to satisfy the NIS2 Directive and the EU AI Act, because enterprises operating under strict regulatory jurisdictions can no longer park their core infrastructure on generic public clouds and call it compliant.
You can read that as a telco market story. If you run a network, you should read it as a warning: the legal assumption underneath it now applies to everyone in scope. Regulators assume your organization knows what is connected to its network right now — not last quarter — and that you can produce a credible account of any incident within 24 hours of detection.
Most IT teams can't do that. Not because the team is bad at its job, but because the tooling was never built for it. The RMM shows every agent green. The monitoring tool polls the 40 devices somebody configured in 2022. And the real network — the forgotten switch in the warehouse closet, the IP camera somebody mounted last March, the second firewall interface nobody documented — lives in a Visio file that was accurate for approximately six weeks.
This post is about closing that gap before an auditor, or a 2 a.m. outage, closes it for you.
What NIS2 Actually Demands From a Network Team
Strip away the legal language and NIS2 asks two things of IT operations:
Know your assets. Article 21 requires risk management measures covering network security, incident handling, and — implicitly — asset management. You cannot run a risk assessment on devices you don't know exist. The printers, IP cameras, access points, and unmanaged endpoints on your VLANs are all in scope.
Report fast, with scope. Article 23 sets the clocks: an early warning within 24 hours of awareness, a detailed incident notification within 72 hours, and a final report within a month. Here's the part that stings: a 24-hour early warning is useless without scope. "Something happened, we're not sure what or where" is not a report — it's an admission that you can't see your own network.
And this reaches MSPs directly: managed network and security service providers are themselves in scope as important entities, and their clients' supply-chain obligations flow straight through them. If you manage client networks, your visibility problem is now a compliance surface for every client you serve.
Where the Tooling Falls Apart
The average mid-size IT shop runs some combination of agent-based RMM (NinjaOne, ConnectWise RMM, Datto RMM), standalone monitoring (PRTG, Zabbix, SolarWinds), a separate helpdesk, and network documentation in Visio or a wiki. Each one has the same structural blind spot, just in different places:
- Agent-based RMM sees managed endpoints only. It's excellent on servers and workstations with agents installed — and completely blind to switches, firewalls, access points, printers, IP cameras, and anything else without an agent. This is why your RMM reports all systems operational while an entire branch sits offline behind a dead switch. The agents are fine. The network under them isn't.
- Scheduled discovery produces snapshots, not state. Nightly or weekly scanners catch a new device eventually — and keep reporting devices that were decommissioned weeks ago. A device plugged in on Tuesday is invisible until the next scan, and an inventory pulled from a quarterly scan is stale the day after it's generated.
- Standalone monitoring polls only what someone added. Sensor licensing means most teams deliberately monitor a subset of the network. And without topology relationships, an alert says "192.168.10.50 unreachable" — not "unreachable because its uplink port on SW-FLOOR-3 died." The root-cause device is usually the one nobody thought to monitor.
- Documentation is manual, so it rots. Visio diagrams describe the network as it looked during one motivated week. Nobody updates them during a firefight, and the map that would have saved you 90 minutes during the outage is the one nobody maintained.
- The helpdesk finds out last. With no integration between monitoring and ticketing, your users become the monitoring system. One flapping uplink generates thirty "the internet is slow" tickets before anyone correlates them.
What that costs in real terms
Tuesday, 9:40 a.m. A branch switch dies quietly.
Without live topology: the first signal is a user ticket at 9:52. You remote in, check the server (fine), check the ISP (fine), start pinging things by hand, walk someone through checking link lights on a switch in a closet, and around 11:15 you've finally scoped it: 12 workstations, a label printer, and a camera down. That's roughly 95 minutes to answer a question a topology map answers in five seconds — while the 24-hour compliance clock is running and you're reconstructing scope from memory.
With live topology: the alert fires at 9:41 — "SW-BRANCH-02 unreachable, 12 downstream devices affected" — an auto-created ticket already contains the context, and you're shipping a replacement switch while the phone is still ringing. The users' tickets become confirmations instead of discoveries.
The downstream effects compound: longer downtime, ticket floods that bury real issues, technicians burning their morning on triage an alert should have done, and — the quiet one — an audit where the best network asset inventory you can produce is a spreadsheet from 14 months ago. That's a finding, and findings become remediation plans, and remediation plans become your Q3.
How AlertMonitor Turns the Network Into a Live, Auditable System
This is exactly the gap AlertMonitor's network visibility layer is built to close.
Continuous discovery, not scheduled scans. AlertMonitor continuously discovers every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. It runs constantly, not nightly. A device that appears at 2 p.m. is on the map at 2 p.m.
A topology map that reflects reality. The live map always shows the network as it is right now. When a switch goes offline or a link drops, the map updates and an alert fires instantly with full network context: which device, where it sits in the topology, and what's downstream of it. You get impact scope with the alert, not three tool-hops later.
New-device alerts. An unknown MAC appearing on a VLAN fires an alert with switch, port, and VLAN context. The rogue access point, the personal laptop on the wrong network, the camera nobody logged — caught when they plug in, not at the next quarterly review.
The alert becomes the incident record. Because monitoring and helpdesk live in the same platform, a network alert auto-creates a ticket carrying the topology context. The technician works from one pane: the map, the affected devices, the ticket, and the timeline. When the 72-hour NIS2 notification is due, the evidence is an exported alert timeline — not reconstructed memory.
One NOC view for MSPs. Per-client topologies under a single dashboard, with alert policies tuned per client. Fifteen client environments, one pane, no tab sprawl across five tools.
Compare the workflows directly:
- Old way: user ticket → remote session → manual tracing → closet visit → update a diagram nobody reads.
- AlertMonitor way: alert with scope → auto-ticket → fix from the map → timeline exported as incident documentation.
Teams running this pattern typically take incident scoping from 60–120 minutes down to minutes, cut the duplicate "is the internet down?" tickets because IT already announced the issue, and walk into audits with evidence generated automatically instead of assembled in a panic.
What You Can Do This Week
You don't need to wait for a platform rollout to start closing the visibility gap. Here's a practical starting sequence.
1. Baseline what's actually live on a subnet
Run a sweep and export IP/MAC pairs. This CSV is also your first artifact of audit evidence — dated, machine-generated, reproducible:
# Sweep a /24 and export IP/MAC pairs as an asset-inventory snapshot
$subnet = "192.168.10"
$arp = arp -a
$liveIPs = foreach ($i in 1..254) {
$ip = "$subnet.$i"
if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip }
}
$inventory = foreach ($ip in $liveIPs) {
$line = $arp | Select-String ([regex]::Escape($ip))
[PSCustomObject]@{
IPAddress = $ip
MACAddress = $(if ($line) { ($line.ToString() -split '\s+')[-2] } else { "unknown" })
FirstSeen = (Get-Date -Format "yyyy-MM-dd HH:mm")
}
}
$inventory | Sort-Object IPAddress |
Export-Csv "C:\Audit\subnet-$subnet-$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
Write-Host "Discovered $($inventory.Count) live devices on $subnet.0/24"
On a Linux jump box, the equivalent sweep is a one-liner:
sudo nmap -sn 192.168.10.0/24 -oG - | awk '/Up$/{print $2}'
2. Hunt the devices your RMM will never see
Diff your current ARP entries against a known-device baseline. Anything new gets flagged immediately:
# Flag ARP entries that are NOT in your known-device baseline
$known = Import-Csv "C:\Audit\known-devices.csv"
$current = Get-NetNeighbor -State Reachable,Stale |
Where-Object { $_.IPAddress -like "192.168.10.*" -and $_.LinkLayerAddress } |
Select-Object IPAddress,
@{n = "MACAddress"; e = { ($_.LinkLayerAddress -replace '-', ':').ToUpper() }}
$newDevices = $current | Where-Object { $_.MACAddress -notin $known.MACAddress }
if ($newDevices) {
$newDevices | Export-Csv "C:\Audit\new-devices-$(Get-Date -Format yyyyMMdd-HHmm).csv" -NoTypeInformation
Write-Warning "$($newDevices.Count) unknown device(s) on VLAN 10 - review before this becomes an incident report."
} else {
Write-Host "No unknown devices. Baseline still matches reality."
}
Run this manually today and you'll usually find at least one device nobody documented. That's the point.
3. Verify your monitoring inputs before you depend on them
Dead SNMP on a core switch means blind monitoring exactly when you need eyes. Check it now, not during the outage:
# Verify SNMP actually answers on your network gear
DEVICES="192.168.1.1 192.168.1.2 192.168.1.5"
COMMUNITY="YourCommunityHere"
for ip in $DEVICES; do
if snmpget -v2c -c "$COMMUNITY" -t 2 -r 1 "$ip" sysName.0 >/dev/null 2>&1; then
echo "$ip: SNMP OK"
else
echo "$ip: SNMP NOT RESPONDING - fix this before you depend on it"
fi
done
4. Make the map live — then retire the Visio
Once you've baselined manually, stop doing it by hand. In AlertMonitor:
- Enable continuous discovery on each site — SNMP, ARP, and active scanning cover the switches, APs, printers, and cameras your RMM agents can't see.
- Set new-device alert policies per VLAN, so an unknown device pages you the moment it appears — not at the next quarterly scan.
- Connect network alerts to the helpdesk, so every topology event opens a ticket with context already attached.
- Declare the live topology map your source of truth, archive the Visio file, and use exported alert timelines as your standing incident documentation.
For MSPs: repeat per client, tune alert thresholds per environment, and review each client's topology dashboard as part of your regular client rhythm — the same review that doubles as NIS2 evidence.
The Sovereignty Story Ends at Your Switch
The telcos building sovereign AI factories are making a simple bet: regulators will increasingly reward organizations that can prove what runs where, inside which borders, under whose control. That bet lands on your desk as something more mundane and more urgent — can you see every device on your network right now, and can you prove what happened within 24 hours of it happening?
If the honest answer currently lives in a Visio file and a quarterly scan report, the gap is fixable this quarter. Make the map live before someone with regulatory authority asks to see it.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.