What the audit should help you decide
The audit should show how an attacker or a compromised account could move through the infrastructure. We look for situations where an Internet-facing service reaches too broad a zone, a user workstation reaches administration, a VPN exposes too many resources, a provider retains broad access, or a legacy rule allows an unnecessary flow.
The debrief should make clear which paths to close immediately, which flows to keep or reduce, where useful segmentation is needed, and which access paths or rules to revisit.
The output should produce architecture decisions and a remediation backlog, not only a list of open ports.
What do we review in the network and infrastructure?
Internet exposure and entry points
We check what an external actor can reach: IP addresses, published services, VPNs, external portals, reverse proxies, DNS, certificates, and administration interfaces. The goal is to distinguish required services from historical or overly permissive exposure.
Network segmentation
We review VLANs, subnets, user zones, servers, production, administration, backups, Wi-Fi, remote sites, and sensitive environments to understand how far a compromise could move. A compromised workstation should not automatically reach critical servers or backups.
Firewall rules and authorized flows
We review firewall rules, inter-zone flows, outbound access, temporary rules, and overly broad openings. The debrief distinguishes justified flows, flows to reduce, and flows that can disappear, including any / any equivalents that are no longer defensible.
VPN, remote access, and third parties
Remote access should provide exactly the resources required for the planned work. We review VPNs, MFA, reachable scope, access duration, authorized devices, maintenance access, and old connections without turning this review into a full IAM audit.
Privileged administration and admin networks
We review network consoles, firewalls, hypervisors, servers, bastions, SSH / RDP access, administration workstations, and authorized connection origins. Administration interfaces should not be reachable from ordinary user networks.
Network devices and configuration hardening
Depending on scope, we examine firewalls, routers, switches, Wi-Fi, VPN appliances, reverse proxies, load balancers, versions, administration protocols, local accounts, and unused services. We look for configurations that create unnecessary access, reduce traceability, or make lateral movement easier.
Logging and detection capability
After an incident, the organization should understand who connected, through which access, to which zone, and what changed. We review firewall and VPN logs, authentications, configuration changes, centralization, alerts, and retention.
Network audit or penetration test: what is the difference?
A network audit reviews architecture, rules, access, and how zones communicate. A penetration test deliberately attempts to exploit weaknesses within a defined scope to demonstrate an attack scenario.
An audit can recommend a targeted penetration test when exposure deserves offensive validation, but the two engagements do not pursue the same objective.
The scenarios we aim to prevent
A compromised workstation reaches critical servers
A user opens a malicious attachment. We check whether that compromise could then reach servers, administration, or backups.
Third-party access opens too many resources
A provider has a VPN to maintain an application. We check whether it reaches only the required components or also unrelated zones.
An old firewall rule remains active
A project temporarily required a port or access range. The audit checks whether that exception still exists and remains justified.
An administration interface remains exposed
A firewall, hypervisor, server, or network console is reachable from a zone that is too broad. A compromised account can then gain disproportionate control.
How does the network audit run?
01 — Scope and architecture
A 45-to-60-minute discussion with the CIO, CISO, infrastructure, network, and where needed managed services teams identifies sites, datacenters, cloud, VPNs, firewalls, critical environments, and external access.
02 — Mapping the real network
We compare diagrams, VLANs, IP ranges, VPNs, devices, flow lists, and interconnections with the configuration actually in place. A clean but old diagram is not proof of the current state.
03 — Configuration and access review
We prioritize configuration exports, read-only access, targeted captures, inventories, and logs. Full administrator access is requested only when the engagement genuinely requires it.
04 — Compromise-path analysis
We connect the gaps: an overly broad provider VPN, an accessible server network, a reachable administration interface, and a weakly protected technical account can form a critical scenario.
05 — Debrief and tradeoffs
A 60-to-90-minute meeting presents risk paths, exposures to close, rules to reduce, recommended segmentation, access to revisit, and structural workstreams.
How long does a network and infrastructure audit take?
A targeted audit of a mid-sized infrastructure usually represents around 8 to 12 business days of work, spread across two to three calendar weeks.
The workload depends on the number of sites, firewalls, segments, VPNs, interconnections, providers, and the quality of documentation. A large multi-site network can be split into waves to keep the output usable.
What do you receive after the audit?
Map of critical zones and flows
A readable representation of the main zones, interconnections, external access, sensitive networks, and administration paths.
Prioritized risk list
For each finding: affected asset or zone, risk, possible scenario, impact, priority, and recommendation.
Review of sensitive rules and access
We distinguish unjustified openings, overly broad rules, third-party access to reduce, poorly isolated administration interfaces, and flows requiring business validation.
Target architecture
Where needed, we propose segmentation, an administration zone, a bastion, user/server separation, a third-party zone, and inter-network filtering without over-designing a new network when a few fixes are enough.
30 / 60 / 90-day remediation plan
Within 30 days: close unnecessary exposure, remove obsolete access, and protect critical consoles. Within 60 days: revisit segmentation, VPNs, third-party access, and logging. Within 90 days and beyond: address administration architecture, segment redesign, device replacement, and stronger monitoring.
What leadership should be able to decide after the audit
The debrief should not leave leadership with a list of hundreds of network rules. It should make visible the decisions that genuinely reduce risk and the work that requires redesign.
Leadership should know whether there is a simple path between a user workstation and critical systems, whether a provider has more access than necessary, and whether backups or administration consoles are sufficiently isolated.
The debrief should also show which changes reduce risk fastest and which fixes can be made without significant interruption.
How can the infrastructure be secured after the audit?
Koragence can take on the fixes identified by the audit under a separate scope: firewall rule cleanup, segmentation, VPN restriction, reduced third-party access, administration hardening, a bastion, device hardening, logging, monitoring, and target architecture documentation.
To take over and operate the infrastructure, the DevOps and infrastructure page covers the complementary operational scope. Important environments can be handled in waves to avoid a disruptive switch.
When should you launch a network security audit?
The engagement is aimed at mid-sized companies, structured SMEs, groups, critical platforms, and multi-site organizations with several networks, firewalls, VPNs, providers, hybrid environments, or sensitive internal systems. It is not aimed at a very small business with an Internet box and a few workstations.
The engagement is particularly relevant when the network grew through successive additions, several sites, subsidiaries, or providers coexist, VPNs or firewall rules have never been reviewed, or an infrastructure migration or managed service change is planned.
It is also useful after an incident or suspected compromise, when documentation is outdated, when a hybrid environment exists, or when administration is reachable from several zones.
