On a Monday morning, IP telephony goes down at a remote site for two hours. The provider diagnoses a saturated switch, installed three years earlier without documentation. This type of failure, often avoidable, illustrates how an IT network audit is not just about ticking boxes: it seeks out the blind spots that daily operations tend to obscure.
Shadow IT and uninventoryed equipment: the real starting point of a network audit
Articles on network audits often begin by defining the scope. In practice, the scope is constantly shifting. IP cameras connected by the maintenance service, a Wi-Fi access point added in an open space, a personal NAS connected to the office VLAN: these “shadow IT” devices escape the official inventory.
Related reading : News and Essential Tips to Boost Your Business Development
Before even launching a vulnerability scan, time is saved by performing a physical and logical sweep of all active ports. This means checking the patch panels, noting the actual connections, and then cross-referencing with ARP tables and DHCP logs. The gap between the two lists measures the shadow IT present on the network.
This discovery phase is all the more critical as hybrid environments (physical sites, cloud, remote work) multiply entry points. Since 2023, feedback has shown a significant increase in incidents related to uninventoryed IoT devices. You can delve deeper into IT network auditing with E-novateur to structure this initial mapping step.
Read also : All the Essential Tools to Easily Create and Grow Your Online Presence
Mapping inter-site and multi-cloud flows: a step often rushed
Most network audits correctly document the LAN. Flows between remote sites, between the data center and cloud providers, or between two distinct cloud environments are much less frequently traced.
Mapping inter-cloud flows before testing security prevents discovering at the end of the audit that a site-to-site VPN tunnel is still using outdated encryption, or that a direct peering between two cloud providers is not monitored by any probes.
What the mapping should concretely cover
- WAN and SD-WAN connections between each site, with actual measured bandwidths (not just contractual bandwidths)
- Application flows to critical SaaS services (messaging, ERP, telephony), identifying routing paths and Internet exit points
- Cloud-to-cloud and cloud-to-on-premise interconnections, with verification of segmentation rules and filtering policies applied to each gateway
Tools like NDR (Network Detection and Response) or SASE platforms provide this visibility. It depends on the setup: a single-site SME with one cloud tenant does not need the same tools as a multi-site group.
Network audit and NIS2 compliance: what the directive changes in practice
The European NIS2 directive, whose national transposition started in 2024, requires entities classified as “essential” or “important” to demonstrate regular monitoring of their networks with traceability of audits. In practical terms, this means that a one-off audit conducted once every three years is no longer sufficient.
NIS2 requires documented action plans after each audit, with follow-up on remediations. For a company conducting its first audit, the challenge is to produce a deliverable that is usable by both management and the technical team.
Structuring the report to meet regulatory requirements
The audit report must contain at least three distinct elements:
- An up-to-date inventory of network assets (hardware, software, configurations), timestamped and signed
- A matrix of identified vulnerabilities, categorized by criticality, with a technical recommendation for each and a proposed correction timeline
- A prioritized remediation plan, validated by an identified responsible person, with quarterly follow-up milestones
This formality may seem burdensome for an SME. It’s better to have a short and actionable document than an 80-page report that is never read. We recommend separating the decision-making summary (maximum two pages, intended for management) from the technical details (annexes structured by equipment category).
Network segmentation tests: verifying what the firewall actually allows through
Configuring VLANs and filtering rules guarantees nothing if no one checks their actual effectiveness. We regularly observe “any-any” rules left in place after a migration, or temporary exceptions that have become permanent.
Testing segmentation involves simulating lateral movement from a standard user workstation to sensitive subnets (servers, administration, IoT). If a workstation on the office VLAN can reach the management interface of a core network switch, the segmentation has failed, regardless of the documented policy.
This test can be conducted with simple tools (Nmap, Netcat) or with automated pentesting solutions. The goal is not to produce a report of hundreds of scanned ports, but to answer a binary question for each zone: does the segmentation work or not.
Prioritizing corrections after tests
Not all segmentation flaws have the same impact. Communication between the printer VLAN and the file server VLAN presents a moderate risk. Direct access from the guest Wi-Fi to the administration network represents a critical flaw that should be prioritized for correction.
The classic trap is to want to correct everything simultaneously. This can block legitimate flows and generate cascading incident tickets. The most reliable sequence is to first correct access to the network administration, then flows to sensitive data, and finally secondary inter-VLAN communications.
A successful network audit is not measured by the number of pages in the report, but by the number of corrections actually applied three months later. The most useful deliverable remains a tracking table shared between the IT department and management, updated at each milestone, with a clear status for each identified vulnerability.