How to Audit Your Network: A Practical Infrastructure Audit Guide

Most networks are not what their documentation says they are. Devices get racked without a record, IP addresses get reassigned without a reservation update, cables get repatched without a diagram change, and the gap between what is documented and what is actually live grows quietly until an outage, an onboarding mistake, or a compliance request forces someone to reconcile it under pressure. A network audit is the deliberate version of that reconciliation: a structured review of what is really connected, whether your records match reality, and which controls are working as intended.

This guide walks through a practical infrastructure audit from start to finish. It covers the device inventory, IP address and VLAN verification, security controls, the physical layer, and the documentation drift that almost every audit exposes, then shows how to turn the findings into a repeatable process instead of a one time event. You do not need a compliance mandate to benefit from an audit, though SOC 2, ISO 27001, and the NIST Cybersecurity Framework give you a vocabulary and a control catalog if you have one. What you need is a method, a checklist, and a place to record what you find.

What a Network Audit Covers

An infrastructure audit compares two things: what you believe you have and what is actually running. Most of the work is verification, not discovery. You take each area of your infrastructure, pull the documented state, check it against live data, and record every difference as a finding. The areas rarely change between audits: the device inventory, IP addressing and VLAN configuration, security controls, the physical layer, and the documentation itself. Each area has a natural source of truth, and the audit is only as strong as the weakest of those sources.

Compliance frameworks are useful here because they tell you how deep to go. NIST CSF 2.0 organizes the work around Identify, Protect, Detect, Respond, and Recover. CIS Controls v8 prioritizes a smaller set of safeguards, starting with asset inventory and secure configuration. ISO 27001 and SOC 2 ask for evidence that controls exist, are implemented, and are reviewed on a schedule. If you answer to any of these, the audit produces the evidence pack. If you do not, the same structure still works, because a network that is undocumented is unmanageable whether or not an auditor is watching.

Build the Device Inventory First

The inventory is the foundation of every other audit step, because you cannot verify records for devices you do not know exist. Start with what you already have. If your team keeps its records in Obelinf, the device inventory is the baseline, and the audit becomes a comparison instead of a reconstruction. Teams without a central record usually begin by scanning the network with tools that enumerate hosts, SNMP agents, ARP tables, and DHCP leases, then merge the results into one list. However you build it, the goal is a single entry per real device, with make, model, serial number, firmware version, role, owner, and physical location attached.

The inventory step is where shadow IT surfaces. Shadow IT is any device that is live on the network but missing from your records: a server a team racked on its own, a wireless access point installed for a conference, an IoT sensor that joined the building network. These devices are a security finding before they are a documentation finding, because nobody has reviewed their firmware, patching, or exposure. When discovery finds a device with no record, the correct outcome is not always deletion, but it is always a decision: add it, quarantine it, or decommission it, and record which.

Firmware and end of life status belong in the same pass. A switch that is still running the firmware it shipped with, or a firewall model that has left vendor support, is a finding even when the rest of the device record is perfect. Most compliance frameworks want proof that the inventory is complete and reviewed, which means the inventory needs an owner, a review date, and a changelog. If the last update to the inventory predates the last three hiring rounds, the inventory itself is the top finding of the audit.

Verify IP Addresses, Subnets, and VLANs

Addressing is where records and reality drift fastest, because IP space is shared, mutable, and rarely owned by a single person. Pull your IP address management records, then compare them against live evidence: static assignments on devices, DHCP lease tables, DNS records, and ARP entries. The questions are mechanical. Are there IPs in use with no reservation? Are there reservations for devices that no longer exist? Do any two devices hold the same address? Each yes is a finding, and each finding has a fix, which is why the IP address management record you audit against matters as much as the audit itself.

VLANs need the same treatment at Layer 2. A VLAN that is configured on your access switches but absent from your records is drift. So is a VLAN that exists in the records but only on half the switches it should span, and so is a VLAN that carries traffic the segmentation policy does not account for. The audit checks three things per VLAN: that it is recorded, that it is configured consistently across the switches that need it, and that the hosts in it match the intended purpose. Subnet utilization belongs here too, because an audit is a natural moment to find the exhausted pool that was quietly handed out in small chunks, and the half empty block that should have been reclaimed.

DNS and DHCP round out the addressing review. Stale DNS records point at retired servers. DHCP scopes with mismatched reservations strand devices on the wrong subnet, and lease times that exceed the device churn rate leave addresses unavailable for days. None of these are dramatic failures, but together they are the difference between an address plan that holds together under pressure and one that starts leaking the moment a new site goes live. Record every discrepancy with the evidence you found, and close each one with a decision rather than a note to check later.

Review Security Controls

The security pass verifies that the controls you believe are in place are actually in place. Firewall rules come first, because rule bases grow faster than they are pruned: check every rule for an owner, a purpose, and a review date, and flag rules that are shadowed, obsolete, or wider than the policy allows. Administrative access is the second priority. Who can log into your switches and firewalls, what authentication do those logins require, and how many of the accounts still belong to people who work here? Shared credentials, local accounts without expiration, and management interfaces reachable from the user network are the findings that recur in almost every audit.

Firmware and patch status is the control that couples the security review to the inventory you built earlier. Devices running versions with known vulnerabilities, or hardware that has passed end of support, need to appear in the report with an owner and a timeline, because an audit finding without an owner is a recommendation, not a fix. Segmentation deserves its own check: the VLANs you verified in the addressing pass should actually separate the traffic they are supposed to separate, and any jump host, management path, or guest network that bypasses the segmentation policy is a finding in its own right.

Be clear about what this pass is and is not. A network audit verifies configuration and record keeping; it does not actively attack the network. Probing for exploitable weaknesses is a vulnerability assessment, a separate exercise with separate tools and expectations. Run both if your risk profile demands it, but an audit should tell you whether your network is managed as you believe it is, which is the question most compliance programs actually ask. A rule base with owners, a patched fleet with a documented baseline, and administrative access that is enforced and reviewed answers that question.

Walk the Physical Layer

The physical layer is the part of the audit that happens in the room rather than at a terminal. Walk every rack and compare what you see with the records: is the server in this position the server the elevation drawing says should be here, and is the cable in this port the cable the cable tracking records say it is? Labels carry most of the weight. A patch panel with labeled ports, a rack with labeled units, and cables with labeled endpoints make the walk a verification pass. Unlabeled panels turn the same walk into detective work, and every ambiguous cable becomes a decision to trust the record or trust your eyes.

Power belongs in the physical pass because it is the failure mode nobody documents until it happens. Check that every device has a documented power feed, that the PDU and circuit records match what is plugged in, and that no rack is carrying more load than its feed is rated for. Redundancy claims deserve special attention: a server that is supposed to be dual fed but is actually single corded is a resilience finding that an audit is uniquely positioned to catch, because it rarely shows up in monitoring until the feed fails.

A messy cabling environment is more than an aesthetic problem. It is a signal about the surrounding processes. Racks where cables are patched without a record usually coexist with IPs assigned without a reservation and VLANs created without a decision, because the same people skip the same documentation step everywhere. Fixing the physical layer is straightforward once it is visible: label, record, and trace each cable, update the rack elevation, and assign an owner to the room. The discipline that makes the room accurate is the discipline that keeps the rest of the audit honest.

Close the Documentation Drift

Documentation drift is the finding that contains all the others. When you compare your network topology diagrams with reality, the mismatches are the visible version of every record that fell behind: links drawn that no longer exist, links live that were never drawn, sites that appear on no diagram at all. The audit should end with the diagrams corrected, because a topology map is the document your team reaches for during an outage, and an outage is the worst possible time to discover the map is wrong.

The deeper question the drift section answers is whether your documentation can be trusted going forward, which is a question about process rather than files. If the network is documented in spreadsheets, drift is structural: there is no relationship between the row that records an IP and the device that holds it, and no mechanism to know when one changed without the other. If the documentation lives in a source of truth where records are linked, drift becomes visible at the moment it happens, because a device change surfaces the IPs, cables, and rack position connected to it. An audit against linked records also gets to check the audit trail itself: can you reconstruct what changed, when, and by whom? If you cannot, the records fail the audit even when they are currently accurate.

Every correction made during the audit needs an owner and a deadline, and every finding needs a status that is tracked to closure. An audit that produces a report and nothing else is an exercise in documentation, not a change in behavior. The closing pass of the audit is therefore the meeting where findings are assigned, not the slide that summarizes them, and the next audit should open by checking that the previous one’s findings are closed.

Set a Cadence and Make It Repeatable

An audit is a process, not an event. Run a full audit at least once a year, and quarterly if you operate under a compliance regime that demands review evidence. Trigger a targeted audit around major changes: a new site, a cloud migration, an acquisition, a change of colocation provider. The targeted audit covers only the affected areas but uses the same checklist and the same reporting format, so the results slot into the same record. Mature teams go further and layer continuous checks on top of the periodic audit, catching drift within days through monitoring and reconciliation rather than waiting for the quarterly pass.

The mechanics of repeatability matter as much as the schedule. Use a fixed checklist so nothing is forgotten and results are comparable between passes. Keep the checklist realistic: the toolkit’s network audit checklist walks through device inventory, VLAN and subnet verification, firewall rules, topology accuracy, DNS and DHCP health, monitoring coverage, configuration baselines, and end of life status in a sequence that maps to a day of work. Assign one owner for the audit, one for the report, and one for each finding. And write the report in a form that can be compared with last year’s, because the trend between audits is more informative than either audit on its own.

The cadence is where most teams either win or lose. An audit you can run in a day, because the records are current and the checklist is sharp, gets run. An audit that takes two weeks of reconstruction, because nothing was recorded since last year, gets postponed, and the postponement is how a network drifts from managed to unmanaged without anyone deciding to let it happen.

Your Audit Trail Lives in Obelinf

Obelinf is built for the audit that keeps happening instead of the one that keeps being planned. Every device, IP address, cable, VLAN, and rack position lives in one linked source of truth, so the audit starts from a complete picture instead of a pile of spreadsheets: the device inventory feeds the discovery pass, the IPAM and VLAN records feed the addressing pass, and the rack and cable records feed the physical walk. The changelog closes the loop that documentation drift normally exploits. Every create, update, and delete is recorded with the user and a timestamp, immutable once written, and every change shows the before and after values at field level, which means the question “what changed and who did it” has an answer you can point to instead of a memory.

The practical payoff is that the audit and the daily work become the same activity. When records are relational, reconciling one device surfaces its IPs, connections, and rack position in the same view, so the fixes an audit demands are the same actions a new engineer would take on their first day. When the audit trail is complete and queryable, the evidence a compliance auditor asks for is already written down, and the next audit opens by checking that the last one’s findings closed. Start at obelinf.com, run the inventory pass against your real network, and let the first gap you find tell you where the second audit needs to focus.