A server that responds slowly, a workstation connecting to an unknown IP address at night, a firewall whose rules haven’t been reviewed by anyone in two years. These weak signals often go unnoticed until the day an intrusion turns them into a crisis. The network security audit exists to identify these vulnerabilities before an attacker does. However, one must know what to audit, with what tools, and especially in what order.
Network Supply Chain: The Perimeter Most Audits Overlook
Have you ever checked who actually manages your MPLS links or your SD-WAN access? The NIS2 directive, which has now been transposed into French law and concerns a wide range of entities, requires verifying the contractual and technical security conditions with telecom operators, managed service providers (MSP/MSSP), and cloud or network equipment suppliers.
Related reading : Everything You Need to Know About Buying a Home through Rent-to-Own: Guide and Practical Tips
In practical terms, a network audit compliant with NIS2 is no longer limited to scanning your own machines. It must also examine the remote access of your subcontractors, the firmware updates of your operator routers, and the incident notification clauses in your contracts. Auditing the network supply chain has become mandatory, not optional.
To structure this approach, the network security audit with E-novateur outlines a methodical framework that incorporates these supplier requirements from the scoping phase.
Read also : Essential Steps for Successfully Dividing a Property in Co-ownership
Technical Scoping of the Network Audit: Defining What We Really Test
Before launching any scan, one must answer a simple question: what is the exact scope? Even a modest corporate network comprises heterogeneous layers. Guest Wi-Fi, business VLANs, VPN access for remote employees, APIs exposed on the internet. Each of these segments presents different vulnerabilities.
Asset Inventory and Mapping
The first concrete action is to create a comprehensive inventory. This includes listing every active device (switches, firewalls, Wi-Fi access points, servers), every external link, and every exposed service. Without this mapping, the rest of the audit relies on assumptions.
- List active public and private IP addresses, cross-referencing DNS, DHCP, and ARP tables from switches.
- Identify unmanaged devices (shadow IT): network printers, IP cameras, connected objects plugged in without validation.
- Document inter-site flows and VPN tunnels, including those opened temporarily and never closed.
An incomplete inventory produces an incomplete audit. If a network segment escapes the scope, its vulnerabilities will remain invisible in the final report.
Setting Measurable Objectives
An audit can aim for regulatory compliance (NIS2, GDPR), preparation for a penetration test, or simply assessing the level of protection after an infrastructure change. Mixing these objectives in the same exercise dilutes the results. It is better to have an audit focused on network segmentation than a broad overview of the entire information system.
Network Vulnerability Analysis: Scanning is Not Enough
Automated scanning tools (Nessus, OpenVAS, Qualys) detect known vulnerabilities by comparing software versions to vulnerability databases. This is a necessary step, but insufficient if it remains isolated.
A vulnerability scan detects known flaws, not configuration errors. An up-to-date firewall can very well allow unfiltered outgoing traffic to any destination. A switch may have the SNMP protocol enabled with the default community “public.” These errors do not always show up in a standard scan report.
Manual Review of Configurations
This is where the audit gains its value. An auditor examines the firewall filtering rules line by line, checks VLAN segmentation, reviews access control lists (ACLs), and ensures that obsolete protocols (Telnet, SNMPv1, unencrypted FTP) are disabled.
NIS2 adds an additional dimension: the audit must also assess the incident detection capability. Are the logs centralized? Do the correlation alerts work? A simple test is to simulate abnormal behavior (connection from an unusual geolocation) and check if the SIEM or monitoring tool generates an alert.
Network Audit Report and Remediation Plan: Turning Findings into Actions
An audit report that lists vulnerabilities without prioritization ends up in a drawer. The real value of the deliverable lies in the risk hierarchy and the corrective roadmap.
- Classify each vulnerability by criticality by cross-referencing its technical severity (CVSS score when available) and its actual exposure in the network architecture.
- Propose corrective actions with a realistic timeline: address critical flaws exposed on the internet first, governance improvements next.
- Identify fixes that depend on third parties (telecom operator, firmware vendor) and anticipate contractual timelines.
- Schedule a follow-up audit date to verify that the remediations have been applied, not just planned.
An audit without follow-up remediation does not reduce risk. The NIS2 gap analysis also requires regular reassessment of the effectiveness of measures, which implies scheduling recurring audits, not just one-off ones.
Governance and Internal Responsibilities
Who is responsible for the fixes after the audit? In many SMEs, the answer remains unclear. The report should name a responsible person for each corrective action and establish a validation circuit. Without this governance, recommendations remain unheeded, even when they are technically relevant.
The network security audit is not a one-time exercise to check off a compliance list. It is a process that starts with mapping the actual scope (including suppliers), goes through a technical analysis combining automated scans and manual reviews, and only produces results if the remediation plan is followed through to completion. The next NIS2 regulatory deadline is approaching: it is better to audit now than to patch up after an incident.