How Consultants Audit Enterprise Network Security

Authorization and scope come first

Nothing technical happens until three documents exist. This is not process theater — testing a system you were not authorized to test can be unlawful, and an audit whose scope was never agreed produces findings the client can dismiss.

• A written authorization naming who approved the work, signed by someone with authority to approve it.
• A scope definition listing address ranges, systems, applications, cloud accounts and physical sites that are in scope — and explicitly what is out.
• Rules of engagement: permitted techniques, testing windows, escalation contacts, and what happens if the audit causes an outage or discovers an active compromise.

That last clause matters more than it sounds. An enterprise network security audit occasionally finds an intrusion already in progress, and the response to that is an incident, not a finding. Agree in advance who is called, how, and whether testing stops.

Third-party systems need separate consideration. A cloud provider or SaaS vendor sits outside your client’s authority to authorize, so testing against them requires their own permission or must be limited to configuration review.

Discovery: the inventory nobody has

Almost every engagement begins by discovering that the asset inventory is incomplete. This is the single most common material finding, and it is a finding rather than a preliminary — you cannot protect or monitor what nobody knows exists.

Discovery combines three passes. Documented: whatever inventory, network diagram and cloud account list the client can produce. Observed: what is actually reachable and responding, from inside and outside. Inferred: what the logs, identity provider and billing records imply exists.

The gaps between those three lists are the output. Forgotten test environments with production data, decommissioned-on-paper systems still answering, shadow cloud accounts on a personal card, and vendor-managed appliances nobody has credentials for are the recurring discoveries.

Configuration review versus testing

These are different activities producing different confidence, and conflating them is why clients sometimes believe they bought something they did not.

The last row deserves attention. Most audits examine preventive controls thoroughly and detection barely at all, yet the question “would we have seen this” is usually more decisive than “could this have been prevented.”

The seven areas examined

1. Perimeter and segmentation. What is exposed externally, and whether internal networks are separated or flat. Flat networks turn one compromise into all of them.
2. Identity and access. Multi-factor coverage, privileged account count, dormant accounts, service accounts with standing credentials, joiner-mover-leaver process.
3. Patch and configuration state. Unsupported operating systems, unpatched appliances, default credentials, management interfaces reachable from the internet.
4. Remote access. How staff and vendors connect, and whether access is per-application or per-network — the distinction our zero trust explainer covers.
5. Logging and monitoring. What is collected, where it is stored, retention, and whether anyone reviews it.
6. Backup and recovery. Whether backups exist, are offline or immutable, and have ever been restored.
7. Vendor and third-party access. Who else can reach the network, with what privileges, reviewed how often.

Findings that get fixed

A finding that does not get remediated was a wasted engagement, and the difference is almost entirely in how it is written. Every finding should carry five elements: what was observed, the evidence, why it matters in this client’s context, a severity with stated reasoning, and a specific remediation.

Two habits raise remediation rates sharply. Rank by exploitability and impact together, not by scanner severity — a medium-severity issue on an internet-facing system beats a critical one on an isolated test box. And name an owner and an effort estimate for each item, because findings without an owner become a document rather than a plan.

Separate quick wins explicitly. An enterprise network security audit that hands over sixty items ranked purely by severity gets ignored; one that opens with five things fixable this week builds the momentum to address the rest.

Deliverables and follow-up

An enterprise network security audit closes with three documents for three audiences. An executive summary of two pages stating overall posture, the three things that most need money or decisions, and what changed since the last audit. A technical report with full findings and evidence. And a remediation plan as a tracked list with owners, effort and dates.

Then schedule the retest before leaving. An audit is a point-in-time measurement, and its value compounds only if the next one can compare against it. Agreeing a retest date at handover is what turns a report into a program — and it is the single most reliable predictor of whether the findings get closed.